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](https://github.com/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.

Thanks, @MasterKale. Your concerns are entirely valid. That said, I believe the issue we're discussing — that a user typically needs to have an account before a passkey can be created — is not limited to demo scenarios or “usernameless” flows. It applies more broadly to any context where new user onboarding is a critical conversion point. E-commerce is a prime example.

From that perspective, I’d like to propose an extension of the current thinking around `getOrCreate()`.

Operating systems and browsers often have access to user identity signals, most notably one or more email addresses. These could be leveraged to introduce an **email or account chooser** as part of the WebAuthn UI, similar to the “Sign in with Apple” experience on Apple devices.

- If only one email address is available, the passkey creation flow could start automatically with that address, optionally allowing the user to edit it.
- If multiple addresses are present (for example, a personal and a work Microsoft account on Windows, or iCloud and Gmail on macOS), the user could select which identifier to pass to the relying party during the `getOrCreate()` process.
- If no identifier is available, the RP would receive an empty username. This is consistent with current “usernameless” semantics, and the RP could still request an identifier after authentication if needed.

This pattern would enable a **hybrid, SSO-like one-click experience** for both **registration and login** with passkeys, without requiring proprietary solutions or compromising user control.

It could also better align with user expectations shaped by modern SSO flows, and help accelerate passkey adoption in high-friction or high-churn environments like e-commerce.

I’d be interested to hear if this direction could be explored further in the context of UX or spec evolution within the FIDO ecosystem.

-- 
GitHub Notification of comment by FlxMgdnz
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1568#issuecomment-3069636513 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 13:32:55 UTC