Add new error codes #2095
Add new error codes #2095
Conversation
MasterKale
requested review from
agl,
emlun,
nsatragno,
timcappalli,
jschanck and
pascoej
There was a problem hiding this comment.
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.
index.bs
Outdated
| @@ -1946,11 +1946,17 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o | |||
| <dl class="switch"> | |||
| : If |lifetimeTimer| expires, | |||
| :: [=set/For each=] |authenticator| in |issuedRequests| invoke the [=authenticatorCancel=] operation on |authenticator| | |||
| and [=set/remove=] |authenticator| from |issuedRequests|. | |||
| and [=set/remove=] |authenticator| from |issuedRequests|. Throw a "[=create/TimeoutError=]" {{DOMException}}. | |||
There was a problem hiding this comment.
General feedback: this PR needs to update section 14, in particular 14.5.2
For example, one such information leak is if the client returns a failure response as soon as the user denies consent to proceed with an authentication ceremony . In this case the Relying Party could detect that the ceremony was canceled by the user and not the timeout, and thus conclude that at least one of the credentials listed in the allowCredentials parameter is available to the user.
This PR is making it possible to distinguish between these cases.
There was a problem hiding this comment.
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.
|
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.) |
|
I've taken |
| If the user agent is informing the user that | ||
| the last used |authenticator| cannot collect [=user verification=] when | ||
| <code>|pkOptions|.{{PublicKeyCredentialCreationOptions/authenticatorSelection}}.{{AuthenticatorSelectionCriteria/userVerification}}</code> | ||
| is set to {{UserVerificationRequirement/required}}, | ||
| throw a "{{UserVerificationError}}" {{DOMException}}. |
There was a problem hiding this comment.
The equivalent error on the authenticator layer is error code equivalent to "ConstraintError", so I think that could be used here too?
This would lump this together with another ConstraintError thrown when authenticatorSelection.userVerification == "required" and mediation == "conditional", but that is also an error expressing that UV was required but couldn't be performed, so I think that can be okay?
Then we could also add a case to pass through error code equivalent to "ConstraintError" from the authenticator layer, like we do with InvalidStateError.
| : {{UnknownError}} | ||
| :: The [=authenticator=] could not process the supplied options, | ||
| or encountered an error while creating the new credential. |
There was a problem hiding this comment.
I don't think error code equivalent to "UnknownError" is actually passed through by the client operation, is it? I think it's currently only InvalidStateError that's passed through like that.
This PR proposes new error codes 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.
Preview | Diff