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

> How cool would it be if passkeys could be improved to offer the same "fire and forget" convenience of 3rd-party OAuth buttons, but without the need to actually involve a 3rd party? Exactly what we've been hoping for with "get or create".

One difference between OAuth-based "sign in or register" flows is that you get back a recognizable account identifier whether "Sign in with IDP" leads to signing into an existing account on your site or the creation of a new account on your site.

Trying to pull this off with passkeys would suffer from the same limitations as existing usernameless flows: the user ends up with a passkey but without a recognizable account identifier associated with it because the RP has to make one up. RPs that implemented a hypothetical get-or-create WebAuthn API call would have to **always** wire up use of `signalCurrentUserDetails()` APIs and then **hope** that a newly registered user was A) using the right browser and B) had registered an authenticator with support for the signal. And if the passkey was registered on a security key, the chances of that security key getting updated are lower still for all of the complexities of reliably communicating with _any_ roaming authenticator.

And it's not a farfetched claim that account recovery is even more important in usernameless flows. So why not encourage RPs to establish a point of contact first (e.g. email verification) before creating a new account? The RP would then have a recognizable account identifier (e.g. the user's email address, a username prompt before passkey creation, etc...) to pass in with the passkey registration request. Of course this immediately stops making it usernameless use of WebAuthn...

I understand well the pain point that the lack of a get-or-create method creates for WebAuthn demo sites and other sites wishing to protect login with usernameless WebAuthn (btw thanks for the break down @FlxMgdnz 🙏.) But optimizing for usernameless flows likely won't ever have as wide an impact on WebAuthn adoption as other registration optimizations like immediate mediation for registration, which I still believe can offer an alternative solution to this use case.

After yesterday's WG meeting we came to a conclusion that adding a new passkey registration method with all of these caveats would arguably add too much unwarranted confusion and complexity to the spec. Even if we defined get-or-create in the spec we'd have to convince user agent vendors, other W3C WGs (CredMan), and authenticator vendors to implement changes to pull this off. It'd be an uphill battle for us. There are other ways within (or coming to) the spec to register passkeys that reliably creates a passkey with a recognizable user identifier and I think we should continue to encourage RPs to use those.

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


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

Received on Thursday, 10 July 2025 15:29:06 UTC