RE: Next steps for accessible authentication

Hi JasonJust to clarify: we are not requiring anyone to use biometrics.  If people choose to use biometrics then I would agree an alternative should be available. There is nothing here which is incomplete with EN 301 549.


The idea is to help more people use the the web. Having more then one method to authenticate that rely on different capabilities  is key and I think is reflected in the wording, but we can clarify in the understanding section.


If you want we can add to the cryteria "rely upon recalling or copying information" to "rely upon recalling or copying information or a single biometric"


Does that address your concern? 






All the best

Lisa Seeman

LinkedIn, Twitter





---- On Thu, 15 Jun 2017 20:18:23 +0300  White<jjwhite@ets.org> wrote ---- 

    Note that if one of the two factors that a Web site operator decides to use is biometric, we don’t have any proposal at present that parallels the requirements in EN 301 549, or in the regulations under section 508 of the Rehabilitation Act in the U.S., regarding the need to ensure that at least two distinct biological characteristics can be used to supply the biometrics. Thus, we could find ourselves addressing some accessibility problems while introducing others by effectively expecting content developers to implement biometrics as part of their authentication schemes, without requiring those biometric components to meet accessibility standards.
  
 Alastair’s questions reflect some of my concerns about this proposal. I don’t think requiring users to purchase specialized authentication hardware in the absence of a Web standard supporting it, or, worse, expecting them to purchase multiple, mutually incompatible devices to authenticate to different Web sites, is practicable. This kind of proposal needs to apply only when the standards are in place and the supporting hardware is available. Even then, some authentication schemes won’t qualify (as they rely on memorization or copying in at least one of the authentication factors), and we need to understand the security implications of restricting ourselves to those approaches that would still qualify.
  
     From: Alastair Campbell [mailto:acampbell@nomensa.com] 
 Sent: Thursday, June 15, 2017 12:44 PM
 To: lisa.seeman <lisa.seeman@zoho.com>
 Cc: public-cognitive-a11y-tf@w3.org; WCAG <w3c-wai-gl@w3.org>
 Subject: Re: Next steps for accessible authentication
 
 
  
 Hi Lisa,
  
 Something I haven’t been able to work out, and will be needed by the web auth folks, is: What are the possible solutions?
  
 Lets take an email provider as an example (e.g. Yahoo, Google).
  
 If they cannot use (or rely) on passwords or copying numbers, what could they use for two factor authentication? I.e. both factors.
  
 There needs to be two things, and we can’t rely on:
  Passwords (recall)
Copying from a two-factor token app like Google Authenticator [1]
SMS, as standards bodies are saying they are to easy to get around so not considered secure [2].
Email resetting, because they are an email provider.
Biometrics that a user doesn’t have, possibly due to disability, but more likely because there is no standard technology that people have.
  
 I’m really struggling to see how a website can provide a secure login, at least in the next year or so until the protocols actually gain some traction (they don’t have to be W3C, but they do have to be reasonably available).
  
 At the other end of the scale, what does a smaller website do? Password and have an easy email reset? Is there anything else?
  
 Cheers,
  
 -Alastair
  
  
  
 1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGoogle_Authenticator&data=02%7C01%7Cjjwhite%40ets.org%7Cc94312804e0848564d7008d4b40dd2cb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636331418844599870&sdata=BsYmKSRBcfYkxalm8tqm15Oc0YnQd%2BrZ8AS%2F87WiHT0%3D&reserved=0 
 2] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theregister.co.uk%2F2016%2F12%2F06%2F2fa_missed_warning%2F&data=02%7C01%7Cjjwhite%40ets.org%7Cc94312804e0848564d7008d4b40dd2cb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636331418844599870&sdata=wMLynvpCeRrS89d%2BP9l5kHLiJDMIAnFjMq29%2BTLro6E%3D&reserved=0 
  
  From: "lisa.seeman" <lisa.seeman@zoho.com>
 
   
 
  Next steps for accessible authentication
 
   
 
  1. We need to set up a review with the web authentication folks and check they are comfortable we are ncreating security problems. Who should set that up? (Options: John, Me, Andrew or Josh as wcag chairs or Janina as APA...)
 
   
 
  2. All the comments need to be addressed in github . see: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F23&data=02%7C01%7Cjjwhite%40ets.org%7Cc94312804e0848564d7008d4b40dd2cb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636331418844599870&sdata=h1%2BrciZq3KE85g8AvXSb0MizM%2BCnGhUqIAMosD4xVms%3D&reserved=0
 
  also we need to check the survey: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2002%2F09%2Fwbs%2F35422%2FCOGA_Auth%2Fresults&data=02%7C01%7Cjjwhite%40ets.org%7Cc94312804e0848564d7008d4b40dd2cb%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636331418844599870&sdata=s%2FPHtSjuzNOXcyHj4FaUvhokZBcPUKTW0mxGHsVjsa8%3D&reserved=0(although we can disagree with them and try and convince them)
 
   
 
  3. We need an exception for when this is not possible with current legislative requirments
 
   
 
  4. Possible exception for coping up to four characters ? DO we see a user problem with this?
 
   
  All the best
 
 Lisa Seeman
 
 LinkedIn, Twitter
 
 
 
 
 
  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 17:48:35 UTC