Alternative error codes

[MasterKale]

This PR proposes alternative WHATWG DOMException errors to be raised across various WebAuthn interactions. There is an assumption that the user has meaningfully interacted with some part of the ceremony to consent to informing RP's why the ceremony failed.

Fixes #2096.

An explainer is available here: https://github.com/w3c/webauthn/wiki/Explainer:-New-Error-Codes-(2024-Edition)

Note: This PR is targeting #2047 and should not be merged until that PR has been merged.

• OptOutError
• ConstraintError
• TimeoutError

---

Preview | Diff

[nsatragno]

Some general thoughts:

• I am in favour of adding more specificity for error states after the user has chosen to go ahead with the authentication ceremony. This would not result in a significant impact to the privacy properties of WebAuthn and if it solves a pain point for RPs, we should do it. Essentially, most circumstances where the user indicates their consent to sign in, an error is shown, and then the user taps "Okay" or "Cancel" could result in more specific errors.
• However, it's not clear to me that cancelling out of a ceremony constitutes a form of user consent. This PR will allow RPs to distinguish between "the user's authenticator has no passkeys or the authenticator decided the user denied consent" (NotAllowedError) and "the user cancelled out of the ceremony (likely because they did have passkeys but did not consent)" (UserCancelledError). This is especially tricky because the actual browser implementation differs from the letter of the standard with respect to dispatching requests to authenticators, e.g. Chrome will default to the platform authenticator if it knows there's a credential there.

[emlun]

Before getting into specifics: I noted in #2096 (comment) that we can't simply use any value as the name of a DOMException:

When creating or throwing a DOMException, specifications must use one of these names. If a specification author believes none of these names are a good fit for their case, they must file an issue to discuss adding a new name to the shared namespace [...]

So we would need to upstream these new name definitions, or use DOMException derived interfaces instead.

[selfissued]

I support adding these error codes after the cleanups suggested by other commenters.

[MasterKale]

I'm inclined to break this PR up to try and get some of the less contentious new error codes into L3 before the upcoming deadline (which those are, I'll try and identify before today's WG meeting.)

[MasterKale]

I've taken HybridPrerequisitesError and UserHybridCancellationError out of the running for now for sake of pursuing incremental improvement in WebAuthn's error messages instead.

[varunbgit]

@agl @pascoej @jschanck
@MasterKale
What is the plan to merge this PR and release it to public?

[mitchgl]

Are there any updates on this? Seems useful for context for RP's

[MasterKale]

This work is on the back burner for now while we continue to work on getting L3 through the process to get it to Recommendation so that it officially supplants L2. I have every intention of picking this back up when we're further along this process.

[timothymiko]

@MasterKale are there any updates on this? Very interested in this as a RP to get more signal on improving the UX of our passkey flows.