Re: Next steps for accessible authentication

Hi AlastairFirstly 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, Twitter





---- 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.