The relying party ID is essentially a domain stored within the passkey, ensuring the passkey only works if the current browser URL (the user’s origin that is automatically sent on every request) matches it (see the native app approach below). It’s a crucial component of the WebAuthn specification. The relying party ID can be
the root domain (e.g. corbado.com) or
a subdomain (e.g. auth.corbado.com)
You cannot store the root domain as relying party ID if it is on the public suffix list.
In theory, you can change the relying party ID in your implementation. However, once a passkey is created, you cannot change the stored relying party ID within the passkey.
Changing the relying party ID for a deployed online service will break
existing passkeys (the only exception: the new relying party ID is a
subdomain of the old relying party ID).
During the authentication process, the relying party ID is checked against the browser URL (user’s origin) to ensure they match. Matching in this sense means that either:
The browser URL (user’s origin) matches precisely the relying party ID OR
The browser URL (user’s origin) is a subdomain that matches the relying party ID and the parent domain is registrable (e.g. “com” or any domain on the Public Suffix List don’t work)
Which relying party ID should I use for native apps?
Native apps (e.g. iOS or Android apps) present a challenge compared to web apps. Unlike web apps, there’s no browser URL to match against the relying party ID. Nevertheless, to ensure the same level of security, domains are connected to native apps via association files (see Passkeys in native apps), so that trust between a domain and a native app is established.
This is particularly important if a passkey was created on a web app and
should be used for the same relying party ID on a native app (and vice
versa).