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

> > If get call fails, you can randomly generate new userHandle and invoke create. As userHandle is random, existing credential will not be overwritten.
> 
> Sure, but then they have two accounts/credentials with random usernames in their Webauthn selection dialog. They didn't lost access to the other one (that is better), but now they have to know which one to pick. Our app can link eventually both of them to the same account, so that could be of help, but it still makes the user ponder the question "which one I have to pick".

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. This is especially likely to happen if the user's existing credential is on a roaming authenticator such as a security key or a device available over [`hybrid`]: if the user attempts to sign in on a new device and the client somehow fails to connect to the right authenticator, it might funnel the user into creating a new passkey on the new device instead. This might not be as apparent to the user (people don't actually read dialogs) as if they had instead explicitly chosen an option in the RP UI to create a new account. I don't see how the unwanted outcome is any less likely in either scenario.

In that sense, that's a fairly substantial _advantage_ of keeping `get` and `create` separate: a `get` operation cannot result in accidentally creating a new credential, and `create` can only result in failure or creating a new credential. I think it's sensible to keep it that way so users can know what to expect to happen (assuming the RP UI is clear about it, of course).

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


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

Received on Friday, 11 July 2025 11:16:50 UTC