RE: Mikes request that we identify an upper limit on the number of digits

Copying to the list the following response to Alastair, who cited the Web Authentication working draft and the current extent of its implementation…

Thanks. This is the same spec that the APA Working Group has reviewed. Based on my reading of the draft, it can support a variety of authentication methods, the details of which depend on the user agent, operating system and hardware. It ought to be (but in practice probably isn’t) a safe assumption that users will choose devices and software offering authentication schemes that meet their accessibility needs. In any case, for Web applications that use this API, the choice of authentication mechanism is very much the user’s responsibility – not the application author’s, unless of course the application disallows certain devices as authentication providers (e.g., for failing to meet specific security criteria).

I think the issue at hand is partly a matter of timing: without an interoperable solution in place, the proposed SC is hard to implement, but the solution is clearly on the path to standardization and early implementation. If we were to include the SC, this issue could well slow down the adoption of WCAG 2.1. It’s for the working group to decide whether this is acceptable.


From: Alastair Campbell [mailto:acampbell@nomensa.com]
Sent: Tuesday, November 28, 2017 1:00 PM
To: lisa.seeman <lisa.seeman@zoho.com>
Cc: W3c-Wai-Gl-Request@W3. Org <w3c-wai-gl@w3.org>
Subject: Re: Mikes request that we identify an upper limit on the number of digits


Hi Lisa,



> LS: there are lots of ways to do this securely. such as…



I covered this in the email yesterday, but there are two types of implementations we are confusing:



  1.  Hardware / apps that supply the secure token / biometrics
  2.  Browser support that connects to those secure devices.



WebAuth is the right standard to refer to, but the current browser support is Chrome-only<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcaniuse.com%2F%23search%3Dfido&data=02%7C01%7Cjjwhite%40ets.org%7C2450fa045e6748f69bfe08d5368a3a24%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636474889664974614&sdata=%2Bf%2BtyzlgD0PNA5rKlMzkqBsiMMxa2KMU%2BBX%2FI2t%2Fa98%3D&reserved=0>, and that is desktop-only as the U2F devices generally use USB.



Is there another way that I’m missing? Otherwise I can’t see how we could get 2 implementations (which is probably why WebAuth is still in draft).





> there are thousands of conforming sites. examples of conforming sites That I use only yesterday include:  the w3c and the EU site for research funding which allows multiple log in methods



I’m confused about that as I was given a password for W3C which I have to type in every time. (Well, I use lastpass, but we seem to be ignoring auto-filling password tools).



I assume those are sites which let you reset email, for which my question was: Is the intent that the email reset logs you in automatically?

A typical implementation would have you copy the new password into a username/password form to login, which I wouldn’t have thought conforms?





> Any level of security can be reached. including use of tokens and dongles , smartcards etc.



But we haven’t shown that for *web content*, I don’t think “use desktop chrome” is a good answer here.



Also, how do you get past the username/password bit? You can set the second factor to remember your device for a set time (usually 30 days), but at some point you would still have to login with a password and with the 2nd factor, otherwise there is no security



Then the last (more complex) level, how do you conform if you are the email-provider? If you can’t provide an email-loop, and you use 2FA, I can’t see how that would work in theory, let alone practice.



If this is getting a security review, can we make sure that is considered? Otherwise it is very hypothetical.



Cheers,



-Alastair



________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________