accessible authentication

[lseeman]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• SC in full draft guideline

SC text: User Authentication Methods

                        <p class="sctxt"><strong class="sc-handle"></a>User Authentication Methods:</strong> A user authentication method  is offered that does not rely upon a user's ability to memorize information; recall information from memory; speak; or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page.</p>
                        <p class="sctxt">An alternative user authentication is available for users who are unable to use the primary user authentication method, unless it can be shown that all users have access via the primary method. This alternative user authentication method does not rely upon the user's ability to do any of the following:</p>
                        <ul>
                            <li>memorize character strings, including memorizing correct spellings; or</li>
                            <li>perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or </li>
                            <li>speak; or</li>
                            <li>reliably produce gestures; or</li>
                            <li>recognize characters presented on screen, and then enter them into an input field.</li>
                        </ul>
                        <p><strong>Exception:</strong> A user identification method, which relies on one of the above abilities, can be the alternative method if an ability is essential to make effective use of the content accessed via the user authentication method.                  </p>
                    </div>
                </blockquote>
                <h2><a id="user-content-suggestion-for-priority-level-aaaaaa" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#suggestion-for-priority-level-aaaaaa"></a>Suggestion for Priority Level</h2>
                <p>(A) </p>
                <h2><a id="user-content-related-glossary-additions-or-changes" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#related-glossary-additions-or-changes"></a>Related Glossary additions or changes</h2>
                <p><span class="sctxt"> A simple web page</span> is a page with simple text; a simple search; and clearly marked links and buttons.</p>
                <h2><a id="user-content-what-principle-and-guideline-the-sc-falls-within" href="https://github.com/w3c/wcag21/wiki/Proposals-for-new-Success-Criteria#what-principle-and-guideline-the-sc-falls-within"></a>What Principle and Guideline the <span id="docs-internal-guid-9beb1966-66b8-fe9a-5ca5-4897cd3bb8a3">success criterion</span> falls within.</h2>
                <p>This topic is directly related to Principle 2 "Operable", as failure to successfully overcome user authentication barriers will mean that users are unable to access and make use of underlying content.</p>

We may need a new guideline or change guideline "2.2 Enough Time: Provide users enough time to read and use content" to something like Guideline "2.2 Barriers and Time: Provide users enough time to read and use content and avoid barriers that prevent some users from accessing content. "

Description

The intent of this success criterion is to ensure that, if users are able to make use of content they are seeking, they do not encounter a barrier that prevents them from accessing it.

Most user interfaces are designed to help users complete tasks. However, traditionally, web security and privacy technologies intentionally introduce barriers to task completion. They require users to perceive more and to do more to complete tasks.

Many user authentication methods rely upon trying to differentiate between a human, and software (bots) that try to pose as a human. The most common way of trying to make this distinction is by the setting of tasks that rely upon human abilities, and that are almost impossible for software (bots) to perform. These methods can frequently be quite challenging for people who have a high level of relevant ability. For people who have a lower level of relevant ability, an authentication task often presents an insurmountable barrier.

An alternative user authentication method is required for users who are temporarily or permanently unable to use the primary user-authentication method. One important example is where users would be unable to use a primary user authentication method, such as when they do not have a suitable trusted device, or if they are not subscribed to or are unable to access third-party services (often part of user authentication methods), which would meet the criteria for primary user-authentication methods.

The six abilities that are referred to in the alternative success criterion are those that are frequently employed as user authentication methods. The SC asks for the availability of at least one method that does not rely upon any of these abilities being offered.

Benefits

Without this success criterion, many people cannot use an application or content at all. See Security and Privacy Technologies issue paper for the full description of this issue, and how it stops people from using web services that are often critical. Many people cannot make doctors appointments, etc., by themselves. This may be partly responsible for the reduced life expectancy of people with learning and cognitive disabilities.

With this success criterion, people who are able to use a primary user authentication method will be able to successfully complete a user authentication procedure almost irrespective of the level of their cognitive abilities. Those who have to use an alternative method will be able to successfully complete a user authentication even though they have limited levels of the cognitive abilities specified in the success criterion.

Related Resources

Issue papers:

• Security and Privacy Technologies
• Numbers and Math

Other

• Gap analysis section 2.3.2
• User needs Table 1
• Background research document (particularly 3.1.3.1 Memory)

See also

https://www.improvinghealthandlives.org.uk/uploads/doc/vid_7479_IHaL2010-3HealthInequality2010.pdf

http://www.hscbereavementnetwork.hscni.net/wp-content/uploads/2014/05/Death-by-Indifference-Mencap-March-2007.pdf

[joshueoconnor]

Assigned to John Rochford (@JohnRochfordUMMS) https://www.w3.org/WAI/GL/wiki/SC_Managers_Phase1

[joshueoconnor]

Surveyed: https://www.w3.org/2002/09/wbs/35422/SC_review_Jan2017/

[awkawk]

Closing since the pull request is in place. Comments go there now.

[lseeman]

https://www.w3.org/TR/webauthn/ and https://www.w3.org/Webauthn/is the web authetification that is refered to in the techneques . Conforming to it enables complete conformance

[awkawk]

This issue is closed - discussion should be over on the pull request.

[lseeman]

Dividing into two 1.User Authentication Methods: A mechanism is available that user authentication does not rely upon a user's ability to memorize information; recall information from memory; speak; or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page. techniques involve being able to reset via an email sent with a new link , or google log in or bimetoics, smart card or allowing browser to rember your password etc.

An alteritive could be to just require A mechanism is provided that enables the user to retrieve or reset their user authetification details

2. Users are not require to memorize character strings, including memorizing correct spellings; or perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or speak unless it is essentisal for the main function of the site

[patrickhlauke]

An alteritive could be to just require A mechanism is provided that enables the user to retrieve or reset their user authetification details

are there many examples of sites that do NOT provide you with a "forgot your id / forgot your password" type functionality? i find this to be almost ubiquitous when it comes to sites that allow account creation and login. is the use case for this SC in that form strong?

[lseeman]

My bank would be an example. if you get the poassword wrong 3 times you need to drive to the bank to get a new one. but yes, it is not a great option - but we were trying to think of ways to reduce the burden whilst increasing awearness. I am not realy pro that solution myslef

[mapluke]

@patrickhlauke I personally believe that we won't get acceptance of an SC (option 1) that can only be fully met by the user of things like smartcards or 3rd party authentication (see my comment below). I believe that at least one of the many arguments against option 1 will be "undue burden".

User authentication on most websites/services rely on the use of a username/password combination as at least one option. Option 2 was proposed (not sure by who), and reworded by me, as an additional SC to improve the accessibility of the cognitive-unfriendly username/password method. Password reset/retrieval is essential for people with cognitive impairments who have impaired long-term memory.

I agree that this is almost universally done, but that ensures that at least this proposal will not be rejected because of "undue burden". Is it inappropriate to propose an SC that has clear cognitive accessibility benefits just because it is more or less standard current practice (and also benefits all users)? I am not sure.

[mapluke]

The accepted understanding is that user authentication depends on at least one of the following:

1. Something you know (eg. a password);
2. Something you have (eg. a smart card). arguably Google and Facebook sign-in falls into this category as you have to have a Google or Facebook account;
3. Something you are (eg. biometrics such as a fingerprint).

The "something you know" is the biggest cognitive accessibility challenge because, by default, users have to recall memorized information. In practice, there are widespread "assistive technology" solutions to support people with impaired memory (and the rest of us) such as password managers (e.g. LastPass). It is not possible to propose an SC that directly addresses option 1, but "A mechanism is provided that enables the user to retrieve or reset their user authetification details" is something that can help a person who cannot remember their login details.

The "something you have" option will only provide accessible user authentication to those people who have the required thing(s) (e.g. a smartcard or a Facebook account). I don't believe that it is acceptable to draft an SC that can only be met on the assumption that users have an unspecified something that proves their identity.

Similarly, the "something you are" option usually depends on device-based biometric sensing which cannot be presumed to be available to all users. I do not see how those providing the content can claim to meet an SC on the assumption that users will be able to biometrically prove their identity. In almost all cases, the content authors will have no idea of which users may be able to use device-based biometric identification.

So overall I do not see how the current "Option 1" SC proposal can meet the strict requirements that an SC needs to meet.

[mapluke]

I am not convinced that it is possible to draft SC text that solves all of the cognitive accessibility issues associated with cognitive accessibility. Do any WCAG SCs provide such comprehensive solutions to complex processes like user authentication?

In the spirit of addressing avoidable cognitive accessibility barriers that occur as part of user authentication procedures, I offer the following proposal:

A user authentication method is available that does not rely on a user's ability to correctly identify and enter numbered characters from a memorized character string.

NOTE: Some user authentication methods ask a user to, for example, enter, the third, sixth and seventh characters from a word that they have previously chosen. Such mechanisms require users to be able to:

a) correctly locate the correct characters by counting from the beginning of the word;

b) hold the located characters in short-term memory long enough to correctly enter these characters;

c) complete the task without the cognitive resources involved in step a) and step b) interfering with each other.

Such methods present significant barriers for many people with cognitive and learning disabilities. e.g.:

• users with learning disabilities such as discalculia may be unable to accurately perform step a).
• users with impaired short-term memory may be unable to perform step b).
• users that have impaired working memory may be unable to simultaneously perform both step a) and step b).

This SC can be met if such awkward procedures are not used or, if such a method is offered, an alternative method is offered that can be used instead of this procedure.

[joshueoconnor]

@mapluke [chair hat off] I agree with Mike here. This brings up the question of what is an 'acceptable cognitive load'. We have to find what that means as I don't think that is clear (and not easy to define). If it is acceptable for COGA purposes that a person can perform task type A, but not type B - then by all means we can look at methods to support task type A - however, every human task has some cognitive overhead.

I also wonder about a 'one size fits all' approach to defining working or acceptable solutions - as this area more than most - is a subjective experience. So we need to be careful about what we define and flexible in what we accept.

On another point, we cannot simply remove all cognitive overhead/load from any task relating to consciousness and I just don't think that should be the goal. We could be doing a disservice to many who maybe just need more usable solutions. So from what I see with many COGA type issues - the actual barriers may not be cognitive issues per se but usability issues.

[lseeman]

Based upon feedback from AG members, the COGA Task Force suggests the following revision. Are you content with it? If not, we can have a call with COGA members to discuss. Or, you can just provide any comments to the SC 23 discussion on GitHub. Thank you.

The proposal is to divide SC 23 into two separate success criteria.

SC 1

User Authentication Methods: A mechanism is available that user authentication does not rely upon a user's ability to memorize information; recall information from memory; speak; or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page.

Techniques involve being able to reset authentication credentials via an email message sent with a new link; and/or use third-party authentication, biometrics, a smart card, or allow a browser to remember a password, etc.

SC 2 we could merge this with on task completion -Issue 21 #21 (@awkawk - can you merge this what do you think_

Users are not required to memorize information, character strings, and correct spellings; or perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or speak, unless it is essential for the main function of a web site.

[mapluke]

I'm afraid I think that thus proposal is rather a mess. It fails to accurately capture the potentially acceptable stand-alone proposals that were made during the COGA call, and instead tries to merge them into text which is never likely to be accepted e.g. "beyond the mental processes that are required to use a simple web page".

[lseeman]

I am confuced mike, You were on the call and I copied this from John's summary to the list. please email me the language that you remember.

[lseeman]

@mapluke @JohnRochfordUMMS Can we just have: Successfully completing tasks does not rely on users memorizing information character strings, and correct spellings; speak; or perform calculations, such as correctly identifying and entering numbers and letters from a character string or memorizing information presented in the current, or previous, user-interaction dialog steps; unless it is essential for the main function of a web site.

It addresses dialogs, authertification and capture

[lseeman]

Ah I see, you are suggesting "A user authentication method is available that does not rely on a user's ability to correctly identify and enter numbered characters from a memorized character string"

What about getting the address right of your childhood home? I think that is included the problem is people can include too many failures such as sending a string to your phone that you type in. That uses working memory but very few people realize that.

@JohnRochfordUMMS are you OK with this?

[DavidMacDonald]

What about a simple requirement that users can recover their lost authentication? For a 2.1 that seems reasonably doable.

User Authentication Methods: A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

[mapluke]

@DavidMacDonald I believe that this simple requirement is easily doable (i.e. no undue burden) and frequently done. There are also numerous existing well proven techniques to meet such an SC. Such a requirement should not be buried as a technique for the current complex and very questionable #23 proposal.

[lseeman]

How about the following It give two options but one of them must be doable by people from coga groups

For user authentication one of the following is true -A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak. -A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.

It needs some work but does the gist meet all our concerns? Many sites already conform to the second options (as @DavidMacDonald and @mapluke pointed out) but this requires it to be simple. The point of adding the first option is:

• if people can not have a simple reset option fro security reasons, then another way to conform is available
• it makes it clear what the issues are, and people can see that doing both is better. Also

[lseeman]

I am in an optermistic mood. If there are no objections I will update the wording with the last proposal

[DavidMacDonald]

For user authentication one of the following is true

• A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.
• A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

[lseeman]

@DavidMacDonald is that a wording change? It looks the same to me

[DavidMacDonald]

The second bullet is the opposite

A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

the idea is that they can retrieve it and refer to it, read it out and copy it into the authentication screen. I often forget passwords, but as long as I can have it sent to me then I'm fine. I just copy and past it over, or look at the email that has the password that was sent to me, and type it into the web page.

[jnurthen]

We should not be encouraging people to send passwords. This means they are storing the password which they should never be doing.

On Mon, 10 Apr 2017 at 12:01 David MacDonald notifications@github.com wrote:

The second bullet is the opposite

A mechanism is available to retrieve or reset authentication that relies upon a user's ability to memorize or recall information.

the idea is that they can retrieve it and refer to it, read it out and copy it into the authentication screen. I often forget passwords, but as long as I can have it sent to me then I'm fine. I just copy and past it over, or look at the email that has the password that was sent to me, and type it into the web page.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/23#issuecomment-293046579, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpQP2Ffh4SlTpkT3qE2c33fh59Q6xnyks5runxsgaJpZM4K7kUh .

[mapluke]

This is a very important point. I think that we should delete the words "retrieve or" as we cannot require services to implement unsafe policies.

[DavidMacDonald]

So it would be simply to "reset" it.

[mapluke]

That's what I thought.

The advantage here is that we have plenty of evidence that this works as it is very widely implemented. Someone commented that we didn't need an SC that said this because it is already almost universally implemented, but I don't buy that.

In the COGA TF we have often met the criticism that implementing some of the SCs would be an undue burden or not possible due to the lack of suitable ready-to-implement techniques. We don't also want to get knocked back for exactly the opposite reason too!!

[mbgower]

In today's call, @lseeman said that both Facebook and Google were examples of companies that met the reset bullet of this draft SC.

A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.

I wanted to clarify that this is not the case.

Google

Following their process, I was provided with a range of actions I could carry out, which all relied on memory or I was provided with a code I had to copy:

1. Enter the last password that you remember
2. Get a verification code by text message or phone call at: (•••) •••-••98
3. Google will send an email containing a one-off verification code to mb•••••@yahoo.com
4. Answer the security question that you added to your account
5. When did you create this Google Account?

   Facebook

   I activated the "Forgot account?" link. FB offered an ability to send a reset code, which I would then need to copy.

Please enter your email or phone number to search for your account.

Email me a link to reset my password m*****r@yahoo.com facebook@wafflerama.com

Text me a code to reset my password +*****98 Enter Security Code Please check your email for a message with your code. Your code is 6 numbers long.

So in both scenarios, the user is at least required to copy the reset code (and know an email address and password for that email account in order to receive the reset code).

[lseeman]

        I think I said the W3C definitely did (I know that as I did it this week at least once) I thought Facebook or google did but was not sure. All the bestLisa SeemanLinkedIn, Twitter---- On Tue, 18 Apr 2017 20:15:00 +0300  Mike Gower<notifications@github.com> wrote ----In today's call, @lseeman said that both Facebook and Google were examples of companies that met the reset bullet of this draft SC.  A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.  I wanted to clarify that this is not the case. Google Following their process, I was provided with a range of actions I could carry out, which all relied on memory or I was provided with a code I had to copy:  Enter the last password that you remember Get a verification code by text message or phone call at: (•••) •••-••98 Google will send an email containing a one-off verification code to mb•••••@yahoo.com Answer the security question that you added to your account When did you create this Google Account?  Facebook I activated the "Forgot account?" link. FB offered an ability to send a reset code, which I would then need to copy.  Please enter your email or phone number to search for your account.   Email me a link to reset my password m*****r@yahoo.com facebook@wafflerama.com   Text me a code to reset my password +*********98 Enter Security Code Please check your email for a message with your code. Your code is 6 numbers long.  So in both scenarios, the user is at least required to copy the reset code (and know an email address and password for that email account in order to receive the reset code).  —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.   

[lseeman]

Hi Mike

I just tried the facebook one

I had : Please enter your email or phone number to search for your account. followed by How would you like to reset your password? Email me a link to reset my password lisa.seeman@zoho.com

in other words you get a link to your email and you do not need to copy anything. This is the intent of the second option.

If people think that remembering their email address (or thier name ) is included in ""memorize or copy information" then we need to clarify that that is not included. Clearly people do need to remember their name or email address or phone number to reset the password. That will be true on any system as the system needs to know who is reseting the password. SOmething like"A mechanism is available to reset authentication that does not require the user's ability to memorize or copy information or character strings or perform calculations other then remembering their contact information"

if people feel it is needed we can also work on a defintion for contact information

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Tue, 18 Apr 2017 20:15:00 +0300 Mike Gower<notifications@github.com> wrote ----

In today's call, @lseeman said that both Facebook and Google were examples of companies that met the reset bullet of this draft SC. A mechanism is available to retrieve or reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak. I wanted to clarify that this is not the case. Google Following their process, I was provided with a range of actions I could carry out, which all relied on memory or I was provided with a code I had to copy: Enter the last password that you remember Get a verification code by text message or phone call at: (•••) •••-••98 Google will send an email containing a one-off verification code to mb•••••@yahoo.com Answer the security question that you added to your account When did you create this Google Account? Facebook I activated the "Forgot account?" link. FB offered an ability to send a reset code, which I would then need to copy. Please enter your email or phone number to search for your account. Email me a link to reset my password m*r@yahoo.com facebook@wafflerama.com Text me a code to reset my password +*****98 Enter Security Code Please check your email for a message with your code. Your code is 6 numbers long. So in both scenarios, the user is at least required to copy the reset code (and know an email address and password for that email account in order to receive the reset code). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mbgower]

in other words you get a link to your email

Did you actually do it? Because as I indicated, when I proceeded further, you get 'Please check your email for a message with your code. Your code is 6 numbers long."

[mraccess77]

@mbgower could the difference be in whether you have two factor authentication turned on or not?

[lseeman]

I did it all the way though. You can either copy a code OR press a link. In other words , it is fine

All the best

Lisa Seeman

LinkedIn, Twitter

---- On Wed, 19 Apr 2017 05:04:42 +0300 Mike Gower<notifications@github.com> wrote ----

in other words you get a link to your email Did you actually do it? Because as I indicated, when I proceeded further, you get 'Please check your email for a message with your code. Your code is 6 numbers long." — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mbgower]

@mraccess77, that's possible; however, the text Lisa and I received was identical. If she can carry out the last step, she can confirm whether she also has a requirement to copy a 6 number code.

As well, the code is arguably only a single factor of authentication, with the email or SMS being the delivery agent. The targetted delivery adds a level of security, but I wouldn't think it would be considered a second factor.

[mbgower]

The point I'm making is that copying over a code is a very common method of authentication. The original proposed text of this SC did not contain language about disallowing copying, so I'm wondering when and why it was introduced. As written, I believe it would fail widespread practices, and if it is going to remain as part of the text, think we need a reason why. I don't see any relevant information in COGA issues papers, etc

[patrickhlauke]

The point I'm making is that copying over a code is a very common method of authentication. The original proposed text of this SC did not contain language about disallowing copying, so I'm wondering when and why it was introduced.

agree with @mbgower here. i'd find that abolishing the copying of information (which i'd argue is far less onerous for a user than having to remember it) would seriously start to clash with security considerations, at it would essentially discourage two-factor authentication

[mapluke]

I'm also unsure where the "copying" came from?

I introduced the idea of having to have an alternative to schemes where you are asked to enter, say, the third fifth and ninth characters of a personal word or phrase. This arguably involves "copying" these characters from a metal visualisation of the word or phrase and then entering them. This is an increasingly common, and cognitively very challenging, form of authentication. This proposal was originally meant to be very specific to one type of authentication challenge and not meant to argue for no copying.

I would also like to see the "copying" removed. To be honest, I'd like to maximise the chances that this SC gets accepted by limiting it to just address reliance on memorization and recall.

[mapluke]

Sorry for the accidental close. I didn't get very clear feedback that the comment had been successfully completed and thought that the close, meant close the editing of the comment - which sounded rather strange. Now I know what "Close and comment" actually means :-)

[mbgower]

I introduced the idea of having to have an alternative to schemes where you are asked to enter, say, the third fifth and ninth characters of a personal word or phrase.

Right. There is some language around that ("or mentally process presented or recalled information beyond the mental processes that are required to use a simple web page") and I think we could even add in guidance on limits to the length of the code string if we have good research to back that up.

[johnfoliot]

Patrick wrote:

would seriously start to clash with security considerations, as it would essentially discourage two-factor authentication

A huge +1 here.

Having previously worked at a major US-based bank, I know for a fact that they are obligated under US Federal Law to support and provide stronger (including "multi-factor") authentication, and so any proposed SC that would run afoul of (or otherwise weaken) that requirement would be a non-starter.

"The 2005 guidance instructed financial institutions to conduct and document the results of an Internet banking risk assessment. In the assessments, banks were required to identify high-risk transactions and, if they existed, strengthen Internet authentication standards if only passwords were used. The guidance defines high-risk transactions as those that allow the transfer of funds to third parties or provide access to nonpublic personal information. For example, bill pay, a common Internet banking product, allows funds to be transferred to third party payees."

(source: https://www.fdic.gov/regulations/examinations/supervisory/insights/siwin07/article05_authentication.html )

Other forms of multi-factor authentication (such as bio-metrics, or tokens) have issues with scale and support: for every bio-metric solution you can present, I can present users who will still be shut-out, and providing millions of customers with an RSA token (dongle) has a distribution and scale/management issue associated to it as well, one that not every financial institution in America may be able to manage efficiently or cost-effectively. Additionally, even using these types of dongles have their issues (or at least they did 4 years ago when we were doing research at JP Morgan Chase) in that they were "unfriendly" to non-sighted users, due to their digital output screens.

Question: in the FDIC guidance referenced above, there is a "legal" definition of "High Risk" that perhaps we may want to contemplate adding to our SC in some fashion (perhaps as an exception marker?), and split the requirement over the two types of "risk management" the client must be responsible for: "standard" (i.e. logging into Facebook) versus "High Risk" (logging into my banking site).

Just a thought...

JF

On Wed, Apr 19, 2017 at 9:01 AM, mapluke notifications@github.com wrote:

Sorry for the accidental close. I didn't get very clear feedback that the comment had been successfully completed and thought that the close, meant close the editing of the comment - which sounded rather strange. Now I know what "Close and comment" actually means :-)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/23#issuecomment-295280437, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c2WszIyZj8sRfgQSRVs9cQOTk88Mks5rxhOegaJpZM4K7kUh .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com

Advancing the mission of digital accessibility and inclusion

[DavidMacDonald]

For user authentication one of the following is true

• A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string; see; hear or speak.
• A mechanism is available to reset authentication.

[mbgower]

@DavidMacDonald, a bit of house cleaning. I removed the bit about copying, which seemed to have traction to drop. I've cleaned up some weird left over language "such as including". I've also removed "see; hear or speak". Two reasons for this: it's a real departure from WCAG guidance to date and there was indication in the thread that a requirement for memorization was the primary issue we were trying to curtail. That let me remove the semi-colons, and also kept this from needing to be a list within a list.

---

For user authentication one of the following is true:

• A user authentication method is offered where the user is not required to memorize character strings or other information, or perform calculations such as correctly identifying numbers or letters from a character string.
• A mechanism is available to reset authentication.

[lseeman]

For user authentication one of the following is true:

• A user authentication method is offered where the user is not required to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string
  • A mechanism is available to reset authentication that does not require the user's ability to memorize or copy information or character strings; perform calculations, such as including correctly identifying and entering numbers and letters from a character string, beyond remembering basic contact information.

Note that requiring the user to remember basic contact information such as their name, current phone number or email address is not excluded by this success criteria .

NOTE: I am fine with getting rid of the second bullet and making it a tequnequ of the WG prefers it.

based on survey Use of or any reference to password retrieval is strongly objected to - so it is removed

Katie suggested: "Accessible Authentication Methods: A mechanism is available to reset any authentication method that relies upon a user's ability to memorize or recall information.” - this is the second bullet with some required additions . However some sites can not use this becuse of security considerations, (such as my bank) SO giving them the option of the first bulet - which can be met with a card, biometrics, phone token , conforming to the W3C''s web authentication specification and other methods make it much more widely addoptable

The end of the bullet point has been removed as it is coverd else were.

Note survey results are at https://www.w3.org/2002/09/wbs/35422/SCs_April_11/results#xq10

[lseeman]

@DavidMacDonald @mbgower your cleaner wording does not address the use cases I am afraid. For example, if you require a security question for the reset then you are typicaly baring millions of people from using the service

[patrickhlauke]

@lseeman this still includes the "copy information" part which was noted as potentially barring two-factor / multi-factor authentication?

also, is this still fundamentally mixing up the idea of authentication (where a user proves WHO they are, e.g. to access their personal account) and more generic CAPTCHA-style challenges (where a user proves that they are indeed a human, and not a bot)?

the latter scenario can be made a lot tighter in terms of what sites should NOT rely on. but in the case of actual authentication, sites MUST challenge the user in a way that guarantees only that particular user would be able to pass through, and saying a method needs to be there that doesn't require users to memorize (or copy) things seems incompatible with being able to provide solid authentication (or would effectively mandate that every site also invest in some form of biometric security system or similar?)

if this is indeed still mixing the two, i'd strongly urge to disentangle these two scenarios into separate SCs

[patrickhlauke]

the act of resetting an account would usually fall across both of the above scenarios. to request the reset, a site would generally only need a CAPTCHA style challenge (as just to request a reset would theoretically not need to check that it's indeed the user herself asking for the reset). but at the completion of the reset request, the user would then be sent an email, text message, or similar (to their registered email address, phone number, etc) which then would require them to either follow a link and/or copy and enter a one-time passphrase/key - and this is the part where copying should be allowed, and it's the part that simply can't simply do away with "copying", as the point here would be that only the individual in question would have access to that particular email address/phone number, and copying a confirmation code would be the act of proving that they indeed are who they claim they are.

[mbgower]

@lseeman, as Patrick mentioned, you added back in the "copy" concept. you also added in the nonsensical words I took out in the first bullet. Please tell me what is wrong with:

A user authentication method is offered where the user is not required to memorize character strings or other information, or perform calculations such as correctly identifying numbers or letters from a character string.

In regard to Katie's rewrite of the second bullet...

A mechanism is available to reset any authentication method that relies upon a user's ability to memorize or recall information.

That's an improvement, but it also doesn't prevent memorization from being part of the reset process, which seems to be paramount? So while I feel like this is progressing, I want to make sure the original desires are considered.

@patrickhlauke raises the same point I initially did last fall: this SC mixes apples and oranges. Here's my original comment to the task force:

There seem to be two matters tackled here: one covers an advanced version of CAPTCHA; the other deals with login. A test that verifies someone is a human is arguably different than an authentication process. The former in its current state is a consideration which affects all 4 principles of WCAG; while the latter need not be different in nature from any other user input – however the surrounding process may need to address non-repudiation, authentication and access control.

Any security-related SC really should address those last three matters head on: non-repudiation, authentication and access control.

Looking back over my original submission, I flagged there is an excellent paper referenced in the COGA background info called Security and Privacy Technologies. It tackles the issue differently than the original SC and clearly distinguishes between password authentication, CAPTCHA and two-factor authentication.

I believe that revisiting the recommendations in that paper may be a good exercise to make sure this SC does what you want. It covers 4 different proposed solution areas:

• w3c recommended guidelines and techniques
• ease of use ideas
• Alternative web security and privacy technologies
• CAPTCHA alternatives

[lseeman]

@patrickhlauke @mbgower Unfortunately copying is a real barrier and the two stage authentication, although popular, means may people can not use the service. Have the two stage authentication send a web link or token works well. For example. I do not have a visual memory. Copying accurately is close to impossible. (I think this is discussed in detail in the issue paper.)

Note it is in the original wording - ""perform calculations, such as including correctly identifying and entering numbers and letters from a character string; or " Further copying always requires the use of the user's working memory. - One of the first things to malfunction in dementia. Whilst I apritiate the wish to "clean up the wording" we need to address the user need and let people carry on loging in and carry on working and functioning independently as long as possible.

[mbgower]

If copying is a real barrier, why wasn't it in the original SC language? And why isn't it listed in the considerations backgrounder (and if it is, where)? I'm trying to understand how cutting and pasting (which requires no memory usage and avoids any transposition problem) or the direct transcription of a simple text string warrants exclusion from this SC. Please provide references. If we want to place a limit on the size of the string based on data, that's one thing. Just saying "it's a barrier" does not provide any insight.