Relying Party ID

​

What is the relying party ID?

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.

​

Can I change the relying party ID?

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.

​

How is the relying party ID validated?

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.

​

Details

For further examples and detailed questions, we highly recommend to have a look at the following blog post: