Re: [webauthn] Update Credential Record to suggest storing RP ID as well for better Related Origins support (#2257)

> So while I like the proposal on one level, I'm not sure this is the right way. This would imply that storing the RP ID tags is enough to solve any issues that come up with related origins, but it isn't. It wouldn't hurt, but it's not enough. So I rather feel like this use case would need much deeper consideration than this simple recommendation.

Thanks for the thorough analysis @emlun. Looking at the current definition of Related Origins in L3, and comparing it to the [Explainer](https://github.com/w3c/webauthn/wiki/Explainer:-Related-origin-requests), I'm not certain how Related Origins supports websites that have users with passkeys spread across those multiple URLs.

I've had it in my head that Related Origins requires use of a single static RP ID across multiple domains, since the processing rules reference "`rpIdRequested`." This indicates to me that a single value for `rp.id` needs to be chosen and specified across related domains. But thinking through this scenario...

> If `acme.com` requests an assertion with RP ID `acme.com` and the user only has a credential for `example.com`, then they won't be able to log in despite the related origins. You'd have to ask the user which site they registered at before you can set the RP ID correctly.

...I can't see how Related Origins, as it currently exists in L3, can handle this use case. Assuming an empty `allowCredentials` how would the website hosted at `acme.com` know which RP ID it needs to provide to allow users with a blend of passkeys at either `example.com` or `acme.com` to log in? It seems there'd need to be some mechanism for an RP ID to specify multiple RP IDs.

I suppose this biggest question on my mind at this point is, is Related Origins trying to solve for A) RP `example.com` subsuming RP `acme.com` and its users and their existing `acme.com` passkeys, and then support auth across both domains with passkeys at either domain? Or is it only trying to offer a solution for RP `example.com` to one day rebrand or service passkey auth later at an `acme.com` that didn't exist before?

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


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

Received on Wednesday, 12 February 2025 14:38:43 UTC