Re: Next steps for accessible authentication

Hi Lisa,

I'm still not clear what a good solution would be for the simple or difficult examples, and there are not as many options as you suggested.

The examples break down to these:

1. A second factor that is off-loaded to a system the user has, which could be a USB thing, Bluetooth thing, or something built into the device. (The web authentification spec is the API to access these authentification devices, conforming to it doesn't magically enable anything in its itself. FIDO is probably furthest along).

I haven't found any implementations of these which start without requiring a username and password, do you know of one?

2. Off-loaded the entire login to a 3rd party like Facebook with oAuth.

3. Use an email loop, either to reset (in which case you have to type a new password twice), or simply get logged in by that link.

4. I'll add one I've been following: https://www.grc.com/sqrl/sqrl.htm which is intended to replace username and passwords. However, it is very new and will require sites to implement this method, I wouldn't say it was ready for relying on in a spec yet.

I still haven't seen a feasible method of meeting this apart from the email loop, which is not always practical. Using a third party like Facebook is problematic on both ends, as not all users will have it, and some sites may not be able to use it (e.g. Government).

If there were a feasible solution for replacing usernames and passwords, companies would love it! It would reduce the most common service queries massively. That hasn't happened, so I have to conclude that there isn't a good, feasible solution yet.

-Alastair


PS. Not a big thing, but I note the issue paper links to HTML keygen, which appears to be deprecated: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen and replaced by https://www.w3.org/TR/WebCryptoAPI/
That is a fairly low level JavaScript api, and doesn't have an obvious library for replacing a login method.