Re: [webauthn] Consider RP ID migration use cases (#2350)

I think we have most of what we need for this, but it's not quite practical to do yet:

* Even if you use related origins, you still can pass a single relying party identifier. It's tough to support usernameless flows when you can't tell which RP ID your user is under.
* The user may have multiple passkeys. Which one is your conditional create call replacing? Even if you only call conditional create after a sign in with a passkey (to give you some confidence that specific passkey will be replaced), it could be that a different one gets replaced! Ignoring this fact and calling the signal API after could result in the user losing their valid passkeys.

There's also the fact that conditional create doesn't quite work for other forms of auth other than password yet, although I don't think that's necessarily a WebAuthn spec issue.

Here's an exciting proposal: what if we have user agents and authenticators show the origin of the request instead of the relying party identifier? This doesn't solve everything: if a company e.g. sells their old domain, they lose access to the passkeys. But it at least solves the branding issue.

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


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

Received on Monday, 27 October 2025 18:26:22 UTC