diff --git a/index.html b/index.html index c54977921..6b7a73ebe 100644 --- a/index.html +++ b/index.html @@ -4,9 +4,9 @@ Web Authentication: An API for accessing Public Key Credentials - Level - + - + - - + - + - - - - - + -

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

-

Editor’s Draft,

+

Editor’s Draft,

More details about this document
@@ -569,7 +931,7 @@

Web Authentication:
An API for accessing Public Key Credentials
Level
Feedback:
GitHub
Editors: -
(Microsoft) +
(independent)
(Microsoft)
(Yubico)
Former Editors: @@ -590,7 +952,7 @@

Web Authentication:
An API for accessing Public Key Credentials
Level
Giridhar Mandyam (Qualcomm)
Matthew Miller (Cisco)
Nina Satragno (Google) -
Nick Steele (Gemini) +
Nick Steele (1Password)
Jiewen Tan (Apple)
Shane Weeden (IBM)
Mike West (Google) @@ -601,7 +963,7 @@

Web Authentication:
An API for accessing Public Key Credentials
Level

-

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

+

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

@@ -632,7 +994,7 @@

Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

-

This document is governed by the 2 November 2021 W3C Process Document.

+

This document is governed by the 12 June 2023 W3C Process Document.

@@ -698,8 +1060,9 @@

Table of Contents

  • 5.1.5 Store an Existing Credential - PublicKeyCredential’s [[Store]](credential, sameOriginWithAncestors) Method
  • 5.1.6 Preventing Silent Access to an Existing Credential - PublicKeyCredential’s [[preventSilentAccess]](credential, sameOriginWithAncestors) Method
  • 5.1.7 Availability of User-Verifying Platform Authenticator - PublicKeyCredential’s isUserVerifyingPlatformAuthenticatorAvailable() Method -
  • 5.1.8 Deserialize Registration ceremony options - PublicKeyCredential’s parseCreationOptionsFromJSON() Method -
  • 5.1.9 Deserialize Authentication ceremony options - PublicKeyCredential’s parseRequestOptionsFromJSON() Methods +
  • 5.1.8 Availability of a passkey platform authenticator - PublicKeyCredential’s isPasskeyPlatformAuthenticatorAvailable() Method +
  • 5.1.9 Deserialize Registration ceremony options - PublicKeyCredential’s parseCreationOptionsFromJSON() Method +
  • 5.1.10 Deserialize Authentication ceremony options - PublicKeyCredential’s parseRequestOptionsFromJSON() Methods
  • 5.2 Authenticator Responses (interface AuthenticatorResponse) @@ -748,6 +1111,7 @@

    Table of Contents

  • 5.8.4 Authenticator Transport Enumeration (enum AuthenticatorTransport)
  • 5.8.5 Cryptographic Algorithm Identifier (typedef COSEAlgorithmIdentifier)
  • 5.8.6 User Verification Requirement Enumeration (enum UserVerificationRequirement) +
  • 5.8.7 User-agent Hints Enumeration (enum PublicKeyCredentialHints)
  • 5.9 Permissions Policy integration
  • 5.10 Using Web Authentication within iframe elements @@ -920,6 +1284,7 @@

    Table of Contents

  • 13.4.6 Credential Loss and Key Mobility
  • 13.4.7 Unprotected account detection
  • 13.4.8 Code injection attacks +
  • 13.4.9 Validating the origin of a credential
  • @@ -1584,10 +1949,11 @@

    Authenticator
    WebAuthn Authenticator
    -

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

    +

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

    A WebAuthn Authenticator could be a roaming authenticator, a dedicated hardware subsystem integrated into the client device, -or a software component of the client or client device.

    +or a software component of the client or client device. A WebAuthn Authenticator is not necessarily confined to operating in +a local context, and can generate or store a credential key pair in a server outside of client-side hardware.

    In general, an authenticator is assumed to have only one user. If multiple natural persons share access to an authenticator, they are considered to represent the same user in the context of that authenticator. @@ -1626,7 +1992,7 @@

    created on an authenticator"

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

    This may also be expressed as "the managing authenticator contains the bound credential", or "the bound credential was created on its managing authenticator". @@ -1669,6 +2035,7 @@

    Client-side discoverable Public Key Credential Source
    Client-side discoverable Credential
    Discoverable Credential +
    Passkey
    [DEPRECATED] Resident Credential
    [DEPRECATED] Resident Key
    @@ -1684,7 +2051,7 @@

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

    +which requires that the authenticator is given both the RP ID and the credential ID but does not require client-side storage of the public key credential source.

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

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

    @@ -1712,14 +2079,14 @@

    User Public Key
    User Credential
    -

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

    -

    A credential public key is the public key portion of a credential key pair. +

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

    +

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

    -

    A credential private key is the private key portion of a credential key pair. +

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

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

    +attestation, the credential key pair is also used as the attestation key pair, see self attestation for details.

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

    Credential Properties
    @@ -1857,7 +2224,7 @@

    userHandle

    The user handle associated when this public key credential source was created. This item is -nullable.

    +nullable, however user handle MUST always be populated for discoverable credentials.

    otherUI

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

    @@ -1931,7 +2298,7 @@

    public key credential source that is only usable in an authentication ceremony when the Relying Party supplies its credential ID in navigator.credentials.get()'s allowCredentials argument. This means that the Relying Party must manage the credential’s storage and discovery, as well as be able to first identify the user in order to discover the credential IDs to supply in the navigator.credentials.get() call.

    -

    Client-side storage of the public key credential source is not required for a server-side credential. +

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

    @@ -1947,7 +2314,7 @@

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

    authorization gesture is a ceremony component often employed to indicate user consent.

    User Handle
    -

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

    -

    The main use of the user handle is to identify the user account in such authentication ceremonies, +

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

    +

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

    -

    Authenticators map pairs of RP ID and user handle to public key credential sources. -As a consequence, an authenticator will store at most one discoverable credential per user handle per Relying Party.

    +

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

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

    User Present @@ -1975,23 +2343,23 @@

    present".

    User Verification
    -

    The technical process by which an authenticator locally authorizes the invocation of the authenticatorMakeCredential and authenticatorGetAssertion operations. User verification MAY be instigated +

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

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

    +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. +and authenticator's capabilities. For example, some devices are intended to be used by a single individual, yet they may allow multiple natural persons to enroll fingerprints or know the same PIN and thus access the same user account(s) using that device.

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

    Also, for security, user verification and use of credential private keys must all occur within the logical security boundary defining the authenticator.

    +

    Also, for security, user verification and use of credential private keys must all occur within the logical security boundary defining the authenticator.

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

    User Verified @@ -2000,7 +2368,7 @@

    5. Web Authentication API

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

    @@ -2027,10 +2395,10 @@

    5. is created as well as in all assertions produced by WebAuthn credentials.

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

    -

    The client facilitates these security measures by providing the Relying Party's origin and RP ID to the authenticator for +

    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.

    @@ -2059,7 +2427,7 @@

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

    response, of type AuthenticatorResponse, readonly
    -

    This attribute contains the authenticator's response to the client’s request to either create a public key +

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

    @@ -2069,9 +2437,9 @@

    AuthenticatorAttachment. Relying Parties SHOULD treat unknown values as if the value were null.

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

    An authenticator’s attachment modality could change over time. +

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

    getClientExtensionResults() @@ -2094,6 +2462,8 @@

    [IANA-WebAuthn-Registries] but not defined in § 9 WebAuthn Extensions.

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

    +

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

    +

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

    typedef DOMString Base64URLString;
 typedef (RegistrationResponseJSON or AuthenticationResponseJSON) PublicKeyCredentialJSON;
@@ -2109,13 +2479,24 @@ 
    dictionary AuthenticatorAttestationResponseJSON {
     required Base64URLString clientDataJSON;
-    required Base64URLString attestationObject;
+    required Base64URLString authenticatorData;
     required sequence<DOMString> transports;
+    // The publicKey field will be missing if pubKeyCredParams was used to
+    // negotiate a public-key algorithm that the user agent doesn’t
+    // understand. (See section “Easily accessing credential data” for a
+    // list of which algorithms user agents must support.) If using such an
+    // algorithm then the public key must be parsed directly from
+    // attestationObject or authenticatorData.
+    Base64URLString publicKey;
+    required long long publicKeyAlgorithm;
+    // This value contains copies of some of the fields above. See
+    // section “Easily accessing credential data”.
+    required Base64URLString attestationObject;
 };
 
 dictionary AuthenticationResponseJSON {
-    required Base64URLString id;
-    required Base64URLString rawId;
+    required Base64URLString id;
+    required Base64URLString rawId;
     required AuthenticatorAssertionResponseJSON response;
     DOMString authenticatorAttachment;
     required AuthenticationExtensionsClientOutputsJSON clientExtensionResults;
@@ -2123,10 +2504,11 @@ 
    dictionary AuthenticatorAssertionResponseJSON {
-    required Base64URLString clientDataJSON;
-    required Base64URLString authenticatorData;
-    required Base64URLString signature;
-    Base64URLString userHandle;
+    required Base64URLString clientDataJSON;
+    required Base64URLString authenticatorData;
+    required Base64URLString signature;
+    Base64URLString userHandle;
+    Base64URLString attestationObject;
 };
 
 dictionary AuthenticationExtensionsClientOutputsJSON {
@@ -2148,14 +2530,14 @@ 
    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.
+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.
    
     
    [[clientExtensionsResults]]
     
    
      
    This internal slot contains the results of processing client extensions requested by the Relying Party upon the Relying Party's invocation of either navigator.credentials.create() or navigator.credentials.get().
    
    
-   
    PublicKeyCredential's interface object inherits Credential's implementation of [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), and defines its own
-implementation of [[Create]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), and [[Store]](credential, sameOriginWithAncestors).
    
+   
    PublicKeyCredential's interface object inherits Credential's implementation of [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors), and defines its own
+implementation of each of [[Create]](origin, options, sameOriginWithAncestors), [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors), and [[Store]](credential, sameOriginWithAncestors).
    
    
    5.1.1. CredentialCreationOptions Dictionary Extension
    
    
    To support registration via navigator.credentials.create(), this document extends
 the CredentialCreationOptions dictionary as follows:
    
@@ -2172,7 +2554,7 @@ 
    5.1.3. Create a New Credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) Method
    
    
    
      PublicKeyCredential's interface object's implementation of the [[Create]](origin,
-options, sameOriginWithAncestors) internal method [CREDENTIAL-MANAGEMENT-1] allows WebAuthn Relying Party scripts to call navigator.credentials.create() to request the creation of a new public key credential source, bound to an authenticator. This navigator.credentials.create() operation can be aborted by leveraging the AbortController;
+options, sameOriginWithAncestors) internal method [CREDENTIAL-MANAGEMENT-1] allows WebAuthn Relying Party scripts to call navigator.credentials.create() to request the creation of a new public key credential source, bound to an authenticator. This navigator.credentials.create() operation can be aborted by leveraging the AbortController;
 see DOM § 3.3 Using AbortController and AbortSignal objects in APIs for detailed instructions. 
     
    This internal method accepts three arguments:
    
     
    
@@ -2327,9 +2709,11 @@ 
    
       
    Let issuedRequests be a new ordered set.
    
      
  • 
-      
    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)
+      
    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.
    
+     
  • 
+      
    Consider the value of hints and craft the user interface accordingly, as the user-agent sees fit.
    
      
  • 
       
    Start lifetimeTimer.
    
      
  • 
@@ -2452,7 +2836,7 @@ 
    If C.transports is not empty, and authenticator is connected over a transport not
 mentioned in C.transports, the client MAY continue.
    
             
    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.
+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.
    
            
  • 
@@ -2475,7 +2859,7 @@ 
    Remove authenticator from issuedRequests.
    
          
  • 
           
    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".
+          
    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",
@@ -2545,7 +2929,7 @@ 
    Anonymization CA).
    
              
    direct or enterprise
              
    
-              
    Convey the authenticator's AAGUID and attestation statement, unaltered, to the Relying Party.
    
+              
    Convey the authenticator's AAGUID and attestation statement, unaltered, to the Relying Party.
    
             
    • 
            
  • 
             
    Let attestationObject be a new ArrayBuffer, created using global’s %ArrayBuffer%, containing the
@@ -2576,7 +2960,7 @@ 
    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: How user agents discover transports supported by a given authenticator is outside the scope of this specification, but may include information from an attestation certificate (for example [FIDO-Transports-Ext]), metadata communicated in an authenticator protocol such as CTAP2, or special-case knowledge about a platform authenticator.
    
+                
    Note: How user agents discover transports supported by a given authenticator is outside the scope of this specification, but may include information from an attestation certificate (for example [FIDO-Transports-Ext]), metadata communicated in an authenticator protocol such as CTAP2, or special-case knowledge about a platform authenticator.
    
               
              
    [[clientExtensionsResults]]
              
    
@@ -2607,7 +2991,7 @@ 
    user mediation (roughly, this specification’s authorization gesture), and if it does not find
 exactly one of those, it then calls PublicKeyCredential.[[DiscoverFromExternalSource]]() to have
 the user select a public key credential source.
    
-   
    Since this specification requires an authorization gesture to create any assertions, the PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) internal method inherits the default behavior of Credential.[[CollectFromCredentialStore]](), of returning an empty set.
    
+   
    Since this specification requires an authorization gesture to create any assertions, the PublicKeyCredential.[[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors) internal method inherits the default behavior of Credential.[[CollectFromCredentialStore]](), of returning an empty set.
    
    
    In general, the user agent SHOULD show some UI to the user to guide them in selecting and authorizing an authenticator with which
 to complete the operation. By setting options.mediation to conditional, Relying Parties can indicate that a prominent modal UI should not be shown unless credentials are discovered. Relying Party script SHOULD first check that isConditionalMediationAvailable() returns true in order to avoid
 the possibility of causing a user-visible error to be returned if the user agent does not support conditional user mediation.
    
@@ -2722,9 +3106,13 @@ 
    origin
        
    
         
    The serialization of callerOrigin.
    
+       
    topOrigin
+       
    
+        
    The serialization of callerOrigin’s top-level origin if
+the sameOriginWithAncestors argument passed to this internal method is false, else undefined.
    
        
    crossOrigin
        
    
-        
    The inverse of the value of the sameOriginWithAncestors argument passed to this internal method.
    
+        
    The inverse of the value of the sameOriginWithAncestors argument passed to this internal method.
    
       
      
  • 
       
    Let clientDataJSON be the JSON-compatible serialization of client data constructed from collectedClientData.
    
@@ -2738,11 +3126,13 @@ 
    map.
    
      
  • 
-      
    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)
+      
    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.
    
      
  • 
-      
    Let silentlyDiscoveredCredentials be a new map whose entries are of the form: DiscoverableCredentialMetadata → authenticator.
    
+      
    Let silentlyDiscoveredCredentials be a new map whose entries are of the form: DiscoverableCredentialMetadata → authenticator.
    
+     
  • 
+      
    Consider the value of hints and craft the user interface accordingly, as the user-agent sees fit.
    
      
  • 
       
    Start lifetimeTimer.
    
      
  • 
@@ -2833,7 +3223,7 @@ 
    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".
+          
    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,
@@ -2856,17 +3246,17 @@ 
    authenticatorDataResult
            
    
-            
    whose value is the bytes of the authenticator data returned by the authenticator.
    
+            
    whose value is the bytes of the authenticator data returned by the authenticator.
    
            
    signatureResult
            
    
-            
    whose value is the bytes of the signature value returned by the authenticator.
    
+            
    whose value is the bytes of the signature value returned by the authenticator.
    
            
    userHandleResult
            
    
-            
    If the authenticator returned a user handle, set the value of userHandleResult to be the bytes of
-the returned user handle. Otherwise, set the value of userHandleResult to null.
    
+            
    If the authenticator returned a user handle, set the value of userHandleResult to be the bytes of
+the returned user handle. Otherwise, set the value of userHandleResult to null.
    
            
    assertionAttestation
            
    
-            
    If the authenticator returned an attestation, set the value of assertionAttestation to be the bytes of
+            
    If the authenticator returned an attestation, set the value of assertionAttestation to be the bytes of
 the attestation statement. Otherwise set it to null.
    
            
    clientExtensionResults
            
    
@@ -2874,6 +3264,8 @@ 
    is not empty and credentialIdFilter does not contain an item whose id's value is set to the value of credentialIdResult, continue.
    
+         
  • 
+          
    If credentialIdFilter is empty and userHandleResult is null, continue.
    
          
  • 
           
    Let constructAssertionAlg be an algorithm that takes a global object global, and whose steps are:
    
           
      
@@ -2901,8 +3293,8 @@ 
      ArrayBuffer, created using global’s %ArrayBuffer%, containing the bytes of assertionCreationData.signatureResult.
      
                
      userHandle
                
      
-                
      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.
      
+                
      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.
      
                
      attestationObject
                
      
                 
      If assertionCreationData.assertionAttestation is null, set this
@@ -2929,16 +3321,16 @@ 
      5.1.4.2. Issuing a Credential Request to an Authenticator
      
    
      This sub-algorithm of [[DiscoverFromExternalSource]]() encompasses the specific UI context-independent
-steps necessary for requesting a credential from a given authenticator, using given PublicKeyCredentialRequestOptions.
+steps necessary for requesting a credential from a given authenticator, using given PublicKeyCredentialRequestOptions.
 It is called by [[DiscoverFromExternalSource]]() from various points depending on which user mediation the present authentication ceremony is subject to (e.g.: conditional mediation).
      
    
      This algorithm accepts the following arguments:
      
    
      
     
      authenticator
     
      
-     
      A client platform-specific handle identifying an authenticator presently available on this client platform.
      
+     
      A client platform-specific handle identifying an authenticator presently available on this client platform.
      
     
      savedCredentialIds
     
      
-     
      A map containing authenticator → credential ID. This argument will be modified in this algorithm.
      
+     
      A map containing authenticator → credential ID. This argument will be modified in this algorithm.
      
     
      pkOptions
     
      
      
      This argument is a PublicKeyCredentialRequestOptions object specifying the desired attributes of the public key credential to discover.
      
@@ -3003,7 +3395,7 @@ 
       If pkOptions.allowCredentials
      
      
      
-      
      is not empty
+      
      is not empty
       
      
        
        
         
      1. 
@@ -3013,7 +3405,7 @@ 
        allowCredentials.type.
 Set allowCredentialDescriptorList to this filtered list.
        
         
      2. 
-         
        If allowCredentialDescriptorList is empty, return false.
        
+         
        If allowCredentialDescriptorList is empty, return false.
        
         
      3. 
          
        Let distinctTransports be a new ordered set.
        
         
      4. 
@@ -3021,24 +3413,24 @@ 
        here in § 6.3.3 The authenticatorGetAssertion Operation for more information).
        
         
      5. 
          
        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.
        
+         
        Note: This will aggregate only distinct values of transports (for this authenticator) in distinctTransports due to the properties of ordered sets.
        
         
      6. 
          
        If distinctTransports
        
          
        
-          
        is not empty
+          
        is not empty
           
        
            
        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, enterpriseAttestationPossible, attestationFormats,
 and authenticatorExtensions as parameters.
        
-          
        is empty
+          
        is empty
           
        
            
        Using local configuration knowledge of the appropriate transport to use with authenticator,
 invoke the authenticatorGetAssertion operation on authenticator with rpId, clientDataHash, allowCredentialDescriptorList, userVerification, enterpriseAttestationPossible, attestationFormats, and authenticatorExtensions as parameters.
        
          
        
        
      
-      
      is empty
+      
      is empty
       
      
        
      Using local configuration knowledge of the appropriate transport to use with authenticator, invoke the authenticatorGetAssertion operation on authenticator with rpId, clientDataHash, userVerification, enterpriseAttestationPossible, attestationFormats,
 and authenticatorExtensions as parameters.
      
@@ -3051,10 +3443,11 @@ 
      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 throws an error.
      
+    
      The [[Store]](credential, sameOriginWithAncestors) method is not supported
+for Web Authentication’s PublicKeyCredential type,
+so its implementation of the [[Store]](credential, sameOriginWithAncestors) internal method always throws an error.
      
     
      Note: This algorithm is synchronous; the Promise resolution/rejection is handled by navigator.credentials.store().
      
-    
      This internal method accepts two arguments:
      
+    
      This internal method accepts two arguments:
      
     
      
      
      credential
      
      
@@ -3074,7 +3467,7 @@ 
      [[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.
      
-    
      This internal method accepts no arguments.
      
+    
      This internal method accepts no arguments.
      
    
      
    
      5.1.7. Availability of User-Verifying Platform Authenticator - PublicKeyCredential’s isUserVerifyingPlatformAuthenticatorAvailable() Method
      
    
      
@@ -3090,78 +3483,98 @@ 
      Note: Invoking this method from a browsing context where the Web Authentication API is "disabled" according to the allowed to use algorithm—i.e., by a permissions policy—will result in the promise being rejected with a DOMException whose name is "NotAllowedError". See also § 5.9 Permissions Policy integration.
      
    
      
-   
      5.1.8. Deserialize Registration ceremony options - PublicKeyCredential’s parseCreationOptionsFromJSON() Method
      
+   
      5.1.8. Availability of a passkey platform authenticator - PublicKeyCredential’s isPasskeyPlatformAuthenticatorAvailable() Method
      
+   
      
+    
      WebAuthn Relying Parties use this method to determine whether they can create a new passkey using a user-verifying platform authenticator or a hybrid authenticator.
+Upon invocation, the client employs a client platform-specific procedure to discover available user-verifying platform authenticators and the 
+availability of hybrid transport.
+If one or both are discovered, the promise is resolved with the value of true.
+If neither is discovered, the promise is resolved with the value of false.
+Based on the result, the Relying Party can take further actions to guide the user to create a passkey.
      
+    
      This method has no arguments and returns a Boolean value.
      
+
      partial interface PublicKeyCredential {
+    static Promise<boolean> isPasskeyPlatformAuthenticatorAvailable();
+};
+
      
+    
      Note: Invoking this method from a browsing context where the Web Authentication API is "disabled" according to the allowed to use algorithm—i.e., by a permissions policy—will result in the promise being rejected with a DOMException whose name is "NotAllowedError". See also § 5.9 Permissions Policy integration.
      
+   
      
+   
      5.1.9. Deserialize Registration ceremony options - PublicKeyCredential’s parseCreationOptionsFromJSON() Method
      
    
      
-    
      WebAuthn Relying Parties use this method to convert JSON type representations of options for navigator.credentials.create() into PublicKeyCredentialCreationOptions.
      
-    
      Upon invocation, the client MUST convert the options argument into a new,
+    
      WebAuthn Relying Parties use this method to convert JSON type representations of options for navigator.credentials.create() into PublicKeyCredentialCreationOptions.
      
+    
      Upon invocation, the client MUST convert the options argument into a new,
 identically-structured PublicKeyCredentialCreationOptions object, using base64url encoding to decode any DOMString attributes in PublicKeyCredentialCreationOptionsJSON that correspond
 to buffer source type attributes in PublicKeyCredentialCreationOptions. This conversion MUST
-also apply to any client extension inputs processed by the client.
      
+also apply to any client extension inputs processed by the client.
      
     
      AuthenticationExtensionsClientInputsJSON MAY include extensions registered in the IANA
 "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] but not defined in § 9 WebAuthn Extensions.
      
-    
      If the client encounters any issues parsing any of the JSON type representations then it
-MUST throw an "EncodingError" DOMException with a description of the incompatible
+    
      If the client encounters any issues parsing any of the JSON type representations then it
+MUST throw an "EncodingError" DOMException with a description of the incompatible
 value and terminate the operation.
      
-
      partial interface PublicKeyCredential {
+
      partial interface PublicKeyCredential {
     static PublicKeyCredentialCreationOptions parseCreationOptionsFromJSON(PublicKeyCredentialCreationOptionsJSON options);
 };
 
 dictionary PublicKeyCredentialCreationOptionsJSON {
     required PublicKeyCredentialRpEntity                    rp;
     required PublicKeyCredentialUserEntityJSON              user;
-    required Base64URLString                                challenge;
+    required Base64URLString                                challenge;
     required sequence<PublicKeyCredentialParameters>        pubKeyCredParams;
     unsigned long                                           timeout;
     sequence<PublicKeyCredentialDescriptorJSON>             excludeCredentials = [];
     AuthenticatorSelectionCriteria                          authenticatorSelection;
-    DOMString                                               attestation = "none";
+    sequence<DOMString>                                     hints = [];
+    DOMString                                               attestation = "none";
+    sequence<DOMString>                                     attestationFormats = [];
     AuthenticationExtensionsClientInputsJSON                extensions;
 };
 
 dictionary PublicKeyCredentialUserEntityJSON {
-    required Base64URLString        id;
-    required DOMString              name;
-    required DOMString              displayName;
+    required Base64URLString        id;
+    required DOMString              name;
+    required DOMString              displayName;
 };
 
 dictionary PublicKeyCredentialDescriptorJSON {
-    required Base64URLString        id;
-    required DOMString              type;
-    sequence<DOMString>             transports;
+    required Base64URLString        id;
+    required DOMString              type;
+    sequence<DOMString>             transports;
 };
 
 dictionary AuthenticationExtensionsClientInputsJSON {
 };
 
      
    
      
-   
      5.1.9. Deserialize Authentication ceremony options - PublicKeyCredential’s parseRequestOptionsFromJSON() Methods
      
+   
      5.1.10. Deserialize Authentication ceremony options - PublicKeyCredential’s parseRequestOptionsFromJSON() Methods
      
    
      
-    
      WebAuthn Relying Parties use this method to convert JSON type representations of options for navigator.credentials.get() into PublicKeyCredentialRequestOptions.
      
-    
      Upon invocation, the client MUST convert the options argument into a new,
-identically-structured PublicKeyCredentialRequestOptions object, using base64url encoding to decode any DOMString attributes in PublicKeyCredentialRequestOptionsJSON that correspond
+    
      WebAuthn Relying Parties use this method to convert JSON type representations of options for navigator.credentials.get() into PublicKeyCredentialRequestOptions.
      
+    
      Upon invocation, the client MUST convert the options argument into a new,
+identically-structured PublicKeyCredentialRequestOptions object, using base64url encoding to decode any DOMString attributes in PublicKeyCredentialRequestOptionsJSON that correspond
 to buffer source type attributes in PublicKeyCredentialRequestOptions. This conversion MUST
-also apply to any client extension inputs processed by the client.
      
+also apply to any client extension inputs processed by the client.
      
     
      AuthenticationExtensionsClientInputsJSON MAY include extensions registered in the IANA
 "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] but not defined in § 9 WebAuthn Extensions.
      
-    
      If the client encounters any issues parsing any of the JSON type representations then it
-MUST throw an "EncodingError" DOMException with a description of the incompatible
+    
      If the client encounters any issues parsing any of the JSON type representations then it
+MUST throw an "EncodingError" DOMException with a description of the incompatible
 value and terminate the operation.
      
-
      partial interface PublicKeyCredential {
+
      partial interface PublicKeyCredential {
     static PublicKeyCredentialRequestOptions parseRequestOptionsFromJSON(PublicKeyCredentialRequestOptionsJSON options);
 };
 
 dictionary PublicKeyCredentialRequestOptionsJSON {
-    required Base64URLString                                challenge;
+    required Base64URLString                                challenge;
     unsigned long                                           timeout;
-    DOMString                                               rpId;
-    sequence<PublicKeyCredentialDescriptorJSON>             allowCredentials = [];
-    DOMString                                               userVerification = "preferred";
+    DOMString                                               rpId;
+    sequence<PublicKeyCredentialDescriptorJSON>             allowCredentials = [];
+    DOMString                                               userVerification = "preferred";
+    sequence<DOMString>                                     hints = [];
+    DOMString                                               attestation = "none";
+    sequence<DOMString>                                     attestationFormats = [];
     AuthenticationExtensionsClientInputsJSON                extensions;
 };
 
      
    
      
    
      5.2. Authenticator Responses (interface AuthenticatorResponse)
      
-   
      Authenticators respond to Relying Party requests by returning an object derived from the AuthenticatorResponse interface:
      
+   
      Authenticators respond to Relying Party requests by returning an object derived from the AuthenticatorResponse interface:
      
 
      [SecureContext, Exposed=Window]
 interface AuthenticatorResponse {
     [SameObject] readonly attribute ArrayBuffer      clientDataJSON;
@@ -3176,14 +3589,14 @@ 
      
    
    • 
    
    5.2.1. Information About Public Key Credential (interface AuthenticatorAttestationResponse)
    
-   
    The AuthenticatorAttestationResponse interface represents the authenticator's response to a client’s request
+   
    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
+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.
    
 
    [SecureContext, Exposed=Window]
 interface AuthenticatorAttestationResponse : AuthenticatorResponse {
     [SameObject] readonly attribute ArrayBuffer      attestationObject;
-    sequence<DOMString>                              getTransports();
+    sequence<DOMString>                              getTransports();
     ArrayBuffer                                      getAuthenticatorData();
     ArrayBuffer?                                     getPublicKey();
     COSEAlgorithmIdentifier                          getPublicKeyAlgorithm();
@@ -3201,7 +3614,7 @@ 
    attestation object, which is opaque to, and cryptographically protected against
 tampering by, the client. The attestation object contains both authenticator data and an attestation
 statement. The former contains the AAGUID, a unique credential ID, and the credential public key. The
-contents of the attestation statement are determined by the attestation statement format used by the authenticator. It also contains any additional information that the Relying Party's server requires to validate the attestation statement, as well as to decode and validate the authenticator data along with the JSON-compatible serialization of client data. For more details, see § 6.5 Attestation, § 6.5.5 Generating an Attestation Object,
+contents of the attestation statement are determined by the attestation statement format used by the authenticator. It also contains any additional information that the Relying Party's server requires to validate the attestation statement, as well as to decode and validate the authenticator data along with the JSON-compatible serialization of client data. For more details, see § 6.5 Attestation, § 6.5.5 Generating an Attestation Object,
 and Figure 6.
    
      
    getTransports()
      
    
@@ -3209,22 +3622,22 @@ 
    getAuthenticatorData()
      
    
       
    This operation returns the authenticator data contained within attestationObject. See § 5.2.1.1 Easily accessing credential data.
    
-     
    getPublicKey()
+     
    getPublicKey()
      
    
       
    This operation returns the DER SubjectPublicKeyInfo of the new credential, or null if this is not available. See § 5.2.1.1 Easily accessing credential data.
    
-     
    getPublicKeyAlgorithm()
+     
    getPublicKeyAlgorithm()
      
    
       
    This operation returns the COSEAlgorithmIdentifier of the new credential. See § 5.2.1.1 Easily accessing credential data.
    
      
    [[transports]]
      
    
-      
    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 SHOULD accept and store unknown values.
    
+      
    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 SHOULD accept and store unknown values.
    
     
    
    
    5.2.1.1. Easily accessing credential data
    
-   
    Every user of the [[Create]](origin, options, sameOriginWithAncestors) method will need to parse and store the returned credential public key in order to verify future authentication assertions. However, the credential public key is in COSE format [RFC9052], inside the credentialPublicKey member of the attestedCredentialData, inside the authenticator data, inside the attestation object conveyed by AuthenticatorAttestationResponse.attestationObject. Relying Parties wishing to use attestation are obliged to do the work of parsing the attestationObject and obtaining the credential public key because that public key copy is the one the authenticator signed. However, many valid WebAuthn use cases do not require attestation. For those uses, user agents can do the work of parsing, expose the authenticator data directly, and translate the credential public key into a more convenient format.
    
-   
    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.
    
-   
    Use of getPublicKey() does impose some limitations: by using pubKeyCredParams, a Relying Party can negotiate with the authenticator to use public key algorithms that the user agent may not understand. However, if the Relying Party does so, the user agent will not be able to translate the resulting credential public key into SubjectPublicKeyInfo format and the return value of getPublicKey() will be null.
    
-   
    User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:
    
+   
    Every user of the [[Create]](origin, options, sameOriginWithAncestors) method will need to parse and store the returned credential public key in order to verify future authentication assertions. However, the credential public key is in COSE format [RFC9052], inside the credentialPublicKey member of the attestedCredentialData, inside the authenticator data, inside the attestation object conveyed by AuthenticatorAttestationResponse.attestationObject. Relying Parties wishing to use attestation are obliged to do the work of parsing the attestationObject and obtaining the credential public key because that public key copy is the one the authenticator signed. However, many valid WebAuthn use cases do not require attestation. For those uses, user agents can do the work of parsing, expose the authenticator data directly, and translate the credential public key into a more convenient format.
    
+   
    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.
    
+   
    Use of getPublicKey() does impose some limitations: by using pubKeyCredParams, a Relying Party can negotiate with the authenticator to use public key algorithms that the user agent may not understand. However, if the Relying Party does so, the user agent will not be able to translate the resulting credential public key into SubjectPublicKeyInfo format and the return value of getPublicKey() will be null.
    
+   
    User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:
    
    
      
     
    • 
      
      -7 (ES256), where kty is 2 (with uncompressed points) and crv is 1 (P-256).
      
@@ -3233,12 +3646,12 @@ 
      
      
      -8 (EdDSA), where crv is 6 (Ed25519).
      
    
    
-   
    A SubjectPublicKeyInfo does not include information about the signing algorithm (for example, which hash function to use) that is included in the COSE public key. To provide this, getPublicKeyAlgorithm() returns the COSEAlgorithmIdentifier for the credential public key.
    
-   
    To remove the need to parse CBOR at all in many cases, getAuthenticatorData() returns the authenticator data from attestationObject. The authenticator data contains other fields that are encoded in a binary format. However, helper functions are not provided to access them because Relying Parties already need to extract those fields when getting an assertion. In contrast to credential creation, where signature verification is optional, Relying Parties should always be verifying signatures from an assertion and thus must extract fields from the signed authenticator data. The same functions used there will also serve during credential creation.
    
-   
    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.
    
+   
    A SubjectPublicKeyInfo does not include information about the signing algorithm (for example, which hash function to use) that is included in the COSE public key. To provide this, getPublicKeyAlgorithm() returns the COSEAlgorithmIdentifier for the credential public key.
    
+   
    To remove the need to parse CBOR at all in many cases, getAuthenticatorData() returns the authenticator data from attestationObject. The authenticator data contains other fields that are encoded in a binary format. However, helper functions are not provided to access them because Relying Parties already need to extract those fields when getting an assertion. In contrast to credential creation, where signature verification is optional, Relying Parties should always be verifying signatures from an assertion and thus must extract fields from the signed authenticator data. The same functions used there will also serve during credential creation.
    
+   
    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)
    
-   
    The AuthenticatorAssertionResponse interface represents an authenticator's response to a client’s request for
-generation of a new authentication assertion given the WebAuthn Relying Party's challenge and OPTIONAL list of credentials it is
+   
    The AuthenticatorAssertionResponse interface represents an authenticator's response to a client’s request for
+generation of a new authentication assertion given the WebAuthn Relying Party's challenge and OPTIONAL list of credentials it is
 aware of. This response contains a cryptographic signature proving possession of the credential private key, and
 optionally evidence of user consent to a specific transaction.
    
 
    [SecureContext, Exposed=Window]
@@ -3264,24 +3677,26 @@ 
    § 6.3.3 The authenticatorGetAssertion Operation.
    
      
    userHandle,  of type ArrayBuffer, readonly, nullable
      
    
-      
    This attribute contains the user handle returned from the authenticator, or null if the authenticator did not return a user handle. See § 6.3.3 The authenticatorGetAssertion Operation.
    
+      
    This attribute contains the user handle returned from the authenticator, or null if the authenticator did not return a user handle. See § 6.3.3 The authenticatorGetAssertion Operation. The authenticator MUST always return a user handle if
+the allowCredentials option used in the authentication ceremony is empty,
+and MAY return one otherwise.
    
      
    attestationObject,  of type ArrayBuffer, readonly, nullable
      
    
-      
    This OPTIONAL attribute contains an attestation object, if the authenticator supports attestation in assertions. The attestation object, if present, includes an attestation statement. Unlike the attestationObject in an AuthenticatorAttestationResponse, it does not contain an authData key because the authenticator data is provided directly in an AuthenticatorAssertionResponse structure. For more details on attestation, see § 6.5 Attestation, § 6.5.1 Attestation in assertions, § 6.5.5 Generating an Attestation Object, and Figure 6.
    
+      
    This OPTIONAL attribute contains an attestation object, if the authenticator supports attestation in assertions. The attestation object, if present, includes an attestation statement. Unlike the attestationObject in an AuthenticatorAttestationResponse, it does not contain an authData key because the authenticator data is provided directly in an AuthenticatorAssertionResponse structure. For more details on attestation, see § 6.5 Attestation, § 6.5.1 Attestation in assertions, § 6.5.5 Generating an Attestation Object, and Figure 6.
    
     
    
    
    5.3. Parameters for Credential Generation (dictionary PublicKeyCredentialParameters)
    
 
    dictionary PublicKeyCredentialParameters {
-    required DOMString                    type;
+    required DOMString                    type;
     required COSEAlgorithmIdentifier      alg;
 };
 
    
    
    
      This dictionary is used to supply additional parameters when creating a new credential. 
     
    
-     
    type,  of type DOMString
+     
    type,  of type DOMString
      
    
-      
    This member specifies the type of credential to be created. The value SHOULD be a member of PublicKeyCredentialType but client platforms MUST ignore unknown values, ignoring any PublicKeyCredentialParameters with an unknown type.
    
+      
    This member specifies the type of credential to be created. The value SHOULD be a member of PublicKeyCredentialType but client platforms MUST ignore unknown values, ignoring any PublicKeyCredentialParameters with an unknown type.
    
      
    alg,  of type COSEAlgorithmIdentifier
      
    
       
    This member specifies the cryptographic signature algorithm with which the newly generated credential will be used, and
@@ -3296,13 +3711,14 @@ 
    PublicKeyCredentialUserEntity       user;
 
     required BufferSource                             challenge;
-    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;
+    required sequence<PublicKeyCredentialParameters>  pubKeyCredParams;
 
     unsigned long                                timeout;
-    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
+    sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
     AuthenticatorSelectionCriteria               authenticatorSelection;
-    DOMString                                    attestation = "none";
-    sequence<DOMString>                          attestationFormats = [];
+    sequence<DOMString>                          hints = [];
+    DOMString                                    attestation = "none";
+    sequence<DOMString>                          attestationFormats = [];
     AuthenticationExtensionsClientInputs         extensions;
 };
 
    
@@ -3310,7 +3726,7 @@ 
    rp,  of type PublicKeyCredentialRpEntity
      
    
-      
    This member contains a name and an identifier for the Relying Party responsible for the request.
    
+      
    This member contains a name and an identifier for the Relying Party responsible for the request.
    
       
    Its value’s name member is REQUIRED. See § 5.4.1 Public Key Entity Description (dictionary PublicKeyCredentialEntity) for further
 details.
    
       
    Its value’s id member specifies the RP ID the credential
@@ -3319,21 +3735,21 @@ 
    user,  of type PublicKeyCredentialUserEntity
      
    
       
    This member contains names and an identifier for the user account performing the registration.
    
-      
    Its value’s name, displayName and id members are REQUIRED. id can be returned as the userHandle in some future authentication ceremonies,
-and is used to overwrite existing discoverable credentials that have the same rp.id and user.id on the same authenticator. name and displayName MAY be used by the authenticator and client in future authentication ceremonies to help the user select a credential, but are not returned to the Relying Party as a result of future authentication ceremonies
    
+      
    Its value’s name, displayName and id members are REQUIRED. id can be returned as the userHandle in some future authentication ceremonies,
+and is used to overwrite existing discoverable credentials that have the same rp.id and user.id on the same authenticator. name and displayName MAY be used by the authenticator and client in future authentication ceremonies to help the user select a credential, but are not returned to the Relying Party as a result of future authentication ceremonies
    
       
    For further details, see § 5.4.1 Public Key Entity Description (dictionary PublicKeyCredentialEntity) and § 5.4.3 User Account Parameters for Credential Generation (dictionary PublicKeyCredentialUserEntity).
    
      
    challenge,  of type BufferSource
      
    
-      
    This member specifies a challenge that the authenticator signs, along with other data,
+      
    This member specifies a challenge that the authenticator signs, along with other data,
 when producing an attestation object for the newly created credential.
 See the § 13.4.3 Cryptographic Challenges security consideration.
    
      
    pubKeyCredParams,  of type sequence<PublicKeyCredentialParameters>
      
    
-      
    This member lists the key types and signature algorithms the Relying Party supports,
+      
    This member lists the key types and signature algorithms the Relying Party supports,
 ordered from most preferred to least preferred.
-The client and authenticator make a best-effort to create a credential of the most preferred type possible.
+The client and authenticator make a best-effort to create a credential of the most preferred type possible.
 If none of the listed types can be created, the create() operation fails.
    
-      
    Relying Parties that wish to support a wide range of authenticators SHOULD include at least the following COSEAlgorithmIdentifier values:
    
+      
    Relying Parties that wish to support a wide range of authenticators SHOULD include at least the following COSEAlgorithmIdentifier values:
    
       
    
    
    
     
    
      
    id,  of type BufferSource
      
    
-      
    The user handle of the user account.
-A user handle is an opaque byte sequence with a maximum size of 64 bytes,
+      
    The user handle of the user account.
+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.
    
-      
    Note: the user handle ought not be a constant value across different user accounts,
-even for non-discoverable credentials, because some authenticators always create discoverable credentials.
-Thus a constant user handle would prevent a user from using such an authenticator
-with more than one user account at the Relying Party.
    
-     
    displayName,  of type DOMString
+      
    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.
    
+      
    Note: the user handle ought not be a constant value across different user accounts,
+even for non-discoverable credentials, because some authenticators always create discoverable credentials.
+Thus a constant user handle would prevent a user from using such an authenticator
+with more than one user account at the Relying Party.
    
+     
    displayName,  of type DOMString
      
    
-      
    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.
    
+      
    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.
    
       
-      
    When clients, client platforms, or authenticators display a displayName's value, they should always use UI elements to provide a clear boundary around the displayed value, and not allow overflow into other elements [css-overflow-3].
    
-      
    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.
    
+      
    When clients, client platforms, or authenticators display a displayName's value, they should always use UI elements to provide a clear boundary around the displayed value, and not allow overflow into other elements [css-overflow-3].
    
+      
    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.
    
     
    
    
    
    
    5.4.4. Authenticator Selection Criteria (dictionary AuthenticatorSelectionCriteria)
    
-   
    WebAuthn Relying Parties may use the AuthenticatorSelectionCriteria dictionary to specify their requirements regarding authenticator
+   
    WebAuthn Relying Parties may use the AuthenticatorSelectionCriteria dictionary to specify their requirements regarding authenticator
 attributes.
    
 
    dictionary AuthenticatorSelectionCriteria {
-    DOMString                    authenticatorAttachment;
-    DOMString                    residentKey;
-    boolean                      requireResidentKey = false;
-    DOMString                    userVerification = "preferred";
+    DOMString                    authenticatorAttachment;
+    DOMString                    residentKey;
+    boolean                      requireResidentKey = false;
+    DOMString                    userVerification = "preferred";
 };
 
    
    
    
     
    
-     
    authenticatorAttachment,  of type DOMString
+     
    authenticatorAttachment,  of type DOMString
      
    
-      
    If this member is present, eligible authenticators are filtered to be only those authenticators attached with the specified authenticator attachment modality (see also § 6.2.1 Authenticator Attachment Modality).
+      
    If this member is present, eligible authenticators are filtered to be only those authenticators attached with the specified authenticator attachment modality (see also § 6.2.1 Authenticator Attachment Modality).
 If this member is absent, then any attachment modality is acceptable.
-The value SHOULD be a member of AuthenticatorAttachment but client platforms MUST ignore unknown values,
+The value SHOULD be a member of AuthenticatorAttachment but client platforms MUST ignore unknown values,
 treating an unknown value as if the member does not exist.
    
-      
    See also the authenticatorAttachment member of PublicKeyCredential,
+      
    See also the authenticatorAttachment member of PublicKeyCredential,
 which can tell what authenticator attachment modality was used
 in a successful create() or get() operation.
    
-     
    residentKey,  of type DOMString
+     
    residentKey,  of type DOMString
      
    
-      
    Specifies the extent to which the Relying Party desires to create a client-side discoverable credential. For historical reasons the naming retains the deprecated “resident” terminology. The value SHOULD be a member of ResidentKeyRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. If no value is given then the effective value is required if requireResidentKey is true or discouraged if it is false or absent.
    
+      
    Specifies the extent to which the Relying Party desires to create a client-side discoverable credential. For historical reasons the naming retains the deprecated “resident” terminology. The value SHOULD be a member of ResidentKeyRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. If no value is given then the effective value is required if requireResidentKey is true or discouraged if it is false or absent.
    
       
    See ResidentKeyRequirement for the description of residentKey's values and semantics.
    
-     
    requireResidentKey,  of type boolean, defaulting to false
+     
    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 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 member specifies the Relying Party's requirements regarding user verification for the create() operation.
-The value SHOULD be a member of UserVerificationRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
+      
    This member specifies the Relying Party's requirements regarding user verification for the create() operation.
+The value SHOULD be a member of UserVerificationRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
       
    See UserVerificationRequirement for the description of userVerification's values and semantics.
    
     
    
    
    
    
    5.4.5. Authenticator Attachment Enumeration (enum AuthenticatorAttachment)
    
-   
    This enumeration’s values describe authenticators' attachment modalities. Relying Parties use this to express a preferred authenticator attachment modality when calling navigator.credentials.create() to create a credential, and clients use this to report the authenticator attachment modality used to complete a registration or authentication ceremony.
    
+   
    This enumeration’s values describe authenticators' attachment modalities. Relying Parties use this to express a preferred authenticator attachment modality when calling navigator.credentials.create() to create a credential, and clients use this to report the authenticator attachment modality used to complete a registration or authentication ceremony.
    
 
    enum AuthenticatorAttachment {
     "platform",
     "cross-platform"
@@ -3537,9 +3956,9 @@ 
    
    
    
    Note: An authenticator attachment modality selection option is available only in the [[Create]](origin, options,
-sameOriginWithAncestors) operation. The Relying Party may use it to, for example, ensure the user has a roaming credential for
+sameOriginWithAncestors) operation. The Relying Party may use it to, for example, ensure the user has a roaming credential for
 authenticating on another client device; or to specifically register a platform credential for easier reauthentication using a
-particular client device. The [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operation has no authenticator attachment modality selection option, so the Relying Party SHOULD accept any of the user’s registered credentials. The client and user will then use whichever is available and convenient at the time.
    
+particular client device. The [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operation has no authenticator attachment modality selection option, so the Relying Party SHOULD accept any of the user’s registered credentials. The client and user will then use whichever is available and convenient at the time.
    
    
    5.4.6. Resident Key Requirement Enumeration (enum ResidentKeyRequirement)
    
 
    enum ResidentKeyRequirement {
     "discouraged",
@@ -3548,29 +3967,29 @@ 
    
 };
 
    
    
    Note: The ResidentKeyRequirement enumeration is deliberately not referenced, see § 2.1.1 Enumerations as DOMString types.
    
-   
    This enumeration’s values describe the Relying Party's requirements for client-side discoverable credentials (formerly known as resident credentials or resident keys):
    
+   
    This enumeration’s values describe the Relying Party's requirements for client-side discoverable credentials (formerly known as resident credentials or resident keys):
    
    
    
     
    
      
    discouraged
      
    
-      
    The Relying Party prefers creating a server-side credential, but will accept a client-side discoverable credential.
-The client and authenticator SHOULD create a server-side credential if possible.
    
-      
    Note: A Relying Party cannot require that a created credential is a server-side credential and the Credential Properties Extension may not return a value for the rk property. Because of this, it may be the case that it does not know if a credential is a server-side credential or not and thus does not know whether creating a second credential with the same user handle will evict the first.
    
+      
    The Relying Party prefers creating a server-side credential, but will accept a client-side discoverable credential.
+The client and authenticator SHOULD create a server-side credential if possible.
    
+      
    Note: A Relying Party cannot require that a created credential is a server-side credential and the Credential Properties Extension may not return a value for the rk property. Because of this, it may be the case that it does not know if a credential is a server-side credential or not and thus does not know whether creating a second credential with the same user handle will evict the first.
    
      
    preferred
      
    
-      
    The Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential.
-The client and authenticator SHOULD create a discoverable credential if possible.
-For example, the client SHOULD guide the user through setting up user verification if needed to create a discoverable credential. This takes precedence over the setting of userVerification.
    
+      
    The Relying Party strongly prefers creating a client-side discoverable credential, but will accept a server-side credential.
+The client and authenticator SHOULD create a discoverable credential if possible.
+For example, the client SHOULD guide the user through setting up user verification if needed to create a discoverable credential. This takes precedence over the setting of userVerification.
    
      
    required
      
    
-      
    The Relying Party requires a client-side discoverable credential.
-The client MUST return an error if a client-side discoverable credential cannot be created.
    
+      
    The Relying Party requires a client-side discoverable credential.
+The client MUST return an error if a client-side discoverable credential cannot be created.
    
     
    
    
    
-   
    Note: The Relying Party can seek information on whether or not the authenticator created a client-side discoverable credential using the resident key credential property of the Credential Properties Extension.
-This is useful when values of discouraged or preferred are used for options.authenticatorSelection.residentKey, because in those cases it is possible for an authenticator to create either a client-side discoverable credential or a server-side credential.
    
+   
    Note: The Relying Party can seek information on whether or not the authenticator created a client-side discoverable credential using the resident key credential property of the Credential Properties Extension.
+This is useful when values of discouraged or preferred are used for options.authenticatorSelection.residentKey, because in those cases it is possible for an authenticator to create either a client-side discoverable credential or a server-side credential.
    
    
    5.4.7. Attestation Conveyance Preference Enumeration (enum AttestationConveyancePreference)
    
-   
    WebAuthn Relying Parties may use AttestationConveyancePreference to specify their preference regarding attestation conveyance during credential generation.
    
+   
    WebAuthn Relying Parties may use AttestationConveyancePreference to specify their preference regarding attestation conveyance during credential generation.
    
 
    enum AttestationConveyancePreference {
     "none",
     "indirect",
@@ -3583,27 +4002,27 @@ 
    
      
    none
      
    
-      
    The Relying Party is not interested in authenticator attestation. For example, in order to
-potentially avoid having to obtain user consent to relay identifying information to the Relying Party, or to save a
+      
    The Relying Party is not interested in authenticator attestation. For example, in order to
+potentially avoid having to obtain user consent to relay identifying information to the Relying Party, or to save a
 roundtrip to an Attestation CA or Anonymization CA.
-If the authenticator generates an attestation statement that is not a self attestation,
-the client will replace it with a None attestation statement.
    
+If the authenticator generates an attestation statement that is not a self attestation,
+the client will replace it with a None attestation statement.
    
       
    This is the default, and unknown values fall back to the behavior of this value.
    
      
    indirect
      
    
-      
    The Relying Party wants to receive a verifiable attestation statement,
-but allows the client to decide how to obtain such an attestation statement.
+      
    The Relying Party wants to receive a verifiable attestation statement,
+but allows the client to decide how to obtain such an attestation statement.
 The client MAY replace an authenticator-generated attestation statement with one generated by an Anonymization CA,
-in order to protect the user’s privacy, or to assist Relying Parties with attestation verification in a heterogeneous ecosystem.
    
-      
    Note: There is no guarantee that the Relying Party will obtain a verifiable attestation statement in this case.
-For example, in the case that the authenticator employs self attestation and the client passes the attestation statement through unmodified.
    
+in order to protect the user’s privacy, or to assist Relying Parties with attestation verification in a heterogeneous ecosystem.
    
+      
    Note: There is no guarantee that the Relying Party will obtain a verifiable attestation statement in this case.
+For example, in the case that the authenticator employs self attestation and the client passes the attestation statement through unmodified.
    
      
    direct
      
    
-      
    The Relying Party wants to receive the attestation statement as generated by the authenticator.
    
+      
    The Relying Party wants to receive the attestation statement as generated by the authenticator.
    
      
    enterprise
      
    
-      
    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.
    
-      
    If permitted, the user agent SHOULD signal to the authenticator (at invocation time) that enterprise attestation is requested, and convey the resulting AAGUID and attestation statement, unaltered, to the Relying Party.
    
+      
    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.
    
+      
    If permitted, the user agent SHOULD signal to the authenticator (at invocation time) that enterprise attestation is requested, and convey the resulting AAGUID and attestation statement, unaltered, to the Relying Party.
    
     
    
    
    5.5. Options for Assertion Generation (dictionary PublicKeyCredentialRequestOptions)
    
@@ -3613,74 +4032,78 @@ 
    <
     required BufferSource                challenge;
     unsigned long                        timeout;
     USVString                            rpId;
-    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
-    DOMString                            userVerification = "preferred";
-    DOMString                            attestation = "none";
-    sequence<DOMString>                  attestationFormats = [];
+    sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
+    DOMString                            userVerification = "preferred";
+    sequence<DOMString>                  hints = [];
+    DOMString                            attestation = "none";
+    sequence<DOMString>                  attestationFormats = [];
     AuthenticationExtensionsClientInputs extensions;
 };
 
    
    
    
     
    challenge,  of type BufferSource
     
    
-     
    This member specifies a challenge that the authenticator signs, along with other data, when producing an authentication assertion. See the § 13.4.3 Cryptographic Challenges security consideration.
    
+     
    This member specifies a challenge that the authenticator signs, along with other data, when producing an authentication assertion. See the § 13.4.3 Cryptographic Challenges security consideration.
    
     
    timeout,  of type unsigned long
     
    
-     
    This OPTIONAL member specifies a time, in milliseconds, that the Relying Party 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 specifies a time, in milliseconds, that the Relying Party is willing to wait for the call to complete.
+The value is treated as a hint, and MAY be overridden by the client.
    
     
    rpId,  of type USVString
     
    
-     
    This OPTIONAL member specifies the RP ID claimed by the Relying Party.
-The client MUST verify that the Relying Party's origin matches the scope of this RP ID.
-The authenticator MUST verify
-that this RP ID exactly equals the rpId of the credential to be used for the authentication ceremony.
    
+     
    This OPTIONAL member specifies the RP ID claimed by the Relying Party.
+The client MUST verify that the Relying Party's origin matches the scope of this RP ID.
+The authenticator MUST verify
+that this RP ID exactly equals the rpId of the credential to be used for the authentication ceremony.
    
      
    If not specified, its value will
 be the CredentialsContainer object’s relevant settings object's origin's effective domain.
    
     
    allowCredentials,  of type sequence<PublicKeyCredentialDescriptor>, defaulting to []
     
    
-     
    This OPTIONAL member is used by the client to find authenticators eligible for this authentication ceremony.
+     
    This OPTIONAL member is used by the client to find authenticators eligible for this authentication ceremony.
 It can be used in two ways:
    
      
      
    If not empty, the client MUST return an error if none of the listed credentials can be used.
    
      
    The list is ordered in descending order of preference: the first item in the list is the most
 preferred credential, and the last is the least preferred.
    
-    
    userVerification,  of type DOMString, defaulting to "preferred"
+    
    userVerification,  of type DOMString, defaulting to "preferred"
     
    
-     
    This OPTIONAL member specifies the Relying Party's requirements regarding user verification for the get() operation. The value SHOULD be a member of UserVerificationRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. Eligible authenticators are filtered to only those capable of satisfying this requirement.
    
+     
    This OPTIONAL member specifies the Relying Party's requirements regarding user verification for the get() operation. The value SHOULD be a member of UserVerificationRequirement but client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist. Eligible authenticators are filtered to only those capable of satisfying this requirement.
    
      
    See UserVerificationRequirement for the description of userVerification's values and semantics.
    
-    
    attestation,  of type DOMString, defaulting to "none"
+    
    hints,  of type sequence<DOMString>, defaulting to []
+    
    
+     
    This OPTIONAL member contains zero or more elements from PublicKeyCredentialHints to guide the user agent in interacting with the user. Note that the elements have type DOMString despite being taken from that enumeration. See § 2.1.1 Enumerations as DOMString types.
    
+    
    attestation,  of type DOMString, defaulting to "none"
     
    
-     
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding attestation conveyance.
-Its value SHOULD be a member of AttestationConveyancePreference. Client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
+     
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding attestation conveyance.
+Its value SHOULD be a member of AttestationConveyancePreference. Client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
      
    The default value is none.
    
-    
    attestationFormats,  of type sequence<DOMString>, defaulting to []
+    
    attestationFormats,  of type sequence<DOMString>, defaulting to []
     
    
-     
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding the attestation statement format used by the authenticator.
+     
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding the attestation statement format used by the authenticator.
 Values SHOULD be taken from the IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
 Values are ordered from most preferable to least preferable.
-This parameter is advisory and the authenticator MAY use an attestation statement not enumerated in this parameter.
    
+This parameter is advisory and the authenticator MAY use an attestation statement not enumerated in this parameter.
    
      
    The default value is the empty list, which indicates no preference.
    
     
    extensions,  of type AuthenticationExtensionsClientInputs
     
    
-     
    The Relying Party MAY use this OPTIONAL member to provide client extension inputs requesting additional processing by the client and authenticator.
    
+     
    The Relying Party MAY use this OPTIONAL member to provide client extension inputs requesting additional processing by the client and authenticator.
    
      
    The extensions framework is defined in § 9 WebAuthn Extensions.
 Some extensions are defined in § 10 Defined Extensions;
 consult the IANA "WebAuthn Extension Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809] for an up-to-date list
@@ -3691,11 +4114,11 @@ 
    DOM § 3.3 Using AbortController and AbortSignal objects in APIs section for detailed instructions.
    
    
    Note: DOM § 3.3 Using AbortController and AbortSignal objects in APIs section specifies that web platform APIs integrating with the AbortController must reject the promise immediately once the AbortSignal is aborted.
     Given the complex inheritance and parallelization structure of the [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) methods, the algorithms for the two APIs fulfills this
-    requirement by checking the aborted property in three places. In the case of [[Create]](origin, options, sameOriginWithAncestors), the aborted property is checked first in Credential Management 1 § 2.5.4 Create a Credential immediately before calling [[Create]](origin, options, sameOriginWithAncestors),
+    requirement by checking the aborted property in three places. In the case of [[Create]](origin, options, sameOriginWithAncestors), the aborted property is checked first in Credential Management 1 § 2.5.4 Create a Credential immediately before calling [[Create]](origin, options, sameOriginWithAncestors),
     then in § 5.1.3 Create a New Credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) Method right before authenticator sessions start, and finally
     during authenticator sessions. The same goes for [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors).
    
-   
    The visibility and focus state of the Window object determines whether the [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations
-should continue. When the Window object associated with the Document loses focus, [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations
+   
    The visibility and focus state of the Window object determines whether the [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations
+should continue. When the Window object associated with the Document loses focus, [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) operations
 SHOULD be aborted.
    
    
     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.
@@ -3722,7 +4145,7 @@ 
    CDDL type AuthenticationExtensionsAuthenticatorInputs defines a CBOR map
 containing the authenticator extension input values for zero or more WebAuthn Extensions.
 Extensions can add members as described in § 9.3 Extending Request Parameters.
    
-   
    This type is not exposed to the Relying Party, but is used by the client and authenticator.
    
+   
    This type is not exposed to the Relying Party, but is used by the client and authenticator.
    
    
    5.7.4. Authentication Extensions Authenticator Outputs (CDDL type AuthenticationExtensionsAuthenticatorOutputs)
    
 
    AuthenticationExtensionsAuthenticatorOutputs = {
   * $$extensionOutput .within ( tstr => any )
@@ -3735,76 +4158,76 @@ 
    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
+   
    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.
    
    
    Note: The CollectedClientData may be extended in the future. Therefore it’s critical when parsing to be tolerant of unknown keys and of any reordering of the keys. See also § 5.8.1.2 Limited Verification Algorithm.
    
 
    dictionary CollectedClientData {
-    required DOMString           type;
-    required DOMString           challenge;
-    required DOMString           origin;
-    DOMString                    topOrigin;
-    boolean                      crossOrigin;
+    required DOMString           type;
+    required DOMString           challenge;
+    required DOMString           origin;
+    DOMString                    topOrigin;
+    boolean                      crossOrigin;
 };
 
 dictionary TokenBinding {
-    required DOMString status;
-    DOMString id;
+    required DOMString status;
+    DOMString id;
 };
 
 enum TokenBindingStatus { "present", "supported" };
 
    
    
    
     
    
-     
    type,  of type DOMString
+     
    type,  of type DOMString
      
    
       
    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).
    
-     
    challenge,  of type DOMString
+     
    challenge,  of type DOMString
      
    
-      
    This member contains the base64url encoding of the challenge provided by the Relying Party. See the § 13.4.3 Cryptographic Challenges security consideration.
    
-     
    origin,  of type DOMString
+      
    This member contains the base64url encoding of the challenge provided by the Relying Party. See the § 13.4.3 Cryptographic Challenges security consideration.
    
+     
    origin,  of type DOMString
      
    
       
    This member contains the fully qualified origin of the requester, as provided to the authenticator by the client, in
 the syntax defined by [RFC6454].
    
-     
    topOrigin,  of type DOMString
+     
    topOrigin,  of type DOMString
      
    
-      
    This OPTIONAL member contains the fully qualified top-level origin of the requester, in the syntax defined
+      
    This OPTIONAL member contains the fully qualified top-level origin of the requester, in the syntax defined
 by [RFC6454]. It is set only if the call was made from context that is not same-origin with its
 ancestors, i.e. if crossOrigin is true.
    
-     
    crossOrigin,  of type boolean
+     
    crossOrigin,  of type boolean
      
    
       
    This OPTIONAL member contains the inverse of the sameOriginWithAncestors argument value
-that was passed into the internal method.
    
+that was passed into the internal method.
    
      
    [RESERVED] tokenBinding
      
    
       
    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
    
+with the Relying Party. Its absence indicates that the client doesn’t support token binding
    
       
    Note: While Token Binding was present in Level 1 and Level 2 of WebAuthn, its use is not expected in Level 3. The tokenBinding field is reserved so that it will not be reused for a different purpose.
    
       
    
        
    
-        
    status,  of type DOMString
+        
    status,  of type DOMString
         
    
-         
    This member SHOULD be a member of TokenBindingStatus but client platforms MUST ignore unknown values, treating an unknown value as if the tokenBinding member does not exist. When known, this member is one of the following:
    
+         
    This member SHOULD be a member of TokenBindingStatus but client platforms MUST ignore unknown values, treating an unknown value as if the tokenBinding member does not exist. When known, this member is one of the following:
    
          
    
           
    
            
    supported
            
    
-            
    Indicates the client supports token binding, but it was not negotiated when communicating with the Relying Party.
    
+            
    Indicates the client supports token binding, but it was not negotiated when communicating with the Relying Party.
    
            
    present
            
    
-            
    Indicates token binding was used when communicating with the Relying Party. In this case, the id member MUST be present.
    
+            
    Indicates token binding was used when communicating with the Relying Party. In this case, the id member MUST be present.
    
           
    
          
    
          
    Note: The TokenBindingStatus enumeration is deliberately not referenced, see § 2.1.1 Enumerations as DOMString types.
    
-        
    id,  of type DOMString
+        
    id,  of type DOMString
         
    
          
    This member MUST be present if status is present, and MUST be a base64url
-encoding of the Token Binding ID that was used when communicating with the Relying Party.
    
+encoding of the Token Binding ID that was used when communicating with the Relying Party.
    
        
    
       
    
-      
    Note: Obtaining a Token Binding ID is a client platform-specific operation.
    
+      
    Note: Obtaining a Token Binding ID is a client platform-specific operation.
    
     
    
     
    The CollectedClientData structure is used by the client to compute the following quantities:
    
     
    
@@ -3849,15 +4272,15 @@ 
    topOrigin is present:
    
+     
    If topOrigin is present:
    
      
      
       
    1. 
        
      Append 0x2c22746f704f726967696e223a (,"topOrigin":) to result.
      
       
    2. 
-       
      Append CCDToString(topOrigin) to result.
      
+       
      Append CCDToString(topOrigin) to result.
      
      
    
     
  • 
-     
    Create a temporary copy of the CollectedClientData and remove the fields type, challenge, origin, crossOrigin (if present), and topOrigin (if present).
    
+     
    Create a temporary copy of the CollectedClientData and remove the fields type, challenge, origin, crossOrigin (if present), and topOrigin (if present).
    
     
  • 
      
    If no fields remain in the temporary copy then:
    
      
      
@@ -3974,7 +4397,7 @@ 
      5.8.1.3. Future development
      
-   
      In order to remain compatible with the limited verification algorithm, future versions of this specification must not remove any of the fields type, challenge, origin, crossOrigin, or topOrigin from CollectedClientData. They also must not change the serialization algorithm to change the order in which those fields are serialized, or insert new fields between them.
      
+   
      In order to remain compatible with the limited verification algorithm, future versions of this specification must not remove any of the fields type, challenge, origin, crossOrigin, or topOrigin from CollectedClientData. They also must not change the serialization algorithm to change the order in which those fields are serialized, or insert new fields between them.
      
    
      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 sixth key–value pair may not appear sixth (or at all) if generated by a user agent working from a previous version.
      
    
      5.8.2. Credential Type Enumeration (enum PublicKeyCredentialType)
      
 
      enum PublicKeyCredentialType {
@@ -3990,34 +4413,34 @@ 
      
    
      5.8.3. Credential Descriptor (dictionary PublicKeyCredentialDescriptor)
      
 
      dictionary PublicKeyCredentialDescriptor {
-    required DOMString                    type;
+    required DOMString                    type;
     required BufferSource                 id;
-    sequence<DOMString>                   transports;
+    sequence<DOMString>                   transports;
 };
 
      
    
      This dictionary identifies a specific public key credential.
-It is used in create() to prevent creating duplicate credentials on the same authenticator,
-and in get() to determine if and how the credential can currently be reached by the client.
-It mirrors some fields of the PublicKeyCredential object returned by create() and get().
      
+It is used in create() to prevent creating duplicate credentials on the same authenticator,
+and in get() to determine if and how the credential can currently be reached by the client.
+It mirrors some fields of the PublicKeyCredential object returned by create() and get().
      
    
      
     
      
-     
      type,  of type DOMString
+     
      type,  of type DOMString
      
      
-      
      This member contains the type of the public key credential the caller is referring to. The value SHOULD be a member of PublicKeyCredentialType but client platforms MUST ignore any PublicKeyCredentialDescriptor with an unknown type.
      
-      
      This mirrors the type field of PublicKeyCredential.
      
+      
      This member contains the type of the public key credential the caller is referring to. The value SHOULD be a member of PublicKeyCredentialType but client platforms MUST ignore any PublicKeyCredentialDescriptor with an unknown type.
      
+      
      This mirrors the type field of PublicKeyCredential.
      
      
      id,  of type BufferSource
      
      
       
      This member contains the credential ID of the public key credential the caller is referring to.
      
-      
      This mirrors the rawId field of PublicKeyCredential.
      
-     
      transports,  of type sequence<DOMString>
+      
      This mirrors the rawId field of PublicKeyCredential.
      
+     
      transports,  of type sequence<DOMString>
      
      
-      
      This OPTIONAL member contains a hint as to how the client might communicate with the managing authenticator of the public key credential the caller is referring to. The values SHOULD be members of AuthenticatorTransport but client platforms MUST ignore unknown values.
      
+      
      This OPTIONAL member contains a hint as to how the client might communicate with the managing authenticator of the public key credential the caller is referring to. The values SHOULD be members of AuthenticatorTransport but client platforms MUST ignore unknown values.
      
       
      This mirrors the response.getTransports() method
-of a PublicKeyCredential structure created by a create() operation.
+of a PublicKeyCredential structure created by a create() operation.
 When registering a new credential,
-the Relying Party SHOULD store the value returned from getTransports().
+the Relying Party SHOULD store the value returned from getTransports().
 When creating a PublicKeyCredentialDescriptor for that credential,
-the Relying Party SHOULD retrieve that stored value
+the Relying Party SHOULD retrieve that stored value
 and set it as the value of the transports member.
      
     
      
    
      
@@ -4027,34 +4450,34 @@ 
      "nfc",
     "ble",
     "smart-card",
-    "hybrid",
+    "hybrid",
     "internal"
 };
 
      
    
      Note: The AuthenticatorTransport enumeration is deliberately not referenced, see § 2.1.1 Enumerations as DOMString types.
      
    
      
-     Authenticators may implement various transports for communicating with clients. This enumeration
+     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(). 
+    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.
      
+      
      Indicates the respective authenticator can be contacted over removable USB.
      
      
      nfc
      
      
-      
      Indicates the respective authenticator can be contacted over Near Field Communication (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).
      
+      
      Indicates the respective authenticator can be contacted over Bluetooth Smart (Bluetooth Low Energy / BLE).
      
      
      smart-card
      
      
-      
      Indicates the respective authenticator can be contacted over ISO/IEC 7816 smart card with contacts.
      
+      
      Indicates the respective authenticator can be contacted over ISO/IEC 7816 smart card with contacts.
      
      
      hybrid
      
      
-      
      Indicates the respective authenticator can be contacted using a combination of (often separate) data-transport and proximity mechanisms. This supports, for example, authentication on a desktop computer using a smartphone.
      
+      
      Indicates the respective authenticator can be contacted using a combination of (often separate) data-transport and proximity mechanisms. This supports, for example, authentication on a desktop computer using a smartphone.
      
      
      internal
      
      
-      
      Indicates the respective authenticator is contacted using a client device-specific transport,
+      
      Indicates the respective authenticator is contacted using a client device-specific transport,
 i.e., it is a platform authenticator.
 These authenticators are not removable from the client device.
      
     
      
@@ -4087,52 +4510,78 @@ 
      "discouraged"
 };
 
    • 
-   
    A WebAuthn Relying Party may require user verification for some of its operations but not for others, and may use this type to express its
+   
    A WebAuthn Relying Party may require user verification for some of its operations but not for others, and may use this type to express its
 needs.
    
    
    Note: The UserVerificationRequirement enumeration is deliberately not referenced, see § 2.1.1 Enumerations as DOMString types.
    
    
    
     
    
      
    required
      
    
-      
    The Relying Party requires user verification for the operation and will fail the overall ceremony if the
+      
    The Relying Party requires user verification for the operation and will fail the overall ceremony if the
 response does not have the UV flag set.
-The client MUST return an error if user verification cannot be performed.
    
+The client MUST return an error if user verification cannot be performed.
    
      
    preferred
      
    
-      
    The Relying Party prefers user verification for the operation if possible, but will not fail the
+      
    The Relying Party prefers user verification for the operation if possible, but will not fail the
 operation if the response does not have the UV flag set.
    
      
    discouraged
      
    
-      
    The Relying Party does not want user verification employed during the operation (e.g., in the
+      
    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).
    
     
    
    
    
+   
    5.8.7. User-agent Hints Enumeration (enum PublicKeyCredentialHints)
    
+
    enum PublicKeyCredentialHints {
+    "security-key",
+    "client-device",
+    "hybrid",
+};
+
    
+   
    Note: The PublicKeyCredentialHints enumeration is deliberately not referenced, see § 2.1.1 Enumerations as DOMString types.
    
+   
    
+     WebAuthn Relying Parties may use this enumeration to communicate hints to the user-agent about how a request may be best completed. These hints are not requirements, and do not bind the user-agent, but may guide it in providing the best experience by using contextual information that the Relying Party has about the request. Hints are provided in order of decreasing preference so, if two hints are contradictory, the first one controls. Hints may also overlap: if a more-specific hint is defined a Relying Party may still wish to send less specific ones for user-agents that may not recognise the more specific one. In this case the most specific hint should be sent before the less-specific ones. 
+    
    Hints MAY contradict information contained in credential transports and authenticatorAttachment. When this occurs, the hints take precedence. (Note that transports values are not provided when using discoverable credentials, leaving hints as the only avenue for expressing some aspects of such a request.)
    
+    
    
+     
    security-key
+     
    
+      
    Indicates that the Relying Party believes that users will satisfy this request with a physical security key. For example, an enterprise Relying Party may set this hint if they have issued security keys to their employees and will only accept those authenticators for registration and authentication.
    
+      
    For compatibility with older user agents, when this hint is used in PublicKeyCredentialCreationOptions, the authenticatorAttachment SHOULD be set to cross-platform.
    
+     
    client-device
+     
    
+      
    Indicates that the Relying Party believes that users will satisfy this request with a platform authenticator attached to the client device.
    
+      
    For compatibility with older user agents, when this hint is used in PublicKeyCredentialCreationOptions, the authenticatorAttachment SHOULD be set to platform.
    
+     
    hybrid
+     
    
+      
    Indicates that the Relying Party believes that users will satisfy this request with general-purpose authenticators such as smartphones. For example, a consumer Relying Party may believe that only a small fraction of their customers possesses dedicated security keys. This option also implies that the local platform authenticator should not be promoted in the UI.
    
+      
    For compatibility with older user agents, when this hint is used in PublicKeyCredentialCreationOptions, the authenticatorAttachment SHOULD be set to cross-platform.
    
+    
    
+   
    
    
    5.9. Permissions Policy integration
    
    
    This specification defines two policy-controlled features identified by
 the feature-identifier tokens "publickey-credentials-create"
 and "publickey-credentials-get".
 Their default allowlists are both 'self'. [Permissions-Policy]
    
-   
    A Document's permissions policy determines whether any content in that document is allowed to successfully invoke the Web Authentication API, i.e., via navigator.credentials.create({publicKey:..., ...}) or navigator.credentials.get({publicKey:..., ...}) If disabled in any document, no content in the document will be allowed to use the foregoing methods: attempting to do so will return an error.
    
-   
    Note: Algorithms specified in [CREDENTIAL-MANAGEMENT-1] perform the actual permissions policy evaluation. This is because such policy evaluation needs to occur when there is access to the current settings object. The [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal methods does not have such access since they are invoked in parallel by CredentialsContainer's Create a Credential and Request a Credential abstract operations [CREDENTIAL-MANAGEMENT-1].
    
+   
    A Document's permissions policy determines whether any content in that document is allowed to successfully invoke the Web Authentication API, i.e., via navigator.credentials.create({publicKey:..., ...}) or navigator.credentials.get({publicKey:..., ...}) If disabled in any document, no content in the document will be allowed to use the foregoing methods: attempting to do so will return an error.
    
+   
    Note: Algorithms specified in [CREDENTIAL-MANAGEMENT-1] perform the actual permissions policy evaluation. This is because such policy evaluation needs to occur when there is access to the current settings object. The [[Create]](origin, options, sameOriginWithAncestors) and [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) internal methods does not have such access since they are invoked in parallel by CredentialsContainer's Create a Credential and Request a Credential abstract operations [CREDENTIAL-MANAGEMENT-1].
    
    
    5.10. Using Web Authentication within iframe elements
    
-   
    The Web Authentication API is disabled by default in cross-origin iframes.
-To override this default policy and indicate that a cross-origin iframe is allowed to invoke the Web Authentication API's [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method, specify the allow attribute on the iframe element and include the publickey-credentials-get feature-identifier token in the allow attribute’s value.
    
-   
    Relying Parties utilizing the WebAuthn API in an embedded context should review § 13.4.2 Visibility Considerations for Embedded Usage regarding UI redressing and its possible mitigations.
    
+   
    The Web Authentication API is disabled by default in cross-origin iframes.
+To override this default policy and indicate that a cross-origin iframe is allowed to invoke the Web Authentication API's [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method, specify the allow attribute on the iframe element and include the publickey-credentials-get feature-identifier token in the allow attribute’s value.
    
+   
    Relying Parties utilizing the WebAuthn API in an embedded context should review § 13.4.2 Visibility Considerations for Embedded Usage regarding UI redressing and its possible mitigations.
    
    
    6. WebAuthn Authenticator Model
    
-   
    The Web Authentication API implies a specific abstract functional model for a WebAuthn Authenticator. This section
+   
    The Web Authentication API implies a specific abstract functional model for a WebAuthn Authenticator. This section
 describes that authenticator model.
    
-   
    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
+   
    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.
    
+   
    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
+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.
    
-   
    Relying Parties may influence authenticator selection, if they deem necessary, by stipulating various authenticator characteristics
+   
    Relying Parties may influence authenticator selection, if they deem necessary, by stipulating various authenticator characteristics
 when creating credentials and/or when generating assertions, through use of credential creation options or assertion generation options,
 respectively. The algorithms underlying the WebAuthn API marshal these options and pass them to the applicable authenticator operations defined below.
    
    
    In this abstract model, the authenticator provides key management and cryptographic signatures. It can be embedded in the
@@ -4144,25 +4593,25 @@ 
    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
+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,
+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
+     
      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.
      
+     
      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.
      
    
    
@@ -4170,28 +4619,28 @@ 
    
     
  • 
      
    An attestation signature is produced when a new public key credential is created via an authenticatorMakeCredential operation. An attestation signature provides cryptographic
-proof of certain properties of the authenticator and the credential. For instance, an attestation signature asserts the authenticator type (as denoted by its AAGUID) and the credential public key. The attestation
+proof of certain properties of the authenticator and the credential. For instance, an attestation signature asserts the authenticator type (as denoted by its AAGUID) and the credential public key. The attestation
 signature is signed by an attestation private key, which is chosen depending on the type of attestation desired.
 For more details on attestation, see § 6.5 Attestation.
    
     
  • 
      
    An assertion signature is produced when the authenticatorGetAssertion method is invoked. It represents an
-assertion by the authenticator that the user has consented to a specific transaction, such as logging
-in, or completing a purchase. Thus, an assertion signature asserts that the authenticator possessing a particular credential private key has established, to the best of its ability, that the user requesting this transaction is the
+assertion by the authenticator that the user has consented to a specific transaction, such as logging
+in, or completing a purchase. Thus, an assertion signature asserts that the authenticator possessing a particular credential private key has established, to the best of its ability, that the user requesting this transaction is the
 same user who consented to creating that particular public key credential. It also asserts additional
 information, termed client data, that may be useful to the caller, such as the means by which user consent was
-provided, and the prompt shown to the user by the authenticator. The assertion signature format is illustrated in Figure 4, below.
    
+provided, and the prompt shown to the user by the authenticator. The assertion signature format is illustrated in Figure 4, below.
    
    
    
    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
+   
    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
+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.
    
+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 .
    
    
    
@@ -4279,12 +4728,12 @@ 
     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.
+   
    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.
    
-   
    Authenticators perform the following steps to generate an authenticator data structure:
    
+the requested credential is scoped to exactly matches the RP ID supplied by the client.
    
+   
    Authenticators perform the following steps to generate an authenticator data structure:

    • -

    It is RECOMMENDED that Relying Parties store the most recent value of these flags with the user account for future evaluation.

    -

    The following is a non-exhaustive list of how Relying Parties might use these flags:

    +

    It is RECOMMENDED that Relying Parties store the most recent value of these flags with the user account for future evaluation.

    +

    The following is a non-exhaustive list of how Relying Parties might use these flags:

    6.2. Authenticator Taxonomy

    -

    Many use cases are dependent on the capabilities of the authenticator used. +

    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 example:

    -

    The attestation type and attestation statement format is chosen by the authenticator; Relying Parties can only signal their preferences by setting the attestation and attestationFormats parameters, or those with the same names in PublicKeyCredentialRequestOptions.

    -

    It is expected that most authenticators will support a small number of attestation types and attestation statement -formats, while Relying Parties will decide what attestation types are acceptable to them by policy. Relying Parties will also need to -understand the characteristics of the authenticators that they trust, based on information they have about these authenticators. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to access such information.

    +

    The attestation type and attestation statement format is chosen by the authenticator; Relying Parties can only signal their preferences by setting the attestation and attestationFormats parameters, or those with the same names in PublicKeyCredentialRequestOptions.

    +

    It is expected that most authenticators will support a small number of attestation types and attestation statement +formats, while Relying Parties will decide what attestation types are acceptable to them by policy. Relying Parties will also need to +understand the characteristics of the authenticators that they trust, based on information they have about these authenticators. For example, the FIDO Metadata Service [FIDOMetadataService] provides one way to access such information.

    6.5.1. Attestation in assertions

    -

    Attestation is most commonly provided during credential creation. However, if supported by the authenticator and requested by the Relying Party using the attestation parameter, attestation MAY be provided in assertions.

    -

    Attestations in assertions could be helpful in at least the following situations:

    +

    Attestation is most commonly provided during credential creation. However, if supported by the authenticator and requested by the Relying Party using the attestation parameter, attestation MAY be provided in assertions.

    +

    Attestations in assertions could be helpful in at least the following situations:

    1. -

      For multi-device credentials, the generating authenticator may have returned a meaningfully different attestation than the authenticator currently exercising the credential. Thus returning an attestation for each use of the credential allows the Relying Party to observe these changes.

      +

      For multi-device credentials, the generating authenticator may have returned a meaningfully different attestation than the authenticator currently exercising the credential. Thus returning an attestation for each use of the credential allows the Relying Party to observe these changes.

    2. If the attestation statement format involves a 3rd-party attesting to the state of the authenticator, then returning an attestation with each use of the credential allows for the continued good health of the authenticator to be attested.

    @@ -5097,7 +5547,7 @@
    6.5.3. Attestation Statement Formats
    -

    As described above, an attestation statement format is a data format which represents a cryptographic signature by an authenticator over a set of contextual bindings. Each attestation statement format MUST be defined using the following +

    As described above, an attestation statement format is a data format which represents a cryptographic signature by an authenticator over a set of contextual bindings. Each attestation statement format MUST be defined using the following template:

    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, @@ -5237,24 +5687,24 @@

    [RFC8017] with SHA-256 as the hash function. The signature is not ASN.1 wrapped.

    -

    7. WebAuthn Relying Party Operations

    -

    A registration or authentication ceremony begins with the WebAuthn Relying Party creating a PublicKeyCredentialCreationOptions or PublicKeyCredentialRequestOptions object, respectively, which encodes the parameters for the ceremony. The Relying Party SHOULD take care to not leak sensitive information during this stage; see § 14.6.2 Username Enumeration for details.

    -

    Upon successful execution of create() or get(), the Relying Party's script receives -a PublicKeyCredential containing an AuthenticatorAttestationResponse or AuthenticatorAssertionResponse structure, -respectively, from the client. It must then deliver the contents of this structure to the Relying Party server, using methods outside -the scope of this specification. This section describes the operations that the Relying Party must perform upon receipt of these +

    7. WebAuthn Relying Party Operations

    +

    A registration or authentication ceremony begins with the WebAuthn Relying Party creating a PublicKeyCredentialCreationOptions or PublicKeyCredentialRequestOptions object, respectively, which encodes the parameters for the ceremony. The Relying Party SHOULD take care to not leak sensitive information during this stage; see § 14.6.2 Username Enumeration for details.

    +

    Upon successful execution of create() or get(), the Relying Party's script receives +a PublicKeyCredential containing an AuthenticatorAttestationResponse or AuthenticatorAssertionResponse structure, +respectively, from the client. It must then deliver the contents of this structure to the Relying Party server, using methods outside +the scope of this specification. This section describes the operations that the Relying Party must perform upon receipt of these structures.

    7.1. Registering a New Credential

    -

    In order to perform a registration ceremony, the Relying Party MUST proceed as follows:

    +

    In order to perform a registration ceremony, the Relying Party MUST proceed as follows:

    1. -

      Let options be a new PublicKeyCredentialCreationOptions structure configured to the Relying Party's needs for the ceremony.

      +

      Let options be a new PublicKeyCredentialCreationOptions structure configured to the Relying Party's needs for the ceremony.

    2. 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. +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.

    3. Let response be credential.response. @@ -5276,44 +5726,47 @@

      challenge equals the base64url encoding of options.challenge.

      +
    4. Verify that the value of C.origin is an origin expected by the Relying Party. + See § 13.4.9 Validating the origin of a credential for guidance.
    5. -

      Verify that the value of C.origin matches the Relying Party's origin.

      -
    6. -

      If C.topOrigin is present:

      +

      If C.topOrigin is present:

      1. -

        Verify that the Relying Party expects that this credential would have been created within an iframe that is +

        Verify that the Relying Party expects that this credential would have been created within an iframe that is not same-origin with its ancestors.

      2. -

        Verify that the value of C.topOrigin matches the origin of a page -that the Relying Party expects to be sub-framed within.

        +

        Verify that the value of C.topOrigin matches the origin of a page +that the Relying Party expects to be sub-framed within. +See § 13.4.9 Validating the origin of a credential for guidance.

    7. Let hash be the result of computing a hash over response.clientDataJSON using SHA-256.

    8. Perform CBOR decoding on the attestationObject field of the AuthenticatorAttestationResponse structure to obtain the attestation statement format fmt, the authenticator data authData, and the attestation statement attStmt.

    9. -

      Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party.

      +

      Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party.

    10. Verify that the UP bit of the flags in authData is set.

    11. -

      If the Relying Party requires user verification for this registration, +

      If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set.

    12. -

      If the Relying Party uses the credential’s backup eligibility to inform its user experience flows and/or policies, evaluate the BE bit of the flags in authData.

      +

      If the BE bit of the flags in authData is not set, verify that the BS bit is not set.

    13. -

      If the Relying Party uses the credential’s backup state to inform its user experience flows and/or policies, evaluate the BS bit of the flags in authData.

      +

      If the Relying Party uses the credential’s backup eligibility to inform its user experience flows and/or policies, evaluate the BE bit of the flags in authData.

      +
    14. +

      If the Relying Party uses the credential’s backup state to inform its user experience flows and/or policies, evaluate the BS bit of the flags in authData.

    15. Verify that the "alg" parameter in the credential public key in authData matches the alg attribute of one of the items in options.pubKeyCredParams.

    16. Verify that the values of the client extension outputs in clientExtensionResults and the authenticator extension outputs in the extensions in authData are as expected, considering the client - extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. - In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use. -

      Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such - situations, whether it be to ignore the unsolicited extensions or reject the attestation. The Relying Party can make this + extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. + In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use. +

      Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such + situations, whether it be to ignore the unsolicited extensions or reject the attestation. The Relying Party can make this decision based on local policy and the extensions in use.

      -

      Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be +

      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.

      Note: The devicePubKey extension has explicit verification procedures, see § 10.2.2.3.1 Registration (create()).

    17. @@ -5333,18 +5786,18 @@

      Assess the attestation trustworthiness using the outputs of the verification procedure in step 21, as follows:
    18. -

      Verify that the credentialId is ≤ 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this registration ceremony.

      +

      Verify that the credentialId is ≤ 1023 bytes. Credential IDs larger than this many bytes SHOULD cause the RP to fail this registration ceremony.

    19. -

      Verify that the credentialId is not yet registered for any user. If the credentialId is already known then the Relying Party SHOULD fail this registration ceremony.

      -

      NOTE: The rationale for Relying Parties rejecting duplicate credential IDs is as follows: credential IDs contain sufficient entropy that accidental duplication is very unlikely. However, attestation types other than self attestation do not include a self-signature to explicitly prove possession of the credential private key at registration time. Thus an attacker who has managed to obtain a user’s credential ID and credential public key for a site (this could be potentially accomplished in various ways), could attempt to register a victim’s credential as their own at that site. If the Relying Party accepts this new registration and replaces the victim’s existing credential registration, and the credentials are discoverable, then the victim could be forced to sign into the attacker’s account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.

      +

      Verify that the credentialId is not yet registered for any user. If the credentialId is already known then the Relying Party SHOULD fail this registration ceremony.

      +

      NOTE: The rationale for Relying Parties rejecting duplicate credential IDs is as follows: credential IDs contain sufficient entropy that accidental duplication is very unlikely. However, attestation types other than self attestation do not include a self-signature to explicitly prove possession of the credential private key at registration time. Thus an attacker who has managed to obtain a user’s credential ID and credential public key for a site (this could be potentially accomplished in various ways), could attempt to register a victim’s credential as their own at that site. If the Relying Party accepts this new registration and replaces the victim’s existing credential registration, and the credentials are discoverable, then the victim could be forced to sign into the attacker’s account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.

    20. If the attestation statement attStmt verified successfully and is found to be trustworthy, then create and store a new credential record in the user account that was denoted in options.user, @@ -5356,7 +5809,7 @@

      id

      credential.id or credential.rawId, -whichever format is preferred by the Relying Party.

      +whichever format is preferred by the Relying Party.

      publicKey

      The credential public key in authData.

      @@ -5365,16 +5818,16 @@

      signCount.

      uvInitialized
      -

      The value of the UV flag in authData.

      +

      The value of the UV flag in authData.

      transports

      The value returned from response.getTransports().

      backupEligible
      -

      The value of the BE flag in authData.

      +

      The value of the BE flag in authData.

      backupState
      -

      The value of the BS flag in authData.

      +

      The value of the BS flag in authData.

      The new credential record MAY also include the following OPTIONAL contents:

      @@ -5387,22 +5840,22 @@

      step 23 above, -the Relying Party SHOULD fail the registration ceremony.

      -

      NOTE: However, if permitted by policy, the Relying Party MAY register the credential ID and credential public key but treat the - credential as one with self attestation (see § 6.5.4 Attestation Types). If doing so, the Relying Party is asserting there - is no cryptographic proof that the public key credential has been generated by a particular authenticator model. +the Relying Party SHOULD fail the registration ceremony.

      +

      NOTE: However, if permitted by policy, the Relying Party MAY register the credential ID and credential public key but treat the + credential as one with self attestation (see § 6.5.4 Attestation Types). If doing so, the Relying Party is asserting there + is no cryptographic proof that the public key credential has been generated by a particular authenticator model. See [FIDOSecRef] and [UAFProtocol] for a more detailed discussion.

    -

    Verification of attestation objects requires that the Relying Party has a trusted method of determining acceptable trust anchors +

    Verification of attestation objects requires that the Relying Party has a trusted method of determining acceptable trust anchors in step 22 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 +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.

    7.2. Verifying an Authentication Assertion

    -

    In order to perform an authentication ceremony, the Relying Party MUST proceed as follows:

    +

    In order to perform an authentication ceremony, the Relying Party MUST proceed as follows:

    1. -

      Let options be a new PublicKeyCredentialRequestOptions structure configured to the Relying Party's needs for the ceremony.

      +

      Let options be a new PublicKeyCredentialRequestOptions structure configured to the Relying Party's needs for the ceremony.

    2. Call navigator.credentials.get() and pass options as the publicKey option. Let credential be the result of the successfully resolved promise. @@ -5415,18 +5868,18 @@

      Let clientExtensionResults be the result of calling credential.getClientExtensionResults().

    3. -

      If options.allowCredentials is not empty, -verify that credential.id identifies one of the public key credentials listed in options.allowCredentials.

      +

      If options.allowCredentials is not empty, +verify that credential.id identifies one of the public key credentials listed in options.allowCredentials.

    4. Identify the user being authenticated and let credentialRecord be the credential record for the credential:

      -
      If the user was identified before the authentication ceremony was initiated, e.g., via a username or cookie, +
      If the user was identified before the authentication ceremony was initiated, e.g., via a username or cookie,

      verify that the identified user account contains a credential record whose id equals credential.rawId. Let credentialRecord be that credential record. If response.userHandle is present, -verify that it equals the user handle of the user account.

      -
      If the user was not identified before the authentication ceremony was initiated, +verify that it equals the user handle of the user account.

      +
      If the user was not identified before the authentication ceremony was initiated,

      verify that response.userHandle is present. Verify that the user account identified by response.userHandle contains a credential record whose id equals credential.rawId. @@ -5448,41 +5901,53 @@

      Verify that the value of C.challenge equals the base64url encoding of options.challenge.

      -
    5. Verify that the value of C.origin matches the Relying Party's origin. +
    6. Verify that the value of C.origin is an origin expected by the Relying Party. + See § 13.4.9 Validating the origin of a credential for guidance.
    7. -

      If C.topOrigin is present:

      +

      If C.topOrigin is present:

      1. -

        Verify that the Relying Party expects this credential to be used within an iframe that is not same-origin with its ancestors.

        +

        Verify that the Relying Party expects this credential to be used within an iframe that is not same-origin with its ancestors.

      2. -

        Verify that the value of C.topOrigin matches the origin of a page -that the Relying Party expects to be sub-framed within.

        +

        Verify that the value of C.topOrigin matches the origin of a page +that the Relying Party expects to be sub-framed within. +See § 13.4.9 Validating the origin of a credential for guidance.

    8. - Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party. + Verify that the rpIdHash in authData is the SHA-256 hash of the RP ID expected by the Relying Party.

      Note: If using the appid extension, this step needs some special logic. See § 10.1.1 FIDO AppID Extension (appid) for details.

    9. -

      Verify that the UP bit of the flags in authData is set.

      +

      Verify that the UP bit of the flags in authData is set.

    10. Determine whether user verification is required for this assertion. User verification SHOULD be required if, and only if, options.userVerification is set to required.

      If user verification was determined to be required, -verify that the UV bit of the flags in authData is set. -Otherwise, ignore the value of the UV flag.

      -
    11. -

      If the credential backup state is used as part of Relying Party business logic or policy, -let currentBe and currentBs be the values of the BE and BS bits, respectively, -of the flags in authData. -Compare currentBe and currentBs with credentialRecord.backupEligible and credentialRecord.backupState and apply Relying Party policy, if any.

      -

      Note: See § 6.1.3 Credential Backup State for examples of how a Relying Party might process the BS flag values.

      +verify that the UV bit of the flags in authData is set. +Otherwise, ignore the value of the UV flag.

      +
    12. +

      If the BE bit of the flags in authData is not set, verify that the BS bit is not set.

      +
    13. +

      If the credential backup state is used as part of Relying Party business logic or policy, +let currentBe and currentBs be the values of the BE and BS bits, respectively, +of the flags in authData. +Compare currentBe and currentBs with credentialRecord.backupEligible and credentialRecord.backupState:

      +
        +
      1. +

        If credentialRecord.backupEligible is set, verify that currentBe is set.

        +
      2. +

        If credentialRecord.backupEligible is not set, verify that currentBe is not set.

        +
      3. +

        Apply Relying Party policy, if any.

        +
      +

      Note: See § 6.1.3 Credential Backup State for examples of how a Relying Party might process the BS flag values.

    14. Verify that the values of the client extension outputs in clientExtensionResults and the authenticator extension outputs in the extensions in authData are as expected, considering the client - extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. - In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use. -

      Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such - situations, whether it be to ignore the unsolicited extensions or reject the assertion. The Relying Party can make this + extension input values that were given in options.extensions and any specific policy of the Relying Party regarding unsolicited extensions, i.e., those that were not specified as part of options.extensions. + In the general case, the meaning of "are as expected" is specific to the Relying Party and which extensions are in use. +

      Note: Client platforms MAY enact local policy that sets additional authenticator extensions or client extensions and thus cause values to appear in the authenticator extension outputs or client extension outputs that were not originally specified as part of options.extensions. Relying Parties MUST be prepared to handle such + situations, whether it be to ignore the unsolicited extensions or reject the assertion. The Relying Party can make this decision based on local policy and the extensions in use.

      -

      Note: Since all extensions are OPTIONAL for both the client and the authenticator, the Relying Party MUST also be +

      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.

      Note: The devicePubKey extension has explicit verification procedures, see § 10.2.2.3.2 Authentication (get()).

    15. @@ -5504,16 +5969,16 @@

      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 + being used in parallel. Relying Parties should incorporate this information into their risk scoring. - Whether the Relying Party updates credentialRecord.signCount below in this case, or not, or fails the authentication ceremony or not, is Relying Party-specific. + Whether the Relying Party updates credentialRecord.signCount below in this case, or not, or fails the authentication ceremony or not, is Relying Party-specific.

    16. -

      If response.attestationObject is present and the Relying Party wishes to verify the attestation then perform CBOR decoding on attestationObject to obtain the attestation statement format fmt, and the attestation statement attStmt.

      +

      If response.attestationObject is present and the Relying Party wishes to verify the attestation then perform CBOR decoding on attestationObject to obtain the attestation statement format fmt, and the attestation statement attStmt.

      1. -

        Verify that the AT bit in the flags field of authData is set, indicating that attested credential data is included.

        +

        Verify that the AT bit in the flags field of authData is set, indicating that attested credential data is included.

      2. Verify that the credentialPublicKey and credentialId fields of the attested credential data in authData match credentialRecord.publicKey and credentialRecord.id, respectively.

      3. @@ -5533,17 +5998,17 @@

        Update credentialRecord.backupState to the value of currentBs.

      4. If credentialRecord.uvInitialized is false, -update it to the value of the UV bit in the flags in authData. +update it to the value of the UV bit in the flags in authData. This change SHOULD require authorization by an additional authentication factor equivalent to WebAuthn user verification; if not authorized, skip this step.

      5. OPTIONALLY, if response.attestationObject is present, update credentialRecord.attestationObject to the value of response.attestationObject and update credentialRecord.attestationClientDataJSON to the value of response.clientDataJSON.

      -

      If the Relying Party performs additional security checks beyond these WebAuthn authentication ceremony steps, +

      If the Relying Party performs additional security checks beyond these WebAuthn authentication ceremony steps, the above state updates SHOULD be deferred to after those additional checks are completed successfully.

    17. -

      If all the above steps are successful, continue with the authentication ceremony as appropriate. Otherwise, fail the authentication ceremony.

      +

      If all the above steps are successful, continue with the authentication ceremony as appropriate. Otherwise, fail the authentication ceremony.

    8. Defined Attestation Statement Formats

    WebAuthn supports pluggable attestation statement formats. This section defines an initial set of such formats.

    @@ -5566,7 +6031,7 @@

    [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).

    +implementable by authenticators with limited resources (e.g., secure elements).

    Attestation statement format identifier
    @@ -5821,11 +6286,11 @@

    < See, for example, the FIDO Metadata Service [FIDOMetadataService].

    8.4. Android Key Attestation Statement Format

    -

    When the authenticator in question is a platform authenticator on the Android "N" or later platform, the +

    When the authenticator in question is a platform authenticator on the Android "N" or later platform, the attestation statement is based on the Android key attestation. In these cases, the attestation statement is produced by a component running in a secure operating environment, but the authenticator data for the attestation is -produced outside this environment. The WebAuthn Relying Party is expected to check that the authenticator data claimed to have been used for +produced outside this environment. The WebAuthn Relying Party is expected to check that the authenticator data claimed to have been used for the attestation is consistent with the fields of the attestation certificate’s extension data.

    Attestation statement format identifier @@ -5898,7 +6363,7 @@

    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 +

    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 @@ -5991,7 +6456,7 @@

    sig

    The attestation signature. -The signature was calculated over the (raw) U2F registration response message [FIDO-U2F-Message-Formats] received by the client from the authenticator.

    +The signature was calculated over the (raw) U2F registration response message [FIDO-U2F-Message-Formats] received by the client from the authenticator.

    Signing procedure
    @@ -6046,9 +6511,9 @@

    8.7. None Attestation Statement Format

    -

    The none attestation statement format is used to replace any authenticator-provided attestation statement when a WebAuthn Relying Party indicates it does not wish to receive attestation information, see § 5.4.7 Attestation Conveyance Preference Enumeration (enum AttestationConveyancePreference).

    -

    The authenticator MAY also directly generate attestation statements of this format -if the authenticator does not support attestation.

    +

    The none attestation statement format is used to replace any authenticator-provided attestation statement when a WebAuthn Relying Party indicates it does not wish to receive attestation information, see § 5.4.7 Attestation Conveyance Preference Enumeration (enum AttestationConveyancePreference).

    +

    The authenticator MAY also directly generate attestation statements of this format +if the authenticator does not support attestation.

    Attestation statement format identifier
    @@ -6149,10 +6614,10 @@

    Client extension processing for registration extensions and authentication extensions.

    -

    When creating a public key credential or requesting an authentication assertion, a WebAuthn Relying Party can request the use of a set -of extensions. These extensions will be invoked during the requested operation if they are supported by the client and/or the WebAuthn Authenticator. The Relying Party sends the client extension input for each extension in the get() call -(for authentication extensions) or create() call (for registration extensions) to the client. -The client performs client extension processing for each extension that the client platform supports, and augments the client data as specified by each extension, by including the extension identifier and client extension output values.

    +

    When creating a public key credential or requesting an authentication assertion, a WebAuthn Relying Party can request the use of a set +of extensions. These extensions will be invoked during the requested operation if they are supported by the client and/or the WebAuthn Authenticator. The Relying Party sends the client extension input for each extension in the get() call +(for authentication extensions) or create() call (for registration extensions) to the client. +The client performs client extension processing for each extension that the client platform supports, and augments the client data as specified by each extension, by including the extension identifier and client extension output values.

    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:

    Note: In practice, several implementations do not implement steps four and onward of the @@ -6358,9 +6823,9 @@

    Client extension output
    -

    Returns the value of output. If true, the AppID was used and thus, when verifying the assertion, the Relying Party MUST expect the rpIdHash to be the hash of the AppID, not the RP ID.

    +

    Returns the value of output. If true, the AppID was used and thus, when verifying the assertion, the Relying Party MUST expect the rpIdHash to be the hash of the AppID, not the RP ID.

    partial dictionary AuthenticationExtensionsClientOutputs {
-  boolean appid;
+  boolean appid;
 };
    Authenticator extension input @@ -6374,8 +6839,8 @@

    None.

    10.1.2. FIDO AppID Exclusion Extension (appidExclude)

    -

    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.

    +

    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.

    Extension identifier
    @@ -6405,7 +6870,7 @@

    determining if a caller’s FacetID is authorized for an AppID. If the latter algorithm rejects appId then -return a "SecurityError" DOMException and terminate the creating a new credential algorithm as well as these steps.

    +return a "SecurityError" DOMException and terminate the creating a new credential algorithm as well as these steps.

    Note: In practice, several implementations do not implement steps four and onward of the algorithm for determining if a caller’s FacetID is authorized for an AppID. Instead, in step three, the comparison on the host is relaxed to accept hosts on the same site.

  • Otherwise, continue with normal processing.

    @@ -6450,9 +6915,9 @@

    Relying Party that the extension was acted upon.

    +

    Returns the value true to indicate to the Relying Party that the extension was acted upon.

    partial dictionary AuthenticationExtensionsClientOutputs {
-  boolean appidExclude;
+  boolean appidExclude;
 };
    Authenticator extension input @@ -6466,7 +6931,7 @@

    10.1.3. Credential Properties Extension (credProps)

    -

    This client registration extension facilitates reporting certain credential properties known by the client to the requesting WebAuthn Relying Party upon creation of a public key credential source as a result of a registration ceremony.

    +

    This client registration extension facilitates reporting certain credential properties known by the client to the requesting WebAuthn Relying Party upon creation of a public key credential source as a result of a registration ceremony.

    At this time, one credential property is defined: the resident key credential property (i.e., client-side discoverable credential property).

    Extension identifier @@ -6477,9 +6942,9 @@

    Registration

    Client extension input
    -

    The Boolean value true to indicate that this extension is requested by the Relying Party.

    +

    The Boolean value true to indicate that this extension is requested by the Relying Party.

    partial dictionary AuthenticationExtensionsClientInputs {
-    boolean credProps;
+    boolean credProps;
 };
    Client extension processing @@ -6489,7 +6954,7 @@

    Set clientExtensionResults["credProps"]["rk"] to the value of the requireResidentKey parameter that was used in the invocation of the authenticatorMakeCredential operation.

    dictionary CredentialPropertiesOutput {
-    boolean rk;
+    boolean rk;
 };
 
 partial dictionary AuthenticationExtensionsClientOutputs {
@@ -6498,14 +6963,14 @@ 
    rk,  of type boolean
+       
    rk,  of type boolean
        
    
         
    This OPTIONAL property, known abstractly as the resident key credential property (i.e., client-side discoverable credential property),
-is a Boolean value indicating whether the PublicKeyCredential returned as a result of a registration ceremony is a client-side discoverable credential.
-If rk is true, the credential is a discoverable credential.
+is a Boolean value indicating whether the PublicKeyCredential returned as a result of a registration ceremony is a client-side discoverable credential.
+If rk is true, the credential is a discoverable credential.
 If rk is false, the credential is a server-side credential.
-If rk is not present, it is not known whether the credential is a discoverable credential or a server-side credential.
    
-        
    Note: some authenticators create discoverable credentials even when not requested by the client platform. Because of this, client platforms may be forced to omit the rk property because they lack the assurance to be able to set it to false. Relying Parties should assume that, if the credProps extension is supported, then client platforms will endeavour to populate the rk property. Therefore a missing rk indicates that the created credential is most likely a non-discoverable credential.
    
+If rk is not present, it is not known whether the credential is a discoverable credential or a server-side credential.
    
+        
    Note: some authenticators create discoverable credentials even when not requested by the client platform. Because of this, client platforms may be forced to omit the rk property because they lack the assurance to be able to set it to false. Relying Parties should assume that, if the credProps extension is supported, then client platforms will endeavour to populate the rk property. Therefore a missing rk indicates that the created credential is most likely a non-discoverable credential.

    Authenticator extension input @@ -6519,11 +6984,11 @@

    10.1.4. Pseudo-random function extension (prf)

    -

    This client registration extension and authentication extension allows a Relying Party to evaluate outputs from a pseudo-random function (PRF) associated with a credential. The PRFs provided by this extension map from BufferSources of any length to 32-byte BufferSources.

    -

    As a motivating example, PRF outputs could be used as symmetric keys to encrypt user data. Such encrypted data would be inaccessible without the ability to get assertions from the associated credential. By using the provision below to evaluate the PRF at two inputs in a single assertion operation, the encryption key could be periodically rotated during assertions by choosing a fresh, random input and reencrypting under the new output. If the evaluation inputs are unpredictable then even an attacker who could satisfy user verification, and who had time-limited access to the authenticator, could not learn the encryption key without also knowing the correct PRF input.

    +

    This client registration extension and authentication extension allows a Relying Party to evaluate outputs from a pseudo-random function (PRF) associated with a credential. The PRFs provided by this extension map from BufferSources of any length to 32-byte BufferSources.

    +

    As a motivating example, PRF outputs could be used as symmetric keys to encrypt user data. Such encrypted data would be inaccessible without the ability to get assertions from the associated credential. By using the provision below to evaluate the PRF at two inputs in a single assertion operation, the encryption key could be periodically rotated during assertions by choosing a fresh, random input and reencrypting under the new output. If the evaluation inputs are unpredictable then even an attacker who could satisfy user verification, and who had time-limited access to the authenticator, could not learn the encryption key without also knowing the correct PRF input.

    This extension is implemented on top of the [FIDO-CTAP] hmac-secret extension. It is a separate client extension because hmac-secret requires that inputs and outputs be encrypted in a manner that only the user agent can perform, and to provide separation between uses by WebAuthn and any uses by the underlying platform. This separation is achieved by hashing the provided PRF inputs with a context string to prevent evaluation of the PRFs for arbitrary inputs.

    The hmac-secret extension provides two PRFs per credential: one which is used for requests where user verification is performed and another for all other requests. This extension only exposes a single PRF per credential and, when implementing on top of hmac-secret, that PRF MUST be the one used for when user verification is performed. This overrides the UserVerificationRequirement if neccessary.

    -

    Note: this extension may be implemented for authenticators that do not use [FIDO-CTAP] so long as the behavior observed by a Relying Party is identical.

    +

    Note: this extension may be implemented for authenticators that do not use [FIDO-CTAP] so long as the behavior observed by a Relying Party is identical.

    Extension identifier
    @@ -6551,17 +7016,17 @@

    eval, of type AuthenticationExtensionsPRFValues
    -

    One or two inputs on which to evaluate PRF. Not all authenticators support evaluating the PRFs during credential creation so outputs may, or may not, be provided. If not, then an assertion is needed in order to obtain the outputs.

    +

    One or two inputs on which to evaluate PRF. Not all authenticators support evaluating the PRFs during credential creation so outputs may, or may not, be provided. If not, then an assertion is needed in order to obtain the outputs.

    evalByCredential, of type record<USVString, AuthenticationExtensionsPRFValues>
    -

    A record mapping base64url encoded credential IDs to PRF inputs to evaluate for that credential. Only applicable during assertions when allowCredentials is not empty.

    +

    A record mapping base64url encoded credential IDs to PRF inputs to evaluate for that credential. Only applicable during assertions when allowCredentials is not empty.

    Client extension processing (registration)
    1. -

      If evalByCredential is present, return a DOMException whose name is “NotSupportedError”.

      +

      If evalByCredential is present, return a DOMException whose name is “NotSupportedError”.

    2. Set hmac-secret to true in the authenticator extensions input.

    3. @@ -6578,15 +7043,15 @@

      results to the decrypted PRF result(s), if any.

    • -

    Note: If PRF results are obtained during registration then the Relying Party MUST inspect the UV bit in the flags of the response in order to determine the correct value of userVerification for future assertions. Otherwise results from assertions may be inconsistent with those from the registration.

    +

    Note: If PRF results are obtained during registration then the Relying Party MUST inspect the UV bit in the flags of the response in order to determine the correct value of userVerification for future assertions. Otherwise results from assertions may be inconsistent with those from the registration.

    Client extension processing (authentication)
    1. -

      If evalByCredential is not empty but allowCredentials is empty, return a DOMException whose name is “NotSupportedError”.

      +

      If evalByCredential is not empty but allowCredentials is empty, return a DOMException whose name is “NotSupportedError”.

    2. -

      If any key in evalByCredential is the empty string, or is not a valid base64url encoding, or does not equal the id of some element of allowCredentials after performing base64url decoding, then return a DOMException whose name is “SyntaxError”.

      +

      If any key in evalByCredential is the empty string, or is not a valid base64url encoding, or does not equal the id of some element of allowCredentials after performing base64url decoding, then return a DOMException whose name is “SyntaxError”.

    3. Initialize the prf extension output to an empty dictionary.

    4. @@ -6605,18 +7070,18 @@

      second is present, let salt2 be the value of SHA-256(UTF8Encode("WebAuthn PRF") || 0x00 || ev.second).

    5. -

      Send an hmac-secret extension to the authenticator using the values of salt1 and, if set, salt2 as the parameters of the same name in that process.

      +

      Send an hmac-secret extension to the authenticator using the values of salt1 and, if set, salt2 as the parameters of the same name in that process.

    6. Decrypt the extension result and set results to the PRF result(s), if any.

    Authenticator extension input / processing / output
    -

    This extension uses the [FIDO-CTAP] hmac-secret extension when communicating with the authenticator. It thus does not specify any direct authenticator interaction for Relying Parties.

    +

    This extension uses the [FIDO-CTAP] hmac-secret extension when communicating with the authenticator. It thus does not specify any direct authenticator interaction for Relying Parties.

    Client extension output 
    dictionary AuthenticationExtensionsPRFOutputs {
-    boolean enabled;
+    boolean enabled;
     AuthenticationExtensionsPRFValues results;
 };
 
@@ -6626,7 +7091,7 @@ 
    enabled,  of type boolean
+       
    enabled,  of type boolean
        
    
         
    true if, and only if, the one or two PRFs are available for use with the created credential. This is only reported during registration and is not present in the case of authentication.
    
        
    results,  of type AuthenticationExtensionsPRFValues
@@ -6636,14 +7101,14 @@ 
    10.1.5. Large blob storage extension (largeBlob)
    
-   
    This client registration 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.
    
+   
    This client registration 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.
    
-   
    Note: Roaming authenticators that use [FIDO-CTAP] as their cross-platform transport protocol only support this Large Blob extension for discoverable credentials,
+   
    Note: Roaming authenticators that use [FIDO-CTAP] as their cross-platform transport protocol only support this Large Blob extension for discoverable credentials,
 and might return an error unless authenticatorSelection.residentKey is set to preferred or required.
-However, authenticators that do not utilize [FIDO-CTAP] do not necessarily restrict this extension to discoverable credentials.
    
+However, authenticators that do not utilize [FIDO-CTAP] do not necessarily restrict this extension to discoverable credentials.
    
    
    
     
    Extension identifier
     
    
@@ -6663,22 +7128,22 @@ 
    <
 };
 
 dictionary AuthenticationExtensionsLargeBlobInputs {
-    DOMString support;
-    boolean read;
+    DOMString support;
+    boolean read;
     BufferSource write;
 };
    -
    support, of type DOMString +
    support, of type DOMString

    A DOMString that takes one of the values of LargeBlobSupport. (See § 2.1.1 Enumerations as DOMString types.) Only valid during registration.

    -
    read, of type boolean +
    read, of type boolean
    -

    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.

    +

    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.

    write, of type BufferSource
    -

    An opaque byte string that the Relying Party wishes to store with the existing credential. Only valid during authentication.

    +

    An opaque byte string that the Relying Party wishes to store with the existing credential. Only valid during authentication.

    Client extension processing (registration) @@ -6688,7 +7153,7 @@

    <

    If read or write is present:

    1. -

      Return a DOMException whose name is “NotSupportedError”.

      +

      Return a DOMException whose name is “NotSupportedError”.

  • If support is present and has the value required:

    @@ -6700,7 +7165,7 @@

    < The AuthenticationExtensionsLargeBlobOutputs will be abandoned if no satisfactory authenticator becomes available.

  • If a candidate authenticator becomes available (Step 20 of [[Create]]()) then, - before evaluating any options, continue (i.e. ignore the candidate authenticator) + before evaluating any options, continue (i.e. ignore the candidate authenticator) if the candidate authenticator is not capable of storing large blobs.

  • @@ -6717,13 +7182,13 @@

    <

    If support is present:

    1. -

      Return a DOMException whose name is “NotSupportedError”.

      +

      Return a DOMException whose name is “NotSupportedError”.

  • If both read and write are present:

    1. -

      Return a DOMException whose name is “NotSupportedError”.

      +

      Return a DOMException whose name is “NotSupportedError”.

  • If read is present and has the value true:

    @@ -6740,13 +7205,13 @@

    <

    If write is present:

    1. -

      If allowCredentials does not contain exactly one element:

      +

      If allowCredentials does not contain exactly one element:

      1. -

        Return a DOMException whose name is “NotSupportedError”.

        +

        Return a DOMException whose name is “NotSupportedError”.

    2. -

      If the assertion operation is successful, attempt to store the contents of write on the authenticator, associated with the indicated credential.

      +

      If the assertion operation is successful, attempt to store the contents of write on the authenticator, associated with the indicated credential.

    3. Set written to true if successful and false otherwise.

    @@ -6758,27 +7223,27 @@

    < }; dictionary AuthenticationExtensionsLargeBlobOutputs { - boolean supported; + boolean supported; ArrayBuffer blob; - boolean written; + boolean written; };
    -
    supported, of type boolean +
    supported, of type boolean

    true if, and only if, the created credential supports storing large blobs. Only present in registration outputs.

    blob, of type ArrayBuffer

    The opaque byte string that was associated with the credential identified by rawId. Only valid if read was true.

    -
    written, of type boolean +
    written, of type boolean
    -

    A boolean that indicates that the contents of write were successfully stored on the authenticator, associated with the specified 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.

    +

    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.

    • 10.2. Authenticator Extensions

    This section defines extensions that are both client extensions and authenticator extensions.

    @@ -6793,9 +7258,9 @@

    Registration and Authentication

    Client extension input
    -

    The Boolean value true to indicate that this extension is requested by the Relying Party.

    +

    The Boolean value true to indicate that this extension is requested by the Relying Party.

    partial dictionary AuthenticationExtensionsClientInputs {
-  boolean uvm;
+  boolean uvm;
 };
    Client extension processing @@ -6804,8 +7269,8 @@

    Client extension output

    Returns a JSON array of 3-element arrays of numbers that encodes the factors in the authenticator extension output.

    -
    typedef sequence<unsigned long> UvmEntry;
-typedef sequence<UvmEntry> UvmEntries;
+
    typedef sequence<unsigned long> UvmEntry;
+typedef sequence<UvmEntry> UvmEntries;
 
 partial dictionary AuthenticationExtensionsClientOutputs {
   UvmEntries uvm;
@@ -6820,7 +7285,7 @@ 
    
     
    Authenticator extension processing
     
    
-     
    The authenticator sets the authenticator extension output to be one or more user verification methods indicating the method(s) used
+     
    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
     
    
@@ -6873,19 +7338,19 @@ 
    
    
    
    10.2.2. Device-bound public key extension (devicePubKey)
    
-   
    This authenticator registration extension and authentication extension provides a Relying Party with a "device continuity" signal for backup eligible credentials. This is done by creating a user credential-specific hardware-bound device key pair on the authenticator, if such a key pair does not already exist for the user credential being created or exercised, and returning the device public key along with a signature by the device private key to the Relying Party. This is done each time this devicePubKey extension is included with either a navigator.credentials.create() or navigator.credentials.get() call.
    
-   
    If the authenticator is incapable of generating a hardware-bound device key pair, or the registration or authentication operation fails for any reason, this extension is ignored and no hardware-bound device key pair is created. In this case, there is no devicePubKey extension output generated.
    
-   
    The hardware-bound device key pair is not on its own a user credential and does not have its own credential ID. Instead, the returned device public key is a device-specific contextual attribute of its associated user credential. That is, when that user credential is used—along with the devicePubKey extension—on a particular authenticator, a particular device public key is returned by the extension, along with a signature demonstrating proof-of-possession of the device private key by that device.
    
+   
    This authenticator registration extension and authentication extension provides a Relying Party with a "device continuity" signal for backup eligible credentials. This is done by creating a user credential-specific hardware-bound device key pair on the authenticator, if such a key pair does not already exist for the user credential being created or exercised, and returning the device public key along with a signature by the device private key to the Relying Party. This is done each time this devicePubKey extension is included with either a navigator.credentials.create() or navigator.credentials.get() call.
    
+   
    If the authenticator is incapable of generating a hardware-bound device key pair, or the registration or authentication operation fails for any reason, this extension is ignored and no hardware-bound device key pair is created. In this case, there is no devicePubKey extension output generated.
    
+   
    The hardware-bound device key pair is not on its own a user credential and does not have its own credential ID. Instead, the returned device public key is a device-specific contextual attribute of its associated user credential. That is, when that user credential is used—along with the devicePubKey extension—on a particular authenticator, a particular device public key is returned by the extension, along with a signature demonstrating proof-of-possession of the device private key by that device.
    
    
    10.2.2.1. Relying Party Usage
    
-   
    This extension is intended for use by those Relying Parties employing risk-analysis systems informing their sign-in decisions. This extension provides a "device continuity" signal when used consistently with both navigator.credentials.create() and navigator.credentials.get() operations:
    
-   
    When a Relying Party uses the devicePubKey extension with a create() call to create a new user credential, a signature by a new device-bound key ("dpk 1") is returned along with the new device public key. Even if the user credential is backed up, "dpk 1" never leaves the generating authenticator ("authenticator 1"). The Relying Party's subsequent get() operations using the same user credential with that same authenticator generate assertions including further signatures by the same device-bound key ("dpk 1"). This behavior on "authenticator 1" is independent of whether this user credential has been copied to any other authenticator.
    
-   
    Then, if this same user credential is copied to a different authenticator ("authenticator 2"), the Relying Party's first get() call on "authenticator 2" (that includes the devicePubKey extension) will produce an assertion including a signature by a new device-bound key ("dpk 2"). Note that such a multi-device credential can be exercised on "authenticator 2" without a create() having been performed on "authenticator 2". The Relying Party's subsequent get() calls on "authenticator 2", using the devicePubKey extension and the same user credential, yield further signatures by "dpk 2".
    
+   
    This extension is intended for use by those Relying Parties employing risk-analysis systems informing their sign-in decisions. This extension provides a "device continuity" signal when used consistently with both navigator.credentials.create() and navigator.credentials.get() operations:
    
+   
    When a Relying Party uses the devicePubKey extension with a create() call to create a new user credential, a signature by a new device-bound key ("dpk 1") is returned along with the new device public key. Even if the user credential is backed up, "dpk 1" never leaves the generating authenticator ("authenticator 1"). The Relying Party's subsequent get() operations using the same user credential with that same authenticator generate assertions including further signatures by the same device-bound key ("dpk 1"). This behavior on "authenticator 1" is independent of whether this user credential has been copied to any other authenticator.
    
+   
    Then, if this same user credential is copied to a different authenticator ("authenticator 2"), the Relying Party's first get() call on "authenticator 2" (that includes the devicePubKey extension) will produce an assertion including a signature by a new device-bound key ("dpk 2"). Note that such a multi-device credential can be exercised on "authenticator 2" without a create() having been performed on "authenticator 2". The Relying Party's subsequent get() calls on "authenticator 2", using the devicePubKey extension and the same user credential, yield further signatures by "dpk 2".
    
    
    A usage example is thus:
    
    
    
     
    Say that a sign-in request appears at a website along with some geolocation signal that has not been seen for this user account before, and is outside of the typical usage hours observed for the account. The risk may be deemed high enough not to allow the request, even with an assertion by a multi-device credential on its own. But if a signature by a device-bound key that is well established for this user can also be presented, then that may tip the balance.
    
    
    
-   
    Note: Relying Parties need to take care to verify device-bound key signatures before associating and storing extension output value fields in conjunction with the user account. See § 10.2.2.3 devicePubKey Extension Output Verification Procedures.
    
-   
    The weight that Relying Parties give to the presence of a signature from a device-bound key may be based on information learned from its optional attestation. An attestation can indicate the level of protection that the hardware offers the private key, certifications for the hardware, etc.
    
+   
    Note: Relying Parties need to take care to verify device-bound key signatures before associating and storing extension output value fields in conjunction with the user account. See § 10.2.2.3 devicePubKey Extension Output Verification Procedures.
    
+   
    The weight that Relying Parties give to the presence of a signature from a device-bound key may be based on information learned from its optional attestation. An attestation can indicate the level of protection that the hardware offers the private key, certifications for the hardware, etc.
    
    
    10.2.2.2. Extension Definition
    
    
    
     
    Extension identifier
@@ -6897,8 +7362,8 @@ 
    dictionary AuthenticationExtensionsDevicePublicKeyInputs {
-    DOMString attestation = "none";
-    sequence<DOMString> attestationFormats = [];
+    DOMString attestation = "none";
+    sequence<DOMString> attestationFormats = [];
 };
 
 partial dictionary AuthenticationExtensionsClientInputs {
@@ -6907,17 +7372,17 @@ 
    attestation,  of type DOMString, defaulting to "none"
+       
    attestation,  of type DOMString, defaulting to "none"
        
    
-        
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding attestation conveyance.
-Its value SHOULD be a member of AttestationConveyancePreference. Client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
+        
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding attestation conveyance.
+Its value SHOULD be a member of AttestationConveyancePreference. Client platforms MUST ignore unknown values, treating an unknown value as if the member does not exist.
    
         
    The default value is none.
    
-       
    attestationFormats,  of type sequence<DOMString>, defaulting to []
+       
    attestationFormats,  of type sequence<DOMString>, defaulting to []
        
    
-        
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding the attestation statement format used by the authenticator.
+        
    The Relying Party MAY use this OPTIONAL member to specify a preference regarding the attestation statement format used by the authenticator.
 Values SHOULD be taken from the IANA "WebAuthn Attestation Statement Format Identifiers" registry [IANA-WebAuthn-Registries] established by [RFC8809].
 Values are ordered from most preferable to least preferable.
-This parameter is advisory and the authenticator MAY use an attestation statement not enumerated in this parameter.
    
+This parameter is advisory and the authenticator MAY use an attestation statement not enumerated in this parameter.
    
         
    The default value is the empty list, which indicates no preference.
    
       
    
      
@@ -6955,7 +7420,7 @@ 
    public key credential source is not backup eligible then terminate these processing steps: this extension only applies to multi-device credentials.
    
       
  • 
-       
    If a hardware-bound device key pair does not already exist for this {Credential ID, RP ID, userHandle} tuple on the authenticator, create it using the same public key algorithm as that used by the user credential's credential key pair, otherwise locate the existing device-bound key.
    
+       
    If a hardware-bound device key pair does not already exist for this {Credential ID, RP ID, userHandle} tuple on the authenticator, create it using the same public key algorithm as that used by the user credential's credential key pair, otherwise locate the existing device-bound key.
    
       
  • 
        
    Let attFormat be the chosen attestation statement format, and attAaguid be a 16-byte value, based on the value of attestation in the extension input:
    
        
    
@@ -7040,11 +7505,11 @@ 
    attAaguid is 16 zero bytes. (Note that, since the device-bound key is already exercised during navigator.credentials.get() calls, the proof-of-possession property provided by "self" attestation is superfluous in that context.)
    
         
    indirect, direct
         
    
-         
    attFormat is an attestation statement format appropriate for this authenticator based on attestationFormats, and attAaguid is the authenticator’s AAGUID. (Since the hardware-bound device key pair is specific to a particular authenticator, its attestation can be tied to hardware roots of trust, although they do not have to be. This is in contrast to the associated user credential's attestation, if it is a multi-device credential.)
    
+         
    attFormat is an attestation statement format appropriate for this authenticator based on attestationFormats, and attAaguid is the authenticator’s AAGUID. (Since the hardware-bound device key pair is specific to a particular authenticator, its attestation can be tied to hardware roots of trust, although they do not have to be. This is in contrast to the associated user credential's attestation, if it is a multi-device credential.)
    
         
    enterprise
         
    
-         
    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. Authenticators MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested RP ID. If not permitted, then attFormat is "none" and attAaguid is 16 zero bytes. Otherwise attFormat is an attestation statement format appropriate for this authenticator based on attestationFormats, and attAaguid is the authenticator’s AAGUID. (Again, since the hardware-bound device key pair is specific to a particular authenticator, the attestation may be tied to hardware roots of trust.)
    
-         
    Note: CTAP2 does not currently provide for an enterpriseAttestation signal during an authenticatorGetAssertion call. Until that is changed, platform-managed enterprise attestation will not work in that context with CTAP2 authenticators.
    
+         
    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. Authenticators MUST NOT provide such an attestation unless the user agent or authenticator configuration expressly permits it for the requested RP ID. If not permitted, then attFormat is "none" and attAaguid is 16 zero bytes. Otherwise attFormat is an attestation statement format appropriate for this authenticator based on attestationFormats, and attAaguid is the authenticator’s AAGUID. (Again, since the hardware-bound device key pair is specific to a particular authenticator, the attestation may be tied to hardware roots of trust.)
    
+         
    Note: CTAP2 does not currently provide for an enterpriseAttestation signal during an authenticatorGetAssertion call. Until that is changed, platform-managed enterprise attestation will not work in that context with CTAP2 authenticators.
    
        
    
       
  • 
        
    Let dpk be the newly created or existing device public key, in COSE_Key format in the same fashion as for the user credential’s credentialPublicKey when the latter is conveyed in attested credential data.
    
@@ -7052,7 +7517,7 @@ 
    device private key.
    
       
  • 
        
    Let randomNonce be a fresh randomly-generated byte string of 32 bytes maximum length, or a zero length byte string if the authenticator chooses to not generate a nonce.
    
-       
    Note: randomNonce’s purpose is to randomize the devicePubKey extension’s attestation signature value. If this is not done, then the devicePubKey extension’s attestation signature value remains constant for all such signatures issued on behalf of this user credential, possibly exposing the authenticator's attestation private key to side-channel attacks. The randomness-generation mechanism should be carefully chosen by the authenticator implementer.
    
+       
    Note: randomNonce’s purpose is to randomize the devicePubKey extension’s attestation signature value. If this is not done, then the devicePubKey extension’s attestation signature value remains constant for all such signatures issued on behalf of this user credential, possibly exposing the authenticator's attestation private key to side-channel attacks. The randomness-generation mechanism should be carefully chosen by the authenticator implementer.
    
       
  • 
        
    Let the devicePubKey authenticator extension output value be a CBOR map as defined by attObjForDevicePublicKey above, with keys and values as follows:
    
        
    Note: as with all CBOR structures used in this specification, the CTAP2 canonical CBOR encoding form MUST be used.
    
@@ -7073,7 +7538,7 @@ 
    assertion signature input with devicePrivateKey.
    
-       
    Note: the assertion signature input, and thus dpkSig, covers the Relying Party's challenge because it includes the hash of the serialized client data. Thus the Relying Party knows that dpkSig is a fresh signature.
    
+       
    Note: the assertion signature input, and thus dpkSig, covers the Relying Party's challenge because it includes the hash of the serialized client data. Thus the Relying Party knows that dpkSig is a fresh signature.
    
       
  • 
        
    Output dpkSig as the extension’s unsigned extension output.
    
        
    Note: dpkSig cannot be included in the authenticator extension output because it is returned inside the authenticator data and that would imply that the signature signs over itself.
    
@@ -7082,7 +7547,7 @@ 
    10.2.2.2.1. AAGUIDs
    
    
    The AAGUID included in the devicePubKey extension output, if non-zero, identifies the make or model of hardware that is storing the device-bound key. This is distinct from the AAGUID in the attested credential data of a multi-device credential, which likely identifies something broader since such credentials are not bound to a single device. Thus the two AAGUIDs MAY be different in a single response and either, or both, may be zero depending on the options requested and authenticator behaviour.
    
    
    10.2.2.2.2. Attestation calculations
    
-   
    When computing attestations, the process in § 6.5.5 Generating an Attestation Object takes two inputs: authData and hash. When calculating an attestation for a device-bound key, the typical value for hash hashes over the attestation signature itself, which is impossible. Also the attestation of a device-bound key is potentially used repeatedly, thus may want to be cached. But signing over values that include Relying Party-chosen nonces, like the hash of the serialized client data, makes that impossible.
    
+   
    When computing attestations, the process in § 6.5.5 Generating an Attestation Object takes two inputs: authData and hash. When calculating an attestation for a device-bound key, the typical value for hash hashes over the attestation signature itself, which is impossible. Also the attestation of a device-bound key is potentially used repeatedly, thus may want to be cached. But signing over values that include Relying Party-chosen nonces, like the hash of the serialized client data, makes that impossible.
    
    
    Therefore when calculating an attestation for a device-bound key, the inputs are:
    
    
@@ -7853,7 +8318,7 @@ 
    
      
    WebAuthn Extension Identifier: appid
    
     
  • 
-     
    Description: This authentication extension allows WebAuthn Relying Parties that have previously registered a credential using the legacy
+     
    Description: This authentication extension allows WebAuthn Relying Parties that have previously registered a credential using the legacy
 FIDO JavaScript APIs to request an assertion.
    
     
  • 
      
    Specification Document: Section § 10.1.1 FIDO AppID Extension (appid) of this specification 

    
@@ -7861,7 +8326,7 @@ 
    WebAuthn Extension Identifier: uvm
    
     
  • 
      
    Description: This registration extension and authentication extension enables use of a user verification method.
-The user verification method extension returns to the WebAuthn Relying Party which user verification methods (factors) were
+The user verification method extension returns to the WebAuthn Relying Party which user verification methods (factors) were
 used for the WebAuthn operation.
    
     
  • 
      
    Specification Document: Section § 10.2.1 User Verification Method Extension (uvm) of this specification
    
@@ -7872,110 +8337,110 @@ 
    
      
    WebAuthn Extension Identifier: appidExclude
    
     
  • 
-     
    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].
    
+     
    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].
    
     
  • 
      
    Specification Document: Section § 10.1.2 FIDO AppID Exclusion Extension (appidExclude) of this specification 

    
     
  • 
      
    WebAuthn Extension Identifier: credProps
    
     
  • 
      
    Description: This client registration extension enables reporting of a newly-created credential's properties,
-as determined by the client, to the calling WebAuthn Relying Party's web application.
    
+as determined by the client, to the calling WebAuthn Relying Party's web application.
    
     
  • 
      
    Specification Document: Section § 10.1.3 Credential Properties Extension (credProps) of this specification 

    
     
  • 
      
    WebAuthn Extension Identifier: largeBlob
    
     
  • 
-     
    Description: This client registration extension and authentication extension allows a Relying Party to store opaque data associated with a credential.
    
+     
    Description: This client registration extension and authentication extension allows a Relying Party to store opaque data associated with a credential.
    
     
  • 
      
    Specification Document: Section § 10.1.5 Large blob storage extension (largeBlob) of this specification
    
    
    
    13. Security Considerations
    
    
    This specification defines a Web API and a cryptographic peer-entity authentication protocol.
-The Web Authentication API allows Web developers (i.e., "authors") to utilize the Web Authentication protocol in their registration and authentication ceremonies.
-The entities comprising the Web Authentication protocol endpoints are user-controlled WebAuthn Authenticators and a WebAuthn Relying Party's
-computing environment hosting the Relying Party's web application.
-In this model, the user agent, together with the WebAuthn Client, comprise an intermediary between authenticators and Relying Parties.
-Additionally, authenticators can attest to Relying Parties as to their provenance.
    
+The Web Authentication API allows Web developers (i.e., "authors") to utilize the Web Authentication protocol in their registration and authentication ceremonies.
+The entities comprising the Web Authentication protocol endpoints are user-controlled WebAuthn Authenticators and a WebAuthn Relying Party's
+computing environment hosting the Relying Party's web application.
+In this model, the user agent, together with the WebAuthn Client, comprise an intermediary between authenticators and Relying Parties.
+Additionally, authenticators can attest to Relying Parties as to their provenance.
    
    
    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.
    
+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
+while security considerations specifically for authenticator, client and Relying Party implementers
 are grouped into respective subsections.
    
    
    13.1. Credential ID Unsigned
    
    
    The credential ID is not signed.
-This is not a problem because all that would happen if an authenticator returns
-the wrong credential ID, or if an attacker intercepts and manipulates the credential ID, is that the WebAuthn Relying Party would not look up the correct credential public key with which to verify the returned signed authenticator data (a.k.a., assertion), and thus the interaction would end in an error.
    
+This is not a problem because all that would happen if an authenticator returns
+the wrong credential ID, or if an attacker intercepts and manipulates the credential ID, is that the WebAuthn Relying Party would not look up the correct credential public key with which to verify the returned signed authenticator data (a.k.a., assertion), and thus the interaction would end in an error.
    
    
    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.
+   
    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 have authentication factor.
-For example, if a roaming authenticator can communicate only via USB or Bluetooth,
+   
    The promise of physical proximity between client and authenticator is a key strength of a something you have authentication 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,
+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.
    
-   
    Direct communication between client and authenticator means the client can enforce the scope restrictions for credentials.
-By contrast, if the communication between client and authenticator is mediated by some third party,
-then the client has to trust the third party to
-enforce the scope restrictions and control access to the authenticator.
+   
    Direct communication between client and authenticator means the client can enforce the scope restrictions for credentials.
+By contrast, if the communication between client and authenticator is mediated by some third party,
+then the client has to trust the third party to
+enforce the scope restrictions and control access to the authenticator.
 Failure to do either could result in
-a malicious Relying Party receiving authentication assertions valid for other Relying Parties,
+a malicious Relying Party receiving authentication assertions valid for other Relying Parties,
 or in a malicious user gaining access to authentication assertions for other users.
    
-   
    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,
+   
    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.
    
-   
    13.3. Security considerations for authenticators 
    
+and the strength of the authenticator as a something you have authentication factor.
    
+   
    13.3. Security considerations for authenticators 
    
    
    13.3.1. Attestation Certificate Hierarchy
    
    
    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
+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
+   
    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
    
-   
    When an intermediate CA or a root CA used for issuing attestation certificates is compromised, WebAuthn Authenticator attestation key pairs are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
-has recorded the attestation public keys for their authenticator models can issue new attestation certificates for these keys from a new
-intermediate CA or from a new root CA. If the root CA changes, the WebAuthn Relying Parties MUST update their trusted root certificates
+   
    When an intermediate CA or a root CA used for issuing attestation certificates is compromised, WebAuthn Authenticator attestation key pairs are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
+has recorded the attestation public keys for their authenticator models can issue new attestation certificates for these keys from a new
+intermediate CA or from a new root CA. If the root CA changes, the WebAuthn Relying Parties MUST update their trusted root certificates
 accordingly.
    
-   
    A WebAuthn Authenticator attestation certificate MUST be revoked by the issuing CA if its private key has been compromised. A WebAuthn
+   
    A WebAuthn Authenticator attestation certificate MUST be revoked by the issuing CA if its private key has been compromised. A WebAuthn
 Authenticator manufacturer may need to ship a firmware update and inject new attestation private keys and certificates into already
-manufactured WebAuthn Authenticators, if the exposure was due to a firmware flaw. (The process by which this happens is out of
-scope for this specification.) If the WebAuthn Authenticator manufacturer does not have this capability, then it may not be
-possible for Relying Parties to trust any further attestation statements from the affected WebAuthn Authenticators.
    
-   
    See also the related security consideration for Relying Parties in § 13.4.5 Revoked Attestation Certificates.
    
-   
    13.4. Security considerations for Relying Parties
    
+manufactured WebAuthn Authenticators, if the exposure was due to a firmware flaw. (The process by which this happens is out of
+scope for this specification.) If the WebAuthn Authenticator manufacturer does not have this capability, then it may not be
+possible for Relying Parties to trust any further attestation statements from the affected WebAuthn Authenticators.
    
+   
    See also the related security consideration for Relying Parties in § 13.4.5 Revoked Attestation Certificates.
    
+   
    13.4. Security considerations for Relying Parties
    
    
    13.4.1. Security Benefits for WebAuthn Relying Parties
    
-   
    The main benefits offered to WebAuthn Relying Parties by this specification include:
    
+   
    The main benefits offered to WebAuthn Relying Parties by this specification include:
    
    
      
     
    1. 
      
      Users and accounts can be secured using widely compatible, easy-to-use multi-factor authentication.
      
     
    2. 
-     
      The Relying Party does not need to provision authenticator hardware to its users. Instead, each user can independently obtain
-any conforming authenticator and use that same authenticator with any number of Relying Parties. The Relying Party can optionally
-enforce requirements on authenticators' security properties by inspecting the attestation statements returned from the authenticators.
      
+     
      The Relying Party does not need to provision authenticator hardware to its users. Instead, each user can independently obtain
+any conforming authenticator and use that same authenticator with any number of Relying Parties. The Relying Party can optionally
+enforce requirements on authenticators' security properties by inspecting the attestation statements returned from the authenticators.
      
     
    3. 
-     
      Authentication ceremonies are resistant to man-in-the-middle attacks.
-Regarding registration ceremonies, see § 13.4.4 Attestation Limitations, below.
      
+     
      Authentication ceremonies are resistant to man-in-the-middle attacks.
+Regarding registration ceremonies, see § 13.4.4 Attestation Limitations, below.
      
     
    4. 
-     
      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 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.
      
     
    5. 
-     
      The Relying Party does not need to store additional secrets in order to gain the above benefits.
      
+     
      The Relying Party does not need to store additional secrets in order to gain the above benefits.
      
    
    
-   
    As stated in the Conformance section, the Relying Party MUST behave as described in § 7 WebAuthn Relying Party Operations to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described below in § 13.4.4 Attestation Limitations.
    
+   
    As stated in the Conformance section, the Relying Party MUST behave as described in § 7 WebAuthn Relying Party Operations to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described below in § 13.4.4 Attestation Limitations.
    
    
    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.
    
+   
    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
+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
+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
@@ -7983,248 +8448,292 @@ 
    13.4.4. Attestation Limitations
    
    
    This section is not normative.
    
    
    When registering a new credential, the attestation statement, if present,
-may allow the WebAuthn Relying Party to derive assurances about various authenticator qualities.
-For example, the authenticator model, or how it stores and protects credential private keys.
+may allow the WebAuthn Relying Party to derive assurances about various authenticator qualities.
+For example, the authenticator model, or how it stores and protects credential private keys.
 However, it is important to note that an attestation statement, on its own,
-provides no means for a Relying Party to verify that an attestation object was generated
-by the authenticator the user intended, and not by a man-in-the-middle attacker.
-For example, such an attacker could use malicious code injected into Relying Party script.
-The Relying Party must therefore rely on other means, e.g., TLS and related technologies,
+provides no means for a Relying Party to verify that an attestation object was generated
+by the authenticator the user intended, and not by a man-in-the-middle attacker.
+For example, such an attacker could use malicious code injected into Relying Party script.
+The Relying Party must therefore rely on other means, e.g., TLS and related technologies,
 to protect the attestation object from man-in-the-middle attacks.
    
-   
    Under the assumption that a registration ceremony is completed securely, and that the authenticator maintains
-confidentiality of the credential private key, subsequent authentication ceremonies using that public key
+   
    Under the assumption that a registration ceremony is completed securely, and that the authenticator maintains
+confidentiality of the credential private key, subsequent authentication ceremonies using that public key
 credential are resistant to tampering by man-in-the-middle attacks.
    
-   
    The discussion above holds for all attestation types. In all cases it is possible for a man-in-the-middle attacker to replace the PublicKeyCredential object, including the attestation statement and the credential public key to be registered, and subsequently tamper with future authentication assertions scoped for the
-same Relying Party and passing through the same attacker.
    
-   
    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
+   
    The discussion above holds for all attestation types. In all cases it is possible for a man-in-the-middle attacker to replace the PublicKeyCredential object, including the attestation statement and the credential public key to be registered, and subsequently tamper with future authentication assertions scoped for the
+same Relying Party and passing through the same attacker.
    
+   
    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.
    
-   
    Attestation types other than Self Attestation and None can increase the difficulty of such attacks, since Relying Parties can possibly display authenticator information, e.g., model designation, to the user. An attacker might therefore need to use
-a genuine authenticator of the same model as the user’s authenticator, or the user might notice that the Relying Party reports
-a different authenticator model than the user expects.
    
+   
    Attestation types other than Self Attestation and None can increase the difficulty of such attacks, since Relying Parties can possibly display authenticator information, e.g., model designation, to the user. An attacker might therefore need to use
+a genuine authenticator of the same model as the user’s authenticator, or the user might notice that the Relying Party reports
+a different authenticator model than the user expects.
    
    
    Note: All variants of man-in-the-middle attacks described above are more difficult for an attacker to mount
 than a man-in-the-middle attack against conventional password authentication.
    
    
    13.4.5. Revoked Attestation Certificates
    
-   
    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
+   
    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
+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.
    
-   
    See also the related security consideration for authenticators in § 13.3.2 Attestation Certificate and Attestation Certificate CA Compromise.
    
+   
    See also the related security consideration for authenticators in § 13.3.2 Attestation Certificate and Attestation Certificate CA Compromise.
    
    
    13.4.6. Credential Loss and Key Mobility
    
-   
    This specification defines no protocol for backing up credential private keys, or for sharing them between authenticators.
-In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the
-lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering
+   
    This specification defines no protocol for backing up credential private keys, or for sharing them between authenticators.
+In general, it is expected that a credential private key never leaves the authenticator that created it. Losing an authenticator therefore, in general, means losing all credentials bound to the
+lost authenticator, which could lock the user out of an account if the user has only one credential registered with the Relying Party. Instead of backing up or sharing private keys, the Web Authentication API allows registering
 multiple credentials for the same user. For example, a user might register platform credentials on
-frequently used client devices, and one or more roaming credentials for use as backup and with new or rarely used client
+frequently used client devices, and one or more roaming credentials for use as backup and with new or rarely used client
 devices.
    
-   
    Relying Parties SHOULD allow and encourage users to register multiple credentials to the same user account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these
-different credentials are bound to different authenticators.
    
+   
    Relying Parties SHOULD allow and encourage users to register multiple credentials to the same user account. Relying Parties SHOULD make use of the excludeCredentials and user.id options to ensure that these
+different credentials are bound to different authenticators.
    
    
    13.4.7. Unprotected account detection
    
    
    This section is not normative.
    
-   
    This security consideration applies to Relying Parties that support authentication ceremonies with a non-empty allowCredentials argument as the first authentication step.
+   
    This security consideration applies to Relying Parties that support authentication ceremonies with a non-empty allowCredentials argument as the first authentication step.
 For example, if using authentication with server-side credentials as the first authentication step.
    
-   
    In this case the allowCredentials argument risks leaking information
+   
    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 a non-empty allowCredentials for some user accounts,
+For example, say an attacker can initiate an authentication ceremony by providing only a username,
+and the Relying Party responds with a non-empty allowCredentials for some user accounts,
 and with failure or a password challenge for other user accounts.
-The attacker can then conclude that the latter user accounts likely do not require a WebAuthn assertion for successful authentication,
+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 issue is similar to the one described in § 14.6.2 Username Enumeration and § 14.6.3 Privacy leak via credential IDs, and can be mitigated in similar ways.
    
    
    13.4.8. Code injection attacks
    
-   
    Any malicious code executing on an origin within the scope of a Relying Party's public key credentials has the potential to invalidate any and all security guarantees WebAuthn may provide. WebAuthn Clients only expose the WebAuthn API in secure contexts,
-which mitigates the most basic attacks but SHOULD be combined with additional precautions by Relying Parties.
    
+   
    Any malicious code executing on an origin within the scope of a Relying Party's public key credentials has the potential to invalidate any and all security guarantees WebAuthn may provide. WebAuthn Clients only expose the WebAuthn API in secure contexts,
+which mitigates the most basic attacks but SHOULD be combined with additional precautions by Relying Parties.
    
    
    Code injection can happen in several ways;
 this section attempts to point out some likely scenarios and suggest suitable mitigations,
 but is not an exhaustive list.
    
    
+   
    13.4.9. Validating the origin of a credential
    
+   
    When registering a credential and
+when verifying an assertion,
+the Relying Party MUST validate the origin member of the client data.
    
+   
    The Relying Party MUST NOT accept unexpected values of origin,
+as doing so could allow a malicious website to obtain valid credentials.
+Although the scope of WebAuthn credentials prevents their use on domains
+outside the RP ID they were registered for,
+the Relying Party's origin validation serves as an additional layer of protection
+in case a faulty authenticator fails to enforce credential scope.
+See also § 13.4.8 Code injection attacks for discussion of potentially malicious subdomains.
    
+   
    Validation MAY be performed by exact string matching or any other method as needed by the Relying Party.
+For example:
    
+   
      
+    
    • 
+     
      A web application served only at https://example.org SHOULD require origin to exactly equal https://example.org.
      
+     
      This is the simplest case, where origin is expected
+to be the string https:// followed by the RP ID.
      
+    
    • 
+     
      A web application served at a small number of domains might require origin to exactly equal some element of a list of allowed origins,
+for example the list ["https://example.org", "https://login.example.org"].
      
+    
    • 
+     
      A web application served at a large set of domains that changes often might parse origin structurally and require that the URL scheme is https and that the authority equals or is any subdomain of the RP ID - for example, example.org or any subdomain of example.org).
      
+     
      Note: See § 13.4.8 Code injection attacks for a discussion of the risks of allowing any subdomain of the RP ID.
      
+    
    • 
+     
      A web application with a companion native application might allow origin to be an operating system dependent
+identifier for the native application. For example, such a Relying Party might require that origin exactly equals some element of the list ["https://example.org", "example-os:appid:204ffa1a5af110ac483f131a1bef8a841a7adb0d8d135908bbd964ed05d2653b"].
      
+   
    
+   
    Similar considerations apply when validating the topOrigin member of the client data.
+When topOrigin is present, the Relying Party MUST validate that its value is expected.
+This validation MAY be performed by exact string matching or any other method as needed by the Relying Party.
+For example:
    
+   
      
+    
    • 
+     
      A web application that does not wish to be embedded in a cross-origin iframe might require topOrigin to exactly equal origin.
      
+    
    • 
+     
      A web application that wishes to be embedded in a cross-origin iframe on a small number of domains
+might require topOrigin to exactly equal some element of a list of allowed origins,
+for example the list ["https://example-partner1.org", "https://login.partner2-example.org"].
      
+    
    • 
+     
      A web application that wishes to be embedded in a cross-origin iframe on a large number of domains
+might allow any value of topOrigin, or use a dynamic procedure
+to determine whether a given topOrigin value is allowed for a particular ceremony.
      
    
    
    
    14. Privacy Considerations
    
    
    The privacy principles in [FIDO-Privacy-Principles] also apply to this specification.
    
    
    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
+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
+   
    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
+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:
    
    
-   
    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.
    
+   
    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.
    
    
    14.2. Anonymous, Scoped, Non-correlatable Public Key Credentials
    
    
    This section is not normative.
    
-   
    Although Credential IDs and credential public keys are necessarily shared with the WebAuthn Relying Party to enable strong
-authentication, they are designed to be minimally identifying and not shared between Relying Parties.
    
+   
    Although Credential IDs and credential public keys are necessarily shared with the WebAuthn Relying Party to enable strong
+authentication, they are designed to be minimally identifying and not shared between Relying Parties.
    
    
-   
    Additionally, a client-side discoverable public key credential source can optionally include a user
-handle specified by the Relying Party. The credential can then be used to both identify and authenticate the user.
-This means that a privacy-conscious Relying Party can allow creation of a user account without a traditional username,
-further improving non-correlatability between Relying Parties.
    
+   
    Additionally, a client-side discoverable public key credential source can optionally include a user
+handle specified by the Relying Party. The credential can then be used to both identify and authenticate the user.
+This means that a privacy-conscious Relying Party can allow creation of a user account without a traditional username,
+further improving non-correlatability between Relying Parties.
    
    
    14.3. Authenticator-local Biometric Recognition
    
-   
    Biometric authenticators perform the biometric recognition internally in the authenticator - though for platform
-authenticators the biometric data might also be visible to the client, depending on the implementation. Biometric data is
-not revealed to the WebAuthn Relying Party; it is used only locally to perform user verification authorizing the creation and registration of, or authentication using, a public key credential. A malicious Relying Party therefore cannot discover the
-user’s personal identity via biometric data, and a security breach at a Relying Party cannot expose biometric data for an attacker to
-use for forging logins at other Relying Parties.
    
-   
    In the case where a Relying Party requires biometric recognition, this is performed locally by the biometric authenticator perfoming user verification and then signaling the result by setting the UV flag in the signed assertion response,
-instead of revealing the biometric data itself to the Relying Party.
    
-   
    14.4. Privacy considerations for authenticators
    
+   
    Biometric authenticators perform the biometric recognition internally in the authenticator - though for platform
+authenticators the biometric data might also be visible to the client, depending on the implementation. Biometric data is
+not revealed to the WebAuthn Relying Party; it is used only locally to perform user verification authorizing the creation and registration of, or authentication using, a public key credential. A malicious Relying Party therefore cannot discover the
+user’s personal identity via biometric data, and a security breach at a Relying Party cannot expose biometric data for an attacker to
+use for forging logins at other Relying Parties.
    
+   
    In the case where a Relying Party requires biometric recognition, this is performed locally by the biometric authenticator perfoming user verification and then signaling the result by setting the UV flag in the signed assertion response,
+instead of revealing the biometric data itself to the Relying Party.
    
+   
    14.4. Privacy considerations for authenticators
    
    
    14.4.1. Attestation Privacy
    
    
    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:
    
    
    
    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.
    
-   
    For the purposes of this discussion, the user handle conveyed as the id member of PublicKeyCredentialUserEntity is not considered personally identifying information; see § 14.6.1 User Handle Contents.
    
-   
    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).
    
-   
    14.5. Privacy considerations for clients
    
+   
    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.
    
+   
    For the purposes of this discussion, the user handle conveyed as the id member of PublicKeyCredentialUserEntity is not considered personally identifying information; see § 14.6.1 User Handle Contents.
    
+   
    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).
    
+   
    14.5. Privacy considerations for clients
    
    
    14.5.1. Registration Ceremony Privacy
    
    
    In order to protect users from being identified without consent, implementations of the [[Create]](origin, options, sameOriginWithAncestors) method need to take care to not leak information that
-could enable a malicious WebAuthn Relying Party to distinguish between these cases, where "excluded" means that at least one of the credentials listed by the Relying Party in excludeCredentials is bound to the authenticator:
    
+could enable a malicious WebAuthn Relying Party to distinguish between these cases, where "excluded" means that at least one of the credentials listed by the Relying Party in excludeCredentials is bound to the authenticator:
    
    
-   
    If the above cases are distinguishable, information is leaked by which a malicious Relying Party could identify the user by probing for
+   
    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
+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.
    
    
    14.5.2. Authentication Ceremony Privacy
    
    
    In order to protect users from being identified without consent, implementations of the [[DiscoverFromExternalSource]](origin, options, sameOriginWithAncestors) method need to take care to not
-leak information that could enable a malicious WebAuthn Relying Party to distinguish between these cases, where "named" means that the credential is listed by the Relying Party in allowCredentials:
    
+leak information that could enable a malicious WebAuthn Relying Party to distinguish between these cases, where "named" means that the credential is listed by the Relying Party in allowCredentials:
    
    
-   
    If the above cases are distinguishable, information is leaked by which a malicious Relying Party could identify the user by probing
+   
    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
+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.
    
    
    14.5.3. Privacy Between Operating System Accounts
    
-   
    If a platform authenticator is included in a client device with a multi-user operating system, the platform
-authenticator and client device SHOULD work together to ensure that the existence of any platform credential is revealed
+   
    If a platform authenticator is included in a client device with a multi-user operating system, the platform
+authenticator and client device SHOULD work together to ensure that the existence of any platform credential is revealed
 only to the operating system user that created that platform credential.
    
-   
    14.6. Privacy considerations for Relying Parties
    
+   
    14.6. Privacy considerations for Relying Parties
    
    
    14.6.1. User Handle Contents
    
-   
    Since the user handle is not considered personally identifying information in § 14.4.2 Privacy of personally identifying information Stored in Authenticators,
-and since authenticators MAY reveal user handles without first performing user verification,
-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 account.
    
+   
    Since the user handle is not considered personally identifying information in § 14.4.2 Privacy of personally identifying information Stored in Authenticators,
+and since authenticators MAY reveal user handles without first performing user verification,
+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 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 authentication ceremony 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 a user 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
+   
    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 authentication ceremony 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 a user 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:
    
    
    
  • android key attestation certificate extension data, in § 8.4.1
    
  • AnonCA, in § 6.5.4
@@ -8370,8 +8879,9 @@ 
    dict-member for AuthenticationExtensionsDevicePublicKeyInputs, in § 10.2.2.2
      
  • dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • Attestation CA, in § 6.5.4
    
  • Attestation Certificate, in § 4
@@ -8384,7 +8894,9 @@ 
    dict-member for AuthenticationExtensionsDevicePublicKeyInputs, in § 10.2.2.2
      
  • dict-member for PublicKeyCredentialCreationOptions, in § 5.4
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • attestation key pair, in § 4
    
  • attestation object, in § 6.5
@@ -8394,6 +8906,7 @@ 
    abstract-op for credential record, in § 4
      
  • attribute for AuthenticatorAssertionResponse, in § 5.2.2
      
  • attribute for AuthenticatorAttestationResponse, in § 5.2.1
+     
  • dict-member for AuthenticatorAssertionResponseJSON, in § 5.1
      
  • dict-member for AuthenticatorAttestationResponseJSON, in § 5.1
     
    
  • attestationObjectResult, in § 5.1.3
@@ -8413,7 +8926,7 @@ 
    Authentication Ceremony, in § 4
    
  • authentication extension, in § 9
    
  • AuthenticationExtensionsClientInputs, in § 5.7.1
-   
  • AuthenticationExtensionsClientInputsJSON, in § 5.1.8
+   
  • AuthenticationExtensionsClientInputsJSON, in § 5.1.9
    
  • AuthenticationExtensionsClientOutputs, in § 5.7.2
    
  • AuthenticationExtensionsClientOutputsJSON, in § 5.1
    
  • AuthenticationExtensionsDevicePublicKeyInputs, in § 10.2.2.2
@@ -8448,6 +8961,7 @@ 
    attribute for AuthenticatorAssertionResponse, in § 5.2.2
      
  • dict-member for AuthenticatorAssertionResponseJSON, in § 5.1
+     
  • dict-member for AuthenticatorAttestationResponseJSON, in § 5.1
     
    
  • authenticator data claimed to have been used for the attestation, in § 6.5.3
    
  • authenticator data for the attestation, in § 6.5.3
@@ -8467,7 +8981,7 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
     
    
  • AuthenticatorSelectionCriteria, in § 5.4.4
    
  • authenticator session, in § 6.3
@@ -8503,9 +9017,9 @@ 
    dict-member for CollectedClientData, in § 5.8.1
      
  • dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
-     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • Client, in § 4
    
  • client data, in § 5.8.1
@@ -8522,7 +9036,9 @@ 
    dfn for assertionCreationData, in § 5.1.4.1
      
  • dfn for credentialCreationData, in § 5.1.3
     
+   
  • "client-device", in § 5.8.7
    
  • Client Device, in § 4
+   
  • client-device, in § 5.8.7
    
  • client extension, in § 9
    
  • client extension input, in § 9.3
    
  • client extension output, in § 9.4
@@ -8613,7 +9129,7 @@ 
    dict-member for PublicKeyCredentialUserEntity, in § 5.4.3
-     
  • dict-member for PublicKeyCredentialUserEntityJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialUserEntityJSON, in § 5.1.9
     
    
  • dpk, in § 10.2.2.3
    
  • ED, in § 6.1
@@ -8629,7 +9145,7 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
     
    
  • extension identifier, in § 9.1
    
  • 
@@ -8637,9 +9153,9 @@ 
    dfn for authData, in § 6.1
      
  • dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
-     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • first, in § 10.1.4
    
  • First-factor roaming authenticator, in § 6.2
@@ -8654,9 +9170,27 @@ 
    getTransports(), in § 5.2.1
    
  • Hardware-bound Device Key Pair, in § 4
    
  • Hash of the serialized client data, in § 5.8.1
+   
  • 
+    hints
+    
    
  • Human Palatability, in § 4
-   
  • "hybrid", in § 5.8.4
-   
  • hybrid, in § 5.8.4
+   
  • 
+    "hybrid"
+    
+   
  • 
+    hybrid
+    
    
  • 
     id
     
@@ -8678,6 +9212,7 @@ 
    "internal", in § 5.8.4
    
  • internal, in § 5.8.4
    
  • isConditionalMediationAvailable(), in § 5.1
+   
  • isPasskeyPlatformAuthenticatorAvailable(), in § 5.1.8
    
  • Issuing a Credential Request to an Authenticator, in § 5.1.4.2
    
  • isUserVerifyingPlatformAuthenticatorAvailable(), in § 5.1.7
    
  • JSON-compatible serialization of client data, in § 5.8.1
@@ -8698,7 +9233,7 @@ 
    dict-member for PublicKeyCredentialEntity, in § 5.4.1
-     
  • dict-member for PublicKeyCredentialUserEntityJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialUserEntityJSON, in § 5.1.9
     
    
  • "nfc", in § 5.8.4
    
  • nfc, in § 5.8.4
@@ -8714,8 +9249,10 @@ 
    dfn for DiscoverableCredentialMetadata, in § 6.3.5
      
  • dfn for public key credential source, in § 4
     
-   
  • parseCreationOptionsFromJSON(options), in § 5.1.8
-   
  • parseRequestOptionsFromJSON(options), in § 5.1.9
+   
  • parseCreationOptionsFromJSON(options), in § 5.1.9
+   
  • parseRequestOptionsFromJSON(options), in § 5.1.10
+   
  • Passkey, in § 4
+   
  • Passkey platform authenticator, in § 6.2
    
  • perform the following steps to generate an authenticator data structure, in § 6.1
    
  • "platform", in § 5.4.5
    
  • platform, in § 5.4.5
@@ -8750,7 +9287,7 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
     
    
  • "public-key", in § 5.8.2
    
  • public-key, in § 5.8.2
@@ -8758,27 +9295,30 @@ 
    abstract-op for credential record, in § 4
+     
  • dict-member for AuthenticatorAttestationResponseJSON, in § 5.1
      
  • dict-member for CredentialCreationOptions, in § 5.1.1
      
  • dict-member for CredentialRequestOptions, in § 5.1.2
     
+   
  • publicKeyAlgorithm, in § 5.1
    
  • Public Key Credential, in § 4
    
  • PublicKeyCredential, in § 5.1
    
  • PublicKeyCredentialCreationOptions, in § 5.4
-   
  • PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+   
  • PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
    
  • PublicKeyCredentialDescriptor, in § 5.8.3
-   
  • PublicKeyCredentialDescriptorJSON, in § 5.1.8
+   
  • PublicKeyCredentialDescriptorJSON, in § 5.1.9
    
  • PublicKeyCredentialEntity, in § 5.4.1
+   
  • PublicKeyCredentialHints, in § 5.8.7
    
  • PublicKeyCredentialJSON, in § 5.1
    
  • PublicKeyCredentialParameters, in § 5.3
    
  • PublicKeyCredentialRequestOptions, in § 5.5
-   
  • PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+   
  • PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
    
  • PublicKeyCredentialRpEntity, in § 5.4.2
    
  • publickey-credentials-create-feature, in § 5.9
    
  • publickey-credentials-get-feature, in § 5.9
    
  • Public Key Credential Source, in § 4
    
  • PublicKeyCredentialType, in § 5.8.2
    
  • PublicKeyCredentialUserEntity, in § 5.4.3
-   
  • PublicKeyCredentialUserEntityJSON, in § 5.1.8
+   
  • PublicKeyCredentialUserEntityJSON, in § 5.1.9
    
  • Rate Limiting, in § 4
    
  • 
     rawId
@@ -8831,7 +9371,7 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
     
    
  • RP ID, in § 4
    
  • 
@@ -8839,7 +9379,7 @@ 
    dfn for public key credential source, in § 4
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
-     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • rpIdHash, in § 6.1
    
  • 
@@ -8851,6 +9391,8 @@ 
    second, in § 10.1.4
    
  • Second-factor platform authenticator, in § 6.2
    
  • Second-factor roaming authenticator, in § 6.2
+   
  • "security-key", in § 5.8.7
+   
  • security-key, in § 5.8.7
    
  • selected authenticator, in § 5.1.3
    
  • Self, in § 6.5.4
    
  • Self Attestation, in § 6.5.4
@@ -8894,9 +9436,9 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
-     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • toJSON(), in § 5.1
    
  • TokenBinding, in § 5.8.1
@@ -8910,7 +9452,7 @@ 
    abstract-op for credential record, in § 4
      
  • dict-member for AuthenticatorAttestationResponseJSON, in § 5.1
      
  • dict-member for PublicKeyCredentialDescriptor, in § 5.8.3
-     
  • dict-member for PublicKeyCredentialDescriptorJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialDescriptorJSON, in § 5.1.9
     
    
  • [[type]], in § 5.1
    
  • 
@@ -8922,7 +9464,7 @@ 
    dict-member for AuthenticationResponseJSON, in § 5.1
      
  • dict-member for CollectedClientData, in § 5.8.1
      
  • dict-member for PublicKeyCredentialDescriptor, in § 5.8.3
-     
  • dict-member for PublicKeyCredentialDescriptorJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialDescriptorJSON, in § 5.1.9
      
  • dict-member for PublicKeyCredentialParameters, in § 5.3
      
  • dict-member for RegistrationResponseJSON, in § 5.1
     
@@ -8935,7 +9477,7 @@ 
    dict-member for PublicKeyCredentialCreationOptions, in § 5.4
-     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.8
+     
  • dict-member for PublicKeyCredentialCreationOptionsJSON, in § 5.1.9
     
    
  • User Account, in § 4
    
  • User Consent, in § 4
@@ -8957,7 +9499,7 @@ 
    dict-member for AuthenticatorSelectionCriteria, in § 5.4.4
      
  • dict-member for PublicKeyCredentialRequestOptions, in § 5.5
-     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.9
+     
  • dict-member for PublicKeyCredentialRequestOptionsJSON, in § 5.1.10
     
    
  • User Verification Method, in § 10.2.1
    
  • UserVerificationRequirement, in § 5.8.6
@@ -9000,9 +9542,9 @@ 
    CredentialRequestOptions
      
  • CredentialsContainer
      
  • Request a Credential
-     
  • [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)
-     
  • [[Create]](origin, options, sameOriginWithAncestors)
-     
  • [[Store]](credential, sameOriginWithAncestors)
+     
  • [[CollectFromCredentialStore]](origin, options, sameOriginWithAncestors)
+     
  • [[Create]](origin, options, sameOriginWithAncestors)
+     
  • [[Store]](credential, sameOriginWithAncestors)
      
  • [[discovery]]
      
  • [[type]]
      
  • conditional
@@ -9020,11 +9562,6 @@ 
    type
      
  • user mediation
     
-   
  • 
-    [CSS-COLOR-3] defines the following terms:
-    
      
-     
    • window
-    
    
    
  • 
     [DOM4] defines the following terms:
     
      
@@ -9085,6 +9622,7 @@ 
      
     [HTML] defines the following terms:
     
        
+     
      • Window
      
      • allow
      
      • allowed to use
      
      • ascii serialization of an origin
@@ -9285,6 +9823,7 @@ 
        interface object
      
      • json type
      
      • long
+     
      • long long
      
      • record
      
      • sequence
      
      • unsigned long
@@ -9302,8 +9841,6 @@ 
        N
    
        Mike West. Credential Management Level 1. URL: https://w3c.github.io/webappsec-credential-management/
    
        [CSP2]
    
        Mike West; Adam Barth; Daniel Veditz. Content Security Policy Level 2. URL: https://w3c.github.io/webappsec-csp/
-   
        [CSS-COLOR-3]
-   
        Tantek Çelik; Chris Lilley; David Baron. CSS Color Module Level 3. URL: https://drafts.csswg.org/css-color-3/
    
        [DOM4]
    
        Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
    
        [ECMAScript]
@@ -9467,8 +10004,19 @@ 
        I
 
 dictionary AuthenticatorAttestationResponseJSON {
     required Base64URLString clientDataJSON;
-    required Base64URLString attestationObject;
+    required Base64URLString authenticatorData;
     required sequence<DOMString> transports;
+    // The publicKey field will be missing if pubKeyCredParams was used to
+    // negotiate a public-key algorithm that the user agent doesn’t
+    // understand. (See section “Easily accessing credential data” for a
+    // list of which algorithms user agents must support.) If using such an
+    // algorithm then the public key must be parsed directly from
+    // attestationObject or authenticatorData.
+    Base64URLString publicKey;
+    required long long publicKeyAlgorithm;
+    // This value contains copies of some of the fields above. See
+    // section “Easily accessing credential data”.
+    required Base64URLString attestationObject;
 };
 
 dictionary AuthenticationResponseJSON {
@@ -9485,6 +10033,7 @@ 
        I
     required Base64URLString authenticatorData;
     required Base64URLString signature;
     Base64URLString userHandle;
+    Base64URLString attestationObject;
 };
 
 dictionary AuthenticationExtensionsClientOutputsJSON {
@@ -9502,6 +10051,10 @@ 
        I
     static Promise<boolean> isUserVerifyingPlatformAuthenticatorAvailable();
 };
 
+partial interface PublicKeyCredential {
+    static Promise<boolean> isPasskeyPlatformAuthenticatorAvailable();
+};
+
 partial interface PublicKeyCredential {
     static PublicKeyCredentialCreationOptions parseCreationOptionsFromJSON(PublicKeyCredentialCreationOptionsJSON options);
 };
@@ -9514,7 +10067,9 @@ 
        I
     unsigned long                                           timeout;
     sequence<PublicKeyCredentialDescriptorJSON>             excludeCredentials = [];
     AuthenticatorSelectionCriteria                          authenticatorSelection;
+    sequence<DOMString>                                     hints = [];
     DOMString                                               attestation = "none";
+    sequence<DOMString>                                     attestationFormats = [];
     AuthenticationExtensionsClientInputsJSON                extensions;
 };
 
@@ -9543,6 +10098,9 @@ 
        I
     DOMString                                               rpId;
     sequence<PublicKeyCredentialDescriptorJSON>             allowCredentials = [];
     DOMString                                               userVerification = "preferred";
+    sequence<DOMString>                                     hints = [];
+    DOMString                                               attestation = "none";
+    sequence<DOMString>                                     attestationFormats = [];
     AuthenticationExtensionsClientInputsJSON                extensions;
 };
 
@@ -9583,6 +10141,7 @@ 
        I
     unsigned long                                timeout;
     sequence<PublicKeyCredentialDescriptor>      excludeCredentials = [];
     AuthenticatorSelectionCriteria               authenticatorSelection;
+    sequence<DOMString>                          hints = [];
     DOMString                                    attestation = "none";
     sequence<DOMString>                          attestationFormats = [];
     AuthenticationExtensionsClientInputs         extensions;
@@ -9632,6 +10191,7 @@ 
        I
     USVString                            rpId;
     sequence<PublicKeyCredentialDescriptor> allowCredentials = [];
     DOMString                            userVerification = "preferred";
+    sequence<DOMString>                  hints = [];
     DOMString                            attestation = "none";
     sequence<DOMString>                  attestationFormats = [];
     AuthenticationExtensionsClientInputs extensions;
@@ -9685,6 +10245,12 @@ 
        I
     "discouraged"
 };
 
+enum PublicKeyCredentialHints {
+    "security-key",
+    "client-device",
+    "hybrid",
+};
+
 partial dictionary AuthenticationExtensionsClientInputs {
   USVString appid;
 };
@@ -10022,7 +10588,7 @@ 
        
    ⚠MDN
    
        
-    
        Headers/Feature-Policy/publickey-credentials-get
        
+    
        Headers/Feature-Policy/publickey-credentials-get
        
     
        In only one current engine.
        
     
        
      FirefoxNoneSafariNoneChrome84+
@@ -10048,7 +10614,7 @@ 
        
-    
        Headers/Permissions-Policy/publickey-credentials-get
        
+    
        Headers/Permissions-Policy/publickey-credentials-get
        
     
        In only one current engine.
        
     
        
      FirefoxNoneSafariNoneChrome88+
@@ -10061,50 +10627,160 @@ 
        
+                    mk.li({},
+                        ...section.refs.map((ref, refI)=>
+                            [
+                                mk.a({
+                                    href: `#${ref.id}`
+                                    },
+                                    (refI == 0) ? section.title : `(${refI + 1})`
+                                ),
+                                " ",
+                            ]
+                        ),
+                    ),
+                ),
+            ),
+        );
+    }
+
+    function genAllDfnPanels() {
+        for(const panelData of Object.values(window.dfnpanelData)) {
+            const dfnID = panelData.dfnID;
+            const dfn = document.getElementById(dfnID);
+            if(!dfn) {
+                console.log(`Can't find dfn#${dfnID}.`, panelData);
+            } else {
+                const panel = genDfnPanel(panelData);
+                append(document.body, panel);
+                insertDfnPopupAction(dfn, panel)
+            }
         }
-        const rect = dfn.getBoundingClientRect();
-        const top = window.scrollY + rect.top
-        panel.style.top = top + "px";
-        panel.top = top;
-        panel.height = rect.height;
-        panel.classList.remove("unpositioned");
-        const panelRect = panel.getBoundingClientRect()
-        if(main) {
-            panel.classList.toggle("overlapping-main", panelRect.left < mainRect.right)
+    }
+
+    document.addEventListener("DOMContentLoaded", ()=>{
+        genAllDfnPanels();
+
+        // Add popup behavior to all dfns to show the corresponding dfn-panel.
+        var dfns = queryAll('.dfn-paneled');
+        for(let dfn of dfns) { ; }
+
+        document.body.addEventListener("click", (e) => {
+            // If not handled already, just hide all dfn panels.
+            hideAllDfnPanels();
+        });
+    })
+
+
+    function hideAllDfnPanels() {
+        // Turn off any currently "on" or "activated" panels.
+        queryAll(".dfn-panel.on, .dfn-panel.activated").forEach(el=>hideDfnPanel(el));
+    }
+
+    function showDfnPanel(dfnPanel, dfn) {
+        hideAllDfnPanels(); // Only display one at this time.
+        dfn.setAttribute("aria-expanded", "true");
+        dfnPanel.classList.add("on");
+        dfnPanel.style.left = "5px";
+        dfnPanel.style.top = "0px";
+        const panelRect = dfnPanel.getBoundingClientRect();
+        const panelWidth = panelRect.right - panelRect.left;
+        if (panelRect.right > document.body.scrollWidth) {
+            // Panel's overflowing the screen.
+            // Just drop it below the dfn and flip it rightward instead.
+            // This still wont' fix things if the screen is *really* wide,
+            // but fixing that's a lot harder without 'anchor()'.
+            dfnPanel.style.top = "1.5em";
+            dfnPanel.style.left = "auto";
+            dfnPanel.style.right = "0px";
         }
     }
-    let vSoFar = 0;
-    for(const panel of panels.sort(cmpTops)) {
-        if(panel.top < vSoFar) {
-            panel.top = vSoFar;
-            panel.style.top = vSoFar + "px";
+
+    function pinDfnPanel(dfnPanel) {
+        // Switch it to "activated" state, which pins it.
+        dfnPanel.classList.add("activated");
+        dfnPanel.style.left = null;
+        dfnPanel.style.top = null;
+    }
+
+    function hideDfnPanel(dfnPanel, dfn) {
+        if(!dfn) {
+            dfn = document.getElementById(dfnPanel.getAttribute("data-for"));
         }
-        vSoFar = panel.top + panel.height + 15;
+        dfn.setAttribute("aria-expanded", "false")
+        dfnPanel.classList.remove("on");
+        dfnPanel.classList.remove("activated");
     }
-}
 
-function cmpTops(a,b) {
-    return a.top - b.top;
-}
+    function toggleDfnPanel(dfnPanel, dfn) {
+        if(dfnPanel.classList.contains("on")) {
+            hideDfnPanel(dfnPanel, dfn);
+        } else {
+            showDfnPanel(dfnPanel, dfn);
+        }
+    }
 
-window.addEventListener("load", repositionAnnoPanels);
-window.addEventListener("resize", repositionAnnoPanels);
-}
-
+
-
-
+
\ No newline at end of file
+}
+
+
\ No newline at end of file