Help RP's understand actionable exceptions from create() and get()

[MasterKale]

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.

---

Preview | Diff

[MasterKale]

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.

[yackermann]

100% support this @MasterKale. Recently working on client lib, NotAllowedError is kinda useless. *)

[emlun]

Substance wise this looks good to me 🙂 but this does highlight that we're not at all consistent about actually forwarding some of these "error code equivalent to..." errors from the authenticator through the client layer. But that should be a different issue.

Some editorial issues to take care of, though:

[MasterKale]

@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?

[sbweeden]

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.

[MasterKale]

@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:

#2062 (comment)

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.

[timcappalli]

These are just nits (I don't feel too strongly either way).

Looks good otherwise.

[MasterKale]

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

[nsatragno]

Thank you for this PR!

[emlun]

Thanks @MasterKale!

[MasterKale]

Heya @pascoej and @marcoscaceres is there a chance you can take a look at this and comment/approve in time for tomorrow's meeting?

[selfissued]

This seems useful.