Re: Next steps for accessible authentication

Hi Lisa,

Firstly, I’m not arguing about the importance (I don’t think anyone is), the discussion is about how sites can practically implement something that both helps and meets the SC. If there are no good options then the SC will be ignored and undermine the whole 2.1 version.

From the latest text [1], I think conforming solutions for single factor auth would be:


-          Username & password with options for:

o    3rd Party login via oAuth (e.g. Facebook/Google), and/or

o    Email-loop for password reset or straight login.

None of these replace username/password, but provide a method of not having to remember them for this login. To be honest, I think most sites allow an email reset so this isn’t a high bar. I’m not sure how useful it is, but a password reset mechanism is pretty standard.

For a second factor a site could use a number-based input from a “Time-based One-time Password Algorithm” (like Google Authenticator [2]), but would also have to include options for:


-          A separate physical device, such as a USB key, or something built into the device. It could be biometric based (fingerprint reader on laptop using TPM), or the ‘Yubikey’ method inputing a long number automatically, but there isn’t any point in separating these as they all go through the browser. The website doesn’t know what physical device is being used, the browser hides that.

Hmm, I think that is the only second factor method available from a website point of view, I don’t know of others and all the examples in the issue paper come back to that one.

This relies heavily on the Web Auth API [3], although there are already some solutions that can be implemented now based on FIDO [4].

Question to the AG group: Is that sufficient support from an implementation point of view?

I haven’t gotten one of those USB key authenticators because it isn’t as flexible as a number-based system like Google Auth. (I.e. you need a USB port so it doesn’t work for logging in from my phone.)

However, once you have one, it would work with password managers like Dashlane. In that case, why put a restriction on websites which rely on username password? Instead of requiring alternative methods, encourage the use of password managers and have an SC that says you should allow the copy/pasting of passwords.

This is encouraged by our National Security service already [5], the friendly arm of GCHQ.

Question for COGA group: Why haven’t password managers figured in this more? It seems like an obvious way to avoid needing to remember a password, and with the device-based keys you don’t even need to remember the password to get into it.

Cheers,

-Alastair

1] https://rawgit.com/w3c/wcag21/accessible-authentication_ISSUE-23/guidelines/#accessible-authentication

2] https://en.wikipedia.org/wiki/Google_Authenticator

3] https://www.w3.org/TR/webauthn/

4] https://developers.yubico.com/U2F/

5] https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords



From: "lisa.seeman" <lisa.seeman@zoho.com>
Date: Tuesday, 20 June 2017 at 04:41
To: Alastair Campbell <acampbell@nomensa.com>
Cc: "public-cognitive-a11y-tf@w3.org" <public-cognitive-a11y-tf@w3.org>, WCAG <w3c-wai-gl@w3.org>
Subject: Re: Next steps for accessible authentication

Hi Alastair
Firstly the resetting your credentials is how I log into the W3c stuff most times (if not all times) that I need to login. Fortunately it allows me to stay logged in so I only have to do this every now and then. It is not a great solutions but without it I doubt I could participate here. SO it is an acceptable way to conform. It is a bit like  the wheal chair ramp around the back and though the kitchens. Slower, a pain, but at least you can get in. For my bank account I need to drive to the bank to reset my credentials. SO I pay my accountant extra so that she will check my bank account for me when I need it. That is not an acceptable solution.

You are right that a second factor requires the user to have a system that supports them - like a smart phone or USB etc. But that is part of the user burden that we often require from the user.

We are not going to be able to include everyone in all scenarios. For example may people do not have a facebook account. SO having that as the alternative will still leave some people out. What we are doing is widening the net of who can use the application. For something very important like using your online banking or healthcare, a person may still need to get some assistance in setting up their system with a web authentication method that works for them and is secure. But after that they will be able to do things like use their work  cloud while  at home, make a doctors appointment independently  or use online banking without driving to the bank to get a new password most of the times that they try.

in the mean time it is worth noting that MENCAP has attributed the lower life expectancy of people with LD to difficulty doing things like setting the doctors appointment independently. It is hard to overestimate how important this could be.

All the best

Lisa Seeman

LinkedIn<http://il.linkedin.com/in/lisaseeman/>, Twitter<https://twitter.com/SeemanLisa>



---- On Tue, 20 Jun 2017 00:21:32 +0300 Alastair Campbell<acampbell@nomensa.com> wrote ----
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.