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.
Relying Party web application developers, especially those responsible for Relying Partyweb application login flows, account recovery flows,
+user account database content, etc.
OS platform developers, responsible for OS platform API design and implementation in regards to platform-specific authenticator APIs, platform WebAuthn Client instantiation, etc.
The below use case scenarios illustrate use of two very different types of authenticators, as well as outline further
+scenarios. Additional scenarios, including sample code, are given later in § 1.3 Sample API Usage Scenarios.
+
1.2.1. Registration
+
+
+
On a phone:
+
+
+
User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using
+(possibly a legacy method such as a password), or creates a new account.
+
+
The phone prompts, "Do you want to register this device with example.com?"
+
+
User agrees.
+
+
The phone prompts the user for a previously configured authorization gesture (PIN, biometric, etc.); the user
+provides this.
+
+
Website shows message, "Registration complete."
+
+
+
1.2.2. Authentication
+
+
+
On a laptop or desktop:
+
+
+
User pairs their phone with the laptop or desktop via Bluetooth.
+
+
User navigates to example.com in a browser and initiates signing in.
+
+
User gets a message from the browser, "Please complete this action on your phone."
+
+
+
Next, on their phone:
+
+
+
User sees a discrete prompt or notification, "Sign in to example.com."
+
+
User selects this prompt / notification.
+
+
User is shown a list of their example.com identities, e.g., "Sign in as Mohamed / Sign in as 张三".
+
+
User picks an identity, is prompted for an authorization gesture (PIN, biometric, etc.) and provides this.
+
+
+
Now, back on the laptop:
+
+
+
Web page shows that the selected user is signed in, and navigates to the signed-in page.
+
+
+
1.2.3. New Device Registration
+
This use case scenario illustrates how a Relying Party can leverage a combination of a roaming authenticator (e.g., a USB security
+key fob) and a platform authenticator (e.g., a built-in fingerprint sensor) such that the user has:
User navigates to example.com in a browser and signs in to an existing account using whatever method they have been using
+(possibly a legacy method such as a password), or creates a new account.
+
+
User navigates to account security settings and selects "Register security key".
+
+
Website prompts the user to plug in a USB security key fob; the user does.
+
+
The USB security key blinks to indicate the user should press the button on it; the user does.
+
+
Website shows message, "Registration complete."
+
+
Note: Since this computer lacks a platform authenticator, the website may require the user to present their USB security
+key from time to time or each time the user interacts with the website. This is at the website’s discretion.
User navigates to example.com in a browser and initiates signing in.
+
+
Website prompts the user to plug in their USB security key.
+
+
User plugs in the previously registered USB security key and presses the button.
+
+
Website shows that the user is signed in, and navigates to the signed-in page.
+
+
Website prompts, "Do you want to register this computer with example.com?"
+
+
User agrees.
+
+
Laptop prompts the user for a previously configured authorization gesture (PIN, biometric, etc.); the user provides this.
+
+
Website shows message, "Registration complete."
+
+
User signs out.
+
+
+
Later, again on their laptop:
+
+
+
User navigates to example.com in a browser and initiates signing in.
+
+
Website shows message, "Please follow your computer’s prompts to complete sign in."
+
+
Laptop prompts the user for an authorization gesture (PIN, biometric, etc.); the user provides this.
+
+
Website shows that the user is signed in, and navigates to the signed-in page.
+
+
+
1.2.4. Other Use Cases and Configurations
+
A variety of additional use cases and configurations are also possible, including (but not limited to):
+
+
+
A user navigates to example.com on their laptop, is guided through a flow to create and register a credential on their phone.
+
+
A user obtains a discrete, roaming authenticator, such as a "fob" with USB or USB+NFC/BLE connectivity options, loads
+example.com in their browser on a laptop or phone, and is guided through a flow to create and register a credential on the
+fob.
+
+
A Relying Party prompts the user for their authorization gesture in order to authorize a single transaction, such as a payment
+or other financial transaction.
+
+
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 first-factor 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.
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.
+
+
The Relying Party script runs the code snippet below.
+
+
The client platform searches for and locates the authenticator.
+
+
The client connects to the authenticator, performing any pairing actions if necessary.
+
+
The authenticator shows appropriate UI for the user to provide a biometric or other authorization gesture.
+
+
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.
+
+
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:"alex.mueller@example.com",
+ displayName:"Alex Müller",
+ },
+
+ // This Relying Party will accept either an ES256 or RS256 credential, but
+ // prefers an ES256 credential.
+ pubKeyCredParams:[
+ {
+ 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:360000,// 6 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
The Relying Party asks the user if they want to create a credential with it. If not, terminate this flow.
+
+
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.
+
+
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.
+
+
+
The user visits example.com, which serves up a script.
+
+
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.
+
+
The Relying Party script runs one of the code snippets below.
+
+
The client platform searches for and locates the authenticator.
+
+
The client connects to the authenticator, performing any pairing actions if necessary.
+
+
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.
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.
+
+
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:120000,// 2 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:120000,// 2 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 =="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.
+
+
+
Possibility #1 -- user reports the credential as lost.
+
+
+
User goes to server.example.net, authenticates and follows a link to report a lost/stolen authenticator.
+
+
Server returns a page showing the list of registered credentials with friendly names as configured during registration.
+
+
User selects a credential and the server deletes it from its database.
+
+
In the future, the Relying Party script does not specify this credential in any list of acceptable credentials, and assertions
+signed by this credential are rejected.
+
+
+
Possibility #2 -- server deregisters the credential due to inactivity.
+
+
+
Server deletes credential from its database during maintenance activity.
+
+
In the future, the Relying Party script does not specify this credential in any list of acceptable credentials, and assertions
+signed by this credential are rejected.
+
+
+
Possibility #3 -- user deletes the credential from the authenticator.
+
+
+
User employs a authenticator-specific method (e.g., device settings UI) to delete a credential from their authenticator.
+
+
From this point on, this credential will not appear in any selection prompts, and no assertions can be generated with it.
+
+
Sometime later, the server deregisters this credential due to inactivity.
+
+
+
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.
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.
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) [RFC8152]. The IANA COSE Algorithms registry [IANA-COSE-ALGS-REG] established by this specification is also used.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+"OPTIONAL" in this document are to be interpreted as described in [RFC2119].
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.
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.
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.
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].
+ 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)
+
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.
+ Note: 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.
+
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.
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 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.
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 Relying Party account(s) using that device.
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.
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.
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.
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.
+
Note: This API does not constrain
+the format or length of this identifier, except that it 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.
Note: All BufferSource objects used in this algorithm must be snapshotted when the algorithm begins, to
+avoid potential synchronization issues. The algorithm implementations should get a copy of the bytes held
+by the buffer source and use that copy for relevant portions of the algorithm.
+
When this method is invoked, the user agent MUST execute the following algorithm:
Note: This "sameOriginWithAncestors" restriction aims to address a tracking concern raised in Issue #1336. This may be revised in future versions of this specification.
If the timeout member of options is present, check if its value lies within a
+reasonable range as defined by the client and if not, correct it to the closest value lying within that range. Set a timer lifetimeTimer to this adjusted value. If the timeout member of options is not
+present, then set lifetimeTimer to a client-specific default.
Note: An effective domain may resolve to a host, which can be represented in various manners,
+ such as domain, ipv4 address, ipv6 address, opaque host, or empty host.
+ Only the domain format of host is allowed here. This is for simplification and also
+ is in recognition of various issues with using direct IP address identification in concert
+ with PKI-based security.
Note:options.rp.id represents the
+ caller’s RP ID. The RP ID defaults to being the caller’s origin's effective domain unless the caller has explicitly set options.rp.id when calling create().
Let authenticatorExtensionInput be the (CBOR) result of running extensionId’s client extension processing algorithm on clientExtensionInput. If the algorithm returned an error, continue.
+
+
SetauthenticatorExtensions[extensionId] to the base64url encoding of authenticatorExtensionInput.
+
+
+
Let collectedClientData be a new CollectedClientData instance whose fields are:
The status of Token Binding between the client and the callerOrigin, as well as the Token Binding ID associated with callerOrigin, if one is available.
Let authenticators represent a value which at any given instant is a set of client platform-specific handles, where each item identifies an authenticator presently available on this client platform at that instant.
+
Note: What qualifies an authenticator as "available" is intentionally unspecified; this is meant to represent how authenticators can be hot-plugged into (e.g., via USB)
+or discovered (e.g., via NFC or Bluetooth) by the client by various mechanisms, or permanently built into the client.
+
+
Start lifetimeTimer.
+
+
WhilelifetimeTimer has not expired, perform the following actions depending upon lifetimeTimer,
+and the state and response for eachauthenticator in authenticators:
+
+
If lifetimeTimer expires,
+
+
For eachauthenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and removeauthenticator from issuedRequests.
+
If the user exercises a user agent user-interface option to cancel the process,
+
For eachauthenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and removeauthenticator from issuedRequests. Then return a DOMException whose name is "AbortError" and terminate this algorithm.
+
If an authenticator becomes available on this client device,
+
+
Note: This includes the case where an authenticator was available upon lifetimeTimer initiation.
+
+
+
This authenticator is now the candidate authenticator.
Let userVerification be the effective user verification requirement for credential creation, a Boolean value,
+as follows. If options.authenticatorSelection.userVerification
Let enterpriseAttestationPossible be true if the user agent wishes to support enterprise attestation for options.rp.id (see Step 8, above). Otherwise false.
+
otherwise
+
+
Let enterpriseAttestationPossible be false.
+
+
+
Let excludeCredentialDescriptorList be a new list.
Note: If the client chooses to continue, this could result in
+inadvertently registering multiple credentials bound to the same authenticator if the transport hints in C.transports are not accurate.
+For example, stored transport hints could become inaccurate
+as a result of software upgrades adding new connectivity options.
+
+
Otherwise, AppendC to excludeCredentialDescriptorList.
+
+
+
Invoke the authenticatorMakeCredential operation on authenticator with clientDataHash, options.rp, options.user, requireResidentKey, userVerification, credTypesAndPubKeyAlgs, excludeCredentialDescriptorList, enterpriseAttestationPossible,
+ and authenticatorExtensions as parameters.
For each remaining authenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and remove it from issuedRequests.
+
Note:Authenticators may return an indication of "the user cancelled the entire operation".
+How a user agent manifests this state to users is unspecified.
+
+
If any authenticator returns an error status equivalent to "InvalidStateError",
+
Note: This error status is handled separately because the authenticator returns it only if excludeCredentialDescriptorList identifies a credential bound to the authenticator and the user has consented to the operation. Given this explicit consent, it is acceptable for this case to be
+distinguishable to the Relying Party.
+
If any authenticator returns an error status not equivalent to "InvalidStateError",
+
The client MAY replace the AAGUID and attestation statement with a more privacy-friendly
+and/or more easily verifiable version of the same data (for example, by employing an Anonymization CA).
A sequence of zero or more unique DOMStrings, in lexicographical order, that the authenticator is believed to support. The values SHOULD be members of AuthenticatorTransport, but client platforms MUST ignore unknown values.
+
If a user agent does not wish to divulge this information it MAY substitute an arbitrary sequence designed to preserve privacy. This sequence MUST still be valid, i.e. lexicographically sorted and free of duplicates. For example, it may use the empty sequence. Either way, in this case the user agent takes the risk that Relying Party behavior may be suboptimal.
+
If the user agent does not have any transport information, it SHOULD set this field to the empty sequence.
Note: All BufferSource objects used in this algorithm must be snapshotted when the algorithm begins, to
+avoid potential synchronization issues. The algorithm implementations should get a copy of the bytes held
+by the buffer source and use that copy for relevant portions of the algorithm.
+
When this method is invoked, the user agent MUST execute the following algorithm:
If the timeout member of options is present, check if its value lies
+within a reasonable range as defined by the client and if not, correct it to the closest value lying within that range.
+Set a timer lifetimeTimer to this adjusted value. If the timeout member of options is not present, then set lifetimeTimer to a client-specific default.
+
Recommended ranges and defaults for the timeout member of options are as follows.
+ If options.userVerification
Note: An effective domain may resolve to a host, which can be represented in various manners,
+ such as domain, ipv4 address, ipv6 address, opaque host, or empty host.
+ Only the domain format of host is allowed here. This is for simplification and also is
+ in recognition of various issues with using direct IP address identification in concert with
+ PKI-based security.
+
+ If options.rpId is not present, then set rpId to effectiveDomain.
+
Note:rpId represents the caller’s RP ID. The RP ID defaults to being the caller’s origin's effective domain unless the caller has explicitly set options.rpId when calling get().
+
+
+
Let clientExtensions be a new map and let authenticatorExtensions be a new map.
+
+
If the extensions member of options is present, then for eachextensionId → clientExtensionInput of options.extensions:
Let authenticatorExtensionInput be the (CBOR) result of running extensionId’s client extension processing algorithm on clientExtensionInput. If the algorithm returned an error, continue.
+
+
SetauthenticatorExtensions[extensionId] to the base64url encoding of authenticatorExtensionInput.
+
+
+
Let collectedClientData be a new CollectedClientData instance whose fields are:
The status of Token Binding between the client and the callerOrigin, as well as the Token Binding ID associated with callerOrigin, if one is available.
Let authenticators represent a value which at any given instant is a set of client platform-specific handles, where each item identifies an authenticator presently available on this client platform at that instant.
+
Note: What qualifies an authenticator as "available" is intentionally unspecified; this is meant to represent how authenticators can be hot-plugged into (e.g., via USB)
+or discovered (e.g., via NFC or Bluetooth) by the client by various mechanisms, or permanently built into the client.
+
+
Start lifetimeTimer.
+
+
WhilelifetimeTimer has not expired, perform the following actions depending upon lifetimeTimer,
+and the state and response for eachauthenticator in authenticators:
+
+
If lifetimeTimer expires,
+
+
For eachauthenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and removeauthenticator from issuedRequests.
+
If the user exercises a user agent user-interface option to cancel the process,
+
For eachauthenticator in issuedRequests invoke the authenticatorCancel operation on authenticator and removeauthenticator from issuedRequests. Then
+return a DOMException whose name is "AbortError" and terminate this algorithm.
Indicate to the user that no eligible credential could be found. When the user acknowledges the dialog, return a DOMException whose name is "NotAllowedError".
If allowCredentialDescriptorList has exactly one value, set savedCredentialIds[authenticator] to allowCredentialDescriptorList[0].id’s
+value (see here in § 6.3.3 The authenticatorGetAssertion Operation for more information).
+
+
For each credential descriptor C in allowCredentialDescriptorList, append each value, if any, of C.transports to distinctTransports.
+
Note: This will aggregate only distinct values of transports (for this authenticator) in distinctTransports due to the properties of ordered sets.
The client selects one transport value from distinctTransports, possibly incorporating local
+configuration knowledge of the appropriate transport to use with authenticator in making its
+selection.
+
Then, using transport, invoke the authenticatorGetAssertion operation on authenticator, with rpId, clientDataHash, allowCredentialDescriptorList, userVerification, and authenticatorExtensions as parameters.
Using local configuration knowledge of the appropriate transport to use with authenticator,
+invoke the authenticatorGetAssertion operation on authenticator with rpId, clientDataHash, allowCredentialDescriptorList, userVerification, and authenticatorExtensions as parameters.
Using local configuration knowledge of the appropriate transport to use with authenticator, invoke the authenticatorGetAssertion operation on authenticator with rpId, clientDataHash, userVerification and authenticatorExtensions as parameters.
+
Note: In this case, the Relying Party did not supply a list of acceptable credential descriptors. Thus, the
+ authenticator is being asked to exercise any credential it may possess that is scoped to
+ the Relying Party, as identified by rpId.
For each remaining authenticator in issuedRequests invoke the authenticatorCancel operation
+on authenticator and remove it from issuedRequests.
+
Note:Authenticators may return an indication of "the user cancelled the entire operation".
+How a user agent manifests this state to users is unspecified.
If assertionCreationData.userHandleResult is null, set this
+field to null. Otherwise, set this field to a new ArrayBuffer, created using global’s %ArrayBuffer%, containing the bytes of assertionCreationData.userHandleResult.
During the above process, the user agent SHOULD show some UI to the user to guide them in the process of selecting and
+authorizing an authenticator with which to complete the operation.
+
+
5.1.5. Store an Existing Credential - PublicKeyCredential’s [[Store]](credential, sameOriginWithAncestors) Method
+
+
The [[Store]](credential, sameOriginWithAncestors) method is not supported
+for Web Authentication’s PublicKeyCredential type, so it always returns an error.
5.1.6. Preventing Silent Access to an Existing Credential - PublicKeyCredential’s [[preventSilentAccess]](credential, sameOriginWithAncestors) Method
+
+
Calling the [[preventSilentAccess]](credential, sameOriginWithAncestors) method
+will have no effect on authenticators that require an authorization gesture,
+but setting that flag may potentially exclude authenticators that can operate without user intervention.
The AuthenticatorAttestationResponse interface represents the authenticator's response to a client’s request
+for the creation of a new public key credential. It contains information about the new credential that can be used to
+identify it for later use, and metadata that can be used by the WebAuthn Relying Party to assess the characteristics of the credential
+during registration.
This internal slot contains a sequence of zero or more unique DOMStrings in lexicographical order. These values are the transports that the authenticator is believed to support, or an empty sequence if the information is unavailable. The values SHOULD be members of AuthenticatorTransport but Relying Parties MUST ignore unknown values.
The getPublicKey() operation thus returns the credential public key as a SubjectPublicKeyInfo. This ArrayBuffer can, for example, be passed to Java’s java.security.spec.X509EncodedKeySpec, .NET’s System.Security.Cryptography.ECDsa.ImportSubjectPublicKeyInfo, or Go’s crypto/x509.ParsePKIXPublicKey.
Note:getPublicKey() and getAuthenticatorData() were only added in level two of this spec. Relying Parties SHOULD use feature detection before using these functions by testing the value of 'getPublicKey' in AuthenticatorAttestationResponse.prototype. Relying Parties that require this function to exist may not interoperate with older user-agents.
+
5.2.2. Web Authentication Assertion (interface AuthenticatorAssertionResponse)
This member specifies the cryptographic signature algorithm with which the newly generated credential will be used, and
+thus also the type of asymmetric key pair to be generated, e.g., RSA or Elliptic Curve.
+
+
Note: we use "alg" as the latter member name, rather than spelling-out "algorithm", because it will be serialized into
+ a message to the authenticator, which may be sent over a low-bandwidth link.
+
+
5.4. Options for Credential Creation (dictionary PublicKeyCredentialCreationOptions)
This member contains information about the desired properties of the credential to be created. The sequence is ordered
+from most preferred to least preferred. The client makes a best-effort to create the most preferred credential that it
+can.
This member specifies a time, in milliseconds, that the caller is willing to wait for the call to complete. This is
+treated as a hint, and MAY be overridden by the client.
This member is intended for use by Relying Parties that wish to limit the creation of multiple credentials for the same
+account on a single authenticator. The client is requested to return an error if the new credential would be created
+on an authenticator that also contains one of the credentials enumerated in this parameter.
This member contains additional parameters requesting additional processing by the client and authenticator. For
+example, the caller may request that only authenticators with certain capabilities be used to create the credential, or
+that particular information be returned in the attestation object. Some extensions are defined in § 9 WebAuthn Extensions;
+consult the IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809] for an up-to-date list
+of registered WebAuthn Extensions.
+
+
+
5.4.1. Public Key Entity Description (dictionary PublicKeyCredentialEntity)
Relying Parties SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264],
+when setting name's value, or displaying the value to the user.
Clients SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264],
+on name's value prior to displaying the value to the user or
+including the value as a parameter of the authenticatorMakeCredential operation.
+
+
+
When inherited by PublicKeyCredentialUserEntity, it is a human-palatable identifier for a
+user account. It is intended only for display, i.e., aiding the user in determining the difference between user
+accounts with similar displayNames. For example, "alexm", "alex.mueller@example.com"
+or "+14255551234".
+
+
+
The Relying Party MAY let the user choose this value. The Relying Party SHOULD perform enforcement,
+as prescribed in Section 3.4.3 of [RFC8265] for the UsernameCasePreserved Profile of the PRECIS
+IdentifierClass [RFC8264], when setting name's value, or displaying the value
+to the user.
Clients SHOULD perform enforcement, as prescribed in Section 3.4.3 of [RFC8265] for the UsernameCasePreserved Profile of the PRECIS IdentifierClass [RFC8264],
+on name's value prior to displaying the value to the user or
+including the value as a parameter of the authenticatorMakeCredential operation.
Authenticators MAY truncate a name member’s value so that it fits within 64 bytes, if the authenticator stores the value. See § 6.4.1 String Truncation about truncation and other considerations.
+
+
+
5.4.2. Relying Party Parameters for Credential Generation (dictionary PublicKeyCredentialRpEntity)
The user handle of the user account entity.
+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.
+
To ensure secure operation, authentication and authorization
+decisions MUST be made on the basis of this id member, not the displayName nor name members. See Section 6.1 of [RFC8266].
+
The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address;
+see § 14.6.1 User Handle Contents for details. The user handle MUST NOT be empty, though it MAY be null.
A human-palatable name for the user account, intended only for display. For example, "Alex Müller" or "田中倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.
+
+
+
Relying Parties SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264],
+when setting displayName's value, or displaying the value to the user.
Clients SHOULD perform enforcement, as prescribed in Section 2.3 of [RFC8266] for the Nickname Profile of the PRECIS FreeformClass [RFC8264],
+on displayName's value prior to displaying the value to the user or
+including the value as a parameter of the authenticatorMakeCredential operation.
Authenticators MUST accept and store a 64-byte minimum length for a displayName member’s value. Authenticators MAY truncate a displayName member’s value so that it fits within 64 bytes. See § 6.4.1 String Truncation about truncation and other considerations.
requireResidentKey, of type boolean, defaulting to false
+
+
This member is retained for backwards compatibility with WebAuthn Level 1 and, for historical reasons, its naming retains the deprecated “resident” terminology for discoverable credentials. Relying Parties SHOULD set it to true if, and only if, residentKey is set to required.
+
userVerification, of type DOMString, defaulting to "preferred"
+
This value indicates that the Relying Party wants to receive an attestation statement that may include uniquely identifying information. This is intended for controlled deployments within an enterprise where the organization wishes to tie registrations to specific authenticators. User agents MUST NOT provide such an attestation unless the user agent or authenticator configuration permits it for the requested RP ID.
The PublicKeyCredentialRequestOptions dictionary supplies get() with the data it needs to generate
+an assertion. Its challenge member MUST be present, while its other members are OPTIONAL.
This OPTIONAL member specifies a time, in milliseconds, that the caller is willing to wait for the call to complete.
+The value is treated as a hint, and MAY be overridden by the client.
This OPTIONAL member contains a list of PublicKeyCredentialDescriptor objects representing public key credentials acceptable to the caller, in descending order of the caller’s preference (the first item in the list is the most
+preferred credential, and so on down the list).
This OPTIONAL member contains additional parameters requesting additional processing by the client and authenticator.
+For example, if transaction confirmation is sought from the user, then the prompt string might be included as an
+extension.
The WHATWG HTML WG is discussing whether to provide a hook when a browsing context gains or
+ loses focuses. If a hook is provided, the above paragraph will be updated to include the hook.
+ See WHATWG HTML WG Issue #2711 for more details.
+
5.7. WebAuthn Extensions Inputs and Outputs
+
The subsections below define the data types used for conveying WebAuthn extension inputs and outputs.
The public key credential type uses certain data structures that are specified in supporting specifications. These are as
+follows.
+
5.8.1. Client Data Used in WebAuthn Signatures (dictionary CollectedClientData)
+
The client data represents the contextual bindings of both the WebAuthn Relying Party and the client. It is a key-value
+mapping whose keys are strings. Values can be any type that has a valid encoding in JSON. Its structure is defined by the
+following Web IDL.
This member contains the string "webauthn.create" when creating new credentials, and "webauthn.get" when getting an
+assertion from an existing credential. The purpose of this member is to prevent certain types of signature confusion
+attacks (where an attacker substitutes one legitimate signature for another).
This OPTIONAL member contains information about the state of the Token Binding protocol [TokenBinding] used when communicating
+with the Relying Party. Its absence indicates that the client doesn’t support token binding.
The serialization of the CollectedClientData is a subset of the algorithm for JSON-serializing to bytes. I.e. it produces a valid JSON encoding of the CollectedClientData but also provides additional structure that may be exploited by verifiers to avoid integrating a full JSON parser. While verifiers are recommended to perform standard JSON parsing, they may use the more limited algorithm below in contexts where a full JSON parser is too large. This verification algorithm requires only base64url encoding, appending of bytestrings (which could be implemented by writing into a fixed template), and three conditional checks (assuming that inputs are known not to need escaping).
+
The serialization algorithm works by appending successive byte strings to an, initially empty, partial result until the complete result is obtained.
If additional fields are added to CollectedClientData then verifiers that employ the limited verification algorithm will not be able to consider them until the two algorithms above are updated to include them. Once such an update occurs then the added fields inherit the same limitations as described in the previous paragraph. Such an algorithm update would have to accomodate serializations produced by previous versions. I.e. the verification algorithm would have to handle the fact that a fifth key–value pair may not appear fifth (or at all) if generated by a user agent working from a previous version.
+
5.8.2. Credential Type Enumeration (enum PublicKeyCredentialType)
+ This enumeration defines the valid credential types. It is an extension point; values can be added to it in the future, as
+ more credential types are defined. The values of this enumeration are used for versioning the Authentication Assertion and
+ attestation structures according to the type of the authenticator.
+
Currently one credential type is defined, namely "public-key".
This dictionary contains the attributes that are specified by a caller when referring to a public key credential as an input
+parameter to the create() or get() methods. It mirrors the fields of the PublicKeyCredential object returned by the latter methods.
+ Authenticators may implement various transports for communicating with clients. This enumeration
+ defines hints as to how clients might communicate with a particular authenticator in order to obtain an assertion for a
+ specific credential. Note that these hints represent the WebAuthn Relying Party's best belief as to how an authenticator may be reached. A Relying Party will typically learn of the supported transports for a public key credential via getTransports().
+
+
usb
+
+
Indicates the respective authenticator can be contacted over removable USB.
+
nfc
+
+
Indicates the respective authenticator can be contacted over Near Field Communication (NFC).
+
ble
+
+
Indicates the respective authenticator can be contacted over Bluetooth Smart (Bluetooth Low Energy / BLE).
+ A COSEAlgorithmIdentifier's value is a number identifying a cryptographic algorithm.
+ The algorithm identifiers SHOULD be values registered in the IANA COSE Algorithms registry [IANA-COSE-ALGS-REG],
+ for instance, -7 for "ES256" and -257 for "RS256".
+
The COSE algorithms registry leaves degrees of freedom to be specified by other parameters in a COSE key. In order to promote interoperability, this specification makes the following additional guarantees of credential public keys:
+
+
+
Keys with algorithm ES256 (-7) MUST specify P-256 (1) as the crv parameter and MUST NOT use the compressed point form.
+
+
Keys with algorithm ES384 (-35) MUST specify P-384 (2) as the crv parameter and MUST NOT use the compressed point form.
+
+
Keys with algorithm ES512 (-36) MUST specify P-521 (3) as the crv parameter and MUST NOT use the compressed point form.
+
+
Keys with algorithm EdDSA (-8) MUST specify Ed25519 (6) as the crv parameter. (These always use a compressed form in COSE.)
+
+
+
Note: There are many checks neccessary to correctly implement signature verification using these algorithms. One of these is that, when processing uncompressed elliptic-curve points, implementations should check that the point is actually on the curve. This check is highlighted because it’s judged to be at particular risk of falling through the gap between a cryptographic library and other code.
+
5.8.6. User Verification Requirement Enumeration (enum UserVerificationRequirement)
This value indicates that the Relying Party requires user verification for the operation and will fail the operation if the
+response does not have the UVflag set.
+
preferred
+
+
This value indicates that the Relying Party prefers user verification for the operation if possible, but will not fail the
+operation if the response does not have the UVflag set.
+
discouraged
+
+
This value indicates that the Relying Party does not want user verification employed during the operation (e.g., in the
+interest of minimizing disruption to the user interaction flow).
Client platforms MAY implement and expose this abstract model in any way desired. However, the behavior of the client’s Web
+Authentication API implementation, when operating on the authenticators supported by that client platform, MUST be indistinguishable
+from the behavior specified in § 5 Web Authentication API.
+
Note:[FIDO-CTAP] is an example of a concrete instantiation of this model, but it is one in which there are differences in the data it returns and those expected by the WebAuthn API's algorithms. The CTAP2 response messages are CBOR maps constructed using integer keys rather than the string keys defined in this specification for the same objects. The client is expected to perform any needed transformations on such data. The [FIDO-CTAP] specification details the mapping between CTAP2 integer keys and WebAuthn string keys, in section §6.2. Responses.
+
For authenticators, this model defines the logical operations that they MUST support, and the data formats that they expose to
+the client and the WebAuthn Relying Party. However, it does not define the details of how authenticators communicate with the client device,
+unless they are necessary for interoperability with Relying Parties. For instance, this abstract model does not define protocols for
+connecting authenticators to clients over transports such as USB or NFC. Similarly, this abstract model does not define specific
+error codes or methods of returning them; however, it does define error behavior in terms of the needs of the client. Therefore,
+specific error codes are mentioned as a means of showing which error conditions MUST be distinguishable (or not) from each other
+in order to enable a compliant and secure client implementation.
In this abstract model, the authenticator provides key management and cryptographic signatures. It can be embedded in the
+WebAuthn client or housed in a separate device entirely. The authenticator itself can contain a cryptographic module which
+operates at a higher security level than the rest of the authenticator. This is particularly important for authenticators that
+are embedded in the WebAuthn client, as in those cases this cryptographic module (which may, for example, be a TPM) could be
+considered more trustworthy than the rest of the authenticator.
Additionally, each authenticator has an AAGUID, which is a 128-bit identifier indicating the type (e.g. make and model) of the
+authenticator. The AAGUID MUST be chosen by the manufacturer to be identical across all substantially identical authenticators
+made by that manufacturer, and different (with high probability) from the AAGUIDs of all other types of authenticators.
+The AAGUID for a given type of authenticator SHOULD be randomly generated to ensure this. The Relying Party MAY use the AAGUID to infer certain
+properties of the authenticator, such as certification level and strength of key protection, using information from other sources.
+
The primary function of the authenticator is to provide WebAuthn signatures, which are bound to various contextual data. These
+data are observed and added at different levels of the stack as a signature request passes from the server to the
+authenticator. In verifying a signature, the server checks these bindings against expected values. These contextual bindings
+are divided in two: Those added by the Relying Party or the client, referred to as client data; and those added by the authenticator,
+referred to as the authenticator data. The authenticator signs over the client data, but is otherwise not interested in
+its contents. To save bandwidth and processing requirements on the authenticator, the client hashes the client data and
+sends only the result to the authenticator. The authenticator signs over the combination of the hash of the serialized client data, and its own authenticator data.
+
The goals of this design can be summarized as follows.
+
+
+
The scheme for generating signatures should accommodate cases where the link between the client device and authenticator
+is very limited, in bandwidth and/or latency. Examples include Bluetooth Low Energy and Near-Field Communication.
+
+
The data processed by the authenticator should be small and easy to interpret in low-level code. In particular, authenticators
+should not have to parse high-level encodings such as JSON.
+
+
Both the client and the authenticator should have the flexibility to add contextual bindings as needed.
+
+
The design aims to reuse as much as possible of existing encoding formats in order to aid adoption and implementation.
+
+
Authenticators produce cryptographic signatures for two distinct purposes:
The term WebAuthn signature refers to both attestation signatures and assertion signatures.
+The formats of these signatures, as well as the procedures for generating them, are specified below.
+
6.1. Authenticator Data
+
The authenticator data structure encodes contextual bindings made by the authenticator. These bindings are
+controlled by the authenticator itself, and derive their trust from the WebAuthn Relying Party's assessment of the security properties of the
+authenticator. In one extreme case, the authenticator may be embedded in the client, and its bindings may be no more trustworthy
+than the client data. At the other extreme, the authenticator may be a discrete entity with high-security hardware and
+software, connected to the client over a secure channel. In both cases, the Relying Party receives the authenticator data in the same
+format, and uses its knowledge of the authenticator to make trust decisions.
+
The authenticator data has a compact but extensible encoding. This is desired since authenticators can be devices with
+limited capabilities and low power requirements, with much simpler software stacks than the client platform.
+
The authenticator data structure is a byte array of 37 bytes or more,
+laid out as shown in Table .
+ Authenticator data layout. The names in the Name column are only for reference within this document, and are not
+ present in the actual representation of the authenticator data.
+
+
The RP ID is originally received from the client when the credential is created, and again when an assertion is generated.
+However, it differs from other client data in some important ways. First, unlike the client data, the RP ID of a
+credential does not change between operations but instead remains the same for the lifetime of that credential. Secondly, it is
+validated by the authenticator during the authenticatorGetAssertion operation, by verifying that the RP ID that
+the requested credential is scoped to exactly matches the RP ID supplied by the client.
The UPflag SHALL be set if and only if the authenticator performed a test of user presence.
+The UVflag SHALL be set if and only if the authenticator performed user verification.
+The RFU bits SHALL be set to zero.
+ Note: authenticator data describes its own length: If the AT and ED flags are not set, it is always 37 bytes long.
+ The attested credential data (which is only present if the AT flag is set) describes its own length. If the ED flag is set, then the total length is 37 bytes plus the length of the attested credential data (if the AT flag is set), plus the length of the extensions output (a CBOR map) that
+ follows.
+
Detecting a signature counter mismatch does not indicate whether the current operation was performed by a cloned authenticator or the original authenticator. Relying Parties should address this situation appropriately relative to their individual situations, i.e., their risk tolerance.
+
Authenticators:
+
+
+
SHOULD implement per credential signature counters. This prevents the signature counter value from being shared between Relying Parties and being possibly employed
+as a correlation handle for the user. Authenticators may implement a global signature counter,
+i.e., on a per-authenticator basis, but this is less privacy-friendly for users.
+
+
SHOULD ensure that the signature counter value does not
+accidentally decrease (e.g., due to hardware failures).
Many use cases are dependent on the capabilities of the authenticator used.
+This section defines some terminology for those capabilities, their most important combinations,
+and which use cases those combinations enable.
For subsequent re-authentication on the same client device, a platform authenticator is likely the most convenient
+since it’s built directly into the client device rather than being a separate device that the user may have to locate.
+
+
For second-factor authentication in addition to a traditional username and password, any authenticator can be used.
These characteristics are independent and may in theory be combined in any way,
+but Table lists and names some authenticator types of particular interest.
A WebAuthn Client MUST connect to an authenticator in order to invoke any of the operations of that authenticator. This connection
+defines an authenticator session. An authenticator must maintain isolation between sessions. It may do this by only allowing one
+session to exist at any particular time, or by providing more complicated session management.
+
The following operations can be invoked by the client in an authenticator session.
+
6.3.1. Lookup Credential Source by Credential ID Algorithm
+
The result of looking up a credential idcredentialId in an authenticatorauthenticator is the result of the following algorithm:
The constant Boolean value true.
+It is included here as a pseudo-parameter to simplify applying this abstract authenticator model to implementations that may
+wish to make a test of user presence optional although WebAuthn does not.
An OPTIONAL list of PublicKeyCredentialDescriptor objects provided by the Relying Party with the intention that, if any of
+these are known to the authenticator, it SHOULD NOT create a new credential. excludeCredentialDescriptorList contains a
+list of known credentials.
+
enterpriseAttestationPossible
+
+
A Boolean value that indicates that individually-identifying attestation MAY be returned by the authenticator.
Note: Before performing this operation, all other operations in progress in the authenticator session MUST be aborted by
+running the authenticatorCancel operation.
+
When this operation is invoked, the authenticator MUST perform the following procedure:
+
+
+
Check if all the supplied parameters are syntactically well-formed and of the correct length. If not, return an error code
+equivalent to "UnknownError" and terminate the operation.
+
+
Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported.
+If not, return an error code equivalent to "NotSupportedError" and terminate the operation.
+
+
For eachdescriptor of excludeCredentialDescriptorList:
return an error code equivalent to "InvalidStateError" and terminate the operation.
+
does not consent to create a new credential
+
+
return an error code equivalent to "NotAllowedError" and terminate the operation.
+
+
Note: The purpose of this authorization gesture is not to proceed with creating a credential,
+but for privacy reasons to authorize disclosure of the fact that descriptor.id is bound to this authenticator.
+If the user consents, the client and Relying Party can detect this and guide the user to use a different authenticator.
+If the user does not consent,
+the authenticator does not reveal that descriptor.id is bound to it,
+and responds as if the user simply declined consent to create a credential.
If requireUserVerification is true and the authenticator cannot perform user verification, return an error code
+equivalent to "ConstraintError" and terminate the operation.
+
+ Collect an authorization gesture confirming user consent for creating a new credential.
+ The prompt for the authorization gesture is shown by the
+ authenticator if it has its own output capability, or by the user agent otherwise. The prompt SHOULD display rpEntity.id, rpEntity.name, userEntity.name and userEntity.displayName, if possible.
+
Let (publicKey, privateKey) be a new pair of cryptographic keys using the combination of PublicKeyCredentialType and cryptographic parameters represented by the first item in credTypesAndPubKeyAlgs that is supported by
+this authenticator.
let the signature counter value for the new credential be zero. (U2F devices may support signature counters but do not return a counter when making a credential. See [FIDO-U2F-Message-Formats].)
The constant Boolean value true.
+It is included here as a pseudo-parameter to simplify applying this abstract authenticator model to implementations that may
+wish to make a test of user presence optional although WebAuthn does not.
Note: Before performing this operation, all other operations in progress in the authenticator session MUST be aborted by running the authenticatorCancel operation.
+
When this method is invoked, the authenticator MUST perform the following procedure:
+
+
+
Check if all the supplied parameters are syntactically well-formed and of the correct length. If not, return an error code
+equivalent to "UnknownError" and terminate the operation.
If allowCredentialDescriptorList was supplied, then for eachdescriptor of allowCredentialDescriptorList:
+
+
+
Let credSource be the result of looking updescriptor.id in this
+authenticator.
+
+
If credSource is not null, append it to credentialOptions.
+
+
+
Otherwise (allowCredentialDescriptorList was not supplied), for eachkey → credSource of this
+authenticator’s credentials map, appendcredSource to credentialOptions.
+
+
Remove any items from credentialOptions whose rpId is not equal to rpId.
+
+
If credentialOptions is now empty, return an error code equivalent to "NotAllowedError" and terminate the operation.
Let signature be the assertion signature of the concatenation authenticatorData || hash using the privateKey of selectedCredential as shown in Figure , below. A simple,
+undelimited
+concatenation is safe to use here because the authenticator data describes its own length. The hash of the serialized
+client data (which potentially has a variable length) is always the last element.
If any error occurred while generating the assertion signature, return an error code equivalent to "UnknownError" and
+terminate the operation.
+
+ Return to the user agent:
+
+
+
selectedCredential.id, if either a list of credentials
+(i.e., allowCredentialDescriptorList) of length 2 or greater was
+supplied by the client, or no such list was supplied.
+
Note: If, within allowCredentialDescriptorList, the client supplied exactly one credential and it was successfully employed, then its credential ID is not returned since the client already knows it. This saves transmitting these bytes over
+ what may be a constrained connection in what is likely a common case.
If the authenticator cannot find any credential corresponding to the specified Relying Party that
+matches the specified criteria, it terminates the operation and returns an error.
+
6.3.4. The authenticatorCancel Operation
+
This operation takes no input parameters and returns no result.
+
When this operation is invoked by the client in an authenticator session, it has the effect of terminating any authenticatorMakeCredential or authenticatorGetAssertion operation currently in progress in that authenticator
+session. The authenticator stops prompting for, or accepting, any user input related to authorizing the canceled operation. The
+client ignores any further responses from the authenticator for the canceled operation.
Authenticators may be required to store arbitrary strings chosen by a Relying Party, for example the name and displayName in a PublicKeyCredentialUserEntity. This section discusses some practical consequences of handling arbitrary strings that may be presented to humans.
+
6.4.1. String Truncation
+
Each arbitrary string in the API will have some accommodation for the potentially limited resources available to an authenticator. If string value truncation is the chosen accommodation then authenticators MAY truncate in order to make the string fit within a length equal or greater than the specified minimum supported length. Such truncation SHOULD also respect UTF-8 sequence boundaries or grapheme cluster boundaries [UTR29]. This defines the maximum truncation permitted and authenticators MUST NOT truncate further.
+
For example, in figure the string is 65 bytes long. If truncating to 64 bytes then the final 0x88 byte must be removed purely because of space reasons. Since that leaves a partial UTF-8 sequence the remainder of that sequence may also be removed. Since that leaves a partial grapheme cluster an authenticator may remove the remainder of that cluster.
+
+
+ The end of a UTF-8 encoded string showing the positions of different truncation boundaries.
+
+
Conforming User Agents are responsible for ensuring that the authenticator behaviour observed by Relying Parties conforms to this specification with respect to string handling. For example, if an authenticator is known to behave incorrectly when asked to store large strings, the user agent SHOULD perform the truncation for it in order to maintain the model from the point of view of the Relying Party. User-agents that do this SHOULD truncate at grapheme cluster boundaries.
+
Truncation based on UTF-8 sequences alone may cause a grapheme cluster to be truncated. This could make the grapheme cluster render as a different glyph, potentially changing the meaning of the string, instead of removing the glyph entirely.
+
In addition to that, truncating on byte boundaries alone causes a known issue that user agents should be aware of: if the authenticator is using [FIDO-CTAP] then future messages from the authenticator may contain invalid CBOR since the value is typed as a CBOR string and thus is required to be valid UTF-8. User agents are tasked with handling this to avoid burdening authenticators with understanding character encodings and Unicode character properties. Thus, when dealing with authenticators, user agents SHOULD:
+
+
+
Ensure that any strings sent to authenticators are validly encoded.
+
+
Handle the case where strings have been truncated resulting in an invalid encoding. For example, any partial code point at the end may be dropped or replaced with U+FFFD.
+
+
6.4.2. Language and Direction Encoding
+
In order to be correctly displayed in context, the language and base direction of a string may be required. Strings in this API may have to be written to fixed-function authenticators and then later read back and displayed on a different platform. Thus language and direction metadata is encoded in the string itself to ensure that it is transported atomically.
+
To encode language and direction metadata in a string that is documented as permitting it, suffix its code points with two sequences of code points:
+
The first encodes a language tag with the code point U+E0001 followed by the ASCII values of the language tag each shifted up by U+E0000. For example, the language tag “en-US” becomes the code points U+E0001, U+E0065, U+E006E, U+E002D, U+E0055, U+E0053.
+
The second consists of a single code point which is either U+200E (“LEFT-TO-RIGHT MARK”), U+200F (“RIGHT-TO-LEFT MARK”), or U+E007F (“CANCEL TAG”). The first two can be used to indicate directionality but SHOULD only be used when neccessary to produce the correct result. (E.g. an RTL string that starts with LTR-strong characters.) The value U+E007F is a direction-agnostic indication of the end of the language tag.
+
So the string “حبیب الرحمان” could have two different DOMString values, depending on whether the language was encoded or not. (Since the direction is unambigous a directionality marker is not needed in this example.)
Consumers of strings that may have language and direction encoded should be aware that truncation could truncate a language tag into a different, but still valid, language. The final directionality marker or CANCEL TAG code point provide an unambigous indication of truncation.
The attestation statement format is the manner in which the signature is represented and the various contextual
+bindings are incorporated into the attestation statement by the authenticator. In other words, this defines the
+syntax of the statement. Various existing components and OS platforms (such as TPMs and the Android OS) have previously defined attestation statement formats. This specification supports a variety of such formats in an extensible way, as defined in § 6.5.2 Attestation Statement Formats. The formats themselves are identified by strings, as described in § 8.1 Attestation Statement Format Identifiers.
The characteristics of the individual authenticator, such as its construction, whether part or all of it runs in a secure
+operating environment, and so on.
Attested credential data is a variable-length byte array added to the authenticator data when generating an attestation
+object for a given credential. Its format is shown in Table .
+
+
+
+
+
Name
+
Length (in bytes)
+
Description
+
+
aaguid
+
16
+
The AAGUID of the authenticator.
+
+
credentialIdLength
+
2
+
Byte length L of Credential ID, 16-bit unsigned big-endian integer.
+
+ Attested credential data layout. The names in the Name column are only for reference within this document, and are not
+ present in the actual representation of the attested credential data.
+
+
6.5.1.1. Examples of credentialPublicKey Values Encoded in COSE_Key Format
+
This section provides examples of COSE_Key-encoded Elliptic Curve and RSA public keys for the ES256, PS256, and RS256
+signature algorithms. These examples adhere to the rules defined above for the credentialPublicKey value, and are presented in CDDL [RFC8610] for clarity.
+
[RFC8152]Section 7 defines the general framework for all COSE_Key-encoded keys.
+Specific key types for specific algorithms are defined in other sections of [RFC8152] as well as in other specifications,
+as noted below.
+
Below is an example of a COSE_Key-encoded Elliptic Curve public key in EC2 format (see [RFC8152]Section 13.1), on the P-256 curve, to be used with the ES256 signature
+algorithm (ECDSA w/ SHA-256, see [RFC8152]Section 8.1:
+
{
+ 1:2, ; kty: EC2 key type
+ 3:-7, ; alg: ES256 signature algorithm
+ -1:1, ; crv: P-256 curve
+ -2: x, ; x-coordinate as byte string 32 bytes in length
+ ; e.g., in hex:65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
+ -3: y ; y-coordinate as byte string 32 bytes in length
+ ; e.g., in hex:1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
+}
+
+
Below is the above Elliptic Curve public key encoded in the CTAP2 canonical CBOR encoding form, whitespace and line breaks
+are included here for clarity and to match the CDDL [RFC8610] presentation above:
Below is an example of a COSE_Key-encoded 2048-bit RSA public key (see [RFC8230]Section 4,
+to be used with the PS256 signature algorithm
+(RSASSA-PSS with SHA-256, see [RFC8230]Section 2:
+
{
+ 1:3, ; kty: RSA key type
+ 3:-37, ; alg: PS256
+ -1:n, ; n: RSA modulus n byte string 256 bytes in length
+ ; e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
+ -2: e ; e: RSA public exponent e byte string 3 bytes in length
+ ; e.g., in hex:010001
+}
+
+
Below is an example of the same COSE_Key-encoded RSA public key as above,
+to be used with the RS256 signature algorithm (RSASSA-PKCS1-v1_5 with SHA-256):
+
{
+ 1:3, ; kty: RSA key type
+ 3:-257, ; alg: RS256
+ -1:n, ; n: RSA modulus n byte string 256 bytes in length
+ ; e.g., in hex (middle bytes elided for brevity): DB5F651550...6DC6548ACC3
+ -2: e ; e: RSA public exponent e byte string 3 bytes in length
+ ; e.g., in hex:010001
+}
+
An error indicating that the attestation is invalid, or
+
+
An implementation-specific value representing the attestation type, and the trust path. This attestation trust path is either
+empty (in case of self attestation), or a set of X.509 certificates.
In this case, an authenticator is based on a Trusted Platform Module (TPM) and holds an authenticator-specific
+"endorsement key" (EK). This key is used to securely communicate with a trusted third party, the Attestation CA[TCG-CMCProfile-AIKCertEnroll] (formerly known as a "Privacy CA"). The authenticator can generate multiple
+attestation identity key pairs (AIK) and requests an Attestation CA to issue an AIK certificate
+for each. Using this approach, such an authenticator can limit the exposure of the EK (which is a global correlation
+handle) to Attestation CA(s). AIKs can be requested for each authenticator-generated public key credential individually, and conveyed to Relying Parties as attestation certificates.
+
Note: This concept typically leads to multiple attestation certificates. The attestation certificate requested most recently
+ is called "active".
Return the attestation object as a CBOR map with the following syntax, filled in with variables initialized by this
+algorithm:
+
attObj = {
+ authData: bytes,
+ $$attStmtType
+ }
+
+ attStmtTemplate = (
+ fmt: text,
+ attStmt: { * tstr => any } ; Map is filled in by each concrete attStmtType
+ )
+
+ ; Every attestation statement format must have the above fields
+ attStmtTemplate .within $$attStmtType
+
+
+
6.5.5. Signature Formats for Packed Attestation, FIDO U2F Attestation, and Assertion Signatures
+
+
+
For COSEAlgorithmIdentifier -7 (ES256), and other ECDSA-based algorithms, the sig value MUST be encoded as an ASN.1 DER Ecdsa-Sig-Value, as defined in [RFC3279] section 2.2.3.
Note: As CTAP1/U2F authenticators are already producing signatures values in this format, CTAP2 authenticators will also produce signatures values in the same format, for consistency reasons.
+
+
It is RECOMMENDED that any new attestation formats defined not use ASN.1 encodings,
+ but instead represent signatures as equivalent fixed-length byte arrays without internal structure,
+ using the same representations as used by COSE signatures as defined in [RFC8152] and [RFC8230].
+
The below signature format definitions satisfy this requirement and serve as examples for deriving the same for other signature algorithms not explicitly mentioned here:
+
+
+
For COSEAlgorithmIdentifier -257 (RS256), sig MUST contain the signature generated using the
+RSASSA-PKCS1-v1_5 signature scheme defined in section 8.2.1 in [RFC8017] with SHA-256 as the hash function.
+The signature is not ASN.1 wrapped.
+
+
For COSEAlgorithmIdentifier -37 (PS256), sig MUST contain the signature generated using the
+RSASSA-PSS signature scheme defined in section 8.1.1 in [RFC8017] with SHA-256 as the hash function.
+The signature is not ASN.1 wrapped.
Call navigator.credentials.create() and pass options as the publicKey option.
+Let credential be the result of the successfully resolved promise.
+If the promise is rejected, abort the ceremony with a user-visible error, or otherwise guide the user experience as
+might be determinable from the context available in the rejected promise. For example if the promise is rejected with
+an error code equivalent to "InvalidStateError", the user might be instructed to use a different authenticator.
+For information on different error contexts and the circumstances leading to them, see § 6.3.2 The authenticatorMakeCredential Operation.
Note: Using any implementation of UTF-8 decode is acceptable as long as it yields the same result as that yielded by
+the UTF-8 decode algorithm. In particular, any leading byte order mark (BOM) MUST be stripped.
+
+
Let C, the client data claimed as collected during the credential creation, be the result of running an
+implementation-specific JSON parser on JSONtext.
+
Note:C may be any implementation-specific data structure representation, as long as C’s components are referenceable, as
+required by this algorithm.
+
+
Verify that the value of C.type is webauthn.create.
+
+
Verify that the value of C.challenge equals
+the base64url encoding of options.challenge.
Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be
+prepared to handle cases where none or not all of the requested extensions were acted upon.
+
+
Determine the attestation statement format by performing a USASCII case-sensitive match on fmt against the set of
+supported WebAuthn Attestation Statement Format Identifier values.
+An up-to-date list of registered WebAuthn Attestation Statement Format Identifier values
+is maintained in the
+IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
If validation is successful, obtain a list of acceptable trust anchors (i.e. attestation root certificates)
+for that attestation type and attestation statement format fmt, from a trusted source or from policy. For
+example, the FIDO Metadata Service [FIDOMetadataService] provides one way to obtain such information, using the aaguid in the attestedCredentialData in authData.
+
+
Assess the attestation trustworthiness using the outputs of the verification procedure in step 19, as follows:
Otherwise, use the X.509 certificates returned as the attestation trust path from the verification procedure to verify that the attestation public key either correctly chains up to an acceptable root certificate, or is itself an acceptable certificate (i.e., it and the root certificate obtained in Step 20 may be the same).
+
+
+
Check that the credentialId is not yet registered to any other user. If registration
+is requested for a credential that is already registered to a different user, the Relying Party SHOULD
+fail this registration ceremony, or it MAY decide to accept the registration, e.g. while deleting the older registration.
+
+
If the attestation statement attStmt verified successfully and is found to be trustworthy, then register the new
+credential with the account that was denoted in options.user:
Associate the credentialId with the transport hints
+returned by calling credential.response.getTransports().
+This value SHOULD NOT be modified before or after storing it.
+It is RECOMMENDED to use this value to populate the transports of the allowCredentials option in future get() calls
+to help the client know how to find a suitable authenticator.
+
+
+
If the attestation statement attStmt successfully verified but is not trustworthy per step 21 above, the Relying Party SHOULD fail
+the registration ceremony.
Verification of attestation objects requires that the Relying Party has a trusted method of determining acceptable trust anchors
+in step 20 above. Also, if certificates are being used, the Relying Party MUST have access to certificate status information for the
+intermediate CA certificates. The Relying Party MUST also be able to build the attestation certificate chain if the client did not
+provide this chain in the attestation information.
Call navigator.credentials.get() and pass options as the publicKey option.
+Let credential be the result of the successfully resolved promise.
+If the promise is rejected, abort the ceremony with a user-visible error, or otherwise guide the user experience as might
+be determinable from the context available in the rejected promise. For information on different error contexts and the
+circumstances leading to them, see § 6.3.3 The authenticatorGetAssertion Operation.
Identify the user being authenticated and verify that this user is the owner of the public key credential sourcecredentialSource identified by credential.id:
+
+
If the user was identified before the authentication ceremony was initiated, e.g., via a username or cookie,
+
+
verify that the identified user is the owner of credentialSource. If response.userHandle is present,
+let userHandle be its value. Verify that userHandle also maps to the same user.
Let JSONtext be the result of running UTF-8 decode on the value of cData.
+
Note: Using any implementation of UTF-8 decode is acceptable as long as it yields the same result as that yielded by
+the UTF-8 decode algorithm. In particular, any leading byte order mark (BOM) MUST be stripped.
+
+
Let C, the client data claimed as used for the signature, be the result of running an implementation-specific
+JSON parser on JSONtext.
+
Note:C may be any implementation-specific data structure representation, as long as C’s components are referenceable, as
+required by this algorithm.
+
+
Verify that the value of C.type is the string webauthn.get.
+
+
Verify that the value of C.challenge equals
+the base64url encoding of options.challenge.
Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be
+prepared to handle cases where none or not all of the requested extensions were acted upon.
+
+
Let hash be the result of computing a hash over the cData using SHA-256.
+
+
Using credentialPublicKey, verify that sig is a valid signature over the binary concatenation of authData and hash.
Let storedSignCount be the stored signature counter value associated with credential.id.
+If authData.signCount is nonzero or storedSignCount is nonzero,
+then run the following sub-step:
Update storedSignCount to be the value of authData.signCount.
+
less than or equal to storedSignCount:
+
This is a signal that
+ the authenticator may be cloned, i.e. at least
+ two copies of the credential private key may exist and are
+ being used in parallel. Relying Parties should incorporate this information
+ into their risk scoring. Whether the Relying Party updates storedSignCount in this case, or not, or fails the authentication ceremony or not, is Relying Party-specific.
+
WebAuthn supports pluggable attestation statement formats. This section defines an initial set of such formats.
+
8.1. Attestation Statement Format Identifiers
+
Attestation statement formats are identified by a string, called an attestation statement format identifier, chosen by
+the author of the attestation statement format.
+
Attestation statement format identifiers SHOULD be registered in the
+IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
+All registered attestation statement format identifiers are unique amongst themselves as a matter of course.
+
Unregistered attestation statement format identifiers SHOULD use lowercase reverse domain-name naming, using a domain name
+registered by the developer, in order to assure uniqueness of the identifier. All attestation statement format identifiers MUST
+be a maximum of 32 octets in length and MUST consist only of printable USASCII characters, excluding backslash and doublequote,
+i.e., VCHAR as defined in [RFC5234] but without %x22 and %x5c.
+
Note: This means attestation statement format identifiers based on domain names MUST incorporate only LDH Labels [RFC5890].
+
Implementations MUST match WebAuthn attestation statement format identifiers in a case-sensitive fashion.
+
Attestation statement formats that may exist in multiple versions SHOULD include a version in their identifier. In effect,
+different versions are thus treated as different formats, e.g., packed2 as a new version of the § 8.2 Packed Attestation Statement Format.
+
The following sections present a set of currently-defined and registered attestation statement formats and their identifiers.
+The up-to-date list of registered WebAuthn Extensions is maintained in the
+IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
+
8.2. Packed Attestation Statement Format
+
This is a WebAuthn optimized attestation statement format. It uses a very compact but still extensible encoding method. It is
+implementable by authenticators with limited resources (e.g., secure elements).
The elements of this array contain attestnCert and its certificate chain (if any), each encoded in X.509 format. The attestation
+certificate attestnCert MUST be the first element in the array.
+
attestnCert
+
+
The attestation certificate, encoded in X.509 format.
If Basic or AttCAattestation is in use, the authenticator produces the sig by concatenating authenticatorData and clientDataHash, and signing the result using an attestation private key selected through an authenticator-specific
+mechanism. It sets x5c to attestnCert followed by the related certificate chain (if any). It sets alg to the algorithm of the
+attestation private key.
+
+
If self attestation is in use, the authenticator produces sig by concatenating authenticatorData and clientDataHash,
+and signing the result using the credential private key. It sets alg to the algorithm of the credential private key and
+omits the other fields.
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract
+the contained fields.
+
+
If x5c is present:
+
+
+
Verify that sig is a valid signature over the concatenation of authenticatorData and clientDataHash using the
+attestation public key in attestnCert with the algorithm specified in alg.
If attestnCert contains an extension with OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) verify that the
+value of this extension matches the aaguid in authenticatorData.
+
+
Optionally, inspect x5c and consult externally provided knowledge to determine whether attStmt conveys a Basic or AttCA attestation.
If the related attestation root certificate is used for multiple authenticator models, the Extension OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) MUST be present, containing the AAGUID as a 16-byte OCTET STRING.
+The extension MUST NOT be marked as critical.
+
Note that an X.509 Extension encodes the DER-encoding of the value in an OCTET STRING.
+Thus, the AAGUID MUST be wrapped in two OCTET STRINGS to be valid. Here is a sample, encoded Extension structure:
The Basic Constraints extension MUST have the CA component set to false.
+
+
An Authority Information Access (AIA) extension with entry id-ad-ocsp and a CRL Distribution Point extension [RFC5280] are both OPTIONAL as the status of many attestation certificates is available through authenticator metadata services.
+See, for example, the FIDO Metadata Service [FIDOMetadataService].
+
+
8.3. TPM Attestation Statement Format
+
This attestation statement format is generally used by authenticators that use a Trusted Platform Module as their cryptographic
+engine.
Concatenate authenticatorData and clientDataHash to form attToBeSigned.
+
Generate a signature using the procedure specified in [TPMv2-Part3] Section 18.2, using the attestation private key and
+setting the extraData parameter to the digest of attToBeSigned using the hash algorithm corresponding to the "alg" signature algorithm.
+(For the "RS256" algorithm, this would be a SHA-256 digest.)
+
Set the pubArea field to the public area of the credential public key, the certInfo field to the output parameter of the
+same name, and the sig field to the signature obtained from the above procedure.
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract the
+contained fields.
+
Verify that the public key specified by the parameters and unique fields of pubArea is identical to the credentialPublicKey in the attestedCredentialData in authenticatorData.
+
Concatenate authenticatorData and clientDataHash to form attToBeSigned.
+
Validate that certInfo is valid:
+
+
+
Verify that magic is set to TPM_GENERATED_VALUE.
+
+
Verify that type is set to TPM_ST_ATTEST_CERTIFY.
+
+
Verify that extraData is set to the hash of attToBeSigned using the hash algorithm employed in "alg".
+
+
Verify that attested contains a TPMS_CERTIFY_INFO structure as specified in [TPMv2-Part2] section 10.12.3,
+whose name field contains a valid Name for pubArea,
+as computed using the algorithm in the nameAlg field of pubArea using the procedure specified in [TPMv2-Part1] section 16.
+
+
Verify that x5c is present.
+
+
Note that the remaining fields in the "Standard Attestation Structure" [TPMv2-Part1] section 31.2, i.e., qualifiedSigner, clockInfo and firmwareVersion are ignored.
+These fields MAY be used as an input to risk engines.
+
+
Verify the sig is a valid signature over certInfo using the attestation public key in aikCert with the
+algorithm specified in alg.
If aikCert contains an extension with OID 1.3.6.1.4.1.45724.1.1.4 (id-fido-gen-ce-aaguid) verify that the value of this
+extension matches the aaguid in authenticatorData.
The Subject Alternative Name extension MUST be set as defined in [TPMv2-EK-Profile] section 3.2.9.
+
+
The Extended Key Usage extension MUST contain the OID 2.23.133.8.3 ("joint-iso-itu-t(2) internationalorganizations(23) 133 tcg-kp(8) tcg-kp-AIKCertificate(3)").
+
+
The Basic Constraints extension MUST have the CA component set to false.
+
+
An Authority Information Access (AIA) extension with entry id-ad-ocsp and a CRL Distribution Point extension [RFC5280] are
+both OPTIONAL as the status of many attestation certificates is available through metadata services.
+See, for example, the FIDO Metadata Service [FIDOMetadataService].
An Android key attestation statement consists simply of the Android attestation statement, which is a series of
+DER encoded X.509 certificates. See the Android developer documentation. Its
+syntax is defined as follows:
Request an Android Key Attestation by calling keyStore.getCertificateChain(myKeyUUID) providing clientDataHash as the
+challenge value (e.g., by using setAttestationChallenge). Set x5c to the returned value.
+
The authenticator produces sig by concatenating authenticatorData and clientDataHash,
+and signing the result using the credential private key. It sets alg to the algorithm of the signature format.
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract the
+contained fields.
+
+
Verify that sig is a valid signature over the concatenation of authenticatorData and clientDataHash using the
+public key in the first certificate in x5c with the algorithm specified in alg.
Verify the following using the appropriate authorization list from the attestation certificate extension data:
+
+
+
The AuthorizationList.allApplications field is not present on either authorization list
+(softwareEnforced nor teeEnforced), since PublicKeyCredential MUST be scoped to the RP ID.
+
+
For the following, use only the teeEnforced authorization list if the RP wants to accept only keys from a
+trusted execution environment, otherwise use the union of teeEnforced and softwareEnforced.
+
+
+
The value in the AuthorizationList.origin field is equal to KM_ORIGIN_GENERATED.
+
+
The value in the AuthorizationList.purpose field is equal to KM_PURPOSE_SIGN.
Android Key Attestation attestation certificate's android key attestation certificate extension
+data is identified by the OID 1.3.6.1.4.1.11129.2.1.17, and its schema is defined in the Android developer documentation.
+
8.5. Android SafetyNet Attestation Statement Format
+
When the authenticator is a platform authenticator on certain Android platforms, the attestation
+statement may be based on the SafetyNet API. In
+this case the authenticator data is completely controlled by the caller of the SafetyNet API (typically an application
+running on the Android platform) and the attestation statement provides some statements about the health of the platform
+and the identity of the calling application
+(see SafetyNet Documentation for more details).
Concatenate authenticatorData and clientDataHash, perform SHA-256 hash of the concatenated string, and
+let the result of the hash form attToBeSigned.
+
Request a SafetyNet attestation, providing attToBeSigned as the nonce value. Set response to the result, and ver to
+the version of Google Play Services running in the authenticator.
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract the
+contained fields.
+
+
Verify that response is a valid SafetyNet response of version ver by following the steps indicated by the SafetyNet online documentation.
+As of this writing, there is only one format of the SafetyNet response and ver is reserved for future use.
+
+
Verify that the nonce attribute in the payload of response is identical to the Base64 encoding of the SHA-256 hash of the concatenation of authenticatorData and clientDataHash.
+
+
Verify that the SafetyNet response actually came from the SafetyNet service by following the steps in the SafetyNet online documentation.
Generate a Registration Response Message as specified in [FIDO-U2F-Message-Formats]Section 4.3, with the application parameter set to the
+SHA-256 hash of the RP ID that the given credential is scoped to, the challenge parameter set to clientDataHash, and the key handle
+parameter set to the credential ID of the given credential. Set the raw signature part of this Registration Response Message (i.e., without the user public key,
+key handle, and attestation certificates) as sig and set the attestation certificates of
+the attestation public key as x5c.
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract the
+contained fields.
+
+
Check that x5c has exactly one element and let attCert be that element. Let certificate public key be the public key
+conveyed by attCert. If certificate public key is not an Elliptic Curve (EC) public
+key over the P-256 curve, terminate this algorithm and return an appropriate error.
+
+
Extract the claimed rpIdHash from authenticatorData, and the claimed credentialId and credentialPublicKey from authenticatorData.attestedCredentialData.
Let x be the value corresponding to the "-2" key (representing x coordinate) in credentialPublicKey, and confirm its
+size to be of 32 bytes.
+If size differs or "-2" key is not found, terminate this algorithm and return an appropriate error.
+
+
Let y be the value corresponding to the "-3" key (representing y coordinate) in credentialPublicKey, and confirm its
+size to be of 32 bytes.
+If size differs or "-3" key is not found, terminate this algorithm and return an appropriate error.
+
+
Let publicKeyU2F be the concatenation 0x04 || x || y.
+
Note: This signifies uncompressed ECC key format.
+
+
+
Let verificationData be the concatenation of (0x00 || rpIdHash || clientDataHash || credentialId || publicKeyU2F) (see Section 4.3 of [FIDO-U2F-Message-Formats]).
+
+
Verify the sig using verificationData and the certificate public key per section 4.1.4 of [SEC1] with SHA-256 as the hash function used in step two.
+
+
Optionally, inspect x5c and consult externally provided knowledge to determine whether attStmt conveys a Basic or AttCA attestation.
credCert followed by its certificate chain, each encoded in X.509 format.
+
credCert
+
+
The credential public key certificate used for attestation, encoded in X.509 format.
+
+
Signing procedure
+
+
+
+
Let authenticatorData denote the authenticator data for the attestation, and let clientDataHash denote the hash of the serialized client data.
+
+
Concatenate authenticatorData and clientDataHash to form nonceToHash.
+
+
Perform SHA-256 hash of nonceToHash to produce nonce.
+
+
Let Apple anonymous attestation CA generate an X.509 certificate for the credential public key and include the nonce as a certificate extension with OID 1.2.840.113635.100.8.2. credCert denotes this certificate. The credCert thus serves as a proof of the attestation, and the included nonce proves the attestation is live. In addition to that, the nonce also protects the integrity of the authenticatorData and client data.
+
+
Set x5c to credCert followed by its certificate chain.
+
+
Verification procedure
+
+
Given the verification procedure inputs attStmt, authenticatorData and clientDataHash, the verification procedure is as follows:
+
+
+
Verify that attStmt is valid CBOR conforming to the syntax defined above and perform CBOR decoding on it to extract the contained fields.
+
+
Concatenate authenticatorData and clientDataHash to form nonceToHash.
+
+
Perform SHA-256 hash of nonceToHash to produce nonce.
+
+
Verify that nonce equals the value of the extension with OID 1.2.840.113635.100.8.2 in credCert.
If successful, return implementation-specific values representing attestation type Anonymization CA and attestation trust path x5c.
+
+
+
9. WebAuthn Extensions
+
The mechanism for generating public key credentials, as well as requesting and generating Authentication assertions, as
+defined in § 5 Web Authentication API, can be extended to suit particular use cases. Each case is addressed by defining a registration
+extension and/or an authentication extension.
+
Every extension is a client extension, meaning that the extension involves communication with and processing by the
+client. Client extensions define the following steps and data:
An extension can also be an authenticator extension, meaning that the extension involves communication with and
+processing by the authenticator. Authenticator extensions define the following steps and data:
All WebAuthn Extensions are OPTIONAL for both clients and authenticators. Thus, any extensions requested by a Relying Party MAY be
+ignored by the client browser or OS and not passed to the authenticator at all, or they MAY be ignored by the authenticator.
+Ignoring an extension is never considered a failure in WebAuthn API processing, so when Relying Parties include extensions with any
+API calls, they MUST be prepared to handle cases where some or all of those extensions are ignored.
+
Clients wishing to support the widest possible range of extensions MAY choose to pass through any extensions that they do not
+recognize to authenticators, generating the authenticator extension input by simply encoding the client extension input in CBOR. All WebAuthn Extensions MUST be defined in such a way that this implementation choice does not endanger the user’s
+security or privacy. For instance, if an extension requires client processing, it could be defined in a manner that ensures such
+a naïve pass-through will produce a semantically invalid authenticator extension input value, resulting in the extension
+being ignored by the authenticator. Since all extensions are OPTIONAL, this will not cause a functional failure in the API
+operation. Likewise, clients can choose to produce a client extension output value for an extension that it does not
+understand by encoding the authenticator extension output value into JSON, provided that the CBOR output uses only types
+present in JSON.
+
When clients choose to pass through extensions they do not recognize,
+the JavaScript values in the client extension inputs are converted to CBOR values in the authenticator extension inputs.
+When the JavaScript value is an %ArrayBuffer%, it is converted to a CBOR byte array.
+When the JavaScript value is a non-integer number, it is converted to a 64-bit CBOR floating point number.
+Otherwise, when the JavaScript type corresponds to a JSON type, the conversion is done
+using the rules defined in Section 6.2 of [RFC8949] (Converting from JSON to CBOR),
+but operating on inputs of JavaScript type values rather than inputs of JSON type values.
+Once these conversions are done,
+canonicalization of the resulting CBOR MUST be performed using the CTAP2 canonical CBOR encoding form.
+
Note that the JavaScript numeric conversion rules have the consequence that
+when a client passes through an extension it does not recognize,
+if the extension uses floating point values, authenticators need to be prepared to receive those values as CBOR integers,
+should the authenticator want the extension to always work without actual client support for it.
+This will happen when the floating point values used happen to be integers.
+
Likewise, when clients receive outputs from extensions they have passed through that they do not recognize,
+the CBOR values in the authenticator extension outputs are converted to JavaScript values in the client extension outputs.
+When the CBOR value is a byte string, it is converted to a JavaScript %ArrayBuffer% (rather than a base64url-encoded string).
+Otherwise, when the CBOR type corresponds to a JSON type, the conversion is done
+using the rules defined in Section 6.1 of [RFC8949] (Converting from CBOR to JSON),
+but producing outputs of JavaScript type values rather than outputs of JSON type values.
+
Note that some clients may choose to implement this pass-through capability under a feature flag.
+Supporting this capability can facilitate innovation, allowing authenticators to experiment with new extensions
+and Relying Parties to use them before there is explicit support for them in clients.
Extensions are identified by a string, called an extension identifier, chosen by the extension author.
+
Extension identifiers SHOULD be registered in the
+IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
+All registered extension identifiers are unique amongst themselves as a matter of course.
+
Unregistered extension identifiers SHOULD aim to be globally unique, e.g., by including the defining entity such as myCompany_extension.
+
All extension identifiers MUST be a maximum of 32 octets in length and MUST consist only of printable USASCII characters,
+excluding backslash and doublequote, i.e., VCHAR as defined in [RFC5234] but without %x22 and %x5c. Implementations MUST
+match WebAuthn extension identifiers in a case-sensitive fashion.
+
Extensions that may exist in multiple versions should take care to include a version in their identifier. In effect, different
+versions are thus treated as different extensions, e.g., myCompany_extension_01
+
§ 10 Defined Extensions defines an additional set of extensions and their identifiers.
+See the IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809] for an up-to-date list of registered WebAuthn Extension Identifiers.
Any client extension that is processed by the client MUST return a client extension output value so that the WebAuthn Relying Party knows that the extension was honored by the client. Similarly, any extension that requires authenticator processing MUST return
+an authenticator extension output to let the Relying Party know that the extension was honored by the authenticator. If an
+extension does not otherwise require any result values, it SHOULD be defined as returning a JSON Boolean client extension
+output result, set to true to signify that the extension was understood and processed. Likewise, any authenticator
+extension that does not otherwise require any result values MUST return a value and SHOULD return a CBOR Boolean authenticator extension output result, set to true to signify that the extension was understood and processed.
+
9.3. Extending Request Parameters
+
An extension defines one or two request arguments. The client extension input,
+which is a value that can be encoded in JSON, is passed from the WebAuthn Relying Party to the client
+in the get() or create() call,
+while the CBOR authenticator extension input is
+passed from the client to the authenticator for authenticator extensions during the processing of these calls.
Note: Other documents have specified extensions where the extension input does not always use the extension identifier as the entry key.
+New extensions SHOULD follow the above convention.
+
var assertionPromise = navigator.credentials.get({
+ publicKey:{
+ // Other members omitted for brevity
+ extensions:{
+ // An "entry key" identifying the "webauthnExample_foobar" extension,
+ // whose value is a map with two input parameters:
+ "webauthnExample_foobar":{
+ foo:42,
+ bar:"barfoo"
+ }
+ }
+ }
+});
+
+
Extension definitions MUST specify the valid values for their client extension input. Clients SHOULD ignore extensions with
+an invalid client extension input. If an extension does not require any parameters from the Relying Party, it SHOULD be defined
+as taking a Boolean client argument, set to true to signify that the extension is requested by the Relying Party.
Note: Extensions should aim to define authenticator arguments that are as small as possible. Some authenticators communicate
+ over low-bandwidth links such as Bluetooth Low-Energy or NFC.
+
9.4. Client Extension Processing
+
Extensions MAY define additional processing requirements on the client during the creation of credentials or the
+generation of an assertion. The client extension input for the extension is used as an input to this client processing.
+For each supported client extension, the client adds an entry to the clientExtensionsmap with the extension identifier as the key, and the extension’s client extension input as the value.
This section defines an additional set of extensions to be registered in the
+IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
+These MAY be implemented by user agents targeting broad interoperability.
+
10.1. FIDO AppID Extension (appid)
+
This extension allows WebAuthn Relying Parties that have previously registered a
+credential using the legacy FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI] to request an assertion. The
+FIDO APIs use an alternative identifier for Relying Parties called an AppID[FIDO-APPID], and any credentials created using those APIs will be scoped to
+that identifier. Without this extension, they would need to be re-registered in
+order to be scoped to an RP ID.
+
In addition to setting the appid extension input,
+using this extension requires some additional processing by the Relying Party in order to allow users to authenticate using their registered U2F credentials:
+
+
+
List the desired U2F credentials in the allowCredentials option
+ of the get() method:
Set the id members to the respective U2F key handles of the desired credentials. Note that U2F key handles commonly use base64url encoding but must be decoded to their binary form when used in id.
+
+
allowCredentials MAY contain a mixture
+ of both WebAuthn credential IDs and U2F key handles;
+ stating the appid via this extension
+ does not prevent the user from using a WebAuthn-registered credential
+ scoped to the RP ID stated in rpId.
This extension does not allow FIDO-compatible credentials to be created. Thus,
+credentials created with WebAuthn are not backwards compatible with the FIDO
+JavaScript APIs.
+
Note:appid should be set to the AppID
+that the Relying Partypreviously used in the legacy FIDO APIs.
+This might not be the same as the result of translating the Relying Party's WebAuthn RP ID to the AppID format,
+e.g., the previously used AppID may have been "https://accounts.example.com"
+but the currently used RP ID might be "example.com".
When building allowCredentialDescriptorList,
+if a U2F authenticator indicates that a credential is inapplicable (i.e. by
+returning SW_WRONG_DATA) then the client MUST retry with the U2F application
+parameter set to the SHA-256 hash of appId. If this results in an applicable
+credential, the client MUST include the credential in allowCredentialDescriptorList. The value of appId then replaces the rpId parameter of authenticatorGetAssertion.
+
+
Let output be the Boolean value false.
+
+
When creating assertionCreationData,
+if the assertion was created by a U2F authenticator with the U2F application parameter set to the SHA-256 hash of appId instead of the SHA-256 hash of the RP ID, set output to true.
This registration extension allows WebAuthn Relying Parties to exclude authenticators that contain specified credentials that were created with the legacy FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI].
+
During a transition from the FIDO U2F JavaScript API, a Relying Party may have a population of users with legacy credentials already registered. The appid extension allows the sign-in flow to be transitioned smoothly but, when transitioning the registration flow, the excludeCredentials field will not be effective in excluding authenticators with legacy credentials because its contents are taken to be WebAuthn credentials. This extension directs client platforms to consider the contents of excludeCredentials as both WebAuthn and legacy FIDO credentials. Note that U2F key handles commonly use base64url encoding but must be decoded to their binary form when used in excludeCredentials.
Check whether C was created using U2F on authenticator by sending a U2F_AUTHENTICATE message to authenticator whose "five parts" are set to the following values:
If authenticator responds with message:error:test-of-user-presence-required (i.e., success):
+cease normal processing of this authenticator and indicate in a platform-specific manner
+that the authenticator is inapplicable. For example, this could be in the form of UI, or
+could involve requesting user consent from authenticator and, upon receipt, treating
+it as if the authenticator had returned InvalidStateError. Requesting user consent can be accomplished by sending another U2F_AUTHENTICATE message to authenticator as
+above except for setting control byte to 0x03 ("enforce-user-presence-and-sign"),
+and ignoring the response.
+
+
+
Continue with normal processing.
+
+
+
Client extension output
+
+
Returns the value true to indicate to the Relying Party that the extension was acted upon.
The Boolean value true, encoded in CBOR (major type 7, value 21).
+
$$extensionInput //= (
+ uvm: true,
+ )
+
+
Authenticator extension processing
+
+
The authenticator sets the authenticator extension output to be one or more user verification methods indicating the method(s) used
+by the user to authorize the operation, as defined below. This extension can be added to attestation objects and assertions.
+
Authenticator extension output
+
+
Authenticators can report up to 3 different user verification methods (factors) used in a single authentication instance,
+using the CBOR syntax defined below:
If >3 factors can be used in an authentication instance the authenticator vendor MUST select the 3 factors it believes
+will be most relevant to the Server to include in the UVM.
+
Example for authenticator data containing one UVM extension for a multi-factor authentication instance where 2 factors
+were used:
+
... -- RP ID hash (32 bytes)
+81 -- UP and ED set
+00 00 00 01 -- (initial) signature counter
+... -- all public key alg etc.
+A1 -- extension: CBOR map of one element
+ 63 -- Key 1: CBOR text string of 3 bytes
+ 75 76 6d -- "uvm" [=UTF-8 encoded=] string
+ 82 -- Value 1: CBOR array of length 2 indicating two factor usage
+ 83 -- Item 1: CBOR array of length 3
+ 02 -- Subitem 1: CBOR integer for User Verification Method Fingerprint
+ 04 -- Subitem 2: CBOR short for Key Protection Type TEE
+ 02 -- Subitem 3: CBOR short for Matcher Protection Type TEE
+ 83 -- Item 2: CBOR array of length 3
+ 04 -- Subitem 1: CBOR integer for User Verification Method Passcode
+ 01 -- Subitem 2: CBOR short for Key Protection Type Software
+ 01 -- Subitem 3: CBOR short for Matcher Protection Type Software
+
This clientregistration extension and authentication extension allows a Relying Party to store opaque data associated with a credential. Since authenticators can only store small amounts of data, and most Relying Parties are online services that can store arbitrary amounts of state for a user, this is only useful in specific cases. For example, the Relying Party might wish to issue certificates rather than run a centralised authentication service.
+
Note:Relying Parties can assume that the opaque data will be compressed when being written to a space-limited device and so need not compress it themselves.
+
Since a certificate system needs to sign over the public key of the credential, and that public key is only available after creation, this extension does not add an ability to write blobs in the registration context. However, Relying Parties SHOULD use the registration extension when creating the credential if they wish to later use the authentication extension.
+
Since certificates are sizable relative to the storage capabilities of typical authenticators, user agents SHOULD consider what indications and confirmations are suitable to best guide the user in allocating this limited resource and prevent abuse.
+
Note: In order to interoperate, user agents storing large blobs on authenticators using [FIDO-CTAP] are expected to use the provisions detailed in that specification for storing large, per-credential blobs.
A boolean that indicates that the Relying Party would like to fetch the previously-written blob associated with the asserted credential. Only valid during authentication.
Note: This is in anticipation of an authenticator capable of storing large blobs becoming available. It occurs during extension processing in Step 11 of [[Create]](). The AuthenticationExtensionsLargeBlobOutputs will be abandoned if no satisfactory authenticator becomes available.
If any authenticator indicates success (in [[DiscoverFromExternalSource]]()), attempt to read any largeBlob data associated with the asserted credential.
A boolean that indicates that the contents of write were successfully stored on the authenticator, associated with the specified credential.
+
+
+
Authenticator extension processing
+
+
This extension directs the user-agent to cause the large blob to be stored on, or retrieved from, the authenticator. It thus does not specify any direct authenticator interaction for Relying Parties.
If value is true and the endpoint node WebAuthn WebDriver implementation does not support the authenticator extension identified by the key,
+the match is unsuccessful.
An non-null string made using up to 48 characters from the unreserved production defined in Appendix A of [RFC3986] that uniquely identifies the Virtual Authenticator.
WebAuthn Attestation Statement Format Identifier: packed
+
+
Description: The "packed" attestation statement format is a WebAuthn-optimized format for attestation. It uses a very
+compact but still extensible encoding method. This format is implementable by authenticators with limited resources (e.g.,
+secure elements).
WebAuthn Attestation Statement Format Identifier: tpm
+
+
Description: The TPM attestation statement format returns an attestation statement in the same format as the packed
+attestation statement format, although the rawData and signature fields are computed differently.
WebAuthn Attestation Statement Format Identifier: none
+
+
Description: Used to replace any authenticator-provided attestation statement when a WebAuthn Relying Party indicates it does not wish to receive attestation information.
Description: This registration extension allows WebAuthn Relying Parties to exclude authenticators that contain specified credentials that were created with the legacy FIDO U2F JavaScript API [FIDOU2FJavaScriptAPI].
At this time, this specification does not feature detailed security considerations. However, the [FIDOSecRef] document provides a security analysis which is overall applicable to this specification.
+Also, the [FIDOAuthnrSecReqs] document suite provides useful information about authenticator security characteristics.
+
The below subsections comprise the current Web Authentication-specific security considerations.
+They are divided by audience;
+general security considerations are direct subsections of this section,
+while security considerations specifically for authenticator, client and Relying Party implementers
+are grouped into respective subsections.
13.2. Physical Proximity between Client and Authenticator
+
In the WebAuthn authenticator model, it is generally assumed that roaming authenticators are physically close to, and communicate directly with, the client.
+This arrangement has some important advantages.
+
The promise of physical proximity between client and authenticator is a key strength of a something you haveauthentication factor.
+For example, if a roaming authenticator can communicate only via USB or Bluetooth,
+the limited range of these transports ensures that any malicious actor
+must physically be within that range in order to interact with the authenticator.
+This is not necessarily true of an authenticator that can be invoked remotely —
+even if the authenticator verifies user presence,
+users can be tricked into authorizing remotely initiated malicious requests.
If designing a solution where the authenticator does not need to be physically close to the client,
+or where client and authenticator do not communicate directly,
+designers SHOULD consider how this affects the enforcement of scope restrictions
+and the strength of the authenticator as a something you have authentication factor.
A 3-tier hierarchy for attestation certificates is RECOMMENDED (i.e., Attestation Root, Attestation Issuing CA, Attestation
+Certificate). It is also RECOMMENDED that for each WebAuthn Authenticator device line (i.e., model), a separate issuing CA is
+used to help facilitate isolating problems with a specific version of an authenticator model.
+
If the attestation root certificate is not dedicated to a single WebAuthn Authenticator device line (i.e., AAGUID), the AAGUID
+SHOULD be specified in the attestation certificate itself, so that it can be verified against the authenticator data.
+
13.3.2. Attestation Certificate and Attestation Certificate CA Compromise
The Relying Party can automatically support multiple types of user verification - for example PIN, biometrics and/or future
+methods - with little or no code change, and can let each user decide which they prefer to use via their choice of authenticator.
+
+
The Relying Party does not need to store additional secrets in order to gain the above benefits.
13.4.2. Visibility Considerations for Embedded Usage
+
Simplistic use of WebAuthn in an embedded context, e.g., within iframes as described in § 5.10 Using Web Authentication within iframe elements, may make users vulnerable to UI Redressing attacks, also known as "Clickjacking". This is where an attacker overlays their own UI on top of a Relying Party's intended UI and attempts to trick the user into performing unintended actions with the Relying Party. For example, using these techniques, an attacker might be able to trick users into purchasing items, transferring money, etc.
+
Even though WebAuthn-specific UI is typically handled by the client platform and thus is not vulnerable to UI Redressing, it is likely important for an Relying Party having embedded WebAuthn-wielding content to ensure that their content’s UI is visible to the user. An emerging means to do so is by observing the status of the experimental Intersection Observer v2's isVisible attribute. For example, the Relying Party's script running in the embedded context could pre-emptively load itself in a popup window if it detects isVisble being set to false, thus side-stepping any occlusion of their content.
+
13.4.3. Cryptographic Challenges
+
As a cryptographic protocol, Web Authentication is dependent upon randomized challenges
+to avoid replay attacks. Therefore, the values of both PublicKeyCredentialCreationOptions.challenge and PublicKeyCredentialRequestOptions.challenge MUST be randomly generated
+by Relying Parties in an environment they trust (e.g., on the server-side), and the
+returned challenge value in the client’s
+response MUST match what was generated. This SHOULD be done in a fashion that does not rely
+upon a client’s behavior, e.g., the Relying Party SHOULD store the challenge temporarily
+until the operation is complete. Tolerating a mismatch will compromise the security
+of the protocol.
+
In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD
+therefore be at least 16 bytes long.
Such an attack would potentially be detectable; since the Relying Party has registered the attacker’s credential public key rather
+than the user’s, the attacker must tamper with all subsequent authentication ceremonies with that Relying Party: unscathed
+ceremonies will fail, potentially revealing the attack.
If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the Relying Party's policy
+requires rejecting the registration/authentication request in these situations, then it is RECOMMENDED that the Relying Party also
+un-registers (or marks with a trust level equivalent to "self attestation") public key credentials that were registered
+after the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus RECOMMENDED
+that Relying Parties remember intermediate attestation CA certificates during registration in order to un-register
+related public key credentials if the registration was performed after revocation of such certificates.
In this case the allowCredentials argument risks leaking information
+about which user accounts have WebAuthn credentials registered and which do not,
+which may be a signal of account protection strength.
+For example, say an attacker can initiate an authentication ceremony by providing only a username,
+and the Relying Party responds with an non-empty allowCredentials for some users,
+and with failure or a password challenge for other users.
+The attacker can then conclude that the latter user accounts
+likely do not require a WebAuthn assertion for successful authentication,
+and thus focus an attack on those likely weaker accounts.
This section is divided by audience;
+general privacy considerations are direct subsections of this section,
+while privacy considerations specifically for authenticator, client and Relying Party implementers
+are grouped into respective subsections.
+
14.1. De-anonymization Prevention Measures
+
This section is not normative.
+
Many aspects of the design of the Web Authentication API are motivated by privacy concerns. The main concern considered in
+this specification is the protection of the user’s personal identity, i.e., the identification of a human being or a correlation
+of separate identities as belonging to the same human being. Although the Web Authentication API does not use or provide any
+form of global identity, the following kinds of potentially correlatable identifiers are used:
These identities are obviously used by each Relying Party to identify a user in their system. They are also visible to the client in the communication with the authenticator.
+
+
The user’s biometric characteristic(s), e.g., fingerprints or facial recognition data [ISOBiometricVocabulary].
Some of the above information is necessarily shared with the Relying Party. The following sections describe the measures taken to
+prevent malicious Relying Parties from using it to discover a user’s personal identity.
Attestation certificates and attestation key pairs can be used to track users
+or link various online identities of the same user together.
+This can be mitigated in several ways, including:
[UAFProtocol] requires that at least 100,000 authenticator devices share the same attestation certificate in order to produce
+sufficiently large groups. This may serve as guidance about suitable batch sizes.
Note: In various places outside this specification, the term "Privacy CA" is used to refer to what is termed here
+ as an Anonymization CA. Because the Trusted Computing Group (TCG) also used the term "Privacy CA" to refer to what
+ the TCG now refers to as an Attestation CA (ACA) [TCG-CMCProfile-AIKCertEnroll], we are using the term Anonymization CA here to try to mitigate
+ confusion in the specific context of this specification.
+
+
14.4.2. Privacy of personally identifying information Stored in Authenticators
+
Authenticators MAY provide additional information to clients outside what’s defined by this specification, e.g.,
+to enable the client to provide a rich UI with which the user can pick which credential to use for an authentication
+ceremony. If an authenticator chooses to do so, it SHOULD NOT expose personally identifying information unless successful user verification has been
+performed. If the authenticator supports user verification with more than one concurrently enrolled user, the authenticator SHOULD NOT expose personally identifying information of users other than the currently verified user. Consequently, an authenticator that is not capable of user verification SHOULD NOT store personally identifying information.
These recommendations serve to prevent an adversary with physical access to an authenticator from extracting personally identifying information about the authenticator's enrolled user(s).
If the above cases are distinguishable, information is leaked by which a malicious Relying Party could identify the user by probing for
+which credentials are available. For example, one such information leak is if the client returns a
+failure response as soon as an excluded authenticator becomes available. In this case - especially if the excluded authenticator is a platform authenticator - the Relying Party could detect that the ceremony was canceled before the
+timeout and before the user could feasibly have canceled it manually, and thus conclude that at least one of the credentials listed in the excludeCredentials parameter is available to the user.
+
The above is not a concern, however, if the user has consented to create a new credential before a
+distinguishable error is returned, because in this case the user has confirmed intent to share the information that would be
+leaked.
A named credential is available, but the user does not consent to use it.
+
+
If the above cases are distinguishable, information is leaked by which a malicious Relying Party could identify the user by probing
+for which credentials are available. For example, one such information leak is if the client returns a
+failure response as soon as the user denies consent to proceed with an authentication ceremony. In this
+case the Relying Party could detect that the ceremony was canceled by the user and not the timeout, and thus conclude that at least
+one of the credentials listed in the allowCredentials parameter is
+available to the user.
Since the user handle is not considered personally identifying information in § 14.4.2 Privacy of personally identifying information Stored in Authenticators, the Relying Party MUST NOT include personally identifying information, e.g., e-mail
+addresses or usernames, in the user handle. This includes hash values of personally identifying information, unless the hash
+function is salted with salt values private to the Relying Party, since hashing does not prevent probing for guessable input
+values. It is RECOMMENDED to let the user handle be 64 random bytes, and store this value in the user’s account.
+
14.6.2. Username Enumeration
+
While initiating a registration or authentication ceremony, there is a risk that the WebAuthn Relying Party might leak sensitive
+information about its registered users. For example, if a Relying Party uses e-mail addresses as usernames and an attacker attempts to
+initiate an authenticationceremony for "alex.mueller@example.com" and the Relying Party responds with a failure, but then
+successfully initiates an authentication ceremony for "j.doe@example.com", then the attacker can conclude that "j.doe@example.com"
+is registered and "alex.mueller@example.com" is not. The Relying Party has thus leaked the possibly sensitive information that
+"j.doe@example.com" has an account at this Relying Party.
+
The following is a non-normative, non-exhaustive list of measures the Relying Party may implement to mitigate or prevent information
+leakage due to such an attack:
When initiating a registration ceremony, disallow registration of usernames that are syntactically valid e-mail
+addresses.
+
Note: The motivation for this suggestion is that in this case the Relying Party probably has no choice but to fail the registration ceremony if the user attempts to register a username that is already registered, and an information
+leak might therefore be unavoidable. By disallowing e-mail addresses as usernames, the impact of the leakage can be
+mitigated since it will be less likely that a user has the same username at this Relying Party as at other Relying Parties.
+
+
+
If the Relying Party uses e-mail addresses to identify users:
+
+
+
When initiating a registration ceremony, interrupt the user interaction after the e-mail address is supplied and
+send a message to this address, containing an unpredictable one-time code and instructions for how to use it to
+proceed with the ceremony. Display the same message to the user in the web interface regardless of the contents of the
+sent e-mail and whether or not this e-mail address was already registered.
+
Note: This suggestion can be similarly adapted for other externally meaningful identifiers, for example, national ID
+numbers or credit card numbers — if they provide similar out-of-band contact information, for example,
+conventional postal address.
Note: The username may be "provided" in various Relying Party-specific fashions: login form, session cookie, etc.
+
Note: If returned imaginary values noticeably differ from actual ones, clever attackers may be able to discern them and
+ thus be able to test for existence of actual accounts. Examples of noticeably different values include if the values
+ are always the same for all username inputs, or are different in repeated attempts with the same username input. The allowCredentials member could therefore be populated with pseudo-random values
+ derived deterministically from the username, for example.
+
+
When verifying an AuthenticatorAssertionResponse response from the authenticator, make it indistinguishable whether
+ verification failed because the signature is invalid or because no such user or credential is registered.
+
+
Perform a multi-step authentication ceremony, e.g., beginning with supplying username and password or a session cookie,
+before initiating the WebAuthn ceremony as a subsequent step.
+This moves the username enumeration problem from the WebAuthn step
+to the preceding authentication step, where it may be easier to solve.
In this case the allowCredentials argument risks leaking personally identifying information,
+since it exposes the user’s credential IDs to an unauthenticated caller. Credential IDs are designed to not be correlatable between Relying Parties,
+but the length of a credential ID might be a hint as to what type of authenticator created it.
+It is likely that a user will use the same username and set of authenticators for several Relying Parties,
+so the number of credential IDs in allowCredentials and their lengths
+might serve as a global correlation handle to de-anonymize the user.
+Knowing a user’s credential IDs also makes it possible to confirm guesses about the user’s identity
+given only momentary physical access to one of the user’s authenticators.
+
In order to prevent such information leakage, the Relying Party could for example:
+
+
+
Perform a separate authentication step,
+such as username and password authentication or session cookie authentication,
+before initiating the WebAuthn authentication ceremony and exposing the user’s credential IDs.
User verification-capable authenticators, whether roaming or platform, should offer users more than one user verification method. For example, both fingerprint sensing and PIN entry. This allows for fallback to other user verification means if the selected one is not working for some reason. Note that in the case of roaming authenticators, the authenticator and platform might work together to provide a user verification method such as PIN entry [FIDO-CTAP].
+
Relying Parties, at registration time, SHOULD provide affordances for users to complete future authorization gestures correctly. This could involve naming the authenticator, choosing a picture to associate with the device, or entering freeform text instructions (e.g., as a reminder-to-self).
The WHATWG HTML WG is discussing whether to provide a hook when a browsing context gains or
+ loses focuses. If a hook is provided, the above paragraph will be updated to include the hook.
+ See WHATWG HTML WG Issue #2711 for more details. ↵
+ 
+ 
+ 
+ 
+ 
+