Relying Party ID
Tenancy settings apply to a specific tenancy/environment.
Hostname (aka RP ID)
The RP ID is similar to the cookie domain property. A passkey registered with an RP ID of example.com could be used on example.com and www.example.com.
Background
For years browser developers and the wider security community have struggled to prevent phishing attacks. The failed "green bar" experiment was one such attempt. All previous attempts to prevent phishing ultimately rested on the user's judgement. Users need to ensure they don't enter their credentials on the wrong site. Time pressed users, ignorant of spoofing and phishing continue to fall victim to scams.
The RP ID
In the end, the industry decided to take the choice away from the user. Given that users don't actually know their passkey (it's a cryptographic private key) they rely on the browser to sign "challenges" for them. Now that the browser is handling authentication, it can prevent phishing attacks by:
- Only using a Passkey on the host/domain for which it was created
- Ensuring the site is running over TLS with a verified hostname
In Passkey terminology the hostname or domain is known as the RP (Relying Party) ID and it needs to be set when creating a Passkey.
Same origin policy
If Passkeys can only be used on the site for which they were created, you're probably wondering why you need to choose an RP ID, surely it's just the hostname? Well, similar to the cookie same-origin policy, you might want to allow a passkey to be used on example.com, www.example.com and test.example.com. By setting an RP ID of example.com, the passkey could be used across all three hostnames.
Choose your RP ID carefully
The phishing protection offered by passkeys is a double edged sword. Even if you legitimately control two domains there is no way you, or your users can use their passkeys across both domains.
There are proposals to allow the sharing of passkeys across domains.