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 #1256 and w3c/wcag3#176

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 WCAG 2.2 Accessible Authentication: clarification on whether this includes CAPTCHAs #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.