Re: [webauthn] Can RPs assume that `InvalidStateError` for `create()` means an excludeCredentials match? (#1566)

Do I understand from the closing of this issue that RPs cannot rely on `InvalidStateError` to indicate that registration failed due to an excluded credential?

As it stands, it sounds like there is no plan to modify the spec to make this safe assumption.

> I would say that while you can use the `InvalidStateError` as inference that the user is using the same platform authenticator, I am a bit confused about the use-case: it seems like you're trying to use this error to determine if the user is already registered. Why not just check with the user by supplying a `get` request?

Because the time when we need to do this is indistinguishable from a situation where a user is on a new device. It sounds like you're suggesting the following registration for for a new trusted device:

- Prompt the user to authenticate with their device.
- Proceed to registration only if that prompt fails.

This is undesirable because:

- The client would see an error every time they try to register a new device. The RP has no control over the UI for this, so we can't do much to reduce the potential for confusion.
- We would like to avoid showing too many prompts to the user, if possible.

We're currently trying to use heuristics to default to the `create` flow when possible. But if our heuristics are wrong, we need a way to catch it, and it would be very useful if we could tell if this is due to an existing registration (and which one).

> Also, In the ideal case, a user registers with an RP and closes the browser client, then opens another client and navigates to the previously registered RP in the new client. Upon the user hitting login, the authenticator **should** be able to use the previously created credential for that RP in the new client browser. Is this not the case? What am I missing? The pandemic has turned my brain into pudding.

Indeed, the authenticator can use the previously created credential *if we know to prompt for it*. This requires either:

- Knowing which user is authenticating, and having authenticated enough for it to be safe to send down `allowCredentials`.
  - For us, "having authenticated enough" means they've entered their password at least once.
- The user has client-side credentials and has a for the site to use them without disrupting the normal (password-based) authentication flow. It sounds like #1545 is the most likely path for that.

Neither makes it possible in a fresh profile to prompt for the credential in a fresh profile.

-- 
GitHub Notification of comment by lgarron
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1566#issuecomment-782429137 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 19 February 2021 22:51:51 UTC