Terms
Here's a list of terms which are used frequently throughout this site and in discussions about passkeys, FIDO2, and WebAuthn.
On this page
- 2FA user
- 2-Factor Authentication (2FA)
- Account bootstrapping
- Attestation
- Authentication factor
- Autofill UI
- Cross-Device Authentication (CDA)
- Conditional Mediation
- Conditional UI
- Device-bound passkey
- Discoverable Credential
- First-Party Passkey Provider
- Login challenge
- Logging in
- Passkey
- Passkey Provider
- Persistent Linking
- Platform authenticator
- Reauthentication
- Relying Party (RP)
- Roaming authenticator
- Signing in
- Single-device passkey
- Synced passkey
- Third-Party Passkey Provider
- User Presence (UP)
- User Verification (UV)
- User-Verifying Roaming Authenticator
2FA user
A user whose account has 2FA turned on, i.e., who must present 2 authentication factors during sign-in.
2-Factor Authentication (2FA)
also sometimes referred to as MFA: multi-factor authentication or 2SV: two-step verification
This refers to a contract between a user and a Relying Party (RP) where the RP must collect at least two distinct authentication factors from the user during a bootstrap sign-in.
Account bootstrapping
A Relying Party (RP) authenticates a user without any prior knowledge of who the user is. This means that the RP not only has to verify the identity of the user (checking the password, verifying cryptographic signatures, etc), it also has to establish the identity of the user (figure out the user id, username, etc. of the user who’s signing in). This may happen when a user signs into an existing account for the first time on a newly-purchased device; or when a user logs into a website for the first time in a given browser instance. Or when a user logs into a website in a private browsing session. Or when a user signs into a mobile app for the first time on a given device (contrast this with reauthentication below).
Note that this is different from creating an account with a service in the first place.
Attestation
Attestation is an optional statement provided by an authenticator which can be used by a Relying Party to identify and verify the provenance of the authenticator.
Authentication factor
Information provided by a user (or one of the user’s devices) for purposes of authentication, usually in response to a login challenge. Often categorized into “knowledge factors” (e.g. passwords), “something you have” factors (e.g. another already signed-in device), and “something you are” factors (e.g. biometrics). Note that a single login challenge may collect multiple factors simultaneously.
Autofill UI
A privacy preserving list UI element that is rendered by the browser (or the OS platform in the case of native apps), in cooperation with the platform authenticator, on username and/or password fields that have the webauthn
value included in the autocomplete
attribute.
This UI element provides a list of passkeys that are available for the Relying Party (RP) on the local device, and may also provide an option to kick off Cross-Device Authentication (CDA) or use a FIDO2 security key.
A generic example of an autofill UI for passkeys is shown below:
The technical name for this feature in the WebAuthn and Credential Management specifications is “Conditional Mediation”.
Cross-Device Authentication (CDA)
FIDO Cross-Device Authentication (CDA) allows a passkey from one device to be used to sign in on another device. For example, your phone can be linked to your laptop, allowing you to use a passkey from your phone to sign into a service on your laptop.
CDA is powered by the FIDO Client-to-Authenticator Protocol (CTAP) using “hybrid” transport. CTAP is implemented by authenticators and client platforms, not Relying Parties.
CDA Client
The client in a cross-device authentication flow is the device where the relying party is being actively accessed.
CDA Authenticator
The authenticator in a cross-device authentication flow is the device generating the FIDO assertion.
Conditional Mediation
See Autofill UI
Conditional UI
See Autofill UI
Device-bound passkey
A FIDO2 Discoverable Credential that is bound to a single authenticator. For example, FIDO2 security keys typically hold device-bound passkeys as the credential cannot leave the device. Device-bound passkeys have been previously referred to as single-device passkeys.
Discoverable Credential
A Discoverable Credential (known in previous version of WebAuthn as a “resident credential” or “resident key”) is a FIDO2/WebAuthn credential that can be used by a user to log in to a relying party without initially providing a user ID. As such, all parts of the credential are entirely stored in the authenticator (private key, credential ID, user handle, and other metadata).
Passkeys are Discoverable Credentials.
First-Party Passkey Provider
A Passkey Provider that is provided by the OS platform vendor and is often enabled by default. Examples include “Windows Hello” on Windows, “Apple iCloud Keychain” on macOS and iOS, and “Google Password Manager” on most Android devices.
Login challenge
A prompt served to the user that they need to satisfy.
Examples:
- a prompt asking the user for their password
- a prompt asking the user to confirm sign-in on another device (e.g., their phone)
- a prompt asking the user to insert and activate their security key
Account bootstrapping and reauthentication usually consist of serving the user one or more login challenges.
Logging in
see Signing in.
Passkey
Usage: “a passkey” or “passkeys”
The high level, end-user centric term for a FIDO2/WebAuthn Discoverable Credential. Like “password”, “passkey” is a common noun intended to be used in every day conversations and experiences.
Passkeys are designed to be used without additional login challenges. All passkeys can be used with modern sign in experiences like the Autofill UI or with a “Sign in with a passkey” button.
From the technical side, there are two flavors of passkeys: synced and device-bound.
Passkey Provider
An app and/or service that is responsible for storing and managing passkeys. Many operating systems include a default passkey provider (first-party), and many also support third-party providers.
Persistent Linking
The informal name for creating a relationship between a Cross-Device Authentication authenticator (typically a phone or tablet) and Cross-Device Authentication client (typically a laptop or desktop), which enables future use without having to scan a QR code.
Both the client and authenticator must support the functionality.
Example with an Android phone linked to a Windows 11 device:
Platform authenticator
A FIDO authenticator that is built-in to a user’s device.
Reauthentication
Reauthentication happens when a Relying Party (RP) already knows who the user is, but would like to reconfirm this.
For example, this can happen before making sensitive changes to an account (adding a recovery email address, changing authentication methods, etc.): a relying party would typically ask the user to re-enter their password or perform some other action to reconfirm their control of the session. Likewise, when a mobile app asks the user to sign in every time the app starts (or a web site asks the user to sign in again after a period of inactivity), this is technically a reauthentication, since the app or web site can choose to remember the user’s identity after the account has been bootstrapped on the device (using things like cookies or local storage).
Relying Party (RP)
The website that is trying to ascertain and verify the identity of the user or perform FIDO authentication.
Roaming authenticator
A FIDO authenticator usable with any device the user is trying to sign-in from. Roaming authenticators attach to users’ devices in using USB, NFC, and/or Bluetooth. These authenticators are often referred to as “security keys”. A smartphone can also act as a roaming authenticator using FIDO Cross-Device Authentication.
Signing in
This can refer to either account bootstrapping or reauthentication.
Single-device passkey
Synced passkey
A FIDO2 Discoverable Credential that can reliably be used for bootstrapping sign-in, without requiring other login challenges such as passwords and OTPs. “Reliable” here means that the passkey should be available to, and usable by, the user whenever they need to sign in. This availability can be achieved through different means: for example, passkey providers could sync passkeys in real-time across a user’s devices, restore passkeys from a backup whenever a user sets up a new device, offer passkeys across different contexts (a passkey established from an app can be used in the browser when visiting the app’s website), or allow users to exercise passkeys across devices (by, say, using the passkey from a nearby phone when signing in from a laptop).
Third-Party Passkey Provider
A Passkey Provider that plugs in to the OS via platform APIs to store and manage a user’s passkeys via the platform authenticator.
NOTE: Some passkey providers support passkeys via a browser extension that intercepts WebAuthn requests. Providers that bypass browser and/or platform interfaces and features in this manner typically offer a way for the intercepted request to be passed back to the browser and/or platform to handle as usual.
User Presence (UP)
A test of User Presence (UP) is used to ensure the user is in local proximity to the authenticator during an authentication or credential creation ceremony. UP is often satisfied by pressing a button or metallic area of a security key, or interacting with a platform authenticator on a device.
User Verification (UV)
User Verification (UV) requires the user to either perform a biometric gesture, enter the device PIN, or enter the device password for the authenticator to authorize creation and/or use of the credential.
User-Verifying Roaming Authenticator
A User-Verifying Roaming Authentication (UVRA), also known as a first-factor roaming authenticator, can verify individual users through the use of biometrics, or through the user entering a device PIN. An important class of UVRAs are smartphones, in which case the “attachment” typically happens over a wireless connection.