At the FIDO Tokyo Seminar, I was told it's hard to track the high-level picture of how passkeys are evolving, and I thought it would be helpful to introduce key terminologies so you can get a grasp of the passkey world and look into more details when necessary. So here it is.

Basics #

Authenticator #

An authenticator is a device that stores and manages passkeys. It can be a hardware security key, a password manager (passkey provider), or a mobile device. In this article, a "password manager" represents authenticators (because it's the most frequently used authenticator).

Relying Party (RP) #

A relying party is a website or application that requests passkeys from the user. It is responsible for verifying the user's identity and storing the public keys.

RP ID #

RP ID (Relying Party Identifier) is the domain name of the website requesting the passkey. It defines the scope of the credential, ensuring that a passkey created for example.com cannot be used on evil.com. It must be a valid domain string and a suffix of the current origin.

Discoverable Credentials #

Discoverable credentials (formerly known as "Resident Keys") are passkeys that are stored on the password manager along with the user's account information (like username and display name). They enable "username-less" authentication flows, where the user just clicks "Sign in" and selects their account from a list provided by the password manager.

User Verification #

User verification refers to the process of verifying that the person authenticating is the actual owner of the password manager, typically via a biometric check (fingerprint, face ID) or a PIN. A user verification happens locally, so information such as biometric data or PIN is not sent to the server.

Attestation #

Attestation is a cryptographic proof provided by the authenticator during credential creation. It allows the RP to verify the make and model of the authenticator (e.g., "This is a YubiKey 5 NFC"). This is primarily used in enterprise or high-security contexts to enforce policies (e.g., "only allow hardware keys"). In general, passkeys on password managers don't support attestations.

AAGUID #

The AAGUID (Authenticator Attestation Globally Unique Identifier) is a 128-bit identifier indicating the type (model) of the authenticator. It allows RPs to identify the specific device being used (e.g., Google Password Manager, iCloud Keychain, Windows Hello, or a specific security key model) even without full attestation. It can be used to detect which password manager the passkey is created on to display the provider's icon, name, and other information by referencing MDS, but verification is not possible, since passkeys on password managers don't support attestations.

MDS #

The MDS (FIDO Metadata Service) is a centralized repository of information about FIDO authenticators. RPs can query the MDS using an AAGUID to retrieve details like the authenticator's certification status, icon, and supported features.

Implementation #

excludeCredentials #

excludeCredentials is a parameter that indicates a list of credential IDs that the server sends to the browser during the passkey creation process. It tells the password manager "if you already hold one of these credentials, don't create a new one." This prevents creating multiple passkeys for the same account on the same password manager.

Conditional mediation #

Also known as "Conditional UI" or "Conditional Get", this feature allows passkeys to be offered in the browser's autofill suggestions on standard username input fields. It enables a seamless transition from passwords to passkeys by letting users sign in with a passkey directly from the form they are used to.

Signal API #

The Signal API allows RPs to communicate the state of a credential back to the password manager. For example, if a user deletes their account or a public key on the server, the RP can signal this so the passkey can be removed or updated on the supporting password manager as well.

Related Origin Request allows a website to accept passkeys that were created for a different, but related, origin. This is useful for multi-domain deployments (e.g., example.com and shop.example) or country-specific deployments (e.g., example.com and example.co.jp).

getClientCapabilities #

getClientCapabilities allows RPs to query the browser to see which WebAuthn features are supported on the current device. It helps in making decisions about the UX, such as checking if conditional mediation is supported before setting up the form.

Client Hints #

Client Hints allows RPs to provide a hint to the browser about which type of authenticator the user is expected to use (e.g., security-key or client-device). This helps the browser to show a more relevant UI to the user, improving the user experience especially in enterprise environments where specific authenticators are required. Note that this is only a hint and does not enforce security policies.

Passkey endpoint #

Passkey endpoint refers to a mechanism (often involving a .well-known file) that allows RPs to signal to password managers (like Google Password Manager) that they support passkeys. This enables the password manager to proactively suggest upgrading an existing password account to a passkey.

Conditional creation #

Also known as "Automatic passkey upgrade" or "Automatic passkey creation". An emerging feature that allows RPs to piggyback the passkey creation request onto a password sign-in or other user action. If the user successfully signs in with a password, the browser can automatically (or with minimal friction) create a passkey for future use.

Immediate mediation #

A proposed feature that immediately returns an error when a credential request is canceled or failed. This allows the RP to improve the user experience by not showing a QR code or other authentication methods and control the fallback authentication method.

Finally #

If you think this article is missing any important keywords, please let me know via @agektmr.