I think I get the idea, but on further thought this might be a bit of a trap.

The idea is that an RP might use two (or more) different RP IDs, but wants to merge them into one logical application? Say that acme.com and example.com have both rolled out WebAuthn and have thousands of credentials registered to each RP ID already, then acme.com acquires example.com and wants to merge both user bases, so they set up related origins to allow users of each site to use their existing credential to log in at the other domain. It makes sense that if they also merge their databases, they'll want to tag each credential with which RP ID it was registered to. So far so good.

But this might still become a problem when it's time for a user to log in to the merged site, because in that call you can only specify one RP ID at a time. Let's consider only discoverable credentials (empty allowCredentials) first. 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.

Non-discoverable credentials (non-empty allowCredentials) aren't as affected, because the RP will look up the credentials first and set the RP ID to the correct one for the user. But as soon as the user registers a new credential for the other RP ID, the problem returns. This would be addressed by continuing to register each user's credentials only to the RP ID they already have credentials for, though. But the problem remains that the discoverable flow wouldn't be available to users registered to the other RP ID.

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.

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, I'm not certain how Related Origins supports websites that have users with passkeys spread across those multiple RP IDs.

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/rpId needs to be chosen and remain constant 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?

Storing the RP ID is valuable for identifier-first flows in brownfield/existing deployments as covered here: https://passkeys.dev/docs/advanced/related-origins/#existing-deployments

It is not needed for greenfield deployments where a common RP ID is used across all origins (but still may be a good practice to store in case of future changes).