Re: [webauthn] Support a "create or get [or replace]" credential re-association operation (#1568)

> Hm, no, why would it use "a new user handle"?

Because that was the scenario you two were discussing in the text I quoted.


> So it should be conservative when it creates a key, opting to fail if it is not possible to assure unique and atomic creation even in the case of distributed credentials store.

And therein lies the problem: it would have to always fail with "unable to determine if you already have an account on this RP", because the credential might exist on an authenticator not currently connected to the client device. This is not about "occasional state discrepancies" or an authenticator being "unable to remember if you have an account" - it's that WebAuthn by its design _always_ operates on a pluggable "distributed credentials store", so the client _cannot_ know that you don't have a passkey since the client is not necessarily the one holding the passkey. This is not an esoteric scenario:

1. On client device DA, user creates an account with a passkey on security key K.
2. On client device DB, user attempts to sign in. K is not connected to DB, so when `getOrCreate` is called on DB it only knows "there is no passkey for this RP on this device, but maybe you have one on a security key that's not connected?". The client might suggest connecting a security key or hybrid authenticator (maybe it also remembers security keys that have been used before), but if the user declines or fails to use those the ceremony will just have to fail with "unable to determine if you already have an account on this RP" (even if security keys are remembered, the user may have created or deleted passkeys on them while connected to a different client device).
3. After connecting K to DB, user eventually does successfully log in.

The `getOrCreate` in step (2) isn't much different from a `get` since the client can almost never conclude with confidence that the user has no passkey for the RP. Sure, the client _can_ explicitly ask the user if they think they have a passkey they can use, but there's no reason the user would remember that any more accurately than if the RP asks the same question.

Either way, with both `get` and `getOrCreate` you're effectively stuck retrying steps (2) and (3) (either in a loop in the client UI or by the RP retrying the call), because the client cannot with confidence give up and proceed to step (4): create a new passkey and register a new account instead. That has to be the user's decision. Yes, it _could_ be an option in the client UI, but I'm not convinced the client UI is a better place to make that decision than the RP UI.

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


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

Received on Monday, 14 July 2025 12:15:56 UTC