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

@MasterKale With all due respect and high admiration for all your work in this space, your comments here are a lot of strawman arguments where you put out some use case or user need and then show how it would not work. The whole "get or create" feature request is in fact meant for a different mindset/approach to authentication, so it has different trade-offs. I completely agree that for existing user flows existing Webauthn works great. But this issue is to support also different user flows and for that you need to accept that there are different trade-offs and you cannot expect same considerations about how authentication flow should happen. Why it is this important to keep in mind is because this is 3rd (tied) most upvoted issue in this repository. So it is clearly about a need not yet meet and thus user flows not yet meet by existing Webauthn flows. With this mindset, let's go one by one:

> the user ends up with a passkey but without a recognizable account identifier associated with it because the RP has to make one up

Why is this a problem? In my implementation RP simply uses the name of RP itself, with constant user ID. Yes, that means only one account can be used with that RP, but that is one example of a trade-off here. For user, it works well, "I am singing-in into RP, I see RP as name in the list, I click on that name".

> 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.

So only if RP wants to support multiple accounts. If not, it does not have to. So yea, multiple accounts per RP support is hard (for now, once there will be more support for A) and B), then it will also be easier). Single account per RP is easy. So perfect does not have to be the enemy of the good: having one click authentication for single-account use case without any username. For many apps, this is completely enough. You click, you are in. One app, one account.

> 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.

All goods points, but multiple accounts is not really the use case which is motivating the "get or create" feature request.

> 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?

Yes, but this is just one approach to do it. You can also encourage to setup account recovery after sign-in. You can nag with banners and whatever after sign-in. In our implementation, we ask user to link other authentication mechanism (social, username/password, recovery codes, etc.).

The main idea here is that if you want to reduce friction, for some types of apps, it is maybe completely OK to allow quick sign-in and encourage account recovery only later. For example, you want to get user quickly into the app and only after they do something meaningful in the app they want to preserve, you prompt them to also add more ways to authenticate to prevent from being locked out. It is similar how some apps use local storage for that, but here you can be slightly better by using authentication which is maybe slightly more durable than local storage. And for lasting recovery you encourage later.

Or maybe this is something you expect user's authentication device to take care of (so recovery for their whole set user's of credentials, not just for that particular RP). Maybe it is not really RP's role to do account recovery, with Webauthn is maybe device's role, while RP just uses simple one-click sign-in to obtain credential and this is it.

If RP cares about user privacy and digital sovereignty, RP might decide that they do not want to ask for any usernames (they can be linked across sites, and if they are unique to the site, then user has to remember them, which works badly as a recovery mechanism) nor e-mail addresses (users often have those at centralized providers, and they can also be linked across sites). And doing setup for account recovery after sign-in enables that: RP can for example generate private key for recovery and give its mnemonic to the user to write it down. Then user can sign-in using Webauthn or by providing a mnemonic. In both cases, no username no e-mail address.

> But optimizing for usernameless flows likely won't ever have as wide an impact on WebAuthn adoption

I do not think nobody here is asking to optimize for usernameless flow, only for it to be possible as well.

> 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.

The problem is that both "cancel the quest" and "key not available" both return `NotAllowedError`. So if PR then attempts key creation it can still override an existing key. (Maybe an alternative approach is to add a parameter to create call to not override an existing key?) Still, "get or create" could enable the browser to provide superior UX instead of having to do that in the client.

> It'd be an uphill battle for us.

I can understand that. Would #2309 be easier for vendors to support? Or even simpler "create key only if none exist for this RP" - so really going full on "single account per RP" flow? Or maybe the "do not create key if it already exist for same user ID and RP" flag to create call? I think those are maybe simpler to get support for and are in general good practice: RP should be able to communicate the intent about overriding possible existing key?

-- 
GitHub Notification of comment by mitar
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1568#issuecomment-3058824260 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 19:49:34 UTC