Web Authentication:
An API for accessing Public Key Credentials
Level 3

Editor’s Draft,

More details about this document
This version:
https://w3c.github.io/webauthn/
Latest published version:
https://www.w3.org/TR/webauthn-3/
Previous Versions:
Implementation Report:
https://www.w3.org/2020/12/webauthn-report.html
Feedback:
GitHub
Editors:
(Okta)
(Self-Issued Consulting)
(Microsoft)
(Yubico)
(Cisco)
Former Editors:
(Google)
(Microsoft)
(Google)
(Google)
Jeff Hodges (formerly Google)
J.C. Jones (formerly Mozilla)
(PayPal)
(Microsoft)
(Nok Nok Labs)
Contributors:
John Bradley (Yubico)
Christiaan Brand (Google)
Adam Langley (Google)
Giridhar Mandyam (Qualcomm)
Pascoe (Apple)
Nina Satragno (Google)
Ki-Eun Shin (SK Telecom)
Nick Steele (1Password)
Jiewen Tan (Apple)
Shane Weeden (IBM)
Mike West (Google)
Jeffrey Yasskin (Google)
Anders Åberg (Bitwarden)
Tests:
web-platform-tests webauthn/ (ongoing work)

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

Abstract

This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality.

Status of this document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the Web Authentication Working Group as an Editors' Draft. This document is intended to become a W3C Recommendation. Feedback and comments on this specification are welcome. Please use Github issues. Discussions may also be found in the [email protected] archives.

Publication as an Editors' Draft does not imply endorsement by W3C and its Members. This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is not normative.

This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. A public key credential is created and stored by a WebAuthn Authenticator at the behest of a WebAuthn Relying Party, subject to user consent. Subsequently, the public key credential can only be accessed by origins belonging to that Relying Party. This scoping is enforced jointly by conforming User Agents and authenticators. Additionally, privacy across Relying Parties is maintained; Relying Parties are not able to detect any properties, or even the existence, of credentials scoped to other Relying Parties.

Relying Parties employ the Web Authentication API during two distinct, but related, ceremonies involving a user. The first is Registration, where a public key credential is created on an authenticator, and scoped to a Relying Party with the present user’s account (the account might already exist or might be created at this time). The second is Authentication, where the Relying Party is presented with an Authentication Assertion proving the presence and consent of the user who registered the public key credential. Functionally, the Web Authentication API comprises a PublicKeyCredential which extends the Credential Management API [CREDENTIAL-MANAGEMENT-1], and infrastructure which allows those credentials to be used with navigator.credentials.create() and navigator.credentials.get(). The former is used during Registration, and the latter during Authentication.

Broadly, compliant authenticators protect public key credentials, and interact with user agents to implement the Web Authentication API. Implementing compliant authenticators is possible in software executing (a) on a general-purpose computing device, (b) on an on-device Secure Execution Environment, Trusted Platform Module (TPM), or a Secure Element (SE), or (c) off device. Authenticators being implemented on device are called platform authenticators. Authenticators being implemented off device (roaming authenticators) can be accessed over a transport such as Universal Serial Bus (USB), Bluetooth Low Energy (BLE), or Near Field Communications (NFC).

1.1. Specification Roadmap

While many W3C specifications are directed primarily to user agent developers and also to web application developers (i.e., "Web authors"), the nature of Web Authentication requires that this specification be correctly used by multiple audiences, as described below.

All audiences ought to begin with § 1.2 Use Cases, § 1.3 Sample API Usage Scenarios, and § 4 Terminology, and should also refer to [WebAuthnAPIGuide] for an overall tutorial. Beyond that, the intended audiences for this document are the following main groups:

Note: Along with the Web Authentication API itself, this specification defines a request-response cryptographic protocol—the WebAuthn/FIDO2 protocol—between a WebAuthn Relying Party server and an authenticator, where the Relying Party’s request consists of a challenge and other input data supplied by the Relying Party and sent to the authenticator. The request is conveyed via the combination of HTTPS, the Relying Party web application, the WebAuthn API, and the platform-specific communications channel between the user agent and the authenticator. The authenticator replies with a digitally signed authenticator data message and other output data, which is conveyed back to the Relying Party server via the same path in reverse. Protocol details vary according to whether an authentication or registration operation is invoked by the Relying Party. See also Figure 1 and Figure 2.

It is important for Web Authentication deployments' end-to-end security that the role of each component—the Relying Party server, the client, and the authenticator— as well as § 13 Security Considerations and § 14 Privacy Considerations, are understood by all audiences.

1.2. Use Cases

The below use case scenarios illustrate use of two very different types of authenticators and credentials across two common deployment types, as well as outline further scenarios. Additional scenarios, including sample code, are given later in § 1.3 Sample API Usage Scenarios. These examples are for illustrative purposes only, and feature availability may differ between client and authenticator implementations.

1.2.1. Consumer with Multi-Device Credentials

This use case illustrates how a consumer-centric Relying Party can leverage the authenticator built-in to a user’s devices to provide phishing-resistant sign in using multi-device credentials (commonly referred to as synced passkeys).

1.2.1.1. Registration
1.2.1.2. Authentication

1.2.2. Workforce with Single-Device Credentials

This use case illustrates how a workforce-centric Relying Party can leverage a combination of a roaming authenticator (e.g., a USB security key) and a platform authenticator (e.g., a built-in fingerprint sensor) such that the user has:

1.2.2.1. Registration

In this example, the user’s employer mails a security key which is preconfigured with a device-bound passkey.

A temporary PIN was sent to the user out of band (e.g., via an RCS message).

1.2.2.2. Authentication

1.2.3. Other Use Cases and Configurations

A variety of additional use cases and configurations are also possible, including (but not limited to):

1.3. Sample API Usage Scenarios

This section is not normative.

In this section, we walk through some events in the lifecycle of a public key credential, along with the corresponding sample code for using this API. Note that this is an example flow and does not limit the scope of how the API can be used.

As was the case in earlier sections, this flow focuses on a use case involving a passkey roaming authenticator with its own display. One example of such an authenticator would be a smart phone. Other authenticator types are also supported by this API, subject to implementation by the client platform. For instance, this flow also works without modification for the case of an authenticator that is embedded in the client device. The flow also works for the case of an authenticator without its own display (similar to a smart card) subject to specific implementation considerations. Specifically, the client platform needs to display any prompts that would otherwise be shown by the authenticator, and the authenticator needs to allow the client platform to enumerate all the authenticator’s credentials so that the client can have information to show appropriate prompts.

1.3.1. Registration

This is the first-time flow, in which a new credential is created and registered with the server. In this flow, the WebAuthn Relying Party does not have a preference for platform authenticator or roaming authenticators.

  1. The user visits example.com, which serves up a script. At this point, the user may already be logged in using a legacy username and password, or additional authenticator, or other means acceptable to the Relying Party. Or the user may be in the process of creating a new account.

  2. The Relying Party script runs the code snippet below.

  3. The client platform searches for and locates the authenticator.

  4. The client connects to the authenticator, performing any pairing actions if necessary.

  5. The authenticator shows appropriate UI for the user to provide a biometric or other authorization gesture.

  6. The authenticator returns a response to the client, which in turn returns a response to the Relying Party script. If the user declined to select an authenticator or provide authorization, an appropriate error is returned.

  7. If a new credential was created,

    • The Relying Party script sends the newly generated credential public key to the server, along with additional information such as attestation regarding the provenance and characteristics of the authenticator.

    • The server stores the credential public key in its database and associates it with the user as well as with the characteristics of authentication indicated by attestation, also storing a friendly name for later use.

    • The script may store data such as the credential ID in local storage, to improve future UX by narrowing the choice of credential for the user.

The sample code for generating and registering a new key follows:

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

var publicKey = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([21,31,105 /* 29 more random bytes generated by the server */]),

  // Relying Party:
  rp: {
    name: "ACME Corporation"
  },

  // User:
  user: {
    id: Uint8Array.from(window.atob("MIIBkzCCATigAwIBAjCCAZMwggE4oAMCAQIwggGTMII="), c=>c.charCodeAt(0)),
    name: "[email protected]",
    displayName: "Alex Müller",
  },

  // This Relying Party will accept either an EdDSA, ES256 or RS256 credential, but
  // prefers an EdDSA credential.
  pubKeyCredParams: [
    {
      type: "public-key",
      alg: -8 // "EdDSA" as registered in the IANA COSE Algorithms registry
    },
    {
      type: "public-key",
      alg: -7 // "ES256" as registered in the IANA COSE Algorithms registry
    },
    {
      type: "public-key",
      alg: -257 // Value registered by this specification for "RS256"
    }
  ],

  authenticatorSelection: {
    // Try to use UV if possible. This is also the default.
    userVerification: "preferred"
  },

  timeout: 300000,  // 5 minutes
  excludeCredentials: [
    // Don't re-register any authenticator that has one of these credentials
    {"id": Uint8Array.from(window.atob("ufJWp8YGlibm1Kd9XQBWN1WAw2jy5In2Xhon9HAqcXE="), c=>c.charCodeAt(0)), "type": "public-key"},
    {"id": Uint8Array.from(window.atob("E/e1dhZc++mIsz4f9hb6NifAzJpF1V4mEtRlIPBiWdY="), c=>c.charCodeAt(0)), "type": "public-key"}
  ],

  // Make excludeCredentials check backwards compatible with credentials registered with U2F
  extensions: {"appidExclude": "https://acme.example.com"}
};

// Note: The following call will cause the authenticator to display UI.
navigator.credentials.create({ publicKey })
  .then(function (newCredentialInfo) {
    // Send new credential info to server for verification and registration.
  }).catch(function (err) {
    // No acceptable authenticator or user refused consent. Handle appropriately.
  });

1.3.2. Registration Specifically with User-Verifying Platform Authenticator

This is an example flow for when the WebAuthn Relying Party is specifically interested in creating a public key credential with a user-verifying platform authenticator.

  1. The user visits example.com and clicks on the login button, which redirects the user to login.example.com.

  2. The user enters a username and password to log in. After successful login, the user is redirected back to example.com.

  3. The Relying Party script runs the code snippet below.

    1. The user agent checks if a user-verifying platform authenticator is available. If not, terminate this flow.

    2. The Relying Party asks the user if they want to create a credential with it. If not, terminate this flow.

    3. The user agent and/or operating system shows appropriate UI and guides the user in creating a credential using one of the available platform authenticators.

    4. Upon successful credential creation, the Relying Party script conveys the new credential to the server.

if (!window.PublicKeyCredential) { /* Client not capable of the API. Handle error. */ }

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()
    .then(function (uvpaAvailable) {
        // If there is a user-verifying platform authenticator
        if (uvpaAvailable) {
            // Render some RP-specific UI and get a Promise for a Boolean value
            return askIfUserWantsToCreateCredential();
        }
    }).then(function (userSaidYes) {
        // If there is a user-verifying platform authenticator
        // AND the user wants to create a credential
        if (userSaidYes) {
            var publicKeyOptions = { /* Public key credential creation options. */};
            return navigator.credentials.create({ "publicKey": publicKeyOptions });
        }
    }).then(function (newCredentialInfo) {
        if (newCredentialInfo) {
            // Send new credential info to server for verification and registration.
        }
    }).catch(function (err) {
        // Something went wrong. Handle appropriately.
    });

1.3.3. Authentication

This is the flow when a user with an already registered credential visits a website and wants to authenticate using the credential.

  1. The user visits example.com, which serves up a script.

  2. The script asks the client for an Authentication Assertion, providing as much information as possible to narrow the choice of acceptable credentials for the user. This can be obtained from the data that was stored locally after registration, or by other means such as prompting the user for a username.

  3. The Relying Party script runs one of the code snippets below.

  4. The client platform searches for and locates the authenticator.

  5. The client connects to the authenticator, performing any pairing actions if necessary.

  6. The authenticator presents the user with a notification that their attention is needed. On opening the notification, the user is shown a friendly selection menu of acceptable credentials using the account information provided when creating the credentials, along with some information on the origin that is requesting these keys.

  7. The authenticator obtains a biometric or other authorization gesture from the user.

  8. The authenticator returns a response to the client, which in turn returns a response to the Relying Party script. If the user declined to select a credential or provide an authorization, an appropriate error is returned.

  9. If an assertion was successfully generated and returned,

    • The script sends the assertion to the server.

    • The server examines the assertion, extracts the credential ID, looks up the registered credential public key in its database, and verifies the assertion signature. If valid, it looks up the identity associated with the assertion’s credential ID; that identity is now authenticated. If the credential ID is not recognized by the server (e.g., it has been deregistered due to inactivity) then the authentication has failed; each Relying Party will handle this in its own way.

    • The server now does whatever it would otherwise do upon successful authentication -- return a success page, set authentication cookies, etc.

If the Relying Party script does not have any hints available (e.g., from locally stored data) to help it narrow the list of credentials, then the sample code for performing such an authentication might look like this:

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

// credentialId is generated by the authenticator and is an opaque random byte array
var credentialId = new Uint8Array([183, 148, 245 /* more random bytes previously generated by the authenticator */]);
var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([4,101,15 /* 29 more random bytes generated by the server */]),
  timeout: 300000,  // 5 minutes
  allowCredentials: [{ type: "public-key", id: credentialId }]
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // Send assertion to server for verification
}).catch(function (err) {
    // No acceptable credential or user refused consent. Handle appropriately.
});

On the other hand, if the Relying Party script has some hints to help it narrow the list of credentials, then the sample code for performing such an authentication might look like the following. Note that this sample also demonstrates how to use the Credential Properties Extension.

if (!window.PublicKeyCredential) { /* Client not capable. Handle error. */ }

var encoder = new TextEncoder();
var acceptableCredential1 = {
    type: "public-key",
    id: encoder.encode("BA44712732CE")
};
var acceptableCredential2 = {
    type: "public-key",
    id: encoder.encode("BG35122345NF")
};

var options = {
  // The challenge is produced by the server; see the Security Considerations
  challenge: new Uint8Array([8,18,33 /* 29 more random bytes generated by the server */]),
  timeout: 300000,  // 5 minutes
  allowCredentials: [acceptableCredential1, acceptableCredential2],
  extensions: { 'credProps': true }
};

navigator.credentials.get({ "publicKey": options })
    .then(function (assertion) {
    // Send assertion to server for verification
}).catch(function (err) {
    // No acceptable credential or user refused consent. Handle appropriately.
});

1.3.4. Aborting Authentication Operations

The below example shows how a developer may use the AbortSignal parameter to abort a credential registration operation. A similar procedure applies to an authentication operation.

const authAbortController = new AbortController();
const authAbortSignal = authAbortController.signal;

authAbortSignal.onabort = function () {
    // Once the page knows the abort started, inform user it is attempting to abort.
}

var options = {
    // A list of options.
}

navigator.credentials.create({
    publicKey: options,
    signal: authAbortSignal})
    .then(function (attestation) {
        // Register the user.
    }).catch(function (error) {
        if (error.name === "AbortError") {
            // Inform user the credential hasn't been created.
            // Let the server know a key hasn't been created.
        }
    });

// Assume widget shows up whenever authentication occurs.
if (widget == "disappear") {
    authAbortController.abort();
}

1.3.5. Decommissioning

The following are possible situations in which decommissioning a credential might be desired. Note that all of these are handled on the server side and do not need support from the API specified here.

1.4. Platform-Specific Implementation Guidance

This specification defines how to use Web Authentication in the general case. When using Web Authentication in connection with specific platform support (e.g. apps), it is recommended to see platform-specific documentation and guides for additional guidance and limitations.

2. Conformance

This specification defines three conformance classes. Each of these classes is specified so that conforming members of the class are secure against non-conforming or hostile members of the other classes.

2.1. User Agents

A User Agent MUST behave as described by § 5 Web Authentication API in order to be considered conformant. Conforming User Agents MAY implement algorithms given in this specification in any way desired, so long as the end result is indistinguishable from the result that would be obtained by the specification’s algorithms.

A conforming User Agent MUST also be a conforming implementation of the IDL fragments of this specification, as described in the “Web IDL” specification. [WebIDL]

2.1.1. Enumerations as DOMString types

Enumeration types are not referenced by other parts of the Web IDL because that would preclude other values from being used without updating this specification and its implementations. It is important for backwards compatibility that client platforms and Relying Parties handle unknown values. Enumerations for this specification exist here for documentation and as a registry. Where the enumerations are represented elsewhere, they are typed as DOMStrings, for example in transports.

2.2. Authenticators

A WebAuthn Authenticator MUST provide the operations defined by § 6 WebAuthn Authenticator Model, and those operations MUST behave as described there. This is a set of functional and security requirements for an authenticator to be usable by a Conforming User Agent.

As described in § 1.2 Use Cases, an authenticator may be implemented in the operating system underlying the User Agent, or in external hardware, or a combination of both.

2.2.1. Backwards Compatibility with FIDO U2F

Authenticators that only support the § 8.6 FIDO U2F Attestation Statement Format have no mechanism to store a user handle, so the returned userHandle will always be null.

2.3. WebAuthn Relying Parties

A WebAuthn Relying Party MUST behave as described in § 7 WebAuthn Relying Party Operations to obtain all the security benefits offered by this specification. See § 13.4.1 Security Benefits for WebAuthn Relying Parties for further discussion of this.

2.4. All Conformance Classes

All CBOR encoding performed by the members of the above conformance classes MUST be done using the CTAP2 canonical CBOR encoding form. All decoders of the above conformance classes SHOULD reject CBOR that is not validly encoded in the CTAP2 canonical CBOR encoding form and SHOULD reject messages with duplicate map keys.

3. Dependencies

This specification relies on several other underlying specifications, listed below and in Terms defined by reference.

Base64url encoding

The term Base64url Encoding refers to the base64 encoding using the URL- and filename-safe character set defined in Section 5 of [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2) and without the inclusion of any line breaks, whitespace, or other additional characters.

CBOR

A number of structures in this specification, including attestation statements and extensions, are encoded using the CTAP2 canonical CBOR encoding form of the Compact Binary Object Representation (CBOR) [RFC8949], as defined in [FIDO-CTAP].

CDDL

This specification describes the syntax of all CBOR-encoded data using the CBOR Data Definition Language (CDDL) [RFC8610].

COSE

CBOR Object Signing and Encryption (COSE) [RFC9052] [RFC9053]. The IANA COSE Algorithms registry [IANA-COSE-ALGS-REG] originally established by [RFC8152] and updated by these specifications is also used.

Credential Management

The API described in this document is an extension of the Credential concept defined in [CREDENTIAL-MANAGEMENT-1].

DOM

DOMException and the DOMException values used in this specification are defined in [DOM4].

ECMAScript

%ArrayBuffer% is defined in [ECMAScript].

URL

The concepts of domain, host, port, scheme, valid domain and valid domain string are defined in [URL].

Web IDL

Many of the interface definitions and all of the IDL in this specification depend on [WebIDL]. This updated version of the Web IDL standard adds support for Promises, which are now the preferred mechanism for asynchronous interaction in all new web APIs.

FIDO AppID

The algorithms for determining the FacetID of a calling application and determining if a caller’s FacetID is authorized for an AppID (used only in the AppID extension) are defined by [FIDO-APPID].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

4. Terminology

Attestation

Generally, attestation is a statement that serves to bear witness, confirm, or authenticate. In the WebAuthn context, attestation is employed to provide verifiable evidence as to the origin of an authenticator and the data it emits. This includes such things as credential IDs, credential key pairs, signature counters, etc.

An attestation statement is provided within an attestation object during a registration ceremony. See also § 6.5 Attestation and Figure 6. Whether or how the client conveys the attestation statement and aaguid portions of the attestation object to the Relying Party is described by attestation conveyance.

Attestation Certificate

An X.509 Certificate for the attestation key pair used by an authenticator to attest to its manufacture and capabilities. At registration time, the authenticator uses the attestation private key to sign the Relying Party-specific credential public key (and additional data) that it generates and returns via the authenticatorMakeCredential operation. Relying Parties use the attestation public key conveyed in the attestation certificate to verify the attestation signature. Note that in the case of self attestation, the authenticator has no distinct attestation key pair nor attestation certificate, see self attestation for details.

Authentication
Authentication Ceremony

The ceremony where a user, and the user’s client platform (containing or connected to at least one authenticator) work in concert to cryptographically prove to a Relying Party that the user controls the credential private key of a previously-registered public key credential (see Registration). Note that this includes a test of user presence or user verification.

The WebAuthn authentication ceremony is defined in § 7.2 Verifying an Authentication Assertion, and is initiated by the Relying Party invoking a navigator.credentials.get() operation with a publicKey argument. See § 5 Web Authentication API for an introductory overview and § 1.3.3 Authentication for implementation examples.

Authentication Assertion
Assertion

The cryptographically signed AuthenticatorAssertionResponse object returned by an authenticator as the result of an authenticatorGetAssertion operation.

This corresponds to the [CREDENTIAL-MANAGEMENT-1] specification’s single-use credentials.

Authenticator
WebAuthn Authenticator

A cryptographic entity, existing in hardware or software, that can register a user with a given Relying Party and later assert possession of the registered public key credential, and optionally verify the user to the Relying Party. Authenticators can report information regarding their type and security characteristics via attestation during registration and assertion.

A WebAuthn Authenticator could be a roaming authenticator, a dedicated hardware subsystem integrated into the client device, or a software component of the client or client device. A WebAuthn Authenticator is not necessarily confined to operating in a local context, and can generate or store a credential key pair in a server outside of client-side hardware.

In general, an authenticator is assumed to have only one user. If multiple natural persons share access to an authenticator, they are considered to represent the same user in the context of that authenticator. If an authenticator implementation supports multiple users in separated compartments, then each compartment is considered a separate authenticator with a single user with no access to other users' credentials.

Authorization Gesture

An authorization gesture is a physical interaction performed by a user with an authenticator as part of a ceremony, such as registration or authentication. By making such an authorization gesture, a user provides consent for (i.e., authorizes) a ceremony to proceed. This MAY involve user verification if the employed authenticator is capable, or it MAY involve a simple test of user presence.

Backed Up

Public Key Credential Sources may be backed up in some fashion such that they may become present on an authenticator other than their generating authenticator. Backup can occur via mechanisms including but not limited to peer-to-peer sync, cloud sync, local network sync, and manual import/export. See also § 6.1.3 Credential Backup State.

Backup Eligibility
Backup Eligible

A Public Key Credential Source’s generating authenticator determines at creation time whether the public key credential source is allowed to be backed up. Backup eligibility is signaled in authenticator data’s flags along with the current backup state. Backup eligibility is a credential property and is permanent for a given public key credential source. A backup eligible public key credential source is referred to as a multi-device credential whereas one that is not backup eligible is referred to as a single-device credential. See also § 6.1.3 Credential Backup State.

Backup State

The current backup state of a multi-device credential as determined by the current managing authenticator. Backup state is signaled in authenticator data’s flags and can change over time. See also backup eligibility and § 6.1.3 Credential Backup State.

Biometric Authenticator

Any authenticator that implements biometric recognition.

Biometric Recognition

The automated recognition of individuals based on their biological and behavioral characteristics [ISOBiometricVocabulary].

Bound credential
"Authenticator contains a credential"
"Credential created on an authenticator"

A public key credential source or public key credential is said to be bound to its managing authenticator. This means that only the managing authenticator can generate assertions for the public key credential sources bound to it.

This may also be expressed as "the managing authenticator contains the bound credential", or "the bound credential was created on its managing authenticator". Note, however, that a server-side credential might not be physically stored in persistent memory inside the authenticator, hence "bound to" is the primary term. See § 6.2.2 Credential Storage Modality.

Ceremony

The concept of a ceremony [Ceremony] is an extension of the concept of a network protocol, with human nodes alongside computer nodes and with communication links that include user interface(s), human-to-human communication, and transfers of physical objects that carry data. What is out-of-band to a protocol is in-band to a ceremony. In this specification, Registration and Authentication are ceremonies, and an authorization gesture is often a component of those ceremonies.

Client
WebAuthn Client

Also referred to herein as simply a client. See also Conforming User Agent. A WebAuthn Client is an intermediary entity typically implemented in the user agent (in whole, or in part). Conceptually, it underlies the Web Authentication API and embodies the implementation of the [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal methods. It is responsible for both marshalling the inputs for the underlying authenticator operations, and for returning the results of the latter operations to the Web Authentication API’s callers.

The WebAuthn Client runs on, and is distinct from, a WebAuthn Client Device.

Client Device
WebAuthn Client Device

The hardware device on which the WebAuthn Client runs, for example a smartphone, a laptop computer or a desktop computer, and the operating system running on that hardware.

The distinctions between a WebAuthn Client device and a client are:

A client device and a client together constitute a client platform.

Client Platform

A client device and a client together make up a client platform. A single hardware device MAY be part of multiple distinct client platforms at different times by running different operating systems and/or clients.

Client-Side

This refers in general to the combination of the user’s client platform, authenticators, and everything gluing it all together.

Client-side discoverable Public Key Credential Source
Client-side discoverable Credential
Discoverable Credential
Passkey
[DEPRECATED] Resident Credential
[DEPRECATED] Resident Key

Note: Historically, client-side discoverable credentials have been known as resident credentials or resident keys. Due to the phrases ResidentKey and residentKey being widely used in both the WebAuthn API and also in the Authenticator Model (e.g., in dictionary member names, algorithm variable names, and operation parameters) the usage of resident within their names has not been changed for backwards compatibility purposes. Also, the term resident key is defined here as equivalent to a client-side discoverable credential.

A Client-side discoverable Public Key Credential Source, or Discoverable Credential for short, is a public key credential source that is discoverable and usable in authentication ceremonies where the Relying Party does not provide any credential IDs, i.e., the Relying Party invokes navigator.credentials.get() with an empty allowCredentials argument. This means that the Relying Party does not necessarily need to first identify the user.

As a consequence, a discoverable credential capable authenticator can generate an assertion signature for a discoverable credential given only an RP ID, which in turn necessitates that the public key credential source is stored in the authenticator or client platform. This is in contrast to a Server-side Public Key Credential Source, which requires that the authenticator is given both the RP ID and the credential ID but does not require client-side storage of the public key credential source.

See also: client-side credential storage modality and non-discoverable credential.

Note: Client-side discoverable credentials are also usable in authentication ceremonies where credential IDs are given, i.e., when calling navigator.credentials.get() with a non-empty allowCredentials argument.

Conforming User Agent

A user agent implementing, in cooperation with the underlying client device, the Web Authentication API and algorithms given in this specification, and handling communication between authenticators and Relying Parties.

Credential ID

A probabilistically-unique byte sequence identifying a public key credential source and its authentication assertions. At most 1023 bytes long.

Credential IDs are generated by authenticators in two forms:

  1. At least 16 bytes that include at least 100 bits of entropy, or

  2. The public key credential source, without its Credential ID or mutable items, encrypted so only its managing authenticator can decrypt it. This form allows the authenticator to be nearly stateless, by having the Relying Party store any necessary state.

    Note: [FIDO-UAF-AUTHNR-CMDS] includes guidance on encryption techniques under "Security Guidelines".

Relying Parties do not need to distinguish these two Credential ID forms.

Credential Key Pair
Credential Private Key
Credential Public Key
User Public Key

A credential key pair is a pair of asymmetric cryptographic keys generated by an authenticator and scoped to a specific WebAuthn Relying Party. It is the central part of a public key credential.

A credential public key is the public key portion of a credential key pair. The credential public key is returned to the Relying Party during a registration ceremony.

A credential private key is the private key portion of a credential key pair. The credential private key is bound to a particular authenticator - its managing authenticator - and is expected to never be exposed to any other party, not even to the owner of the authenticator.

Note that in the case of self attestation, the credential key pair is also used as the attestation key pair, see self attestation for details.

Note: The credential public key is referred to as the user public key in FIDO UAF [UAFProtocol], and in FIDO U2F [FIDO-U2F-Message-Formats] and some parts of this specification that relate to it.

Credential Properties

A credential property is some characteristic property of a public key credential source, such as whether it is a client-side discoverable credential or a server-side credential.

Credential Record

In order to implement the algorithms defined in § 7 WebAuthn Relying Party Operations, the Relying Party MUST store some properties of registered public key credential sources. The credential record struct is an abstraction of these properties stored in a user account. A credential record is created during a registration ceremony and used in subsequent authentication ceremonies. Relying Parties MAY delete credential records as necessary or when requested by users.

The following items are RECOMMENDED in order to implement all steps of § 7.1 Registering a New Credential and § 7.2 Verifying an Authentication Assertion as defined:

type

The type of the public key credential source.

id

The Credential ID of the public key credential source.

publicKey

The credential public key of the public key credential source.

signCount

The latest value of the signature counter in the authenticator data from any ceremony using the public key credential source.

transports

The value returned from getTransports() when the public key credential source was registered.

Note: Modifying or removing items from the value returned from getTransports() could negatively impact user experience, or even prevent use of the corresponding credential.

uvInitialized

A Boolean value indicating whether any credential from this public key credential source has had the UV flag set.

When this is true, the Relying Party MAY consider the UV flag as an authentication factor in authentication ceremonies. For example, a Relying Party might skip a password prompt if uvInitialized is true and the UV flag is set, even when user verification was not required.

When this is false, including an authentication ceremony where it would be updated to true, the UV flag MUST NOT be relied upon as an authentication factor. This is because the first time a public key credential source sets the UV flag to 1, there is not yet any trust relationship established between the Relying Party and the authenticator’s user verification. Therefore, updating uvInitialized from false to true SHOULD require authorization by an additional authentication factor equivalent to WebAuthn user verification.

backupEligible

The value of the BE flag when the public key credential source was created.

backupState

The latest value of the BS flag in the authenticator data from any ceremony using the public key credential source.

The following items are OPTIONAL:

attestationObject

The value of the attestationObject attribute when the public key credential source was registered. Storing this enables the Relying Party to reference the credential’s attestation statement at a later time.

attestationClientDataJSON

The value of the clientDataJSON attribute when the public key credential source was registered. Storing this in combination with the above attestationObject item enables the Relying Party to re-verify the attestation signature at a later time.

WebAuthn extensions MAY define additional items needed to process the extension. Relying Parties MAY also include any additional items as needed, and MAY omit any items not needed for their implementation.

The credential descriptor for a credential record is a PublicKeyCredentialDescriptor value with the contents:

type

The type of the credential record.

id

The id of the credential record.

transports

The transports of the credential record.

Generating Authenticator

The Generating Authenticator is the authenticator involved in the authenticatorMakeCredential operation resulting in the creation of a given public key credential source. The generating authenticator is the same as the managing authenticator for single-device credentials. For multi-device credentials, the generating authenticator may or may not be the same as the current managing authenticator participating in a given authentication operation.

Human Palatability

An identifier that is human-palatable is intended to be rememberable and reproducible by typical human users, in contrast to identifiers that are, for example, randomly generated sequences of bits [EduPersonObjectClassSpec].

Non-Discoverable Credential

This is a credential whose credential ID must be provided in allowCredentials when calling navigator.credentials.get() because it is not client-side discoverable. See also server-side credentials.

Registrable Origin Label

The first domain label of the registrable domain of a domain, or null if the registrable domain is null. For example, the registrable origin label of both example.co.uk and www.example.de is example if both co.uk and de are public suffixes.

Public Key Credential

Generically, a credential is data one entity presents to another in order to authenticate the former to the latter [RFC4949]. The term public key credential refers to one of: a public key credential source, the possibly-attested credential public key corresponding to a public key credential source, or an authentication assertion. Which one is generally determined by context.

Note: This is a willful violation of [RFC4949]. In English, a "credential" is both a) the thing presented to prove a statement and b) intended to be used multiple times. It’s impossible to achieve both criteria securely with a single piece of data in a public key system. [RFC4949] chooses to define a credential as the thing that can be used multiple times (the public key), while this specification gives "credential" the English term’s flexibility. This specification uses more specific terms to identify the data related to an [RFC4949] credential:
"Authentication information" (possibly including a private key)

Public key credential source

"Signed value"

Authentication assertion

[RFC4949] "credential"

Credential public key or attestation object

At registration time, the authenticator creates an asymmetric key pair, and stores its private key portion and information from the Relying Party into a public key credential source. The public key portion is returned to the Relying Party, which then stores it in the active user account. Subsequently, only that Relying Party, as identified by its RP ID, is able to employ the public key credential in authentication ceremonies, via the get() method. The Relying Party uses its stored copy of the credential public key to verify the resultant authentication assertion.

Public Key Credential Source

A credential source ([CREDENTIAL-MANAGEMENT-1]) used by an authenticator to generate authentication assertions. A public key credential source consists of a struct with the following items:

type

whose value is of PublicKeyCredentialType, defaulting to public-key.

id

A Credential ID.

privateKey

The credential private key.

rpId

The Relying Party Identifier, for the Relying Party this public key credential source is scoped to. This is determined by the rp.id parameter of the create() operation.

userHandle

The user handle associated when this public key credential source was created. This item is nullable, however user handle MUST always be populated for discoverable credentials.

otherUI

OPTIONAL other information used by the authenticator to inform its UI. For example, this might include the user’s displayName. otherUI is a mutable item and SHOULD NOT be bound to the public key credential source in a way that prevents otherUI from being updated.

The authenticatorMakeCredential operation creates a public key credential source bound to a managing authenticator and returns the credential public key associated with its credential private key. The Relying Party can use this credential public key to verify the authentication assertions created by this public key credential source.

Rate Limiting

The process (also known as throttling) by which an authenticator implements controls against brute force attacks by limiting the number of consecutive failed authentication attempts within a given period of time. If the limit is reached, the authenticator should impose a delay that increases exponentially with each successive attempt, or disable the current authentication modality and offer a different authentication factor if available. Rate limiting is often implemented as an aspect of user verification.

Registration
Registration Ceremony

The ceremony where a user, a Relying Party, and the user’s client platform (containing or connected to at least one authenticator) work in concert to create a public key credential and associate it with a user account. Note that this includes employing a test of user presence or user verification. After a successful registration ceremony, the user can be authenticated by an authentication ceremony.

The WebAuthn registration ceremony is defined in § 7.1 Registering a New Credential, and is initiated by the Relying Party invoking a navigator.credentials.create() operation with a publicKey argument. See § 5 Web Authentication API for an introductory overview and § 1.3.1 Registration for implementation examples.

Relying Party
WebAuthn Relying Party

The entity whose web application utilizes the Web Authentication API to register and authenticate users.

A Relying Party implementation typically consists of both some client-side script that invokes the Web Authentication API in the client, and a server-side component that executes the Relying Party operations and other application logic. Communication between the two components MUST use HTTPS or equivalent transport security, but is otherwise beyond the scope of this specification.

Note: While the term Relying Party is also often used in other contexts (e.g., X.509 and OAuth), an entity acting as a Relying Party in one context is not necessarily a Relying Party in other contexts. In this specification, the term WebAuthn Relying Party is often shortened to be just Relying Party, and explicitly refers to a Relying Party in the WebAuthn context. Note that in any concrete instantiation a WebAuthn context may be embedded in a broader overall context, e.g., one based on OAuth.

Relying Party Identifier
RP ID

In the context of the WebAuthn API, a relying party identifier is a valid domain string identifying the WebAuthn Relying Party on whose behalf a given registration or authentication ceremony is being performed. A public key credential can only be used for authentication with the same entity (as identified by RP ID) it was registered with.

By default, the RP ID for a WebAuthn operation is set to the caller’s origin’s effective domain. This default MAY be overridden by the caller, as long as the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin’s effective domain. See also § 5.1.3 Create a New Credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) Internal Method and § 5.1.4 Use an Existing Credential to Make an Assertion.

An RP ID is based on a host’s domain name. It does not itself include a scheme or port, as an origin does. The RP ID of a public key credential determines its scope. I.e., it determines the set of origins on which the public key credential may be exercised, as follows:

For example, given a Relying Party whose origin is https://login.example.com:1337, then the following RP IDs are valid: login.example.com (default) and example.com, but not m.login.example.com and not com. Another example of a valid origin is http://localhost:8000, due to the origin being localhost.

This is done in order to match the behavior of pervasively deployed ambient credentials (e.g., cookies, [RFC6265]). Please note that this is a greater relaxation of "same-origin" restrictions than what document.domain’s setter provides.

These restrictions on origin values apply to WebAuthn Clients.

Other specifications mimicking the WebAuthn API to enable WebAuthn public key credentials on non-Web platforms (e.g. native mobile applications), MAY define different rules for binding a caller to a Relying Party Identifier. Though, the RP ID syntaxes MUST conform to either valid domain strings or URIs [RFC3986] [URL].

Server-side Public Key Credential Source
Server-side Credential
[DEPRECATED] Non-Resident Credential

Note: Historically, server-side credentials have been known as non-resident credentials. For backwards compatibility purposes, the various WebAuthn API and Authenticator Model components with various forms of resident within their names have not been changed.

A Server-side Public Key Credential Source, or Server-side Credential for short, is a public key credential source that is only usable in an authentication ceremony when the Relying Party supplies its credential ID in navigator.credentials.get()’s allowCredentials argument. This means that the Relying Party must manage the credential’s storage and discovery, as well as be able to first identify the user in order to discover the credential IDs to supply in the navigator.credentials.get() call.

Client-side storage of the public key credential source is not required for a server-side credential. This is in contrast to a client-side discoverable credential, which instead does not require the user to first be identified in order to provide the user’s credential IDs to a navigator.credentials.get() call.

See also: server-side credential storage modality and non-discoverable credential.

Test of User Presence

A test of user presence is a simple form of authorization gesture and technical process where a user interacts with an authenticator by (typically) simply touching it (other modalities may also exist), yielding a Boolean result. Note that this does not constitute user verification because a user presence test, by definition, is not capable of biometric recognition, nor does it involve the presentation of a shared secret such as a password or PIN.

User Account

In the context of this specification, a user account denotes the mapping of a set of credentials [CREDENTIAL-MANAGEMENT-1] to a (sub)set of a Relying Party’s resources, as maintained and authorized by the Relying Party. The Relying Party maps a given public key credential to a user account by assigning a user account-specific value to the credential’s user handle and storing a credential record for the credential in the user account. This mapping, the set of credentials, and their authorizations, may evolve over time. A given user account might be accessed by one or more natural persons (also known as "users"), and one natural person might have access to one or more user accounts, depending on actions of the user(s) and the Relying Party.

User Consent

User consent means the user agrees with what they are being asked, i.e., it encompasses reading and understanding prompts. An authorization gesture is a ceremony component often employed to indicate user consent.

User Handle

A user handle is an identifier for a user account, specified by the Relying Party as user.id during registration. Discoverable credentials store this identifier and MUST return it as response.userHandle in authentication ceremonies started with an empty allowCredentials argument.

The main use of the user handle is to identify the user account in such authentication ceremonies, but the credential ID could be used instead. The main differences are that the credential ID is chosen by the authenticator and is unique for each credential, while the user handle is chosen by the Relying Party and ought to be the same for all credentials registered to the same user account.

Authenticators map pairs of RP ID and user handle to public key credential sources. As a consequence, an authenticator will store at most one discoverable credential per user handle per Relying Party. Therefore a secondary use of the user handle is to allow authenticators to know when to replace an existing discoverable credential with a new one during the registration ceremony.

A user handle is an opaque byte sequence with a maximum size of 64 bytes, and is not meant to be displayed to the user. It MUST NOT contain personally identifying information, see § 14.6.1 User Handle Contents.

User Present

Upon successful completion of a user presence test, the user is said to be "present".

User Verification

The technical process by which an authenticator locally authorizes the invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations. User verification MAY be instigated through various authorization gesture modalities; for example, through a touch plus pin code, password entry, or biometric recognition (e.g., presenting a fingerprint) [ISOBiometricVocabulary]. The intent is to distinguish individual users. See also § 6.2.3 Authentication Factor Capability.

Note that user verification does not give the Relying Party a concrete identification of the user, but when 2 or more ceremonies with user verification have been done with that credential it expresses that it was the same user that performed all of them. The same user might not always be the same natural person, however, if multiple natural persons share access to the same authenticator.

Note: Distinguishing natural persons depends in significant part upon the client platform’s and authenticator’s capabilities. For example, some devices are intended to be used by a single individual, yet they may allow multiple natural persons to enroll fingerprints or know the same PIN and thus access the same user account(s) using that device.

NOTE: Invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations implies use of key material managed by the authenticator.

For security, user verification and use of credential private keys MUST all occur within the logical security boundary defining the authenticator.

User verification procedures MAY implement rate limiting as a protection against brute force attacks.

User Verified

Upon successful completion of a user verification process, the user is said to be "verified".

5. Web Authentication API

This section normatively specifies the API for creating and using public key credentials. The basic idea is that the credentials belong to the user and are managed by a WebAuthn Authenticator, with which the WebAuthn Relying Party interacts through the client platform. Relying Party scripts can (with the user’s consent) request the browser to create a new credential for future use by the Relying Party. See Figure , below.

Registration Flow

Scripts can also request the user’s permission to perform authentication operations with an existing credential. See Figure , below.

Authentication Flow

All such operations are performed in the authenticator and are mediated by the client platform on the user’s behalf. At no point does the script get access to the credentials themselves; it only gets information about the credentials in the form of objects.

In addition to the above script interface, the authenticator MAY implement (or come with client software that implements) a user interface for management. Such an interface MAY be used, for example, to reset the authenticator to a clean state or to inspect the current state of the authenticator. In other words, such an interface is similar to the user interfaces provided by browsers for managing user state such as history, saved passwords, and cookies. Authenticator management actions such as credential deletion are considered to be the responsibility of such a user interface and are deliberately omitted from the API exposed to scripts.

The security properties of this API are provided by the client and the authenticator working together. The authenticator, which holds and manages credentials, ensures that all operations are scoped to a particular origin, and cannot be replayed against a different origin, by incorporating the origin in its responses. Specifically, as defined in § 6.3 Authenticator Operations, the full origin of the requester is included, and signed over, in the attestation object produced when a new credential is created as well as in all assertions produced by WebAuthn credentials.

Additionally, to maintain user privacy and prevent malicious Relying Parties from probing for the presence of public key credentials belonging to other Relying Parties, each credential is also scoped to a Relying Party Identifier, or RP ID. This RP ID is provided by the client to the authenticator for all operations, and the authenticator ensures that credentials created by a Relying Party can only be used in operations requested by the same RP ID. Separating the origin from the RP ID in this way allows the API to be used in cases where a single Relying Party maintains multiple origins.

The client facilitates these security measures by providing the Relying Party’s origin and RP ID to the authenticator for each operation. Since this is an integral part of the WebAuthn security model, user agents only expose this API to callers in secure contexts. For web contexts in particular, this only includes those accessed via a secure transport (e.g., TLS) established without errors.

The Web Authentication API is defined by the union of the Web IDL fragments presented in the following sections. A combined IDL listing is given in the IDL Index.

5.1. PublicKeyCredential Interface

The PublicKeyCredential interface inherits from Credential [CREDENTIAL-MANAGEMENT-1], and contains the attributes that are returned to the caller when a new credential is created, or a new assertion is requested.

[SecureContext, Exposed=Window]
interface PublicKeyCredential : Credential {
    [SameObject] readonly attribute ArrayBuffer              rawId;
    [SameObject] readonly attribute AuthenticatorResponse    response;
    readonly attribute DOMString?                            authenticatorAttachment;
    AuthenticationExtensionsClientOutputs getClientExtensionResults();
    static Promise<boolean> isConditionalMediationAvailable();
    PublicKeyCredentialJSON toJSON();
};
id

This attribute is inherited from Credential, though PublicKeyCredential overrides Credential’s getter, instead returning the base64url encoding of the data contained in the object’s [[identifier]] internal slot.

rawId

This attribute returns the ArrayBuffer contained in the [[identifier]] internal slot.

response, of type AuthenticatorResponse, readonly

This attribute contains the authenticator’s response to the client’s request to either create a public key credential, or generate an authentication assertion. If the PublicKeyCredential is created in response to create(), this attribute’s value will be an AuthenticatorAttestationResponse, otherwise, the PublicKeyCredential was created in response to get(), and this attribute’s value will be an AuthenticatorAssertionResponse.

authenticatorAttachment, of type DOMString, readonly, nullable

This attribute reports the authenticator attachment modality in effect at the time the navigator.credentials.create() or navigator.credentials.get() methods successfully complete. The attribute’s value SHOULD be a member of AuthenticatorAttachment. Relying Parties SHOULD treat unknown values as if the value were null.

Note: If, as the result of a registration or authentication ceremony, authenticatorAttachment’s value is "cross-platform" and concurrently isUserVerifyingPlatformAuthenticatorAvailable returns true, then the user employed a roaming authenticator for this ceremony while there is an available platform authenticator. Thus the Relying Party has the opportunity to prompt the user to register the available platform authenticator, which may enable more streamlined user experience flows.

An authenticator’s attachment modality could change over time. For example, a mobile phone might at one time only support platform attachment but later receive updates to support cross-platform attachment as well.

getClientExtensionResults()

This operation returns the value of [[clientExtensionsResults]], which is a map containing extension identifier → client extension output entries produced by the extension’s client extension processing.

isConditionalMediationAvailable()

PublicKeyCredential overrides this method to indicate availability for conditional mediation during navigator.credentials.get(). WebAuthn Relying Parties SHOULD verify availability before attempting to set options.mediation to conditional.

Upon invocation, a promise is returned that resolves with a value of true if conditional user mediation is available, or false otherwise.

This method has no arguments and returns a promise to a Boolean value.

The conditionalGet capability is equivalent to this promise resolving to true.

Note: If this method is not present, conditional user mediation is not available for navigator.credentials.get().

Note: This method does not indicate whether or not conditional user mediation is available in navigator.credentials.create(). For that, see the conditionalCreate capability in getClientCapabilities().

toJSON()

This operation returns RegistrationResponseJSON or AuthenticationResponseJSON, which are JSON type representations mirroring PublicKeyCredential, suitable for submission to a Relying Party server as an application/json payload. The client is in charge of serializing values to JSON types as usual, but MUST take additional steps to first encode any ArrayBuffer values to DOMString values using base64url encoding.

The RegistrationResponseJSON.clientExtensionResults or AuthenticationResponseJSON.clientExtensionResults member MUST be set to the output of getClientExtensionResults(), with any ArrayBuffer values encoded to DOMString values using base64url encoding. This MAY include ArrayBuffer values from extensions registered in the IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] but not defined in § 9 WebAuthn Extensions.

The AuthenticatorAttestationResponseJSON.transports member MUST be set to the output of getTransports().

The AuthenticatorAttestationResponseJSON.publicKey member MUST be set to the output of getPublicKey().

The AuthenticatorAttestationResponseJSON.publicKeyAlgorithm member MUST be set to the output of getPublicKeyAlgorithm().

typedef DOMString Base64URLString;
// The structure of this object will be either
// RegistrationResponseJSON or AuthenticationResponseJSON
typedef object PublicKeyCredentialJSON;

dictionary RegistrationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAttestationResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAttestationResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required sequence<DOMString> transports;
    // The publicKey field will be missing if pubKeyCredParams was used to
    // negotiate a public-key algorithm that the user agent doesn't
    // understand. (See section “Easily accessing credential data” for a
    // list of which algorithms user agents must support.) If using such an
    // algorithm then the public key must be parsed directly from
    // attestationObject or authenticatorData.
    Base64URLString publicKey;
    required COSEAlgorithmIdentifier publicKeyAlgorithm;
    // This value contains copies of some of the fields above. See
    // section “Easily accessing credential data”.
    required Base64URLString attestationObject;
};

dictionary AuthenticationResponseJSON {
    required DOMString id;
    required Base64URLString rawId;
    required AuthenticatorAssertionResponseJSON response;
    DOMString authenticatorAttachment;
    required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
    required DOMString type;
};

dictionary AuthenticatorAssertionResponseJSON {
    required Base64URLString clientDataJSON;
    required Base64URLString authenticatorData;
    required Base64URLString signature;
    Base64URLString userHandle;
};

dictionary AuthenticationExtensionsClientOutputsJSON {
};
[[type]]

The PublicKeyCredential interface object’s [[type]] internal slot’s value is the string "public-key".

Note: This is reflected via the type attribute getter inherited from Credential.

[[discovery]]

The PublicKeyCredential interface object’s [[discovery]] internal slot’s value is "remote".

[[identifier]]

This internal slot contains the credential ID, chosen by the authenticator. The credential ID is used to look up credentials for use, and is therefore expected to be globally unique with high probability across all credentials of the same type, across all authenticators.

This API does not constrain the format of this identifier, except that it MUST NOT be longer than 1023 bytes and MUST be sufficient for the authenticator to uniquely select a key. For example, an authenticator without on-board storage may create identifiers containing a credential private key wrapped with a symmetric key that is burned into the authenticator.

[[clientExtensionsResults]]

This internal slot contains the results of processing client extensions requested by the Relying Party upon the Relying Party’s invocation of either navigator.credentials.create() or navigator.credentials.get().

PublicKeyCredential’s interface object inherits Credential’s implementation of [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), and defines its own implementation of each of [[Create]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), and [[Store]](credential, sameOriginWithAncestors).

Calling CredentialsContainer’s preventSilentAccess() method will have no effect on PublicKeyCredential credentials, since they always require user interaction.

5.1.1. CredentialCreationOptions Dictionary Extension

To support registration via navigator.credentials.create(), this document extends the CredentialCreationOptions dictionary as follows:

partial dictionary CredentialCreationOptions {
    PublicKeyCredentialCreationOptions      publicKey;
};

5.1.2. CredentialRequestOptions Dictionary Extension

To support obtaining assertions via navigator.credentials.get(), this document extends the CredentialRequestOptions dictionary as follows:

partial dictionary CredentialRequestOptions {
    PublicKeyCredentialRequestOptions      publicKey;
};

5.1.3. Create a New Credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) Internal Method

PublicKeyCredential’s interface object’s implementation of the [[Create]](origin, options, sameOriginWithAncestors) internal method [CREDENTIAL-MANAGEMENT-1] allows WebAuthn Relying Party scripts to call navigator.credentials.create() to request the creation of a new public key credential source, bound to an authenticator.

By setting options.mediation to conditional, Relying Parties can indicate that they would like to register a credential without prominent modal UI if the user has already consented to create a credential. The Relying Party SHOULD first use getClientCapabilities() to check that the client supports the conditionalCreate capability in order to prevent a user-visible error in case this feature is not available. The client MUST set BOTH requireUserPresence and requireUserVerification to FALSE when options.mediation is set to conditional unless they may be explicitly performed during the ceremony.

Any navigator.credentials.create() operation can be aborted by leveraging the AbortController; see DOM § 3.3 Using AbortController and AbortSignal objects in APIs for detailed instructions.

This internal method accepts three arguments:

origin

This argument is the relevant settings object’s