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)

If needed I would be glad to help putting content into the HTML template. I
will keep the integrity of your content and won't make any edits.

Thad
On Sep 15, 2016 2:21 PM, "Michael Pluke" <Mike.Pluke@castle-consult.com>
wrote:

> I will make an attempt, but I am in a conference for the next three days
> (with events during the evening). Working in raw html is not a task that
> will be easy for me when I am trying to focus on the content of the busy
> conference!
>
>
>
> Best regards
>
>
>
> Mike
>
>
>
> *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 2nd
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>