RE: Argument to revert my "User authentication methods" success criteria to the pre-5th Sept COGA call version (with a small mod)

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> 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<mailto:lisa.seeman@zoho.com>]
Sent: 14 September 2016 02:25
To: Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>
Cc: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org<mailto: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<mailto: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






________________________________