A relying party (RP) is responsible for issuing and authenticating passkeys. Typically, a relying party is in charge of the server-side and client ceremonies.

How to choose the best Relying Party ID (rpID) for your application

Because the binding of the relying party is a crucial component of a passkey registration and authentication ceremony, choosing a rpID is an important decision before turning passkeys on for your users. By its nature, passkeys are tightly bound to their rpID, so changing it after a passkey rollout can become problematic.

The simplest approach is to choose the highest level parent domain as your rpID, for example, yourwebsite.com. By choosing this as your rpID, you can use the passkey across both the parent domain and all subdomains, for example, app1.yourwebsite.com and app2.yourwebsite.com. Do note that this doesn’t apply the other way around; if you register a passkey with a rpID of app1.yourwebsite.com the passkey is strictly bound to that domain and can’t be used on any other domain, apart from its children subdomain.app1.yourwebsite.com.

The next question that typically follows this is, what happens if I have other domains like yourwebsite.com.au or yourwebsite.co.uk. This scenario constitutes a cross-origin registration. As of this blog post (July 2024), cross-origin passkey registration is still in the early roll-out phases amongst browsers and not widely supported as this specification is a relatively new addition to the WebAuthn API spec. This means that even with an iframe originating from yourwebsite.com, if the parent origin is yourwebsite.com.au then you’d be unable to register passkeys on most browsers. This doesn’t apply to cross-origin verification; if a passkey was registered on yourwebsite.com you’d be able to do a verification process on yourwebsite.co.uk provided you add the domain https://yourwebsite.co.uk to the list of expected origins. This may sound a bit complicated, but the reason for this is to ensure all the domain properties bind to the passkey while allowing a level of controlled flexibility, and we will keep this post up to date on the coverage of cross-origin registration.

https://docs.authsignal.com/scenarios/passkeys-prebuilt-ui#adding-expected-origins