WebAuthn FAQs – Part 7

Question: Explain the steps involved in the authenticatorMakeCredential operation.

The authenticatorMakeCredential operation is the heart of the WebAuthn registration ceremony. It’s the process by which a new credential is created on an authenticator, bound to a specific Relying Party and user account. This operation occurs entirely within the authenticator’s secure environment.

Here’s a breakdown of the steps involved, explained in detail for new engineers:

1. Input Validation

The authenticator first receives a set of parameters from the client platform (browser/OS), which acts as a conduit between the Relying Party’s website and the authenticator. These parameters include:

• hash: A cryptographic hash of the client data, which includes information about the Relying Party and the user’s browsing context.
• rpEntity: Information about the Relying Party, including its name and a unique identifier (RP ID).
• userEntity: Information about the user account, including a unique identifier (user handle), display name, and potentially a username.
• requireResidentKey: A boolean indicating whether the Relying Party requires a discoverable credential (also known as a “resident key”).
• requireUserPresence: WebAuthn always requires a test of user presence. This is included as a parameter for theoretical flexibility.
• requireUserVerification: A boolean indicating whether the Relying Party requires strong user verification (e.g., PIN, biometric).
• credTypesAndPubKeyAlgs: A list of supported credential types and algorithms that the Relying Party is willing to accept. This allows the authenticator to select the best option it supports.
• excludeCredentialDescriptorList: A list of credential descriptors (ID, type) that the Relying Party wants to avoid duplicating. If the authenticator finds a matching credential, it should signal to the client to use a different authenticator.
• enterpriseAttestationPossible: A boolean indicating whether enterprise attestation, which may reveal more identifying information about the authenticator, is allowed.
• attestationFormats: A list of preferred attestation statement formats, allowing the Relying Party to express its preferences.
• extensions: A data structure for any additional custom information requested by the Relying Party through WebAuthn extensions.

The authenticator checks that all these parameters are well-formed and have the correct data types and lengths. Any issues at this stage result in an error (“UnknownError“) returned to the client.

2. Capability Check

The authenticator verifies that it supports at least one of the requested credential types and algorithms in credTypesAndPubKeyAlgs. If not, it returns an error ("NotSupportedError").

3. Duplicate Credential Check

If the Relying Party provides an excludeCredentialDescriptorList, the authenticator checks its internal storage for any matching credentials. If a match is found:

• The authenticator prompts the user for consent to reveal this information to the client.
• If the user consents, the authenticator returns an error ("InvalidStateError"), signaling the client to guide the user towards a different authenticator.
• If the user doesn’t consent, the authenticator proceeds as if the credential wasn’t found, protecting the user’s privacy.

4. Constraint Validation

• If requireResidentKey is true, but the authenticator can’t create a discoverable credential (maybe it lacks storage), it returns an error ("ConstraintError").
• If requireUserVerification is true, but the authenticator can’t perform user verification (maybe it lacks a fingerprint sensor or PIN capability), it also returns a "ConstraintError".

5. User Consent and Authorization

The authenticator prompts the user for consent to create the new credential. This is a critical step to ensure the user is aware and approves of the process. The prompt will typically show information about the Relying Party and the user account.

• If requireUserVerification is true, the authenticator will also perform a strong user verification check (e.g., prompting for a PIN, fingerprint scan).
• If the user doesn’t consent, or if user verification fails, the operation is aborted with an error ("NotAllowedError").

6. Credential Generation

Once consent is obtained:

• The authenticator generates a new key pair (publicKey, privateKey) based on the chosen credential type and algorithm from the credTypesAndPubKeyAlgs list.
• A new credentialSource object is created, containing the privateKey, the RP ID (rpEntity.id), the user handle (userEntity.id), and any additional UI-related information.

7. Credential Storage and ID Generation

The way the credential is stored and how its ID is generated depends on whether it’s a discoverable credential or not:

Discoverable Credentials:

• The authenticator generates a random, unique credential ID (credentialId).
• The credentialSource is stored in the authenticator’s internal storage, associated with the RP ID and user handle.

Server-side Credentials (Non-discoverable):

• The credentialSource itself (excluding the id) is encrypted using a mechanism specific to the authenticator. The resulting ciphertext becomes the credentialId.
• The Relying Party is responsible for storing the credentialId, which is effectively an encrypted version of the credential. The authenticator can later decrypt it when needed.

8. Extensions Processing

If the Relying Party requested any extensions, the authenticator processes them according to the extension definitions. This might involve collecting additional data, performing extra checks, or modifying the credential creation process.

9. Signature Counter Initialization

The authenticator initializes the signature counter for the new credential. This is a security measure to help Relying Parties detect cloned authenticators. The counter can be either:

• Global (for the entire authenticator)
• Per-credential (specific to the newly created credential)

10. Authenticator Data and Attestation

• The authenticator builds the authenticatorData structure, which includes information about the authenticator itself, the credential public key, flags indicating user presence and verification, the signature counter value, and any data from extensions.
• If attestation is requested, the authenticator also creates an attestation statement, proving certain properties of the authenticator and the credential. This typically involves a signature by the authenticator’s attestation key.

11. Attestation Object Creation

Finally, the authenticator assembles the attestationObject, which combines the authenticatorData and the attestation statement. This object is returned to the client.

Successful Completion

The authenticatorMakeCredential operation completes successfully, and the newly created credential is ready for use. The Relying Party can now register the credentialId and credentialPublicKey in its database, associating them with the user account.

This concludes the complex but crucial process of registering a new WebAuthn credential. Each step contributes to the security and privacy of the WebAuthn ecosystem

Question: How does the excludeCredentialDescriptorList parameter influence the authenticatorMakeCredential operation?

The excludeCredentialDescriptorList parameter in the authenticatorMakeCredential operation plays a crucial role in preventing the creation of duplicate credentials on the same authenticator. Here’s a detailed breakdown of its influence:

Purpose:

The primary purpose of excludeCredentialDescriptorList is to prevent a user from accidentally registering multiple credentials for the same account on the same authenticator. This list, provided by the Relying Party, contains details about existing credentials associated with the user account.

How it Works:

1. Credential Matching: When the authenticatorMakeCredential operation is invoked, the authenticator checks if any of the credential descriptors in the excludeCredentialDescriptorList match existing credentials stored on the device. The matching is done based on:

• rpEntity.id: The Relying Party ID for the new credential being created.
• descriptor.id: The Credential ID from the excludeCredentialDescriptorList.
• descriptor.type: The credential type (e.g., “public-key”) from the list.

1. User Consent: If a match is found:
   • The authenticator MUST collect an authorization gesture from the user to confirm their consent for creating a new credential. This gesture MUST include a test of user presence.
   • This consent prompt is crucial for privacy. It informs the user that the authenticator already has a credential for this account and allows them to choose whether to proceed with creating a duplicate or not.
2. Authenticator Response: Based on the user’s response:
   • Consent Granted: The authenticator returns an error code equivalent to "InvalidStateError". The client and Relying Party can detect this error, understand that a credential already exists on this authenticator, and guide the user to use a different authenticator.
   • Consent Denied: The authenticator returns an error code equivalent to "NotAllowedError", hiding the fact that a matching credential exists to protect the user’s privacy.

Security and Privacy Implications:

• Preventing Duplicate Credentials: By using excludeCredentialDescriptorList, the Relying Party can prevent the accidental creation of multiple credentials for the same account on the same authenticator, simplifying credential management and reducing potential security risks.
• User Privacy: The required authorization gesture when a matching credential is found ensures that the user is aware of the situation and consents to the potential privacy implications of revealing that a particular credential is stored on their authenticator.

Example:

Imagine a user has already registered a credential for their account on a security key. Later, they attempt to register a new credential for the same account using the same security key. The Relying Party would include the existing credential’s details in the excludeCredentialDescriptorList. The authenticator, detecting the match, would prompt the user, “This security key already has a credential for this account. Do you want to create another one?”

Best Practices:

• Relying Parties SHOULD always populate excludeCredentialDescriptorList with all known credentials for the user account to minimize the risk of duplicate registrations.
• Include transport information (descriptor.transports) in the excludeCredentialDescriptorList whenever possible. This helps the client optimize the process and avoids unnecessary checks with inapplicable authenticators.

By effectively utilizing the excludeCredentialDescriptorList parameter, Relying Parties can enhance the security and user experience of WebAuthn credential registration.

Question: What authorization gestures are required during the authenticatorMakeCredential operation?

The authenticatorMakeCredential operation requires two authorization gestures:

1. For excluded credentials:

• This gesture is triggered for each descriptor in the excludeCredentialDescriptorList where the authenticator recognizes the credential ID.
• Purpose: To obtain user consent for disclosing that the listed credential ID is already registered on this authenticator. This prevents malicious Relying Parties from probing for the presence of specific credentials without the user’s knowledge.
• Requirement: MUST include a test of user presence.
• Outcome:
  • If the user consents, the authenticator returns an InvalidStateError to the client. This signals to the Relying Party that they should guide the user to use a different authenticator.
  • If the user doesn’t consent, the authenticator returns a NotAllowedError, effectively hiding the presence of the credential from the Relying Party.

1. For creating a new credential:

• This gesture is triggered after processing the excludeCredentialDescriptorList.
• Purpose: To obtain user consent for creating a new credential on this authenticator.
• Requirement:
  • MUST include a test of user presence.
  • MUST include user verification if requireUserVerification is true.
• Outcome:
  • If the user consents and verification (if required) succeeds, the authenticator proceeds with generating the new credential.
  • If the user doesn’t consent or verification fails, the authenticator returns a NotAllowedError.

In summary:

The first authorization gesture is for privacy protection, allowing the user to control disclosure of existing credentials. The second authorization gesture is for security, ensuring the user explicitly approves the creation of a new credential.

Question: Describe the process of generating a new credential object within the authenticatorMakeCredential operation.

Let’s break down how a new credential object is generated within the authenticatorMakeCredential operation in WebAuthn. This is the core of the registration process, where a new public key-based credential is created on the user’s authenticator.

1. Key Pair Generation

• The authenticator selects the first supported combination of PublicKeyCredentialType (always “public-key”) and the cryptographic algorithm (COSEAlgorithmIdentifier) from the credTypesAndPubKeyAlgs list provided by the Relying Party.
• It generates a new pair of cryptographic keys (publicKey, privateKey) using the selected algorithm. The specific key type (e.g., RSA, Elliptic Curve) is determined by this algorithm.

2. User Handle Extraction

• The userHandle is extracted from the userEntity.id provided by the Relying Party. This opaque byte sequence (up to 64 bytes) represents the user account on the Relying Party’s system.

3. Credential Source Construction

• A new public key credential source structure (credentialSource) is created. This structure holds the core components of the credential:
  • type: Set to “public-key”.
  • privateKey: The newly generated private key.
  • rpId: The Relying Party Identifier (rpEntity.id) the credential is scoped to.
  • userHandle: The user handle extracted earlier.
  • otherUI: Any additional information the authenticator wants to store, often used for UI purposes during authentication (e.g., user’s display name).

4. Credential ID Generation and Storage

• Discoverable Credential:
  • If requireResidentKey is true (the Relying Party wants a discoverable credential), or the authenticator decides to create a discoverable credential:
    • A new, globally unique credentialId is generated.
    • The credentialSource.id is set to this credentialId.
    • The credentialSource is added to the authenticator’s credentials map, indexed by the pair (rpEntity.id, userHandle).
• Non-Discoverable Credential:
  • Otherwise:
    • The entire credentialSource is serialized and encrypted so that only this authenticator can decrypt it. The result becomes the credentialId. This is how authenticators with limited storage handle credentials. The Relying Party stores this encrypted credentialId and provides it back to the authenticator during authentication.

Error Handling

• If any error occurs during the key generation or credential creation steps, the operation is terminated with an error code equivalent to “UnknownError”.

In Summary

The authenticator generates a new key pair, associates it with the Relying Party and user handle, and creates a credentialSource structure to encapsulate these elements. Depending on whether the credential is discoverable or not, a credentialId is generated either randomly or by encrypting the entire credentialSource. This process ensures that the credential is securely stored and bound to the authenticator, ready to be used in future authentication ceremonies.

Question: Explain the steps involved in the authenticatorGetAssertion operation.

The authenticatorGetAssertion operation is the heart of the WebAuthn authentication ceremony. It’s the process by which an authenticator (like a security key or a platform authenticator) proves to a Relying Party (website or service) that the user possesses the private key associated with a previously registered credential.

Here’s a breakdown of the steps involved, explained for engineers new to WebAuthn:

1. Input Parameters

The authenticatorGetAssertion operation takes several parameters from the client (browser):

• rpId: The Relying Party ID (a domain string like “example.com”) for which authentication is requested.
• hash: A cryptographic hash of the “client data”, which includes information like the challenge from the Relying Party, the origin of the request, etc.
• allowCredentialDescriptorList (optional): A list of credential descriptors the Relying Party is willing to accept. Each descriptor includes the credential ID, type, and optionally transports (USB, NFC, BLE, etc.).
• requireUserPresence: A constant true value, signifying that the operation must include a test of user presence (e.g., touching a security key).
• requireUserVerification: A boolean indicating whether user verification (stronger than presence, like a PIN or biometric) is required.
• enterpriseAttestationPossible: A boolean indicating if the authenticator can return an attestation statement that might contain uniquely identifying information.
• attestationFormats: A list of attestation statement formats the Relying Party prefers, if attestation is desired.
• extensions: A CBOR map containing inputs for any WebAuthn extensions requested by the Relying Party.

2. Parameter Validation

The authenticator first validates that all received parameters are well-formed and have correct lengths. If there are errors, it returns an error code (“UnknownError”) and stops.

3. Credential Selection

The authenticator must determine which credential(s) are eligible for this authentication:

• If allowCredentialDescriptorList is provided: The authenticator looks up each credential ID in the list within its own storage. Only matching credentials scoped to the given rpId are added to a set of credentialOptions.
• If allowCredentialDescriptorList is not provided: The authenticator considers all client-side discoverable credentials (also known as passkeys) it holds for the given rpId.

4. Empty Credential Options

If, after filtering, credentialOptions is empty (no suitable credentials found), the authenticator returns “NotAllowedError” and terminates.

5. User Interaction and Consent

This is a crucial step for security:

• Prompt: The authenticator, or the client platform if the authenticator lacks display capabilities, prompts the user to select a credential from credentialOptions.
• Authorization Gesture: The authenticator obtains an authorization gesture (e.g., button press, biometric scan) to confirm user consent.
• If requireUserVerification is true, the gesture MUST include user verification.
• requireUserPresence is always true, ensuring a presence test is performed.
• Denial: If the user doesn’t consent or verification fails, the authenticator returns “NotAllowedError” and stops.

6. Extension Processing

• For each supported extension, the authenticator runs its authenticator extension processing to generate outputs based on the provided inputs.

7. Signature Counter Handling

• Authenticators SHOULD implement a signature counter per credential to help detect cloned authenticators. The counter is incremented for each successful assertion. If the authenticator doesn’t support counters, the value remains zero.

8. Attestation (Optional)

• If the Relying Party requested attestation in the input parameters, and the authenticator supports it, it generates an attestation object as described in step 6 of the authenticatorMakeCredential operation.

9. Authenticator Data and Signature

• The authenticator assembles the authenticatorData byte array as described in section 6.1 of the WebAuthn spec, including the incremented signature counter, extension outputs, and optionally attested credential data if attestation is used.
• The authenticator uses the selected credential’s private key to generate a signature over the concatenation of authenticatorData and the hash.

10. Return Values

On success, the authenticator returns the following to the client:

• The selected credential’s ID.
• The authenticatorData.
• The signature.
• The attestation object, if generated.
• The selected credential’s userHandle, if available.

Error Handling

Throughout these steps, if any errors occur (e.g., cryptographic operations fail), the authenticator returns an “UnknownError” and stops.

Key Points

• Security: User consent and authorization gestures are central to WebAuthn’s security model. The authenticator ensures the user is present and optionally verified.
• Scope: The authenticator verifies that the requested credential is indeed scoped to the rpId provided by the client, preventing credentials from being used on the wrong website.
• Flexibility: The use of extensions allows for additional functionality and customization.
• Privacy: Authenticators are designed to protect user privacy by minimizing the information revealed to the Relying Party.

Question: What happens if the allowCredentialDescriptorList parameter is not provided during the authenticatorGetAssertion operation?

Here’s what happens when the allowCredentialDescriptorList parameter is not provided in the authenticatorGetAssertion operation:

The Situation:

The allowCredentialDescriptorList parameter, when provided to authenticatorGetAssertion, gives the authenticator a list of specific credentials (identified by their credentialId) that the Relying Party is willing to accept for this authentication attempt.

When this list is not provided, it signals to the authenticator that the Relying Party is open to accepting any credential the user possesses that’s associated with that Relying Party (identified by the rpId).

How the Authenticator Responds:

1. Discoverable Credentials Only: The authenticator will only consider client-side discoverable credentials (also known as passkeys). These are credentials that can be discovered and selected by the authenticator without the Relying Party providing a specific credentialId.
2. User Selection: If the authenticator has multiple discoverable credentials for that Relying Party, it will prompt the user to choose which credential they want to use for authentication. The prompt will typically display information associated with each credential to help the user make a selection (e.g., user name, display name, RP name).
3. Generate Assertion: Once the user selects a credential, the authenticator generates the assertion (including the signature, authenticator data, and potentially a user handle) using the chosen credential’s private key.

Key Implications:

• Simplified User Experience: This approach streamlines the user experience, especially for scenarios where the user has multiple credentials registered for the same Relying Party.
• Passwordless Authentication: This mechanism is essential for enabling passwordless authentication flows where the user doesn’t need to provide a username or any other identifying information upfront.
• User Privacy: The authenticator ensures that only discoverable credentials are considered, protecting the user’s privacy by not exposing other credentials they might have stored.

In Summary: Omitting the allowCredentialDescriptorList parameter tells the authenticator to use any available discoverable credential associated with the Relying Party, providing a user-friendly and privacy-conscious approach to authentication.

Question: How does user verification work during the authenticatorGetAssertion operation?

Let’s break down how user verification works during the authenticatorGetAssertion operation in WebAuthn.

Understanding the Basics

• authenticatorGetAssertion: This operation is the heart of the WebAuthn authentication ceremony. It’s when the authenticator (e.g., your security key or phone’s built-in biometric sensor) uses a registered credential to generate a cryptographic signature proving you possess the corresponding private key.
• User Verification: This is a crucial security step where the authenticator ensures that the person attempting to use the credential is the legitimate owner. It usually involves an action like:
  • Entering a PIN
  • Providing a fingerprint
  • Facial recognition scan
  • Pressing a button on a security key
• requireUserVerification: The Relying Party (the website or service you’re logging into) specifies whether user verification is mandatory by setting the userVerification parameter in PublicKeyCredentialRequestOptions. Its possible values are:
  • "required": Authentication must include user verification.
  • "preferred": The authenticator should try to perform user verification if possible, but it’s not a deal-breaker.
  • "discouraged": The Relying Party doesn’t want user verification for this particular request.

The authenticatorGetAssertion Flow

1. Relying Party Request: The website initiates the authentication process and calls the WebAuthn API’s navigator.credentials.get() function. The userVerification preference is passed in the PublicKeyCredentialRequestOptions.
2. Client Preparation: The client (your web browser or operating system) receives the request and locates available authenticators.
3. Authenticator Selection: Based on the request, the client determines which authenticators meet the criteria (including the userVerification requirement).
4. User Interaction:

• If requireUserVerification is true: The authenticator MUST perform user verification before proceeding. It will prompt you with its chosen method (PIN, fingerprint, etc.).
• If requireUserVerification is "preferred": The authenticator will attempt user verification. If the authenticator is capable and you succeed, great! If not (maybe the authenticator can’t do user verification, or you fail the check), the process might still continue.
• If requireUserVerification is "discouraged": The authenticator skips user verification. This is used for low-security contexts where convenience is prioritized.

1. Assertion Generation: After (successful or skipped) user verification, the authenticator signs the Relying Party’s challenge and other data, creating an AuthenticatorAssertionResponse. This response includes:

• The signature
• Authenticator data, which includes a flag indicating whether user verification was performed (UV flag)

1. Response to Relying Party: The client sends the AuthenticatorAssertionResponse back to the Relying Party.
2. Relying Party Verification: The website verifies the signature and examines the UV flag to know if user verification happened. Based on its security policy, the website then decides whether to grant access.

Key Points

• User verification happens entirely on the authenticator. The website only receives a flag indicating whether it succeeded.
• The Relying Party controls whether user verification is mandatory, preferred, or discouraged.
• Different authenticators support different user verification methods.
• WebAuthn’s design emphasizes security and user privacy. Biometric data or PINs never leave the authenticator.

Question: Describe the process of generating an assertion signature within the authenticatorGetAssertion operation.

The process of generating an assertion signature within the authenticatorGetAssertion operation is a crucial step in the WebAuthn authentication process. Here’s a detailed breakdown:

1. Preparation:

• Input Parameters: The authenticator receives several input parameters, including:
  • rpId: The Relying Party Identifier, indicating the website the user is trying to authenticate with.
  • hash: The SHA-256 hash of the client data, which contains contextual information about the authentication request.
  • allowCredentialDescriptorList: (Optional) A list of acceptable credentials, potentially filtered by the client.
  • requireUserPresence: A boolean, always true in WebAuthn, indicating the requirement for user interaction.
  • requireUserVerification: A boolean indicating whether user verification (e.g., fingerprint, PIN) is required.
  • enterpriseAttestationPossible: A boolean indicating if enterprise attestation is possible.
  • attestationFormats: A list of preferred attestation statement formats.
  • extensions: A CBOR map of requested authenticator extensions and their input values.
• Credential Selection:
  • If allowCredentialDescriptorList is provided, the authenticator looks for a matching credential among those listed.
  • If no list is provided, the authenticator uses any suitable credential scoped to the rpId.
  • The user is prompted to choose a credential if multiple options are available.
• User Consent and Verification:
  • The user must authorize the use of the chosen credential through an authorization gesture (e.g., touching a security key, providing a biometric scan).
  • If requireUserVerification is true, the authenticator performs user verification.

2. Generating the Authenticator Data:

• The authenticator assembles the authenticator data, a byte array containing:
  • rpIdHash: The SHA-256 hash of the rpId.
  • flags: A single byte representing various flags, such as user presence (UP), user verification (UV), backup eligibility (BE), and backup state (BS).
  • signCount: A 32-bit counter that increments with each successful assertion, helping detect cloned authenticators.
  • extensions: (Optional) A CBOR map of authenticator extension outputs for any processed extensions.
  • attestedCredentialData: (Conditional) Included only if attestation is requested.

3. Signature Generation:

• Concatenation: The authenticator data (authenticatorData) and the hash of the client data (hash) are concatenated into a single byte string: authenticatorData || hash.
• Signing: The authenticator uses the private key (privateKey) associated with the selected credential to sign this concatenated byte string. The specific signature algorithm is determined by the credential’s public key algorithm.
• Output: The signature (signature) is generated, representing the authenticator’s assertion that the user possesses the private key and has consented to the request.

4. Returning Data:

The authenticator returns the following data to the client:

• Credential ID: (Conditional) The ID of the credential used.
• authenticatorData: The generated authenticator data.
• signature: The generated assertion signature.
• Attestation Object: (Optional) An attestation object, if attestation was requested.
• User Handle: (Optional) The user handle associated with the credential.

Simplified Illustration:

             +-------------------+
             |   Authenticator   |
             +-------------------+
                 |
                 |  authenticatorGetAssertion(rpId, hash, ...)
                 V
+-----------------------------------------+
| 1. Locate Credential                    |
| 2. Prompt User for Consent/Verification |
| 3. Generate Authenticator Data         |
| 4. Calculate Signature:                |
|    signature = SIGN(privateKey,        |
|                     authenticatorData || hash) |
+-----------------------------------------+
                 |
                 | return(credentialId, authenticatorData, signature, ...)
                 V

Security Significance:

The assertion signature provides cryptographic proof:

• Possession: The user possesses the private key corresponding to the public key registered with the Relying Party.
• Consent: The user has authorized the operation (through the authorization gesture).
• Authenticity: The response originates from the authenticator.

The Relying Party will later verify this signature to authenticate the user.

Question: What is the purpose and functionality of the authenticatorCancel operation?

The authenticatorCancel operation is a crucial part of the WebAuthn Authenticator Model, designed to enhance security and user control during WebAuthn ceremonies (registration or authentication). Here’s a breakdown of its purpose and functionality:

Purpose:

• Graceful Termination: Its primary purpose is to provide a mechanism for gracefully terminating ongoing authenticatorMakeCredential (registration) or authenticatorGetAssertion (authentication) operations. This is particularly important in scenarios where an operation needs to be aborted due to various reasons like timeouts, user cancellation, or errors.
• Preventing Resource Leaks: It helps prevent potential resource leaks on the authenticator by ensuring that any ongoing operation is properly stopped and any resources held by it are released.
• User Control: It empowers the user, via the client (browser), to cancel an operation that they might have unintentionally initiated or changed their mind about.

Functionality:

1. Invocation: The authenticatorCancel operation is invoked by the WebAuthn Client (typically part of the web browser) during an authenticator session.
2. Effect: When invoked, it terminates any ongoing authenticatorMakeCredential or authenticatorGetAssertion operation within that specific authenticator session.
3. Stopping User Input: The authenticator, upon receiving the authenticatorCancel signal, immediately stops prompting the user for any further input related to the canceled operation (e.g., PIN, biometric scan).
4. Ignoring Responses: The client (browser) will disregard any further responses from the authenticator related to the operation that was canceled.
5. Idempotency: The authenticatorCancel operation is idempotent. If invoked in a session where no operation is in progress, it has no effect.

Example Scenario:

Imagine a user initiates a WebAuthn registration using a security key. They plug in the key and the key starts blinking, prompting for a button press. However, the user decides they don’t want to register at that moment. They click the “Cancel” button on the browser prompt.

Behind the scenes, the browser invokes the authenticatorCancel operation. The security key stops blinking and no longer waits for the button press. Any further communication from the key related to that registration attempt is ignored by the browser.

Key Points:

• authenticatorCancel does not send any input parameters to the authenticator and does not expect any output. It’s a simple signal to halt the process.
• The success of the authenticatorCancel operation itself is not explicitly indicated to the Relying Party (website). The Relying Party will only observe that the original registration or authentication operation failed due to cancellation.

In essence, the authenticatorCancel operation is a vital part of WebAuthn’s security and user experience model, ensuring clean termination of operations and providing users with the ability to stop any WebAuthn process midway if needed.

Question: How does the silentCredentialDiscovery operation enable conditional user mediation?

Let’s break down how the silentCredentialDiscovery operation facilitates conditional user mediation in WebAuthn.

Understanding Conditional User Mediation

Conditional user mediation aims to enhance the user experience by showing authentication prompts only when necessary. Instead of automatically popping up a modal dialog for credential selection, the user agent waits for a specific trigger. This trigger is often the user interacting with a form field that has the “webauthn” autofill detail token in its autocomplete attribute.

The Role of silentCredentialDiscovery

1. Credential Discovery Without User Interaction: When a Relying Party calls navigator.credentials.get() with options.mediation set to “conditional”, the user agent checks if the available authenticators support silentCredentialDiscovery.
2. Quietly Identifying Credentials: If supported, the user agent calls the silentCredentialDiscovery operation on the authenticator. This operation scans the authenticator for discoverable credentials (passkeys) that are scoped to the requested RP ID. Crucially, this happens without any user prompts.
3. Building a List of Available Credentials: The authenticator returns a list of DiscoverableCredentialMetadata structs, each containing information about a matched credential. The user agent stores this list, along with a reference to the authenticator that holds each credential.
4. Triggering User Mediation: The user agent waits for the user to interact with a relevant form field (e.g., one with the “webauthn” autofill detail token). Upon this interaction, the user agent presents a UI listing the silently discovered credentials, allowing the user to select one.
5. Initiating Authentication: Once the user selects a credential, the user agent sends a full credential request (using authenticatorGetAssertion) to the corresponding authenticator, which then prompts for user verification (if required) and generates the assertion.

Benefits of silentCredentialDiscovery:

• Reduced User Interruptions: The user is not bombarded with prompts unless they specifically initiate a WebAuthn-related action.
• Smoother User Experience: The authentication flow is more integrated with the website’s normal form interaction.
• Privacy Enhancement: User credentials are not unnecessarily revealed until the user has indicated intent to authenticate.

In Summary:

The silentCredentialDiscovery operation enables conditional user mediation by allowing the user agent to discover available passkeys without user interaction. This lets the user agent delay user prompts until the user indicates a desire to authenticate, improving the overall experience.

References

Web Authentication: An API for accessing Public Key Credentials – Level 3 (w3.org)