Clarify how to differentiate between exceptions about webauthn

[MasterKale]

From 11/1/23 WG meeting: There's definitely still a desire for this from RP's, CC'ing @nsatragno and @emlun to consider the idea that came up today about being able to include more info in errors that happen after a user consents to a ceremony.

[MasterKale]

You have to go digging into the spec to connect the pieces, but the spec definitely outlines discrete error scenarios that should be reliably detectable. For sake of discussion, I've done so with my own library for both registration and authentication:

• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/helpers/identifyRegistrationError.ts
• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/helpers/identifyAuthenticationError.ts

The exceptions here are the various NotAllowedError that can come up. The spec defines a couple of discrete conditions under which NotAllowedError can be mapped to specific error causes. However, browsers have overloaded this type of error with browser-specific error messages too that make it trickier to differentiate spec-related error conditions from browser-related error conditions.

All this said, I agree that the spec doesn't make it easy at all to identify all the discrete errors that can come up during a WebAuthn ceremony. Perhaps this becomes an editorial PR to bundle these errors together and under what conditions they'd arise.

[dolda2000]

Please correct me if I'm wrong, but the code you link to seems to be more about providing some explanatory text for every error, rather than, for example, categorizing errors into those that should be displayed to the user vs those that shouldn't, no? As far as I can tell, it also does not seem to provide a useful return value when, for example, Firefox throws an error in the above mentioned example where the presented authenticator doesn't contain a key for the account.

[timcappalli]

2023-08-30 meeting: @MasterKale did you still want to do anything with this issue for L3?

[emlun]

Just noting that there is precedent in the spec for this: the InvalidStateError in create() explicitly calls out that a more granular error is acceptable because the user has consented to the operation:

Note: This error status is handled separately because [...] and the user has consented to the operation. Given this explicit consent, it is acceptable for this case to be distinguishable to the Relying Party.

I too was recently surprised that we don't have such a case in get() for when the user attempts to use an authenticator that is not registered. There are probably other error causes that could be communicated too ("various failure cases in the hybrid flow" was mentioned on the call). We might end up needing a custom DOMException derived interface for that.

[MasterKale]

Another error use case to consider:

• RP requires UV, but a user tries to use a U2F security key that doesn't support PIN. It would be useful to see that the user tried to use an older security key so we could be more specific about why they couldn't use it.

[lgarron]

I'd also love for it to be clarified how the RP can interpret InvalidStateError during create(…):

• #1566
• #1888

For now the only possible cause is a excludeCredentials match, but I believe the spec does not specify that this is a safe assumption for the future.