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

lgarron has just created a new issue for https://github.com/w3c/webauthn:

== Can RPs assume that `InvalidStateError` for `create()` means an excludeCredentials match? ==
Based on talking to some browser authors, it seems that the spec is currently designed so that an `InvalidStateError` response for `navigator.credentials.get()` means the registration failed because all authenticators that match the selection criteria (e.g. user-verifying platform authenticator) already have a registration for the RP ID.

However, Safari currently has a bug for this situation that makes the result indistinguishable from the user canceling the operation: https://bugs.webkit.org/show_bug.cgi?id=219813
In addition, the spec seems to make no guarantees that `InvalidStateError` will only cover this particular meaning in the future.

Would it be possible to clarify whether RPs can rely on this?

GA "create or get" operation would really help here, but [this was not seen as an area of improvement for the spec](https://github.com/w3c/webauthn/issues/1533) when I brought it up. And I presume that letting the RP query "is a user-verifying platform authenticator registered?" is also out of the question.

So the `InvalidStateError` error is one of the few signals that RPs can use to to support reasonable user flows for the same platform authenticator across multiple browsers (e.g. Windows Hello). We'd like to know whether Apple's implementation should be considered a bug, or if we need to weaken clarity of our platform authenticator (re-)registration flow to accommodate for the possibility that `InvalidStateError` does not indicate an existing registration.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1566 using your GitHub account


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

Received on Tuesday, 9 February 2021 01:59:58 UTC