- From: Michael Gower <michael.gower@ca.ibm.com>
- Date: Thu, 21 Dec 2017 07:35:46 -0800
- To: "lisa.seeman" <lisa.seeman@zoho.com>
- Cc: "Alastair Campbell" <acampbell@nomensa.com>, "John Foliot" <john.foliot@deque.com>, "WCAG" <w3c-wai-gl@w3.org>
- Message-Id: <OFA6BBB724.FA5B978A-ON882581FD.00532B27-882581FD.0055AB34@notes.na.collabserv.c>
Without getting into a big discussion on security, I think it's important to say that a PIN or password is a common and valid form of authentication, even in multi-factor authentication. A PIN, which can be reset so that it is only known to the user, is more secure from a number of perspectives than most biometrics which are permanent yet can be copied (i.e., I can copy your finger prints and use them to spoof your identity, and you can't replace your fingerprints). That's not to discount the use of biometrics, especially facial recognition. Just to say that we shouldn't discount passwords either. Finally, although I know more about government security, my limited experience with the banking industry is that it tends to be pretty conservative and cautious in its adoption of new specifications. And don't forget that they may also have to factor in government regulation requirements. I wouldn't want to assume too much about how quickly they will adopt anything. I also wouldn't assume that a WCAG requirement will be a primary influencer in their security considerations. Michael Gower IBM Accessibility Research 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034 From: "lisa.seeman" <lisa.seeman@zoho.com> To: Michael Gower <michael.gower@ca.ibm.com> Cc: "Alastair Campbell" <acampbell@nomensa.com>, "John Foliot" <john.foliot@deque.com>, "WCAG" <w3c-wai-gl@w3.org> Date: 2017-12-21 07:06 AM Subject: Re: some questions: : working on re-authentication Hi Mike I doubt if there are jurisdictions that are not allowing support for Webauth specification or biometrics markers. these are much more secure then the username passwords they are asking for now All the best Lisa Seeman LinkedIn, Twitter ---- On Thu, 21 Dec 2017 16:53:58 +0200 Michael Gower<michael.gower@ca.ibm.com> wrote ---- Depending on jurisdictions, a bank is likely covered by regulations that make it fall under the exception. I do not recommend you focus primarily on something like a bank when trying to QA this SC, as banking is by nature an environment where heightened security is a requirement. Michael Gower IBM Accessibility Research 1803 Douglas Street, Victoria, BC V8T 5C3 gowerm@ca.ibm.com voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034 From: "lisa.seeman" <lisa.seeman@zoho.com> To: Alastair Campbell <acampbell@nomensa.com> Cc: "WCAG" <w3c-wai-gl@w3.org>, "John Foliot" < john.foliot@deque.com> Date: 2017-12-21 04:31 AM Subject: Re: some questions: : working on re-authentication Hi Alastair I do not think it is supported in 1.3.1. (info & relationships) or well supported in 4.1.2 or even "purpose of common controls". My bank (the example from hell) gives you different login number/card number where a "user id" needs to match a password. The password card id number is not part of the list of purpose of common controls. The role and name may be accessible, but auto complete is not "on" and I suspect they often change the name attribute about once every two months because once the password auto fill thing works and then it stops. What is more it needs to match the card number ID and password, and they give me a new card each time I go to the back (because I am locked out again...). three mistakes and you are blocked again. Basically they may conform to the other SC's but I still can not use it. (Yes I think of changing banks but I do not know that another one is better until I have an account there) All the best Lisa Seeman LinkedIn, Twitter ---- On Thu, 21 Dec 2017 14:13:34 +0200 Alastair Campbell< acampbell@nomensa.com>wrote ---- Hi Lisa, (John – question for you below.) For this: - authentication process can rely on the user or user-agent entering personal identification information such as name, username, password, and email address if the web content consistently supports automatic entry. > Automatic entry of user information can not work because autocomplete and the name is not set . It is not quite blocking the user agent rather they are not supported. If the username/password (or other) inputs pass 1.3.1. (info & relationships) and 4.1.2 (role/name/value) then user-agents currently support automatic entry unless the site actively blocks it. Also, there would also be overlap with the new SC that requires the autofill attributes, which I think includes username and current-password? (JF – have they been kept in the list?) Therefore, I would like to revert that change to avoid overlap with other SCs. > Also if transcribe follows the dictionary definition we can just clarify what we mean in the understanding section. Is that Ok? I think that would be best. Cheers, -Alastair
Received on Thursday, 21 December 2017 15:36:25 UTC