3.3.8/3.3.9: How is "authentication process" defined?

[dbjorge]

As we're starting to develop step-by-step guidance for testing 3.3.8 and 3.3.9, we're noticing that different folks are a bit unclear about exactly what constitutes an "authentication process" for the purposes of applicability to these requirements, since WCAG 2.2 doesn't formally define it.

I see that there were some past discussions of this in https://github.com/w3c/wcag/issues/1256 and https://github.com/w3c/wcag/issues/1463

Some examples at the boundary:

1. A website allows anonymous comments, but requires users fill out a CAPTCHA to post one. Is filling out a CAPTCHA on its own with no further identifying information an "authentication process"?
   • The past issues I linked above suggest "no", but I think this is contentious; IBM documents that they think "yes", and without a normative definition in WCAG, it's easy to find supporting examples of both sides.
2. A website's user registration process includes a step that verifies a user's email address by sending them an email with a one-time confirmation link. Does the act of sending the confirmation link mean that the user registration process as a whole is now an "authentication process", where without that verification step it would only be a later login process that would count?
3. In the #1256 discussion, folks were generally agreeing that just the act of offering an identity (eg, an email address) without any step to confirm the authenticity of that information was probably not enough to constitute "authentication". What is the boundary of how private information must be to constitute "authentication"? For example, which of the following count as "authentication processes"?
   1. An online bank account sign-up form that requests your social security number
   2. An employment application form that requests just the last 4 digits of your social security number
   3. An airline boarding pass website that asks for a flight confirmation number
   4. An airline boarding pass website that asks for a flight number + last name
   5. A marketing website for an R-rated move that asks for your birthday before being allowed to view the website
   6. An online poker game allows game hosts to set password for their table. The host's friends can use the password to join the table (even if they are not logged in as a specific user)

Ideally, there'd be a normative definition that disambiguates this, but since that's probably not feasible to add at this point, it'd be nice for us to at least define the term in the understanding doc.

[patrickhlauke]

authentication, for me, has always read as "logging into an existing account" and along the lines of https://en.wikipedia.org/wiki/Authentication#Authentication_factors

my take would be:

1. no, just solving a CAPTCHA does not verify the identity of a user. it just verifies (supposedly) if they're human or not. it doesn't verify who they are, but what they are
2. that's an interesting wrinkle, but to me in this case it's a no as well. because the idea is that to pass the requirement of the SC, then there should be an alternative to the challenge. but at this point, as the user is still in the process of setting up their account, they most likely haven't provided enough data to allow for an alternative?
3. to me (and perhaps that's down to my personal interpretation of what "authentication" means?) most of those don't seem to be examples of authentication in the "logging into an existing account" sense

[alastc]

I agree with Patrick's take(s), we almost called it "re-authentication", but that was already taken.

There was discussion that creating an account would probably involve things that wouldn't pass the SC, and it should not apply there.

The airline example (and some delivery firms) are interesting because they allow access to certain data with sufficient details, or logging in. I think this would only apply to the logging in route. (E.g. you can track a parcel with the tracking number and zip/post code, or login.)

[dbjorge]

I definitely think we're in territory where there are many different reasonable definitions we could use here. For example, the US National Institute of Standards and Technology (NIST) maintains a glossary entry for "authentication" that cites a few dozen distinct definitions of "authentication" just from among NIST/FIPS-200 sources.

I think some of those definitions are fairly close to your interpretations, though I think the wikipedia article in particular is a bit rough to use as a starting point for such an interpretation:

• Its opening sentence uses an extremely general definition, where identity of a user is just one non-exhaustive example of an assertion that an authentication process might be proving: "Authentication... is the act of proving an assertion, such as the identity of a computer system user."
• The "Authentication factors" section of that article, which Patrick linked earlier, explicitly includes "challenge-response", which in turn explicitly lists CAPTCHA as an example.

FIPS-200 and ENIST's Incident Response Glossary both provide starting points we might consider that would probably be more reasonable choices than a wikipedia article. Respectively,

AUTHENTICATION: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an information system.

and

Authentication is a way to ascertain that a user is who they claim to be. This is usually performed by presenting one or more challenges to the user. There are three broad categories of challenges:

• Something the user knows. The user is asked for a secret, known only to her. Typical examples are passwords and PINs, but can also take the form of security questions.
• Something the user has. The user is in possession of a unique token, like a key. In the case of computer tokens, this can take the form of an NFC tag, or a device.
• Something the user is. Aka biometrics. The user is asked to present a part of her body that forms unique and repeatable patterns, like fingerprints, voice, or face recognition.

I think the theme among these is that it does require that an "authentication process" verify an "identity" (which I would interpret to mean that a CAPTCHA on its own probably doesn't qualify), but that it does not require that the identity be in the form of a pre-existing account on the same website (ie, a process that involves verifying ownership of an email address or that asks the user to confirm their social security number would qualify).

[dbjorge]

There was discussion that creating an account would probably involve things that wouldn't pass the SC, and it should not apply there.

Do you have a recollection of when/where this discussion happened? The most applicable looking stuff I've found digging through past issues/minutes/surveys was question 14 of this survey from 2019, but the only comment there that's specifically concerned about "creating an account would probably involve things that wouldn't pass" only seems to use an example of "needing to provide a memorized password as part of the registration process" as being problematic. As I understand it, we've substantively changed the understanding document since that original discussion to clarify that so long as copy/paste is allowed between a password manager and a password field, that's allowable - I think that's true regardless of whether the password field is in a registration form or a login form, so I'm not sure it's necessary for us to except it.

[patrickhlauke]

I think that's true regardless of whether the password field is in a registration form or a login form

the idea though is that it's helpful for authentication scenarios because, presumably, you already have data stored in your password manager that you can then paste if it's a site that you're returning to and already have an account on. whereas for a registration, you may not (though there are of course scenarios where browsers can autofill fields for you, and that then falls more under 1.3.5 Identify Input Purpose, though that SC says nothing about allowing pasting as such).

similarly, for things like CAPTCHAs or even email verification ... the idea of providing an alternative that does not involve either remembering something or solving a puzzle becomes trickier in registration cases where the user has not provided anything else yet that the site could use as an alternative.

i believe it's because of these that the decision was made to at least narrow down the scope of the criterion to authentication in the sense of logging into an already set-up account.

[dbjorge]

the idea though is that it's helpful for authentication scenarios because, presumably, you already have data stored in your password manager that you can then paste if it's a site that you're returning to and already have an account on. whereas for a registration, you may not (though there are of course scenarios where browsers can autofill fields for you, and that then falls more under 1.3.5 Identify Input Purpose, though that SC says nothing about allowing pasting as such).

I'm not sure I understand this distinction. As a user of a (non-browser-built-in) password manager, my typical workflow when creating a new password during registration of a new account is to create a new entry for the account in my password manager, have it generate a new password and save it to the password manager entry, and then use the password manager's autofill function to copy the new password into the registration form's "create your new account's password" field. The password manager's autofill or copy/paste function enables me to avoid having to memorize or transcribe the new password myself to fill out the registration form. It's no more or less helpful on the registration form vs the login form.

similarly, for things like CAPTCHAs or even email verification ... the idea of providing an alternative that does not involve either remembering something or solving a puzzle becomes trickier in registration cases where the user has not provided anything else yet that the site could use as an alternative.

For email verification, the use of a one-time link to authenticate ownership of an email address is already specifically called out as a sufficient technique in G218. For CAPTCHAs, we already except some types of CAPTCHA in the AA criterion; I do not understand why a cognitive-function-test-as-a-CAPTCHA would be any more or less of an accessibility barrier during registration of an account vs login to an account.

Anyway, regardless of whether we decide to use a narrow or broad definition of "authentication process", we should document clearly what qualifies and what does not, at least in the understanding document - being ambiguous is a bigger problem than being narrowly-defined, even if I'd prefer a broader definition.

[patrickhlauke]

the distinction is that for authentication (as in logging in) with a password it's about avoiding a user (particularly with cognitive disabilities) having to recall/remember a previously provided password. in the case of registration, they're not needing to recall/remember anything since at that point they've not previously provided anything.

[bruce-usab]

I will propose an update to Understanding providing some examples where account creation can be different from (re)authentication processes.

[bruce-usab]

I propose adding a sentence to the end of Intent:

This Success Criterion does not address creation of a username or initiating an account. For many web sites, establishing an initial username is not significantly different than logging in with that username. However, for many other web sites, the processes are quite different. Moreover, the means used for creating an account vary more than the means used for re-authentication. This is because initial authentication may require more due diligence with assuring the identity of a new user. Another substantive difference between first authentication and re-authentication is that a third party, human or automated, is often required.

[yatil]

Not that it matters much at this point, but as a non-native speaker I did not understand that “Authentication” means ”Re-Authentication”, and without a definition, I’m unclear how I would have gathered that from normative sources.

[fstrr]

I've seen some confusion with this recently, including authentication including:

1. having to answer an equation before being able to submit a form
2. having to transcribe a product key from the bottom of a router into an online product registration form

I do think it would be helpful to clarify exactly what is meant by authentication.

[patrickhlauke]

A colleague just pointed out that, for added spice/confusion the definition of "process" (references in both 3.3.8 and 3.3.9) confusingly gives an example of registration, which we're saying is not what we intend authentication to mean.

An account registration page requires successful completion of a Turing test before the registration form can be accessed

https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html#dfn-process

If we're indeed trying to scope these SCs to just cover (re)authentication, we should really amend that definition, as this is now in direct contradiction to what the intention is...

(gratuitous "see slide 68 in my presentation" link https://patrickhlauke.github.io/wcag-interpretation/#68)

[patrickhlauke]

See https://github.com/w3c/wcag/pull/3538

[KevinP-NZ]

the distinction is that for authentication (as in logging in) with a password it's about avoiding a user (particularly with cognitive disabilities) having to recall/remember a previously provided password. in the case of registration, they're not needing to recall/remember anything since at that point they've not previously provided anything.

Even that first registration often requires a user to reproduce the password - you enter the password and then have to confirm it. Without the ability to copy/paste, or at least view what you placed in the first box it is a cognitive test (especially when your typing is as bad as mine)

[KevinP-NZ]

I've seen some confusion with this recently, including authentication including:

1. having to answer an equation before being able to submit a form
2. having to transcribe a product key from the bottom of a router into an online product registration form

I do think it would be helpful to clarify exactly what is meant by authentication.

Unless the use of the router ID is to prove who you are that is clearly not authentication.

[patrickhlauke]

Even that first registration often requires a user to reproduce the password - you enter the password and then have to confirm it. Without the ability to copy/paste, or at least view what you placed in the first box it is a cognitive test (especially when your typing is as bad as mine)

not disputing that that's a cognitive test. also things like CAPTCHAs for a simple form submission (such as being able to comment on a blog - not logging in or anything, just commenting) is of course a cognitive test. but the SC is scoped to "authentication process", and it was understood to mean "proving who you are", which is not what you're doing in those cases (you're not proving your identity when creating an account, nor when solving a captcha to post a comment, etc)

[GreggVan]

interesting point Patrick -- Captcha is not authentication... hmmmm Another barrier - proving your human -- is different than authentication and not covered.

[patrickhlauke]

In part I believe the issue is that 3.3.8/3.3.9 tried to cram two separate concepts into the SCs - the challenge of having to remember information for authentication, and then the idea of cognitive function tests/puzzles/CAPTCHAs but only in the scope of authentication. in hindsight, the second aspect should probably have been spun out into its own SC(s) to make it applicable to non-authentication scenarios.

[abijames]

There is also confusion about whether accessible authentication only applies to logging in or also to authentication tasks after login. As WCAG 2.2 AA compliance is now required within UK public sector organisations the ambiguity around whether it only applies to login or all authentication is being debated and causing confusion. The understanding document In brief and Intent sections refer to "login" not authentication implying that the success criteria only applies to log-in authentication situations.

If we take the ENISA definition that authentication is "a way to ascertain that a user is who they claim to be" then this would also apply to any authentication steps required after a user has logged in. Typical examples include:

• authorising a payment (2 factor authentication is require for e-commerce in EU and UK)
• making a non-reversible change to a system or file such as entering an admin password

People with disabilities face the same barriers to authentication in these situations as they do on the initial login step (UK Which survey reported reported 21% of people with disabilities reported struggling with passwords and security devices). I fear that in attempts to make the understanding document easier to read, the original intent has been diluted. Looking back at the COGA notes and earlier drafts of this SC, there doesn't seem to be any direction that this should be limited only to login authentication. Publishing a definition of authentication (or referencing one) would provide much needed clarity or amending the understanding document to be clear that logging in is only one such authentication scenario (and providing examples).

[mbgower]

interesting point Patrick -- Captcha is not authentication... hmmmm Another barrier - proving your human -- is different than authentication and not covered.

I feel like this statement is not entirely true. Research supported that CAPTCHA was (improperly) being included as a step during authentication, even though CAPTCHA in no way authenticates an individual. As such, the SC covers it where it is part of the authentication process, and where the method places higher demand on cognition (at the AA level).

We could consider having an independent SC focused on CAPTCHA, but there would need to be research to identify how widespread it is in preventing a user being able to complete a task, and what the effects would be of effectively outlawing CAPTCHA. The conclusion could be that such an SC is needed at A/AA level, and that going forward in 3.0, CAPTCHA should be entirely separated from authentication considerations.

But I think that discussion is separate from this issue, which is 'what is an authentication process?'

Can people provide examples and clarify the problem?

As a first step, I think we need to get Bruce's suggested wording examined and see to what degree it clarifies things for Dan and others who have commented on this. I began creating a PR, then discovered he had already generated one. I have closed mine, and made some changes to his PR to address comments in this issue. Would people please review and comment on whether the new language wholly or partially addresses this issue? https://github.com/w3c/wcag/pull/3309/files

As a next step, if needed, it would be very useful to have folks identify things they perceive as an authentication process which are causing issues with their interpretation of this SC. It's unclear to me whether the main problem is deciding when to apply it, or if in applying it, the SC requirements are causing issues for interactions we did not anticipate.

[KevinP-NZ]

For sure - CAPTCHA as part of the authentication process is caught by the checkpoint. Captcha as part of a random form submission isn't. I think that's clear but agree a separate checkpoint focused on it wouldn't have been a bad thing. K

From: Patrick H. Lauke @.> Sent: Thursday, November 16, 2023 8:55 PM To: w3c/wcag @.> Cc: Kevin Prince @.>; Comment @.> Subject: Re: [w3c/wcag] 3.3.8/3.3.9: How is "authentication process" defined? (Issue #3264)

CAUTION: This email originated from outside of the organization.

In part I believe the issue is that 3.3.8/3.3.9 tried to cram two separate concepts into the SCs - the challenge of having to remember information for authentication, and then the idea of cognitive function tests/puzzles/CAPTCHAs but only in the scope of authentication. in hindsight, the second aspect should probably have been spun out into its own SC(s) to make it applicable to non-authentication scenarios.

- Reply to this email directly, view it on GitHubhttps://github.com/w3c/wcag/issues/3264#issuecomment-1813948696, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZGJDHAEAGAMAQTNX5R7333YEXBDRAVCNFSM6AAAAAAZ4YCNZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJTHE2DQNRZGY. You are receiving this because you commented.Message ID: @.**@.>>

Kevin Prince

Product Accessibility & Usability Consultant

E @.***

Christchurch

fostermoore.com

This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.

[KevinP-NZ]

It's pretty clear in the checkpoint. Authentication. The Understanding isn't normative but shows mostly log ins as an example but I can only see there being a debate for disruption. Authentication is authentication - if I have to do it to access something after I've logged in once it's still authentication.

From: Abi James @.> Sent: Thursday, November 23, 2023 12:55 AM To: w3c/wcag @.> Cc: Kevin Prince @.>; Comment @.> Subject: Re: [w3c/wcag] 3.3.8/3.3.9: How is "authentication process" defined? (Issue #3264)

CAUTION: This email originated from outside of the organization.

There is also confusion about whether accessible authentication only applies to logging in or also to authentication tasks after login. As WCAG 2.2 AA compliance is now required within UK public sector organisations the ambiguity around whether it only applies to login or all authentication is being debated and causing confusion.

If we take the ENISA definition that authenticationhttps://www.enisa.europa.eu/topics/incident-response/glossary/authentication-methods?v2=1 is "a way to ascertain that a user is who they claim to be" then this would also apply to any authentication steps required after a user has logged in. Typical examples include:

• authorising a payment (2 factor authentication is require for e-commerce in EU and UK)
• making a non-reversible change to a system or file such as entering an admin password

People with disabilities face the same barriers to authentication in these situations as they do on the initial login step (UK Which survey reportedhttps://www.which.co.uk/news/article/bank-branch-closures-and-poor-websites-risk-excluding-disabled-people-aIx2t5m6q4cb reported 21% of people with disabilities reported struggling with passwords and security devices). Publishing a definition of authentication (or referencing one) would provide much needed clarity.

- Reply to this email directly, view it on GitHubhttps://github.com/w3c/wcag/issues/3264#issuecomment-1822631839, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AZGJDHEZONBYYMFYHXQIGG3YFXR2FAVCNFSM6AAAAAAZ4YCNZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRSGYZTCOBTHE. You are receiving this because you commented.Message ID: @.**@.>>

Kevin Prince

Product Accessibility & Usability Consultant

E @.***

Christchurch

fostermoore.com

This email and its contents are confidential. If you are not the intended recipient, you should contact the sender immediately, you must not use, copy or disclose any of the information in the email, and you must delete it from your system immediately.

[alastc]

The task force review the PR and is happy with that, but Scott is going to just check that it answers the examples in this thread.

[mraccess77]

So, do I understand the following 3.3.8 & 3.3.9

• Do not apply to sign-up process
• Do not apply after authentication such as to verify human during session
• Do apply to re-authentication if you need to authenticate after a timeout

[patrickhlauke]

@mraccess77 that's been my understanding, yes

[detlevhfischer]

I think @abijames has a good point that the SC should equally appy to cases where some process after login requires renewed authentification (e.g., when making a payment). Since the Understanding doc is not normative and not exhaustive and the normative text does not specify this is only about login, the question remains whether such cases would be in scope.

[alastc]

Note the PR is going forward as an improvement, but does not completely resolve the issues above.

[mgifford]

Maybe just:

Authentication is a process used to ascertain that a user is who they claim to be.

Built on from https://github.com/w3c/wcag/issues/3264#issuecomment-1622088528

[alastc]

The current PR #3309 can go through, but isn't enough.

From discussion in the Friday meeting, the general thought is that an erratum is needed, with something like:

"AUTHENTICATION: Verifying the identity of a user, process, or device, often as a prerequisite to allowing access to a previously created account."

Plus example block after the definition, and expanding in the understanding doc.

Also, overlap with #3320.

[dav-idc]

Proposed next steps, in order:

1. Make a list of what is not covered by 'authentication process', added to the understanding document
2. Make a list of what is covered by 'authentication process', added to the understanding document
3. Draft a normative change for defining 'authentication process'