Does Related Origins introduce a need for "Related RP IDs" support in .get()?

[MasterKale]

Proposed Change

The Related Origins feature being added in #2040 allows a company handling auth on multiple domains to use a single RP ID. However, for an RP that wants to rebrand completely such that their RP ID would move from example.com to example.net, they have to support existing credentials bound to "example.com". In addition, there is no path forward for them to ever start using "example.net" as an RP ID without forcing all users to re-register passkeys to ones bound to "example.net".

Should we consider adding support for multiple RP IDs in calls to .get()? I can see Related Origins being a natural restriction on which RP IDs could appear in such a list, but haven't sat down to fully think this through.

[timcappalli]

The requirements/design for ROR was to explicitly not make any changes to the data model/interfaces/methods. If there are no passkeys for the current origin, the user can fall back to entering their username. A backend service can then look up the user and any credential to RP mappings, and take the appropriate action.

This is something that eventually needs to be documented on passkeys.dev.