- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 20 Dec 2017 13:21:38 -0600
- To: "lisa.seeman" <lisa.seeman@zoho.com>, Gregg Vanderheiden GPII <gregg@raisingthefloor.org>
- Cc: Alastair Campbell <acampbell@nomensa.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, Michael Gower <michael.gower@ca.ibm.com>, "Rochford, John" <john.rochford@umassmed.edu>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
Thanks, Lisa. Gregg, do you see a problem with any what Lisa listed has below for being sufficient author techniques for this SC? Kindest regards, Laura On 12/20/17, lisa.seeman <lisa.seeman@zoho.com> wrote: > Hi Laura > > Among the sufficient techniques are allowing any one of the following: > > > Complying to https://www.w3.org/TR/webauthn/ and allowing one component > method such as biometrics , FIDO or tokens > > A cheap and easy way is "logon via facebook" (being already logged in to > third-party authentication services ). > > Using multi-factor identification with Bluetooth or generate a RC code (on > the browser) or simply send a link. I have sent links in other emails to > places that do multi-step authentication in fully conformant ways. Also you > can use what ever way you want as long as there is an alternative that is > conformance > > Automatic user authentication based upon the use of a trusted device (to > which the user has already logged in with their own identity); > > Fast IDentity Online (FIDO), password-free standards for typical and > two-factor authentication. > > FIDO relies upon user authentication based upon a user's device (e.g., > phone, tablet, computer). > > A user's device registers the user, to a server, via a public key. > > Upon a challenge from the server, the user's device responds with a private > key. > > The device's keys are unlocked by the user biometrically (e.g., fingerprint > scanner) or by a button press, not by a password. > > Allowing the user to reset a password by pressing a link sent to them in an > SMS or email.sms, which brings the user to a page that provides the > opportunity to create a new username and/or password > Being compatible with password managers that allow user login with one of > the above techniques. > > > > All the best > > Lisa Seeman > > LinkedIn, Twitter > > > > > > ---- On Wed, 20 Dec 2017 19:39:30 +0200 Laura > Carlson<laura.lee.carlson@gmail.com> wrote ---- > > Hi Gregg and Lisa, > > I think it may come down to techniques. Lisa, what author techniques > for this SC are in the works? > > Thanks. > > Kindest Regards, > Laura > > On 12/20/17, Gregg Vanderheiden GPII <gregg@raisingthefloor.org> > wrote: > > I still don’t see how you can require an AUTHOR to provide an > authentication > > method ( or re-authentication — which is authentication) without > requiring > > any information beyond publicly available information ( not good for > > authenticating) or their country ID (which I would NOT want to give to > any > > and all websites that have sign in. > > > > As such this SC is not implementable by authors since the only solution > to > > it is biometrics - which a page author cannot do. > > > > Am I missing something? > > > > G > > > > > >> On Dec 20, 2017, at 11:30 AM, lisa.seeman > <lisa.seeman@zoho.com> wrote: > >> > >> Hi Alastair > >> > >> The reason it might be ok to allow transcribing etc at sign up, is > that it > >> might be reasonable for someone to get help the first time they use > the > >> site, but completely unreasonable to expect the user to have help > each > >> time they sign in. It is a compromise if people felt that we have > to allow > >> people to copy in a code first time. (Which is why i thought you > had tried > >> to limit the scope to re-authentication. ) > >> > >> If we can live without the exception that is better. > >> > >> All the best > >> > >> Lisa Seeman > >> > >> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter > >> <https://twitter.com/SeemanLisa> > >> > >> > >> > >> > >> ---- On Wed, 20 Dec 2017 18:08:08 +0200 Alastair > >> Campbell<acampbell@nomensa.com> wrote ---- > >> Hi Andrew, > >> > >> I agree we should be able to answer those, I just updated the wiki > page > >> and I think this version helps: > >> ————- > >> Re-authentication processes do not rely upon the user to do any of > the > >> following: > >> > >> - memorize information; > >> - perform calculations; > >> - reliably produce gestures; > >> - transcribe information. > >> > >> Exceptions: > >> > >> - Re-authentication process can rely on the user or user-agent > entering > >> personal identification information such as name, username, > 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. > >> ————— > >> > >> On your questions: > >> > 1. Regarding user’s abilities to memorize information, don’t > browser/OS > >> > capabilities or separate tools (e.g. splash ID, LastPass, etc) > > >> > >> I think the first exception covers that now, and yes, I think we > need to > >> except that is a user-agent & education issue rather than > content, so long > >> as content doesn’t prevent their use (which is also accepted > security best > >> practice, despite certain banks thinking otherwise). > >> > >> > Regarding the ability to transcribe information, this > includes: > >> > >> Anything where you see/hear characters and have to type them in > >> somewhere. > >> > >> > Regarding the ability to transcribe information, what kind of > barrier > >> > does this create for users – is it a complete barrier or > something less? > >> > In one of the current options it seems that transcribing a > one-time code > >> > is ok for the first time – why is it not a barrier the first > time but is > >> > a barrier after that? > >> > >> In usability testing, which wasn’t exactly on this, but close as we > gave > >> people made-up information to type in as part of usability testing, > it can > >> take 5-10 seconds per character, if they are patient and motivated. > The > >> typical time-based-one time code is 6 characters to type in within > 30 > >> seconds. > >> > >> We can discuss degree, but personally I’ve seen enough to know it > is a > >> real issue and any transcription will prevent some people from > completing > >> that task. > >> > >> I don’t think we were saying some transcription is ok the 1st time, > but > >> that you could set/reset your password? Not sure where that came > from. In > >> the above SC text you can: > >> - rely on a password manager so long as you don’t block it. > >> - use a magic-link or email loop password reset. > >> - use webauth for 2nd factor. > >> > >> > It seems that there is a possible conflict with 1.1.1. In that > SC there > >> > is language about using CAPTCHA, which is sometimes used as > part of an > >> > authentication process. > >> > >> *Generally* I’ve seen it used in account creation rather than > >> authentication, but I guess that can happen. > >> > >> > It seems that providing a multi-modal approach which uses but > doesn’t > >> > rely exclusively on visual CAPTCHA is ok under 1.1.1 but may > be > >> > forbidden in this SC? > >> > >> Yes, as that involves transcription (which can be either visual or > > >> auditory, I don’t think we can discriminate here ;-) > >> > >> So I think it prevents CAPTCHA for being used for > re-authentication, but > >> not account creation or authenticating the 1st time in a browser. I > think > >> there is good argument for that, as CAPTCHA should not be used if > you have > >> already proven you’re not a robot. > >> > >> The current 2.0 SC is still useful for the multi-model aspect. > >> > >> > Are there examples of sites that currently pass the proposed > SC language > >> > without relying on the exceptions? > >> > >> Yes, in the above form just having a username/password is fine. If > you > >> block pasting then you’d need to provide an email alternative. > >> With second factor it gets more difficult, as you need to off-load > the 2nd > >> factor onto an OS/hardware device, which Chrome supports now, and > others > >> support soon. As Chrome supports webauth now I assume there are > some > >> google sites which support it, and as it can be used as an > alternative > >> method (e.g. time-based code OR webauth), I’m sure we can find > some. > >> > >> Cheers, > >> > >> -Alastair > >> > >> PS. The 10 years of listening to security podcasts are finally > coming in > >> useful! > >> > >> > >> > > > > > > > -- > Laura L. Carlson > > > > > > > > -- Laura L. Carlson
Received on Wednesday, 20 December 2017 19:22:04 UTC