Re: Accessible Authentication and issue responses

On 24/12/2017 00:17, Alastair Campbell wrote:
>> Because if so...this SC would
>> only prohibit a small number of scenarios (like "enter the first, third
>> and seventh digit of your secret number" or similar)
> 
> Also consider the 2 factor cases, where you have to transcribe a 6 digit number in 30 seconds.
> 
> The aim is to push sites to allow for other methods, such as WebAuth based hardware/OS methods like Windows Hello.

But if a site can pass by simply having regular inputs that don't 
somehow disable autofill, the push (if that's the intention) seems quite 
soft.

I guess the "understanding" doc really needs to clarify some more 
aspects of this (and again, I'll mention that currently there still seem 
to be aspects related not to authentication per se, but purely to 
CAPTCHA, in that understanding doc).

>> Password managers/UAs can autofill other types of information as well.
> 
> Yes, but the reliability is not great, and not standardised AFAICT. Sites do strange things to even username/password fields, expanding the range of things that *might* be remembered by browsers /pw-managers doesn't seem like a great approach.

Enshrining in normative language the only fields that are allowed as 
exceptions also doesn't seem a good approach. What happens when 
reliability improves for even one more type of field? Are we left with a 
normative list of types of fields which call back to a past time and 
isn't relevant anymore? (Of course, we could argue "we'll fix/expand 
that in future / in Silver", but by then you could have technical 
"fail"s that are real-world passes / passes in Silver...which may seem 
strange).



-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Sunday, 24 December 2017 01:28:33 UTC