- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Wed, 20 Dec 2017 11:39:30 -0600
- To: Gregg Vanderheiden GPII <gregg@raisingthefloor.org>, "lisa.seeman" <lisa.seeman@zoho.com>
- 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>
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
Received on Wednesday, 20 December 2017 17:39:54 UTC