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

> Is the outcome of @akshayku's suggestion different from what it would be with "getOrCreate", though? In both cases, a failure to generate an assertion leads to creating a new credential with a new user handle, and the user possibly ends up with two credentials for two separate accounts.

Hm, no, why would it use "a new user handle"? RP is always using a constant user IDs for all users. So it will be a new credential for the same user ID. Now, if only there was a way to prevent credential creation for existing user ID, like #2313. But you are right that `getOrCreate` could have a better UX here, for example, client would know why get failed: e.g., was it because there is an issue accessing credentials, or because user clicked cancel. In both these two cases it would not proceed to create a key.

But you are right that in some distributed credential store there could be an issue that local state is missing a credential and so a credential is created, but then later on once local state is reconnected to the cloud, it is found out that for some user ID, there are now two credentials. And that is again something `getOrCreate` (or #2313) should take care of: that it should create key only if it is known that the state is up to date and that for example, connection to the cloud is present. 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.

> it might funnel the user into creating a new passkey on the new device instead.

Yea, I think that can and will happen. But I do not see it much different from current state of affairs. In user studies I have seen many cases where people forget if they have an account on the RP and decide to sign up again. They even proceed even if "their e-mail address is taken", trying to sign-up with another e-mail address they might have (they also tend to forget which e-mail address they used on the RP). So they create second account, which is of course empty. So a good RP does not need a way to merge/meld those accounts together once user realizes "oh, but I should have had some content already here, I remember now" (once they sign-in and see whole UI and remember what it is).

Same goes for username + webauthn scenario. If we are really in the context you are describing (roaming authenticator + client somehow fails to connect to the right authenticator) I think it is possible that the user will go and create a new account with anther username ("username is already taken"), coming to the same spot of having two accounts on RP, once the authenticator synces up.

So I do not buy the claim that the solution (to the the fact that there might be occasionally state discrepancies which will lead to multiple accounts being created) is to rely on the user to remember what is the expected state and which accounts/credentials should exist and which are missing. I do think the whole idea behind "sign in or sign up" button is exactly because we do not believe (especially for small RPs user uses only occasionally, and because they are small it is reasonable to have a trade-off where only one account per RP is supported) user remembers where where they have an account and where they do not. If we are unable to make tech which reliably remembers and retrieves that for them, I do not think we can expect users to reliably remember that either.

> and `create` can only result in failure or creating a new credential

Or overriding an existing credential for the same user ID, with prior credential being lost forever. That is the main issue here. If a user is forgetful and does not remember if they created an account, they can override their own credential (when using constant user ID). The same goes for username, they can forget it and create another account. I think what this whole issue is about is really **can we design an approach where user does not have to know if they have an account or not on the site**. It works with social authenticators (like Facebook, Google), can we make it work also for Webauthn? I am fine if Webauthn fails with "unable to determine if you already have an account on this RP, please try again". But doing "I am unable to remember if you have an account on this RP, please you remember that, and also remember this piece of information, username, as well" is sad. Maybe we are really not able to collectively come to the solution to this.

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


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

Received on Saturday, 12 July 2025 10:15:46 UTC