- From: Thad C <inclusivethinking@gmail.com>
- Date: Sat, 17 Sep 2016 06:37:27 -0700
- To: Michael Pluke <Mike.Pluke@castle-consult.com>
- Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
- Message-ID: <CAOh2y+-Y25O+vf93n_eM=9Xf6Kur6vas-=QeJ=EzMJtuss4HOQ@mail.gmail.com>
Hi Mike, I will add other into the template for yo8. Best Thaddeus On Sep 17, 2016 2:00 AM, "Michael Pluke" <Mike.Pluke@castle-consult.com> wrote: > Hi > > I realise that I omitted an important paragraph that should have preceded > the last paragraph of the "Description" section. This is: > > "An alternative user authentication method is required to cope with users > who are temporarily or permanently unable to use the primary > user-authentication methods. One important situation where a user will be > unable to user the primary user authentication methods is if they do not > have a suitable trusted device or are not subscribed to or unable to access > the third-party services that are frequently part of user authentication > methods that meet the criteria for primary user-authentication methods." > > If there is a possibility to add this it would enhance the understanding > of why an alternative user-authentication method is required. > > Best regards > > Mike > > Sent using CloudMagic Email > <https://cloudmagic.com/k/d/mailapp?ct=ti&cv=7.9.8&pv=9.3.1&source=email_footer_2> > > On Fri, Sep 16, 2016 at 6:37 pm, Thad C <inclusivethinking@gmail.com> > wrote: > > Hi Mike, > > Yes, not a problem. Glad to help. > > Best, > Thaddeus > On Sep 16, 2016 10:02 AM, "Michael Pluke" <Mike.Pluke@castle-consult.com> > wrote: > >> Hi Thad >> >> >> >> Thank you for your kind offer to put my SC proposal into the template. >> >> >> >> The attached Word document is the best I have been able to do whilst in >> the conference with a badly depleting battery! >> >> >> >> I hope that you are able to handle it so that we can get to the WCAG WG. >> >> >> >> Best regards >> >> >> >> Mike >> >> New SC v2 <https://1drv.ms/w/s!AonHhdlMwzu_zFziFK13W1io4NZ8> >> >> OneDrive >> >> >> >> >> >> >> >> >> >> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com] >> *Sent:* 15 September 2016 19:51 >> *To:* Michael Pluke <Mike.Pluke@castle-consult.com> >> *Cc:* Thad C <inclusivethinking@gmail.com>; public-cognitive-a11y-tf < >> public-cognitive-a11y-tf@w3.org> >> *Subject:* Re: Re: what is the consensus? was RE: Argument to revert my >> "User authentication methods" success criteria to the pre-5th Sept COGA >> call version (with a small mod) >> >> >> >> Mike, could you put this in the draft template and I show it to wcag at >> tpac? They might have some interesting feedback >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Thu, 15 Sep 2016 20:52:43 +0300 *<**lisa.seeman@zoho.com* >> <lisa.seeman@zoho.com>*>* wrote ---- >> >> I think that could work but wonder if the second provision will not be >> come outdated soon after it gets to CR >> >> >> >> In which case maybe we want the following: >> >> >> >> >> >> If there maybe users who are unable to use the primary user >> authentication method an alternative method should be offered that >> ...(conforms to Option 2). >> >> >> >> That way the extra burned of an additional login expires as soon as the >> easy sign in becomes ubiquitous. we can explain it in the description >> section >> >> >> >> >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Thu, 15 Sep 2016 15:35:24 +0300 *Michael Pluke >> <Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* wrote >> ---- >> >> Hi Thad and Lisa >> >> >> >> Lack of good technology is not really my primary concern regarding Option >> 1. I think that quite good technology already exists to support user >> authentication methods that pose few problems for users with cognitive >> disabilities e.g. web services that support automatic login of Apple >> TouchID authenticated users as well as login via Facebook, Google, AppleID >> etc. I expect that these will increasingly become the PRIMARY method >> offered to users - leading to the apparent death of the password. All of >> these methods meet the rigorous Option 1 requirements - which I think can >> be more succinctly summarised as not requiring the user to memorise, recall >> or mentally process information. >> >> >> >> However all of these methods require some pre-conditions before a user >> can use them. The user approaching the service must have specific >> proprietary hardware configurations or be signed up to and logged in to a >> service recognised by the web service's user authentication method. A web >> service can, and several do, support multiple of these proprietary methods >> but there will always be people who are permanently (don't own the hardware >> or are not subscribed to the offered service(s)) or temporarily unable >> (dead battery on a key authentication device) to use the offered methods.. >> >> >> >> I think that this contrast between what would be best for users with >> cognitive disabilities (Option 1) and what a last-resort fallback solution >> (Option 2) should look like when the Option 1 solution won't work for a >> user (which is inevitable) is the cause of the strong Option 1/Option 2 >> divergence. >> >> >> >> Option 1 is the ideal form of user authentication to maximise the >> usability for all - the problem is there will be situations where users >> will be unable to use such a biometric/SSO/token solution. Option 2 >> describes the minimum requirements for a fallback method that those unable >> to use the Option 1 method should expect. I think that it is these >> completely different perspectives that is the cause of the strongly felt >> Option 1/Option 2 divergence. I believe that both perspectives are valid in >> their own context and that neither is sufficient to fully describe the >> requirement. >> >> >> >> Here is a suggestion of how I think that we can define a very robust and >> comprehensive success criterion that says (in terms of ideas rather than >> exact words): >> >> >> >> 1) The primary user authentication method offered to users should not >> require the user to memorise, recall or mentally process information. >> >> >> >> 2) For users who are unable to use the primary user authentication method >> an alternative method should be offered that ...(conforms to Option 2). >> >> >> >> Whereas I was not prepared to draft a simple Option 1 as I thought it had >> serious limitations, I would be happy to try to modify the success >> criterion to reflect this more sophisticated and realistic model. >> >> >> >> Does this option look OK to others? >> >> >> >> Best regards >> >> >> >> Mike >> >> >> >> >> >> Sent using CloudMagic Email >> <https://cloudmagic.com/k/d/mailapp?ct=ti&cv=7.9.8&pv=9.3.1&source=email_footer_2> >> >> >> >> On Wed, Sep 14, 2016 at 6:50 pm, Thad C <inclusivethinking@gmail.com> >> wrote: >> >> I vote for option #1 as it reflects the most collaborative effort of the >> purposed information. Sorry Mike I dont mean to dismiss your POV, expertise >> or hard work. I do think we need: >> >> "rewording to make it widely applicable, if the technology has not moved >> forward in the next 3 years such as another exception" >> >> That was my intention in providing the links that referenced articles on >> the future landscape of authentication models. >> >> On Sep 14, 2016 10:40 AM, "lisa.seeman" <lisa.seeman@zoho.com> wrote: >> >> Hi folks >> >> >> >> there have been arguments on both sides, and unfortunately I do not think >> we have the time to spend on this now. >> >> >> >> can we see what the consensus is >> >> >> >> *option 1:* go with the wording from the call three weeks ago. We can >> put some notes in the bottom of the proposal saying it may need some >> rewording to make it widely applicable, if the technology has not moved >> forward in the next 3 years such as another exception >> >> >> >> *option 2:* go with Mikes original wording ( the concern was that some >> mechanism for authentication were allowed that some coga users will not be >> able to use) >> >> >> >> *option 3:* continue the discussion >> >> >> >> Please write back with you preference >> >> >> >> (Mine is option 1) >> >> >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Wed, 14 Sep 2016 16:16:00 +0300 *<lisa.seeman@zoho.com >> <lisa.seeman@zoho.com>>* wrote ---- >> >> "they might accept an automatic login from an iPhone 5s or later to which >> the owner has authenticated themselves with Touch ID. But this option would >> still not help people who are trying to access the website from their PC.." >> >> >> >> Lisa comments - The idea was bluetooth tokens. By the time the this >> becomes a standard (in 3 years) it is very likely that this >> is common place and can be used by people who are trying to access the >> website from their PC. >> >> There is a concept of the user burden. They may need to have a the common >> accounts for third part sign in or an assistive technology - in this case >> that might be a phone that uses Bluetooth. >> >> >> >> Remembering in image is not an option for many users with an impaired >> visual memory and/or short term memory. It is a limited solution for a a >> subset of our users. >> >> >> >> >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Wed, 14 Sep 2016 16:06:02 +0300 *Michael >> Pluke<Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* >> wrote ---- >> >> Hi Lisa >> >> >> >> The issue paper may have been looking at things from a user perspective >> *only*. If, as a user, biometric identification is available to me then >> that is very convenient – but to the majority of users in many contexts >> that is not an option (i.e. those that don’t own a top-end smartphone or >> that are accessing a web service via a computer that does not have >> biometric identification support (most)). If I am lucky and also if the web >> service will trust the secure chip in the device to which I authenticated >> myself I have avoided all cognitive barriers. This is an ideal available to >> a minority of people in a minority of contexts. >> >> >> >> The success criterion has to consider what a web service can actually >> offer. A web service* cannot*, of itself, *offer biometric >> identification* as an option for its users. If, say, the British Airways >> website declared that it offered biometric user authentication as its >> alternative to its username and password option what would that actually >> mean? How could someone evaluating the website begin to understand or test >> that assertion? What feature would the evaluator look for on the British >> Airways site? >> >> >> >> A web service could, justifiably, claim to offer login from a trusted >> device as an alternative i.e. they might accept an automatic login from an >> iPhone 5s or later to which the owner has authenticated themselves with >> Touch ID. But this option would still not help people who are trying to >> access the website from their PC. Even when hybrid solutions like being >> able to use a trusted mobile device to authenticate to a service being >> accessed from a PC become more common, these will still be options that >> will not be available to the majority of users – and hence not a viable >> alternative to methods that persons with cognitive disabilities are unable >> to use. >> >> >> >> Where an alternative to potentially inaccessible methods is proposed it >> MUST be available to anyone accessing the service (not just to those owning >> suitable devices). An alternative that asks the user to identify their >> security image from a page containing a number of images will be usable by >> many people who find it impossible to remember usernames and awkward >> passwords. Such a method would be acceptable according to my original >> proposal but unacceptable according to Lisa’s revision. >> >> >> >> Such a method could still prove impossible for some people with, for >> example, advanced dementia whose ability to recognise or recall images had >> been seriously impaired. Providing an alternative cannot always be a >> guarantee that everyone who makes use of it can access the service. >> Attempting to ensure that the SC covers all severities of all cognitive >> disabilities has resulted in an SC that no service provider could say that >> they have met. >> >> >> >> Best regards >> >> >> >> Mike >> >> >> >> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com] >> *Sent:* 14 September 2016 10:57 >> *To:* Michael Pluke <Mike.Pluke@castle-consult.com> >> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org> >> *Subject:* RE: Argument to revert my "User authentication methods" >> success criteria to the pre-5th Sept COGA call version (with a small mod) >> >> >> >> From the issue paper it seemed that the group consensus is to recommend >> two authentication mechanism, one of which should be biometric or a token >> or other such suggestion. Until such time as a widely usable >> authentication method is available, no one is suggesting having only one >> alternative. >> >> >> >> Right now for capture, the visual user has one option, the non visual >> user has another option (audio). It is ok if one option meets some needs >> of some users, and the other option meets the needs of other users. It is >> the best we can do for now. >> >> >> >> To me that was clear from the language, but we can also make a language >> tweak to clarify that ideals like tokens or biometric is an acceptable >> alternative, although it does not need to be the only alternative to >> conform and sometimes having two access methods may be necessary to >> address issues you brought up. Hopefully at some point there will be a >> universal sign in, but until then more then one method is recommended. >> (This can go in the description) >> >> >> >> But perhaps I still do not understand. >> >> >> >> What scenarios would you see as acceptable ? >> >> >> >> >> >> >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Wed, 14 Sep 2016 11:41:40 +0300 *Michael >> Pluke<Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* >> wrote ---- >> >> Hi Lisa >> >> >> >> The fundamental reason that biometrics cannot be the (potential single) >> alternative method are, off the top of my head: >> >> >> >> - a person providing a web-based service is not in a position >> to offer this as an alternative. Biometric sensing is always something >> performed on a device and this will only ever be available on devices that >> have the necessary sensing devices (e.g. finger sensors, infrared “depth >> cameras”, etc.). >> >> - for security reasons matching the biometric measure to a >> template is (almost?) never done by a remote service, it is performed on >> the device – but only on a few high-end devices; >> >> - having a (potentially) single alternative method that is >> biometric will break the universally accepted rule that there should always >> be a non-biometric alternative (but I have already argued that all known >> alternatives except SSO will fail the SC – which leads into a circular >> logic that the SC demands and alternative – if that is biometric it also >> demands an alternative – all alternatives break the SC. >> >> >> >> It can be argued that it is a user choice not to use a commercial service >> to facilitate login to a service whose default login method is not >> accessible to the user. However, I am sure that this argument is totally >> against the spirit (and law?) of what constitutes an acceptable success >> criterion. Here are a few reasons: >> >> >> >> - many users may not have made a conscious decision to avoid >> Facebook as I have. When they encounter an inaccessible user authentication >> method they will be presented with an option to use a service to which they >> are not subscribed and which they maybe know nothing about. They will >> either be totally unable to use this alternative method or forced to >> sign-up to a service which they know too little about and had no previous >> need to use. This latter option is pretty unacceptable for all users and >> even more so for many people with cognitive disabilities who will be >> panicked by sudden surprises and uncertainty. >> >> - If it is acceptable that not owning a device or subscribing >> to a service can be dismissed as a “user choice”, then it might be possible >> to remove many WCAG success criteria because, say, an iPhone meets those >> criteria and it is a “user choice” not to own an iPhone. >> >> - Even if a “standardized third party sign in” can be >> universally agreed *and* *universally adopted* (a big IF that might be >> against the interests of Facebook and Google), it is still very doubtful >> that it would be acceptable to have a success criterion that only works >> properly if you assume that everyone is signed up to this service. >> >> >> >> As I tried to argue before, both of the above sets of arguments amount to >> the same thing: >> >> >> >> - I do not believe that it is acceptable to say you must >> provide an alternative unless you can be sure that this alternative will be >> available to everyone in all contexts. I believe that this is a quite >> fundamental aim of WCAG SCs and, as argued above, biometrics and SSO/social >> logins fail that criterion very badly! >> >> >> >> I believe that the your attempt to significantly broaden the scope of my >> restricted scope draft “User authentication methods” success criterion has >> broken it. One thing that characterises many WCAG Success Criteria is that >> they are short, simple and of quite limited scope. Broadening the scope (or >> reducing the scope to remove exceptions) almost inevitably reduces the >> universality of the success criterion and reduces its conformance level e.g. >> >> - 1.2.5 Audio Description (Prerecorded) [AA] - 1.2.7 Extended >> Audio Description (Prerecorded) [AAA] >> >> - 1.4.3 Contrast (Minimum) [AA] - 1.4.6 Contrast (Enhanced) >> [AAA] >> >> - 2.1.1 Keyboard [A] - 2.1.3 Keyboard (No Exception) [AAA] >> >> - 2.2.1 Timing Adjustable [A] - 2.2.3 No Timing [AAA] >> >> - 2.4.4 Link Purpose (In Context) [A] - 2.4.9 Link Purpose >> (Link Only) [AAA] >> >> - 2.4.6 Headings and Labels [A] - 2.4.10 Section Headings [AAA] >> >> - 3.3.4 Error Prevention (Legal, Financial, Data) [AA] - 3.3.6 >> Error Prevention (All) [AAA] >> >> >> >> I was not involved in the development of WCAG 2.0 but I wouldn’t be >> surprised to learn that there were very many success criterion candidates >> that didn’t make it to AAA because of an over-ambitious scope. In my view >> extending beyond my original idea, plus the proposed improvement of my 2 >> nd bullet to “processing presented or memorised information" is the only >> way to get an SC that can definitely reach level AA and maybe level A. >> >> >> >> Best regards >> >> >> >> Mike >> >> >> >> >> >> *From:* lisa.seeman [mailto:lisa.seeman@zoho.com] >> *Sent:* 14 September 2016 02:25 >> *To:* Michael Pluke <Mike.Pluke@castle-consult.com> >> *Cc:* public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org> >> *Subject:* Re: Argument to revert my "User authentication methods" >> success criteria to the pre-5th Sept COGA call version (with a small mod) >> >> >> >> Hi Mike >> >> >> >> The wording (before the bullets) are "*At least one user authentication >> method is offered that does not rely on a user's ability to:*" >> >> >> >> In other words we are asking people to offer an alternative - Such as a >> standard long complex password and Biometrics, or the long password AND a >> facebook or other sign in. Now you might not like the alternative >> (Biometrics or facebook) but it is available and hence the content is >> available, even to people who can not use long passwords. >> >> you wrote >> >> >> >> *"Biometrics fails at the first hurdle as it is widely accepted that >> there should always be a non-biometric alternative to biometric user >> authentication mechanisms"* >> >> >> >> Why would the combination of an hard password option and biometrics be an >> issue? >> >> >> >> Another option, for example was the third party sign in (facebook gmail >> etc) >> >> The user may not like the options being given because they can not use >> the long passwords and " avoid facebook with a passion" But the avoiding >> facebook , while understandable is a user choice, so the author of the >> content had provided an accessible option even if the user prefers not to >> use it. I have a gmail account that I only use for sign in's. >> >> >> >> Further, we can hope and encourage a standardized third party sign in >> that is only that - and helps the user long on anywhere. >> >> >> >> >> >> The other alternative Mike is to go back to the drawing board with the >> wording. >> >> >> >> >> >> All the best >> >> Lisa Seeman >> >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter >> <https://twitter.com/SeemanLisa> >> >> >> >> >> ---- On Wed, 14 Sep 2016 02:27:06 +0300 *Michael Pluke >> <Mike.Pluke@castle-consult.com <Mike.Pluke@castle-consult.com>>* wrote >> ---- >> >> During the 5th September COGA call Lisa, Steve Lee and myself considered >> my draft SC on "User authentication methods" (below) and discussed and >> agreed some changes. At the time I was persuaded, but on reflection I >> believe that, with the exception of the item mentioned at the very end of >> this (long) email, the changes we agreed wreck the SC and, in my opinion, >> make it unacceptable (probably even for AAA)! >> >> >> >> Original SC (with rationalizations for each bullet in square brackets >> following the bullet): >> >> TITLE: User authentication methods >> >> >> >> At least one user authentication method is offered that does not rely on >> a user's ability to: >> >> - memorize character strings or; [a frequently used mechanism i.e. >> usernames and passwords. - the ability to perform this is something that >> will diminish with even the mildest cognitive decline due to ageing] >> >> - correctly identify and enter numbered characters from a character >> string or; [this was probably not well worded, but was aimed at the very >> common and complex method that says "enter the third, seventh and ninth >> characters of your passphrase" - such a task involves multiple cognitive >> skills - memory, recall from long-term memory, sequential counting, holding >> the result of each sub-task in short term memory, retrieving the multiple >> sub-task results from short term memory and accurately entering them into >> the system!!!] >> >> - perform calculations or; [self-explanatory] >> >> - speak or; [aimed at speech recognition based authentication that will >> fail if the user is unable to speak the required word in a consistent way - >> i.e. where the current state of their cognitive disability has a >> significant impact on the quality of their speech - or could result in an >> inability to speak] >> >> - reliably produce gestures or; [this involves a mixture of cognitive and >> physical skills i.e. drawing a pattern (e.g. on a touchpad) that acts as >> the person's unique security pattern, memorizing what the pattern was, >> recalling what the pattern was with sufficient accuracy, accurately >> reproducing that pattern in a drawing gesture] >> >> - recognise characters presented on screen and then enter them into an >> input field. [e.g .CAPTCHA - this involves, at least, a level of reading >> skill to correctly recognise the characters so that they can be entered].. >> >> >> >> Exception: A user identification method that relies on one of the above >> abilities can be the only method if that ability is essential to make >> effective use of the content accessed via the user authentication method.. >> >> >> >> Lisa's suggested that the bullets should be changed to (with critiques of >> each bullet in square brackets following the bullet): >> >> -memorize information such as characters, words, numbers or gestures or; >> [In the chat we also added pictures. This bullet rules out all mechanisms >> that rely on ANY memorization] >> >> -correctly identify information such as characters, words, numbers or >> gestures or; [this rules out all methods that expects the user to >> comprehend ANY type of content] >> >> -correctly copy information such as characters, words, numbers or >> gestures or; [this rules out all methods involving copying ANY type of >> presented information (correctly)] >> >> -reliably produce information from memory [this rules all methods that >> rely on memory recall of ANY type of information] >> >> -perform calculations or complex cognitive function [this rules out all >> methods that expects the user to process information in ANY way (depending >> on the interpretation of "complex cognitive function" i.e. it rules out the >> use of executive functions including working memory] >> >> -speak [as above] >> >> >> >> Taken as a set, the above bullets manage to exclude pretty much every >> type of cognitive functioning e.g. no memorizing, no recall, no >> comprehension, no executive functions. In the call we agreed that the only >> methods that would meet the criteria were biometric methods or methods that >> permitted access from a trusted device (that would still require a >> device-level user authentication). Subsequently Steve Lee (who was on the >> call) suggested that single sign on solutions and social logins such as via >> Facebook. >> >> >> >> The problem is that none of these can be the "at least one other method".. >> >> >> >> Biometrics fails at the first hurdle as it is widely accepted that there >> should always be a non-biometric alternative to biometric user >> authentication mechanisms (as biometric methods will not work for some >> users because they have a disability that prevents them from using the >> method e.g. no hands, damaged iris, etc.), because the user has not setup >> the biometric functions, or because the device does not support the >> relevant biometric method. >> >> >> >> The other two methods (and biometrics) badly fail one of the key factors >> that SCs (at least those at levels A or AA) would be expected to conform to: >> >> >> >> " whether it is possible to satisfy the Success Criterion for all Web >> sites and types of content that the Success Criteria would apply to (e.g.., >> different topics, types of content, types of Web technology)" >> >> >> >> It is not acceptable to have a trusted device as the "at least one other >> method" as even users that have a suitable device will sometimes need to >> authenticate from other devices. SSO and social logins would not be >> acceptable as being the "at least one other method" as whichever method was >> offered as this alternative method would not be usable by anyone except >> those that were using the correct SSO solution (i.e. offering Facebook >> would not work for me as I avoid it with a passion). >> >> >> >> CONCLUSION >> >> So I propose that I leave the SC with my original wording with the >> exception of the 2nd bullet. Here, the suggestion during the call of >> "processing presented or memorised information" instead of my poorly worded >> 2nd bullet works OK for me. >> >> >> >> Best regards >> >> >> >> Mike >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >
Attachments
- image/jpeg attachment: image001.jpg
Received on Saturday, 17 September 2016 13:38:35 UTC