Clarify browser behavior when an authenticators return equivalent of "InvalidStateError" about webauthn

[akshayku]

For local platform, it makes sense to return immediately because there is no other option. For external security keys, user may want to user another security key, but plugged in another key because maybe they all look alike, or user accidently inserted an already created one. We try to strive for the user to succeed.

[arnar]

Right, that is the logic for the current implementations, but it is only controlled by the authenticatorAttachment preference in the request. So this applies to requests where the user might do hybrid now as well. Hybrid flows are high touch, and it is unlikely that the user has alternative phones etc. to satisfy the request. So I don't think that "Try again?" logic is helpful for those users.

In comparison to those cases, we expect SK usage, and in particular users with multiple SKs to be rare. And the RP can equally help the user enter a try-again flow if they want as well.

So I think currently this behavior is not helping users overall.

Note that my motivation for the proposal is also because I think we should strive for the user to succeed. Unfortunately the browser must fall back to very generic language in these prompts and we've seen them be unhelpful more than we've seen them be helpful.

[MasterKale]

However this thing goes I'd like to emphasize how useful it is as an RP to get ISE on an excludeCredentials collision, and hope that if the browser and/or platform continue to own the WebAuthn experience that an ISE continues to get returned even if a user clicks Cancel on a, "sorry, you already registered that" message that the browser/platform displays. Otherwise all that RP's would be left with is the signal indicating the user canceled out of the ceremony with no idea that it was because the authenticator was already registered.

[emlun]

I think I agree with @MasterKale. I would put the ask as:

• If the user cancels out of the ceremony, and at no point during that ceremony the user attempted to use an authenticator that matched excludeCredentials, then return NotAllowedError.
• If the user cancels out of the ceremony, but at some point during that ceremony the user attempted to use an authenticator that matched excludeCredentials (even if the user afterwards clicked a retry option and, for example, attempted to use hybrid but failed), then return InvalidStateError.

Does that match up with what you're saying, @MasterKale?

(I currently have no opinion on whether the browser should offer a retry option or should always return on first failure.)

[MasterKale]

Does that match up with what you're saying, @MasterKale?

Catching up, yes, I think your logic holds up to what I'd like to see happen if this moves forward.

[arnar]

Sure, that sounds fine with me. But the primary ask in this issue is that if a local credential matches an exclude list entry, and the user performs its UV ceremony (which already should be offered before any external authnr interactions), then immediately return ISE and don't offer to retry with other authenticators.

I'm ok if requests with attachment=cross-platform offer some retry options, but I don't think they should. In general we should try and reduce the already complex branching logic in the common UX.

[arnar]

(I am on leave until Sept 18 btw so replies from me here will be sporadic. Tony, feel free to reassign if needed, otherwise I can tend to this when I'm back.)