webauthn
webauthn copied to clipboard
w3c
Help RP's understand actionable exceptions from `create()` and `get()`
This PR attempts to pull together any exceptions raised by create() and get() to help RP's understand what exceptions may be encountered when using WebAuthn. The intention here is to help RP's understand which errors might be surfaced to the user, and which should not.
Addresses #1859.
I've finally cobbled together reasons for all of the exceptions during both registration and authentication.
...Except I cop out a bit with NotAllowedError because it has many more possible reasons it gets raised, and in practice clients have overloaded this exception with causes not documented in the spec. I thought it prudent to present this error as one that RPs should prepare to handle as a general, "the user canceled the ceremony, or something went wrong" exception and handle it as such. This is as opposed to encouraging each RP to try and interpret all possible reasons the issue was raised. I'm open to feedback on this approach.
100% support this @MasterKale. Recently working on client lib, NotAllowedError is kinda useless. *)
@emlun I incorporated all but one of your suggested changes; I left a comment on the one about TypeError. Can you please take another look when you have a chance?
And @timcappalli and @sbweeden can you also please take a look when you can?
Whilst I cannot vouch for the completeness or accuracy of the documented errors, I certainly support the idea that they be listed, along with their reasons when known. I do feel however that this effort is more about documenting encumbent behaviour than defining a set of useful-to-the-RP error conditions that the clients should implement. As a simple example, it would be good for an RP to be able to differentiate a user canceling an operation vs timeout. At the next WG call I'd like to at least raise whether this effort should consider the approach of trying to define what RPs want, rather than just what browsers currently do.
@sbweeden This PR will pave a path towards introducing more nuanced errors like the ones I detailed here in response to a similar statement you made a month ago:
https://github.com/w3c/webauthn/issues/2062#issuecomment-2093823953
The hope is that we establish a sensible way of centrally capturing errors, and keep it updated as we consider introducing more nuanced errors for the benefit of RPs.
WAWG Meeting @ 6/26:
- @nsatragno suggested I mark these sections non-normative so the processing steps remain the authority on what errors clients should raise
- I'm going to make @timcappalli's suggested section title changes, it's a bit confusing as-is given parent header titles
I was overthinking things, I added TypeError to the list of .get() exceptions:
I'm going to close out #2094 with this.
Heya @pascoej and @marcoscaceres is there a chance you can take a look at this and comment/approve in time for tomorrow's meeting?