W3C home > Mailing lists > Public > public-cognitive-a11y-tf@w3.org > December 2017

Re: going though comments from 2.2.6 Accessible Authentication and new wording.

From: Alastair Campbell <acampbell@nomensa.com>
Date: Tue, 19 Dec 2017 16:51:47 +0000
To: Gregg Vanderheiden GPII <gregg@raisingthefloor.org>, lisa.seeman <lisa.seeman@zoho.com>
CC: "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>, public-cognitive-a11y-tf <public-cognitive-a11y-tf@w3.org>, "Rochford, John" <john.rochford@umassmed.edu>
Message-ID: <0B9EFAF1-1B2C-4A47-9EE6-0C0D596442DC@nomensa.com>
Hi Gregg,

I think you’ve missed quote a few threads, but a summary at this stage would be useful I think?

There are several current scenarios I worry about:

  1.  A simple site which currently uses username/password (1 factor).

  2.  A site with two-factor authentication, such as: un/pw and a time-based one-time password (random 6-digit code) [1]. There are common libraries for web frameworks to do this.

  3.  An email provider with the same settings as 2. (Which means it’s impossible to use the email-reset method.)

For scenario 1 (un/pw) the feasible methods we’ve found are:

  *   Doing an email reset, where you use the forgotten password feature.

  *   Using a ‘magic link’, where the site emails a link to the person, and they click that to login (e.g. Slack and Linkedin do that, it’s ok for lower security sites.) There are common libraries for web frameworks to do this.

For scenario 2 (with 2nd factor), you’d need to use the same as 1, but also:

  *   WebAuth, an API to hardware or OS level authentication. It abstracts away the second factor and puts it in the user’s control and they can choose what it is, such as a USB key, Bluetooth thing, Windows Hello etc.

  *   Other (expensive) methods such as custom phone app, IR codes. I’m discounting these as expensive and non-standardised.

For scenario 3 (an email provider) I’m at a loss to provide a good technique unless it is scoped to re-authentication only.


  *   If you assume people can use a password manager, scenario 1 moves to be a user-agent requirement and we can put that to one side (except for advice).

  *   WebAuth is not scheduled to finish until mid 2018, and so far only Chrome has released an implementation. Edge and Firefox are working on it, but their implementations are still in beta so we can’t be certain they will be ready by the time 2.1 is released.

  *   If you have WebAuth, that replaces one factor, NOT both, so in scenario 2 it still needs to be combined with another mechanism (e.g. magic link).

So for me, the release of WebAuth is a key factor in whether this SC is feasible.

Also, I think we should assume password managers are available and re-scope it on that basis.



1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

From: Gregg Vanderheiden GPII


this still is using publicly obtainable information for authentication such as name address email address (bad idea)  or their  national ID number which is a very bad idea to be giving out on every website -=- and how would the website know it anyway. (also a bad idea).

other than that — the only thing I know of is  biometrics which the computer does not have the ability to carry out.

am I missing something?


Received on Tuesday, 19 December 2017 16:52:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:00 UTC