Re: working on re-authentication

Hi Gregg,

Right, I have a keyboard and multiple windows now!

I was making similar arguments back in June:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017AprJun/1142.html


Here I outlined the potential solutions/techniques from a feasibility point of view, taking 3 levels of security / difficulty:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0680.html


Here I explained why the proliferation of various hardware/OS devices are not necessarily available for website creators (without a great deal of cost):
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0722.html


Which all leads to the version I proposed earlier in this thread:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/1061.html


So the techniques in a single-factor scenario were (in the CR version):

  *   An email reset link, no transcription required.
  *   Off-loading to a 3rd party oAuth service like Facebook, although that has problems.
  *   A webauth method (the W3C’s API spec for the browser to access OS or hardware tokens)

For a 2-factor scenario, you would have to combine two of the above techniques, which is, um, messy. For an email provider with 2 factor you are out-of-luck.

Lisa mentioned other hardware methods such as Bluetooth, but I have not found a ‘standardised’ one that isn’t a huge cost. We have charity clients where the cost of that method would be similar to the cost of their whole web project.

That is why I’ve been saying it needs to be scoped to allow for passwords managers, so:
————-
Authentication processes do not rely upon the user to do any of the following:

- memorize information;
- perform calculations;
- reliably produce gestures;
- transcribe information.

Exceptions:

- Authentication process can rely on the user *or user-agent* entering personal identification information such as name, *username, password*, address, email address or national identification number *if the web content does not block automatic entry*.

- There are governing statutory requirements that require the use of memorisation, calculations, gestures or transcription in re-authentication processes.
—————
(*Bold* to show updates for the password manager aspect, if that works.)

I think, given that we allow for username & password to be remembered by the browser or password manager, we can keep the scope at authentication (rather than re-authentication, which I was pushing for previously).

Potentially we could remove the national ID number aspect now?

Also note that the SC text above says “do not rely upon”, instead of there being “alternative steps”. I think these are equivalent, and the above formulation is easier to parse.

Scanning through your email, I think that answers everything?

The major at-risk factor for me is whether there will be implementations of WebAuthn in time, it is in-progress for Firefox and Microsoft, and Chrome as a FIDO-based implementation now, but I’m not sure if it is compatible with WebAuth now.

Cheers,

-Alastair