W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > September 2016

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

From: Michael Pluke <Mike.Pluke@castle-consult.com>
Date: Tue, 13 Sep 2016 23:27:06 +0000
To: public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>
Message-ID: <A48C91EB13E45544B16FBC94C9298D8D333531E2@S11MAILD013N2.sh11.lan>
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
Received on Tuesday, 13 September 2016 23:27:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 September 2016 23:27:39 UTC