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)

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<mailto: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
[cid:image001.jpg@01D21044.6BA483D0]

New SC v2<https://1drv.ms/w/s!AonHhdlMwzu_zFziFK13W1io4NZ8>
OneDrive







From: lisa.seeman [mailto:lisa.seeman@zoho.com<mailto:lisa.seeman@zoho.com>]
Sent: 15 September 2016 19:51
To: Michael Pluke <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>
Cc: Thad C <inclusivethinking@gmail.com<mailto:inclusivethinking@gmail.com>>; public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:lisa.seeman@zoho.com>]
Sent: 14 September 2016 10:57
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)

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<mailto: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














________________________________