Re: Next steps for accessible authentication

Sorry 
I wasn’t asking if people with cognitive disabilities had been asked.  — I was asking 

Were people with cognitive disabilities     that are severe enough that they cannot copy information,    tested with each of these techniques and were they able to do each of them.   

If not then they are not alternatives for them.

If people can copy information then they don’t need these 

This is a pretty severe cognitive disability — and it looked to me - from my work with people with cognitive disabilities,  like anyone who was unable to copy information would be unable to do many or all of these.     I am delighted to be proven wrong.    Has someone demonstrated that these are doable by the group this is targeted to?  (people who cannot even copy information) 

thanks  

g 

Gregg C Vanderheiden
greggvan@umd.edu




> On Jun 19, 2017, at 2:56 PM, lisa.seeman <lisa.seeman@zoho.com> wrote:
> 
> Hi Gregg
> 
> Yes, they have been reviewed by security experts and people with cognitive disabilities.
> 
> We are also reaching out to the web authentication group to see if they have any issue wit the current draft
> 
> All the best
> 
> Lisa Seeman
> 
> LinkedIn <http://il.linkedin.com/in/lisaseeman/>, Twitter <https://twitter.com/SeemanLisa>
> 
> 
> 
> 
> ---- On Mon, 19 Jun 2017 21:23:18 +0300 Gregg C Vanderheiden<greggvan@umd.edu> wrote ---- 
> +1 to Jason’s concern about security of these.  Have they been vetted by a security specialist? 
> 
> 
> Also — are these supposed to be easier than copying something ? 
> 
> All of these appear to be cognitively much more complicated than copying information from one place into the field.   As such - is this something where the solution requires more cognitive skills than the problem? 
> 
> Has anyone demonstrated that someone who cannot copy information — can do any/all of these?     That these are indeed simpler? 
> 
> If not - then is there any grounds for assuming that any of these will reduce the cognitive demands on a person…..
> 
> These all sound complicated to me….
> 
> g 
> 
> Gregg C Vanderheiden
> greggvan@umd.edu <mailto:greggvan@umd.edu>
> 
> 
> 
> 
> On Jun 19, 2017, at 1:48 PM, White, Jason J <jjwhite@ets.org <mailto:jjwhite@ets.org>> wrote:
> 
>  
>   <>
> From: lisa.seeman [mailto:lisa.seeman@zoho.com <mailto:lisa.seeman@zoho.com>] 
> Sent: Monday, June 19, 2017 1:30 PM
> 
> We are allowing multiple alternatives, such as:
>  two step authentication that has a link to press as an alternative to entering a code
> [Jason] What are the security implications, if any? The server comprising the destination of the link could be attacked (e.g., by trying different values for the data carried in the link in succession).
>  two step authentication using devices that sends a tokens via Bluetooth
> [Jason] These are promising as an idea, but without standardization, the user may end up having to use several different devices with different Web sites – not a desirable outcome. I think these could only be required in WCAG when the standards are in place.
>  Email resetting is an option for most places,  including google if people have an alternative address
> [Jason] This isn’t suitable for high security applications, since anyone who gains access to the e-mail account can compromise the security of the system.
> login in via something like facbook
> [Jason] This involves trusting/relying on a third party to perform the authentication. If I remember correctly, this is known to have serious security shortcomings.
> conformance to the web authentification specification at https://www.w3.org/TR/webauthn/ <https://www.w3.org/TR/webauthn/>
> [Jason] This is the most promising of your alternatives. Will it be practically available by the time WCAG 2.1 enters Candidate Recommendation?
>  
> In short, I think most of the options are at least suspect from a security point of view.
>  
> 
> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
> 
> 
> Thank you for your compliance.
> 
> 
> 
> 

Received on Monday, 19 June 2017 19:58:51 UTC