From 79afe10dc3e07c0c5e41880ce2258dee2842c118 Mon Sep 17 00:00:00 2001 From: CI Bot Date: Tue, 3 May 2016 21:45:57 +0000 Subject: [PATCH] Script updating gh-pages. [ci skip] --- index.html | 458 +++++++++++++++++++++++++++-------------------------- 1 file changed, 236 insertions(+), 222 deletions(-) diff --git a/index.html b/index.html index f3c2f9185..04928fcba 100644 --- a/index.html +++ b/index.html @@ -180,7 +180,7 @@

W3C

Web Authentication: A Web API for accessing scoped credentials

-

Editor’s Draft,

+

Editor’s Draft,

@@ -263,17 +263,16 @@

Table of Contents

  • 3.3 User Account Information (dictionary Account)
  • 3.4 Parameters for Credential Generation (dictionary ScopedCredentialParameters)
  • 3.5 WebAuthn Assertion (interface WebAuthnAssertion) -
  • 3.6 Client data used in assertion (dictionary ClientData) -
  • 3.7 WebAuthn Assertion Extensions (dictionary WebAuthnExtensions) -
  • 3.8 Key Attestation Statement (interface AttestationStatement) -
  • 3.9 Credential Attestation Header (interface AttestationHeader) -
  • 3.10 Attestation core data (interface AttestationCore) +
  • 3.6 WebAuthn Assertion Extensions (dictionary WebAuthnExtensions) +
  • 3.7 Key Attestation Statement (interface AttestationStatement) +
  • 3.8 Credential Attestation Header (interface AttestationHeader) +
  • 3.9 Attestation core data (interface AttestationCore)
  • - 3.11 Supporting Data Structures + 3.10 Supporting Data Structures
      -
    1. 3.11.1 Credential Type enumeration (enum CredentialType) -
    2. 3.11.2 Unique Identifier for Credential (interface Credential) -
    3. 3.11.3 Cryptographic Algorithm Identifier (type AlgorithmIdentifier) +
    4. 3.10.1 Credential Type enumeration (enum CredentialType) +
    5. 3.10.2 Unique Identifier for Credential (interface Credential) +
    6. 3.10.3 Cryptographic Algorithm Identifier (type AlgorithmIdentifier)
  • @@ -286,55 +285,56 @@

    Table of Contents

  • 4.1.2 The authenticatorGetAssertion operation
  • 4.1.3 The authenticatorCancel operation +
  • 4.2 Signature Format
  • - 4.2 Signature Format + 4.3 Client data used in WebAuthn signatures (dictionary ClientData)
      -
    1. 4.2.1 Authenticator data -
    2. 4.2.2 Generating a signature +
    3. 4.3.1 Authenticator data +
    4. 4.3.2 Generating a signature
  • - 4.3 Key Attestation Format + 4.4 Key Attestation Format
    1. - 4.3.1 Overview + 4.4.1 Overview
        -
      1. 4.3.1.1 Attestation Models -
      2. 4.3.1.2 Attestation Raw Data Types +
      3. 4.4.1.1 Attestation Models +
      4. 4.4.1.2 Attestation Raw Data Types
    2. - 4.3.2 Defined Attestation Raw Data Types + 4.4.2 Defined Attestation Raw Data Types
      1. - 4.3.2.1 Packed Attestation + 4.4.2.1 Packed Attestation
          -
        1. 4.3.2.1.1 Attestation rawData (type="packed") -
        2. 4.3.2.1.2 Signature -
        3. 4.3.2.1.3 Packed attestation statement certificate requirements +
        4. 4.4.2.1.1 Attestation rawData (type="packed") +
        5. 4.4.2.1.2 Signature +
        6. 4.4.2.1.3 Packed attestation statement certificate requirements
      2. - 4.3.2.2 TPM Attestation + 4.4.2.2 TPM Attestation
          -
        1. 4.3.2.2.1 Attestation rawData (type="tpm") -
        2. 4.3.2.2.2 Signature -
        3. 4.3.2.2.3 TPM attestation statement certificate requirements +
        4. 4.4.2.2.1 Attestation rawData (type="tpm") +
        5. 4.4.2.2.2 Signature +
        6. 4.4.2.2.3 TPM attestation statement certificate requirements
      3. - 4.3.2.3 Android Attestation + 4.4.2.3 Android Attestation
          -
        1. 4.3.2.3.1 Attestation rawData (type="android") -
        2. 4.3.2.3.2 Signature -
        3. 4.3.2.3.3 Converting SafetyNet response to attestationStatement -
        4. 4.3.2.3.4 AndroidAttestationClientData -
        5. 4.3.2.3.5 Verifying AndroidClientData specific contextual bindings +
        6. 4.4.2.3.1 Attestation rawData (type="android") +
        7. 4.4.2.3.2 Signature +
        8. 4.4.2.3.3 Converting SafetyNet response to attestationStatement +
        9. 4.4.2.3.4 AndroidAttestationClientData +
        10. 4.4.2.3.5 Verifying AndroidClientData specific contextual bindings
      -
    3. 4.3.3 Verifying an Attestation Statement +
    4. 4.4.3 Verifying an Attestation Statement
    5. - 4.3.4 Security Considerations + 4.4.4 Security Considerations
        -
      1. 4.3.4.1 Privacy -
      2. 4.3.4.2 Attestation Certificate and Attestation Certificate CA Compromise -
      3. 4.3.4.3 Attestation Certificate Hierarchy +
      4. 4.4.4.1 Privacy +
      5. 4.4.4.2 Attestation Certificate and Attestation Certificate CA Compromise +
      6. 4.4.4.3 Attestation Certificate Hierarchy
    @@ -495,9 +495,9 @@

    Web Cryptography API

    -

    The AlgorithmIdentifier#dictdef-algorithmidentifierReferenced in:3. Web Authentication API (2)3.11.3. Cryptographic Algorithm Identifier (type AlgorithmIdentifier) type and the method for normalizing an algorithm are defined in Web Cryptography API §algorithm-dictionary.

    +

    The AlgorithmIdentifier#dictdef-algorithmidentifierReferenced in:3. Web Authentication API3.10.3. Cryptographic Algorithm Identifier (type AlgorithmIdentifier)4.3. Client data used in WebAuthn signatures (dictionary ClientData) type and the method for normalizing an algorithm are defined in Web Cryptography API §algorithm-dictionary.

    -

    The JsonWebKey#jsonwebkeyReferenced in:3. Web Authentication API4.3.2.3.4. AndroidAttestationClientData interface for representing cryptographic keys is defined in Web Cryptography API §JsonWebKey-dictionary.

    +

    The JsonWebKey#jsonwebkeyReferenced in:4.3. Client data used in WebAuthn signatures (dictionary ClientData)4.4.2.3.4. AndroidAttestationClientData interface for representing cryptographic keys is defined in Web Cryptography API §JsonWebKey-dictionary.

    Base64url encoding

    @@ -524,14 +524,14 @@

    3. ScopedCredentialInfo > makeCredential ( Account accountInformation, sequence < ScopedCredentialParameters > cryptoParameters, - DOMString attestationChallenge, + BufferSource attestationChallenge, optional unsigned long credentialTimeoutSeconds, optional sequence < Credential > blacklist, optional WebAuthnExtensions credentialExtensions ); Promise < WebAuthnAssertion > getAssertion ( - DOMString assertionChallenge, + BufferSource assertionChallenge, optional unsigned long assertionTimeoutSeconds, optional sequence < Credential > whitelist, optional WebAuthnExtensions assertionExtensions @@ -558,54 +558,46 @@

    3. WebAuthnAssertion { - readonly attribute Credential credential; - readonly attribute DOMString clientData; - readonly attribute DOMString authenticatorData; - readonly attribute DOMString signature; + readonly attribute Credential credential; + readonly attribute ArrayBuffer clientData; + readonly attribute ArrayBuffer authenticatorData; + readonly attribute ArrayBuffer signature; }; -dictionary ClientData { - required DOMString challenge; - required DOMString facet; - required JsonWebKey tokenBinding; - required AlgorithmIdentifier hashAlg; - WebAuthnExtensions extensions; -}; - -dictionary WebAuthnExtensions { +dictionary WebAuthnExtensions { }; interface AttestationStatement { readonly attribute AttestationHeader header; readonly attribute AttestationCore core; - readonly attribute DOMString signature; + readonly attribute ArrayBuffer signature; }; interface AttestationCore { - readonly attribute DOMString type#dom-attestationcore-typeReferenced in:3.10. Attestation core data (interface AttestationCore); - readonly attribute unsigned long version#dom-attestationcore-versionReferenced in:3.10. Attestation core data (interface AttestationCore); - readonly attribute DOMString rawData; - readonly attribute DOMString clientData; + readonly attribute DOMString type#dom-attestationcore-typeReferenced in:3.9. Attestation core data (interface AttestationCore); + readonly attribute unsigned long version#dom-attestationcore-versionReferenced in:3.9. Attestation core data (interface AttestationCore); + readonly attribute ArrayBuffer rawData; + readonly attribute ArrayBuffer clientData; }; interface AttestationHeader { - readonly attribute DOMString claimedAAGUID; + readonly attribute ArrayBuffer claimedAAGUID; readonly attribute DOMString[] x5c; readonly attribute DOMString alg; }; enum CredentialType { - "ScopedCred" + "ScopedCred" }; interface Credential { readonly attribute CredentialType type; - readonly attribute DOMString id; + readonly attribute BufferSource id; };

    3.1. WebAuthentication#webauthenticationReferenced in:3. Web Authentication API (2) Interface

    This interface has two methods, which are described in the following subsections.

    -

    3.1.1. Create a new credential (makeCredential()#dom-webauthentication-makecredentialReferenced in:3. Web Authentication API4.1.1. The authenticatorMakeCredential operation4.3.2.3.5. Verifying AndroidClientData specific contextual bindings5. WebAuthn Extensions (2)5.2. Defining extensions5.3. Extending request parameters (2)6.2. Authenticator Selection Extension method)

    +

    3.1.1. Create a new credential (makeCredential()#dom-webauthentication-makecredentialReferenced in:3. Web Authentication API4.1.1. The authenticatorMakeCredential operation4.4.2.3.5. Verifying AndroidClientData specific contextual bindings5. WebAuthn Extensions (2)5.2. Defining extensions5.3. Extending request parameters (2)6.2. Authenticator Selection Extension method)

    With this method, a script can request the User Agent to create a new credential of a given type and persist it to the underlying platform, which may involve data storage managed by the browser or the OS. The user agent will prompt the user to approve this operation. On success, the promise will be resolved with a ScopedCredentialInfo object describing the newly @@ -691,7 +683,7 @@

    3.1.2. Use an existing credential (getAssertion()#dom-webauthentication-getassertionReferenced in:3. Web Authentication API3.7. WebAuthn Assertion Extensions (dictionary WebAuthnExtensions)4.1.2. The authenticatorGetAssertion operation5. WebAuthn Extensions (2)5.2. Defining extensions5.3. Extending request parameters (2) method)

    +

    3.1.2. Use an existing credential (getAssertion()#dom-webauthentication-getassertionReferenced in:3. Web Authentication API3.6. WebAuthn Assertion Extensions (dictionary WebAuthnExtensions)4.1.2. The authenticatorGetAssertion operation5. WebAuthn Extensions (2)5.2. Defining extensions5.3. Extending request parameters (2) method)

    This method is used to discover and use an existing scoped credential, with the user’s consent. The script optionally specifies some criteria to indicate what credentials are acceptable to it. The user agent and/or platform locates credentials matching the specified criteria, and guides the user to pick one that the script should be allowed to use. The user may choose not to provide @@ -699,8 +691,8 @@

    -

    The assertionChallenge#assertionchallengeReferenced in:3.1.2. Use an existing credential (getAssertion() method) parameter contains a string that the selected authenticator is expected to sign to produce -the assertion.

    +

    The assertionChallenge#assertionchallengeReferenced in:3.1.2. Use an existing credential (getAssertion() method) parameter contains a challenge that the selected authenticator is expected to sign to +produce the assertion.

  • The optional assertionTimeoutSeconds#assertiontimeoutsecondsReferenced in:3.1.2. Use an existing credential (getAssertion() method) (2) parameter specifies a time, in seconds, that the caller is willing to wait for the call to complete. This is treated as a hint, and may be overridden by the platform.

    @@ -797,38 +789,22 @@

    The algorithm member specifies the cryptographic algorithm with which the newly generated credential will be used.

    • -

    3.5. WebAuthn Assertion (interface WebAuthnAssertion#webauthnassertionReferenced in:3. Web Authentication API (2)3.1.2. Use an existing credential (getAssertion() method))

    +

    3.5. WebAuthn Assertion (interface WebAuthnAssertion#webauthnassertionReferenced in:3. Web Authentication API (2)3.1.2. Use an existing credential (getAssertion() method)4.3.2. Generating a signature)

    Scoped credentials produce a cryptographic signature that provides proof of possession of a private key as well as evidence of user consent to a specific transaction. The structure of these signatures is defined as follows.

    The credential member represents the credential that was used to generate this assertion. -

    The clientData member contains the base64url encoding of the parameters sent to the authenticator by the client. - (See clientDataJSON in §3.6 Client data used in assertion (dictionary ClientData).)

    -

    The authenticatorData#webauthnassertion-authenticatordataReferenced in:5. WebAuthn Extensions member contains the base64url encoding of the data returned by the authenticator. (See §4.2.1 Authenticator data.)

    -

    The signature member contains the base64url encoding of the raw signature returned from the authenticator. (See §4.2.2 Generating a signature.)

    -
    -

    3.6. Client data used in assertion (dictionary ClientData#dictdef-clientdataReferenced in:3. Web Authentication API4.2.2. Generating a signature (2)4.3.2.3.4. AndroidAttestationClientData5. WebAuthn Extensions (2)5.2. Defining extensions (2)5.3. Extending request parameters5.4. Extending client processing (2))

    -

    The client data represents the contextual bindings of both the WebAuthn Relying Party and the client platform. It is a key-value mapping with -string-valued keys. Values may be any type that has a valid encoding in JSON. It MUST contain at least the following key-value -pairs.

    -
    - The challenge member contains the base64url-encoded challenge provided by the RP. -

    The facet member contains a string value describing the RP identifier facet. When the WebAuthn Relying Party client-side app is a - website, this is its fully qualified web origin, using the syntax defined by [RFC6454]. When the client-side app is a - native application, this string is a platform specific identifier.

    -

    The tokenBinding member contains a JsonWebKey object as defined by Web Cryptography API §JsonWebKey-dictionary describing the public key that this client uses for the Token Binding protocol when communicating with the WebAuthn Relying Party. This can be - omitted if no Token Binding has been negotiated between the client and the WebAuthn Relying Party.

    -

    The hashAlg#clientdata-hashalgReferenced in:4.2.2. Generating a signature (2) member specifies the hash algorithm used to compute clientDataHash (see §4.2.2 Generating a signature). Use "S256" for SHA-256, "S384" for SHA384, "S512" for SHA512, and "SM3" for SM3 (see §7 IANA Considerations).

    -

    The optional extensions#clientdata-extensionsReferenced in:5.4. Extending client processing member contains the extension-provided authenticator data. Signature extensions are - detailed in Section §5 WebAuthn Extensions.

    +

    The clientData member contains the parameters sent to the authenticator by the client, in serialized form. (See §4.3 Client data used in WebAuthn signatures (dictionary ClientData).)

    +

    The authenticatorData member contains the serialized data returned by the authenticator. (See §4.3.1 Authenticator data.)

    +

    The signature member contains the raw signature returned from the authenticator. (See §4.3.2 Generating a signature.)

    -

    3.7. WebAuthn Assertion Extensions (dictionary WebAuthnExtensions#dictdef-webauthnextensionsReferenced in:3. Web Authentication API (2) (3) (4))

    +

    3.6. WebAuthn Assertion Extensions (dictionary WebAuthnExtensions#dictdef-webauthnextensionsReferenced in:3. Web Authentication API (2) (3)4.3. Client data used in WebAuthn signatures (dictionary ClientData))

    This is a dictionary containing zero or more extensions as defined in §5 WebAuthn Extensions. An extension is an additional parameter that can be passed to the getAssertion() method and triggers some additional processing by the client platform and/or the authenticator.

    If the caller wants to pass extensions to the platform, it SHOULD do so by adding one entry per extension to this dictionary with the extension identifier as the key, and the extension’s value as the value (see §4.2 Signature Format for details).

    -

    3.8. Key Attestation Statement (interface AttestationStatement#attestationstatementReferenced in:3. Web Authentication API (2))

    +

    3.7. Key Attestation Statement (interface AttestationStatement#attestationstatementReferenced in:3. Web Authentication API (2)4.3.2. Generating a signature)

    Authenticators also provide some form of key attestation. The basic requirement is that the authenticator can produce, for each credential public key, attestation information that can be verified by a WebAuthn Relying Party. Typically this information contains a signature by an attesting key over the attested public key and a challenge, as well as a certificate or similar information @@ -837,43 +813,43 @@

    header element contains the attestation header, including algorithm, (optionally) the claimed AAGUID and (optionally) the attestation certificate chain.

    The core element describes the data that is being attested to, and its type.

    -

    The signature element contains the base64url-encoded attestation signature. The structure of this object depends - on the signature algorithm specified in the header.

    +

    The signature element contains the attestation signature. The structure of this object depends on the signature + algorithm specified in the header.

    This attestation statement is delivered to the WebAuthn Relying Party according to the Client API. It contains all the information that the WebAuthn Relying Party’s server requires to reconstruct the signature base string, as well as to decode and validate the bindings of both the client- and authenticator data.

    -

    3.9. Credential Attestation Header (interface AttestationHeader#attestationheaderReferenced in:3. Web Authentication API (2))

    +

    3.8. Credential Attestation Header (interface AttestationHeader#attestationheaderReferenced in:3. Web Authentication API (2))

    This structure contains additional data required to verify the attestation signature.

    The claimedAAGUID element contains the claimed Authenticator Attestation GUID (a version 4 GUID, see [RFC4122]). This value is used by the WebAuthn Relying Party to look up the trust anchor for verifying the following AttestationCore object. If the verification succeeds, the AAGUID related to the trust anchor is trusted. This field MUST be present, if either no attestation certificates are used (e.g., DAA) or if the attestation certificate doesn’t contain the AAGUID value in an extension.

    The x5c attribute contains the attestation certificate and its certificate chain as described in [RFC7515] section 4.1.6.

    -

    The alg element contains the name of the algorithm used to generate the attestation signature according to [RFC7518]. See §4.3.2.1.2 Signature for the signature algorithms to be implemented by servers.

    +

    The alg element contains the name of the algorithm used to generate the attestation signature according to [RFC7518]. See §4.4.2.1.2 Signature for the signature algorithms to be implemented by servers.

    -

    3.10. Attestation core data (interface AttestationCore#attestationcoreReferenced in:3. Web Authentication API (2)3.9. Credential Attestation Header (interface AttestationHeader))

    +

    3.9. Attestation core data (interface AttestationCore#attestationcoreReferenced in:3. Web Authentication API (2)3.8. Credential Attestation Header (interface AttestationHeader))

    This structure contains the data attested by the Authenticator and a description of its structure. Different types of Authenticators might generate different object types (identified by type and version).

    The type member specifies the type of the rawData object. This specification defines a number of attestation raw - data types, in §4.3.2 Defined Attestation Raw Data Types. Other attestation raw data types may be defined in further versions + data types, in §4.4.2 Defined Attestation Raw Data Types. Other attestation raw data types may be defined in further versions of this specification.

    The version member specifies the version number of the rawData object.

    The rawData object contains the attested public key and the clientDataHash.

    -

    The clientData member contains the base64url encoding of clientDataJSON (see §4.2 Signature Format). The - exact encoding must be preserved as the hash (clientDataHash) has been computed over it.

    +

    The clientData member contains the clientDataJSON (see §4.2 Signature Format). The exact JSON encoding + must be preserved as the hash (clientDataHash) has been computed over it.

    -

    3.11. Supporting Data Structures

    +

    3.10. Supporting Data Structures

    The scoped credential type uses certain data structures that are specified in supporting specifications. These are as follows.

    -

    3.11.1. Credential Type enumeration (enum CredentialType#enumdef-credentialtypeReferenced in:3. Web Authentication API (2) (3)3.1.1. Create a new credential (makeCredential() method))

    +

    3.10.1. Credential Type enumeration (enum CredentialType#enumdef-credentialtypeReferenced in:3. Web Authentication API (2) (3)3.1.1. Create a new credential (makeCredential() method))

    This enumeration defines the valid credential types. It is an extension point; values may be added to it in the future, as more credential types are defined. The values of this enumeration are used for versioning the WebAuthn assertion and attestation statement according to the type of the authenticator.

    Currently one credential type is defined, namely "ScopedCred".

    -

    3.11.2. Unique Identifier for Credential (interface Credential#credentialReferenced in:3. Web Authentication API (2) (3) (4) (5))

    +

    3.10.2. Unique Identifier for Credential (interface Credential#credentialReferenced in:3. Web Authentication API (2) (3) (4) (5))

    This interface contains the attributes that are returned to the caller when a new credential is created, and can be used later by the caller to select a credential for use.

    @@ -885,7 +861,7 @@

    -

    3.11.3. Cryptographic Algorithm Identifier (type AlgorithmIdentifier)

    +

    3.10.3. Cryptographic Algorithm Identifier (type AlgorithmIdentifier)

    A string or dictionary identifying a cryptographic algorithm and optionally a set of parameters for that algorithm. This type is defined in [WebCryptoAPI].

    4. WebAuthn Authenticator model

    @@ -981,7 +957,29 @@

    4.2.1. Authenticator data

    +

    4.3. Client data used in WebAuthn signatures (dictionary ClientData#dictdef-clientdataReferenced in:4.3. Client data used in WebAuthn signatures (dictionary ClientData)4.3.2. Generating a signature (2)4.4.2.3.4. AndroidAttestationClientData5. WebAuthn Extensions (2)5.2. Defining extensions (2)5.3. Extending request parameters5.4. Extending client processing (2))

    +

    The client data represents the contextual bindings of both the WebAuthn Relying Party and the client platform. It is a key-value mapping with +string-valued keys. Values may be any type that has a valid encoding in JSON. Its structure is defined by the following Web IDL.

    +
    dictionary ClientData {
+    required DOMString           challenge;
+    required DOMString           facet;
+    required AlgorithmIdentifier hashAlg;
+    JsonWebKey                   tokenBinding;
+    WebAuthnExtensions           extensions;
+};
+
    +
    + The challenge member contains the base64url encoding of the challenge provided by the RP. +

    The facet member contains a string value describing the RP identifier facet. When the WebAuthn Relying Party client-side app is a + website, this is its fully qualified web origin, using the syntax defined by [RFC6454]. When the client-side app is a + native application, this string is a platform specific identifier.

    +

    The tokenBinding member contains a JsonWebKey object as defined by Web Cryptography API §JsonWebKey-dictionary describing the public key that this client uses for the Token Binding protocol when communicating with the WebAuthn Relying Party. This can be + omitted if no Token Binding has been negotiated between the client and the WebAuthn Relying Party.

    +

    The hashAlg#clientdata-hashalgReferenced in:4.3.2. Generating a signature (2) member specifies the hash algorithm used to compute clientDataHash (see §4.3.2 Generating a signature). Use "S256" for SHA-256, "S384" for SHA384, "S512" for SHA512, and "SM3" for SM3 (see §7 IANA Considerations).

    +

    The optional extensions#clientdata-extensionsReferenced in:5.4. Extending client processing member contains additional parameters generated by processing the extensions passed in + by the WebAuthn Relying Party. WebAuthn extensions are detailed in Section §5 WebAuthn Extensions.

    +
    +

    4.3.1. Authenticator data

    The authenticator data encodes contextual bindings made by the authenticator itself. 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 components.

    @@ -1017,42 +1015,43 @@

    The figure below shows a visual representation of the authenticator data structure.

    -
    authenticatorData layout.
    +
    authenticatorData#authenticatordataReferenced in:4.3.2. Generating a signature (2)5. WebAuthn Extensions layout.

    Note: The signatureData describes its own length: If the ED flag is not set, it is always 5 bytes long. If the ED flag is set, it is 5 bytes plus the CBOR map that follows.

    -

    4.2.2. Generating a signature

    +

    4.3.2. Generating a signature

    Before making a request to an authenticator, the client platform layer SHALL perform the following steps.

    1. -

      Let clientDataJSON#clientdatajsonReferenced in:3.5. WebAuthn Assertion (interface WebAuthnAssertion)3.10. Attestation core data (interface AttestationCore)4.2.2. Generating a signature be the UTF-8 encoded JSON serialization [RFC7159] of ClientData.

      +

      Represent the parameters passed in by the RP in the form of a ClientData structure.

      +
    2. +

      Let clientDataJSON#clientdatajsonReferenced in:3.9. Attestation core data (interface AttestationCore)4.3.2. Generating a signature (2) (3) be the UTF-8 encoded JSON serialization [RFC7159] of this ClientData dictionary.

    3. -

      Let clientDataHash be the hash (computed using hashAlg) of clientDataJSON, as an array.

      +

      Let clientDataHash#clientdatahashReferenced in:4.3.2. Generating a signature (2) be the hash (computed using hashAlg) of clientDataJSON, as an array.

    -

    The clientDataHash value is incorporated into a signature by an authenticator (see §4.2.2 Generating a signature). It is -delivered to integrated authenticators in platform specific manners, and to external authenticators as a part of a signature -request. The client platform SHOULD also preserve the exact encodedClientData string used to create it, for embedding in a -signature object sent back to the WebAuthn Relying Party (see §4.2.2 Generating a signature). This is necessary since multiple JSON encodings of -the same client data are possible.

    -

    The hash algorithm hashAlg used to compute clientDataHash is included in the ClientData object. This way it is -available to the WebAuthn Relying Party and it is also hashed over when computing clientDataHash and hence anchored in the signature itself.

    +

    The clientDataHash value is delivered to the authenticator.

    +

    The hash algorithm hashAlg used to compute clientDataHash is included in the ClientData object. This way it +is available to the WebAuthn Relying Party and it is also hashed over when computing clientDataHash and hence anchored in the signature +itself.

    A raw cryptographic signature must assert the integrity of both the client data and the authenticator data. Thus, an authenticator SHALL compute a signature over the concatenation of the authenticatorData and the clientDataHash.

    Generating a signature on the authenticator.

    Note: A simple, undelimited concatenation, is safe to use here because the authenticatorData describes its own length. The clientDataHash (which potentially has a variable length) is always the last element.

    -

    The authenticator MUST return both the authenticatorData and the raw signature back to the client.

    -

    4.3. Key Attestation Format

    +

    The authenticator MUST return both the authenticatorData and the raw signature back to the client. The client, in turn, +MUST return clientDataJSON, authenticatorData and the signature to the RP. The clientDataJSON is returned +in the clientData member of the WebAuthnAssertion and AttestationStatement structures.

    +

    4.4. Key Attestation Format

    An attestation statement is a specific type of signature, which contains statements about a credential itself and the authenticator that holds it. Therefore, the format of attestation statements and the procedures for generating them closely parallel those for generating WebAuthn assertions as described in §4.2 Signature Format, though the semantics of the contextual bindings are quite different.

    -

    The general structure of an attestation statement is specified in §3.8 Key Attestation Statement (interface AttestationStatement). This section provides a +

    The general structure of an attestation statement is specified in §3.7 Key Attestation Statement (interface AttestationStatement). This section provides a profile of these structures when different types of hardware act as the crypto kernel. More profiles are expected to be added as the specification evolves.

    -

    4.3.1. Overview

    -
    4.3.1.1. Attestation Models
    +

    4.4.1. Overview

    +
    4.4.1.1. Attestation Models

    WebAuthn supports multiple attestation models:

    @@ -1086,28 +1085,27 @@

    Compliant servers MUST support all attestation models. Authenticators can choose what attestation model to implement.

    Note: WebAuthn Relying Parties can always decide what attestation models are acceptable to them by policy.

    -
    4.3.1.2. Attestation Raw Data Types
    +
    4.4.1.2. Attestation Raw Data Types

    WebAuthn supports pluggable attestation raw data types, i.e., ways to serialize the data being attested to by the Authenticator. The reason is to be able to support existing devices like TPMs and other platform-specific formats.

    Each attestation type provides the ability to cryptographically attest to a public key, the authenticator model, and contextual data to a remote party.

    Attestation raw data types are orthogonal to attestation models, i.e. attestation raw data types in general are not restricted to a single attestation model.

    -

    4.3.2. Defined Attestation Raw Data Types

    +

    4.4.2. Defined Attestation Raw Data Types

    Attestation Raw Data (rawData) is the to-be-signed object of the attestation statement. WebAuthn supports pluggable attestation data types. This allows support of TPM generated attestation data as well as support of other WebAuthn authenticators.

    The contents of the attestation data must be controlled (i.e., generated or at least verified) by the authenticator itself.

    -
    4.3.2.1. Packed Attestation
    +
    4.4.2.1. Packed Attestation

    Packed attestation is a WebAuthn optimized format of attestation data. It uses a very compact but still extensible encoding method. Encoding this format can even be implemented by authenticators with very limited resources (e.g., secure elements).

    -
    4.3.2.1.1. Attestation rawData (type="packed")
    +
    4.4.2.1.1. Attestation rawData (type="packed")

    The attestation data encodes contextual bindings made by the authenticator itself. Unlike client data, 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 components.

    For this type, only version="1" is defined at this time.

    -

    The field rawData is the *base64url encoding of the byte array*. The encoding of attestation data (for type "packed") is a -byte array of 45 bytes + length of public key + length of KeyHandle + potentially more extensions. The first bytes before the -extensions have a fixed layout as follows:

    +

    The field rawData for this type is a byte array of 45 bytes + length of public key + length of KeyHandle + potentially more +extensions. The first bytes before the extensions have a fixed layout as follows:

    @@ -1170,7 +1168,7 @@
    Byte length n of clientDataHash
    n - clientDataHash (see §4.2.2 Generating a signature). This is the hash of clientData. The hash algorithm itself is + clientDataHash (see §4.3.2 Generating a signature). This is the hash of clientData. The hash algorithm itself is stored in the clientData object §4.2 Signature Format.
    As defined by the extension map @@ -1181,8 +1179,8 @@
    The TUP flag SHALL be set if and only if the authenticator detected a user through an authenticator-specific gesture. The RFU bits in the flags byte SHALL be cleared (i.e., zeroed).

    If the authenticator does not wish to add extensions, it MUST clear the ED flag in the third byte.

    -
    4.3.2.1.2. Signature
    -

    The signature is computed over the base64url-decoded rawData field. The following algorithms must be implemented by servers:

    +
    4.4.2.1.2. Signature
    +

    The signature is computed over the rawData field. The following algorithms must be implemented by servers:

    1. "ES256" [RFC7518]

      @@ -1194,7 +1192,7 @@
      [FIDOEcdaaAlgorithm]

    Authenticators can choose which algorithm(s) to implement.

    -
    4.3.2.1.3. Packed attestation statement certificate requirements
    +
    4.4.2.1.3. Packed attestation statement certificate requirements

    Note: In the case of DAA attestation [FIDOEcdaaAlgorithm] no attestation certificate is used.

    The attestation certificate MUST have the following fields/extensions:

      @@ -1227,13 +1225,14 @@

      An Authority Information Access (AIA) extension with entry id-ad-ocsp and a CRL Distribution Point extension [RFC5280] are both optional as the status of attestation certificates is available through the FIDO Metadata Service [FIDOMetadataService].

    -
    4.3.2.2. TPM Attestation
    -
    4.3.2.2.1. Attestation rawData (type="tpm")
    -

    The value of rawData is the *base64url encoding of a binary object*. This binary object is either a TPM_CERTIFY_INFO or a -TPM_CERTIFY_INFO2 structure [TPMv1-2-Part2] sections 11.1 and 11.2, if attestationStatement.core.version equals 1. Else, if attestationStatement.core.version equals 2, it MUST be the base64url encoding of a TPMS_ATTEST structure as defined in [TPMv2-Part2] sections 10.12.9.

    +
    4.4.2.2. TPM Attestation
    +
    4.4.2.2.1. Attestation rawData (type="tpm")
    +

    The value of rawData is either a TPM_CERTIFY_INFO or a TPM_CERTIFY_INFO2 structure [TPMv1-2-Part2] sections 11.1 and 11.2, +if attestationStatement.core.version equals 1. Else, if attestationStatement.core.version equals 2, it MUST be a TPMS_ATTEST +structure as defined in [TPMv2-Part2] sections 10.12.9.

    The field "extraData" (in the case of TPMS_ATTEST) or the field "data" (in the case of TPM_CERTIFY_INFO or TPM_CERTIFY_INFO2) MUST contain the clientDataHash (see [[#signature-format]).

    -
    4.3.2.2.2. Signature
    +
    4.4.2.2.2. Signature

    If attestationStatement.core.version equals 1, (i.e., for TPM 1.2), RSASSA-PKCS1-v1_5 signature algorithm (section 8.2 of [RFC3447]) can be used by WebAuthn Authenticators (i.e. attestationStatement.header.alg="RS256").

    If attestationStatement.core.version equals 2, the following algorithms can be used by WebAuthn Authenticators:

      @@ -1248,9 +1247,9 @@

      TPM_ALG_SM2 (0x1B); attestationStatement.header.alg="SM256".

    -

    The signature is computed over the base64url-decoded rawData field See §4.3.2.1.2 Signature for the signature -algorithms to be implemented by servers.

    -
    4.3.2.2.3. TPM attestation statement certificate requirements
    +

    The signature is computed over the rawData field. See §4.4.2.1.2 Signature for the signature algorithms to be +implemented by servers.

    +
    4.4.2.2.3. TPM attestation statement certificate requirements

    TPM attestation certificate MUST have the following fields/extensions:

    • @@ -1268,12 +1267,12 @@
      An Authority Information Access (AIA) extension with entry id-ad-ocsp and a CRL Distribution Point extension [RFC5280] are both optional as the status of attestation certificates is available through the FIDO Metadata Service [FIDOMetadataService].

    -
    4.3.2.3. Android Attestation
    +
    4.4.2.3. Android Attestation

    When the Authenticator in question is a platform-provided Authenticator on the Android platform, the attestation statement is based on the SafetyNet API.

    -

    Android attestation statement MUST always be used in conjunction with the more specific AndroidAttestationClientData (see §4.3.2.3.4 AndroidAttestationClientData) in order to let the WebAuthn Relying Party App store the public key in the attestation object.

    -
    4.3.2.3.1. Attestation rawData (type="android")
    +

    Android attestation statement MUST always be used in conjunction with the more specific AndroidAttestationClientData (see §4.4.2.3.4 AndroidAttestationClientData) in order to let the WebAuthn Relying Party App store the public key in the attestation object.

    +
    4.4.2.3.1. Attestation rawData (type="android")

    Android SafetyNet returns a JWS [RFC7515] object (see SafetyNet online documentation) in Compact Serialization. A JWS in Compact Serialization consists of three segments (each a base64url-encoded string) separated by a dot ("."). The rawData object is the concatenation of:

    @@ -1287,18 +1286,18 @@

    In contrast to the "packed" and "tpm" attestation types, for the "android" attestation type, the rawData field and the rawData object are the same string. (In the "packed" and "tpm" attestation types the rawData field is the base64url-encoding of the rawData object.)

    -
    4.3.2.3.2. Signature
    +
    4.4.2.3.2. Signature

    The signature is directly computed over the rawData field, as defined above (see [RFC7515] for more details). The third -segment of the JWS returned by SafetyNet is the base64url encoding of this signature, and also becomes the AttestationStatement.signature.

    -
    4.3.2.3.3. Converting SafetyNet response to attestationStatement
    +segment of the JWS returned by SafetyNet is the base64url encoding of this signature, and is decoded into the AttestationStatement.signature.

    +
    4.4.2.3.3. Converting SafetyNet response to attestationStatement

    The Authenticator and/or platform SHOULD use the steps outlined below to create an attestationStatement from an Android SafetyNet response. It MAY use a different algorithm, as long as the results are the same.

    1. -

      create clientDataJSON with type AndroidAttestationClientData (see below) and compute clientData as base64url-encoded +

      create clientDataJSON with type AndroidAttestationClientData (see below) and compute clientDataHash as the hash of clientDataJSON.

    2. -

      provide the clientDataHash computed as the hash value of clientData as Nonce value when requesting the SafetyNet attestation.

      +

      provide clientDataHash as Nonce value when requesting the SafetyNet attestation.

    3. take SafetyNet response snr. This is a JWS object ([RFC7515]).

    4. @@ -1306,7 +1305,7 @@

      extract the base64url-encoded payload p from snr

    5. -

      extract the base64url-encoded signature s from snr

      +

      extract the base64url-encoded signature from snr. Let s be its base64url-decoded form.

    6. set AttestationStatement.core.rawData = hdr | "." | p

    7. @@ -1325,7 +1324,7 @@
      set AttestationStatement.core.version to the version number of Google Play Services responsible for providing the SafetyNet API

    -
    4.3.2.3.4. AndroidAttestationClientData
    +
    4.4.2.3.4. AndroidAttestationClientData

    The ClientData dictionary is extended in the following way:

    dictionary AndroidAttestationClientData : ClientData {
     JsonWebKey    publicKey;
@@ -1365,8 +1364,8 @@ 
    4.3.2.3.5. Verifying AndroidClientData specific contextual bindings
    
-   
    A WebAuthn Relying Party shall verify the clientData contextual bindings (see step 4 in §4.3.3 Verifying an Attestation Statement) as follows:
    
+   
    4.4.2.3.5. Verifying AndroidClientData specific contextual bindings
    
+   
    A WebAuthn Relying Party shall verify the clientData contextual bindings (see step 4 in §4.4.3 Verifying an Attestation Statement) as follows:
    
    
      
     
    • 
      
      Check that AndroidAttestationClientData.challenge equals the attestationChallenge that was passed into the makeCredential() call.
      
@@ -1388,7 +1387,7 @@ 
      4.3.3. Verifying an Attestation Statement
      
+   
      4.4.3. Verifying an Attestation Statement
      
    
      This section outlines the recommended algorithm for verifying an attestation statement, independent of attestation type.
      
    
      Upon receiving an attestation statement, the WebAuthn Relying Party shall:
      
    
        
@@ -1434,7 +1433,7 @@ 
        
-     
        Verify the contextual bindings (e.g., channel binding) from the clientData (see §4.2.2 Generating a signature).
        
+     
        Verify the contextual bindings (e.g., channel binding) from the clientData (see §4.3.2 Generating a signature).
        
     
      1. 
      
        Verify that user verification method and other authenticator characteristics related to this authenticator model, match the
 WebAuthn Relying Party policy. The FIDO Metadata Service [FIDOMetadataService] provides an easy way to access the authenticator
@@ -1446,15 +1445,15 @@ 
        
      
        Accept the request associated with the attestation statement but treat the attested Scoped Credential as one with surrogate
-basic attestation (see §4.3.1.1 Attestation Models), if policy allows it. If doing so, there is no cryptographic proof that the
+basic attestation (see §4.4.1.1 Attestation Models), if policy allows it. If doing so, there is no cryptographic proof that the
 Scoped Credential has been generated by a particular Authenticator model. See [FIDOSecRef] and [UAFProtocol] for more
 details on the relevance on attestation.
        
    
    
    
    Verification of attestation statements requires that the relying party trusts the root of the attestation certificate chain.
 Also, the WebAuthn 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 didn’t provide this chain in the attestation information.
    
-   
    4.3.4. Security Considerations
    
-   
    4.3.4.1. Privacy
    
+   
    4.4.4. Security Considerations
    
+   
    4.4.4.1. Privacy
    
    
    Attestation keys may be used to track users or link various online identities of the same user together. This may be mitigated
 in several ways, including:
    
    
      
@@ -1472,7 +1471,7 @@ 
      
    
    
-   
    4.3.4.2. Attestation Certificate and Attestation Certificate CA Compromise
    
+   
    4.4.4.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 keys are still safe although their certificates can no longer be trusted. A WebAuthn Authenticator manufacturer that
 has recorded the public attestation keys for their devices 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
@@ -1484,14 +1483,14 @@ 
    
    
    If attestation certificate validation fails due to a revoked intermediate attestation CA certificate, and the WebAuthn Relying Party’s policy
 requires rejecting the registration/authentication request in these situations, then it is recommended that the WebAuthn Relying Party also
-un-registers (or marks as "surrogate attestation" (see §4.3.1.1 Attestation Models), policy permitting) scoped credentials that were
+un-registers (or marks as "surrogate attestation" (see §4.4.1.1 Attestation Models), policy permitting) scoped credentials that were
 registered post the CA compromise date using an attestation certificate chaining up to the same intermediate CA. It is thus
 recommended that WebAuthn Relying Parties remember intermediate attestation CA certificates during Authenticator registration in order to
 un-register related Scoped Credentials if the registration was performed after revocation of such certificates.
    
    
    If a DAA attestation key has been compromised, it can be added to the RogueList (i.e., the list of revoked authenticators)
 maintained by the related DAA-Issuer. The WebAuthn Relying Party should verify whether an authenticator belongs to the RogueList when performing
 DAA-Verify. The FIDO Metadata Service [FIDOMetadataService] provides an easy way to access such information.
    
-   
    4.3.4.3. Attestation Certificate Hierarchy
    
+   
    4.4.4.3. 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
 used to help facilitate isolating problems with a specific version of a device.
    
@@ -1508,7 +1507,7 @@ 
    5
     
  • 
      
    Client processing, and the ClientData structure, for registration extensions and signature extensions.
    
     
  • 
-     
    Authenticator processing, and the authenticatorData structure, for signature extensions.
    
+     
    Authenticator processing, and the authenticatorData structure, for signature extensions.
    
    
    
    When requesting an assertion for a scoped credential, a WebAuthn Relying Party can list a set of extensions to be used, if they are supported by
 the client and/or the authenticator. It sends the request parameters for each extension in the getAssertion() call (for
@@ -1565,7 +1564,7 @@ 
    §4.2.1 Authenticator data, the authenticator data value of each processed extension is included in the
+   
    As specified in §4.3.1 Authenticator data, the authenticator data value of each processed extension is included in the
 extended data part of the authenticatorData. This part is a CBOR map, with extension identifiers as keys, and the
 authenticator data value of each extension as the value.
    
    
    5.6. Example extension
    
@@ -2140,11 +2139,11 @@ 
    9. Terminology
    
    
    
     
    
-     
    Attestation Certificate#attestation-certificateReferenced in:4.3.2.1.3. Packed attestation statement certificate requirements4.3.2.2.3. TPM attestation statement certificate requirements
    
+     
    Attestation Certificate#attestation-certificateReferenced in:4.4.2.1.3. Packed attestation statement certificate requirements4.4.2.2.3. TPM attestation statement certificate requirements
    
     
    
      
    A X.509 Certificate for a keypair used by an Authenticator to attest to its manufacture and capabilities.
    
     
    
-     
    Authenticator#authenticatorReferenced in:1. Use Cases4. WebAuthn Authenticator model4.2. Signature Format4.2.1. Authenticator data4.2.2. Generating a signature4.3.1.2. Attestation Raw Data Types4.3.2. Defined Attestation Raw Data Types4.3.2.1. Packed Attestation4.3.2.1.1. Attestation rawData (type="packed") (2)4.3.2.1.2. Signature4.3.2.3. Android Attestation4.3.2.3.3. Converting SafetyNet response to attestationStatement4.3.4.1. Privacy4.3.4.2. Attestation Certificate and Attestation Certificate CA Compromise6.3. AAGUID Extension8. Sample scenarios9. Terminology (2)
    
+     
    Authenticator#authenticatorReferenced in:1. Use Cases4. WebAuthn Authenticator model4.2. Signature Format4.3.1. Authenticator data4.3.2. Generating a signature4.4.1.2. Attestation Raw Data Types4.4.2. Defined Attestation Raw Data Types4.4.2.1. Packed Attestation4.4.2.1.1. Attestation rawData (type="packed") (2)4.4.2.1.2. Signature4.4.2.3. Android Attestation4.4.2.3.3. Converting SafetyNet response to attestationStatement4.4.4.1. Privacy4.4.4.2. Attestation Certificate and Attestation Certificate CA Compromise6.3. AAGUID Extension8. Sample scenarios9. Terminology (2)
    
     
    
      
    The device used by the user agent to authenticate with the WebAuthn Relying Party. These can be Embedded Authenticators or External Authenticators.
    
     
    
@@ -2162,7 +2161,7 @@ 
    
     
    
      
    The effective top-level domain, plus the first label. Also known as a Registered Domain. See [PSL].
    
     
    
-     
    WebAuthn Relying Party#webauthn-relying-partyReferenced in:1. Use Cases3.1.1. Create a new credential (makeCredential() method)3.2. ScopedCredentialInfo Interface3.3. User Account Information (dictionary Account)3.8. Key Attestation Statement (interface AttestationStatement) (2)3.9. Credential Attestation Header (interface AttestationHeader)4. WebAuthn Authenticator model4.2. Signature Format5.3. Extending request parameters5.4. Extending client processing5.6. Example extension8.2. Authentication8.3. Decommissioning9. Terminology
    
+     
    WebAuthn Relying Party#webauthn-relying-partyReferenced in:1. Use Cases3.1.1. Create a new credential (makeCredential() method)3.2. ScopedCredentialInfo Interface3.3. User Account Information (dictionary Account)3.7. Key Attestation Statement (interface AttestationStatement) (2)3.8. Credential Attestation Header (interface AttestationHeader)4. WebAuthn Authenticator model4.2. Signature Format5.3. Extending request parameters5.4. Extending client processing5.6. Example extension8.2. Authentication8.3. Decommissioning9. Terminology
    
     
    
      
    The entity which needs to rely in the authentication provided by the WebAuthn specification. When registration concludes,
 the WebAuthn Relying Party has the public key that was created by the Authenticator.
    
@@ -2181,7 +2180,7 @@ 
    attribute for AttestationHeader, in §3
-     
  • dfn for AttestationHeader, in §3.9
+     
  • dfn for AttestationHeader, in §3.8
     
    
  • 
     algorithm
@@ -2190,7 +2189,7 @@ 
    dfn for ScopedCredentialParameters, in §3.4
     
    
  • AlgorithmIdentifier, in §2.1
-   
  • AndroidAttestationClientData, in §4.3.2.3.4
+   
  • AndroidAttestationClientData, in §4.4.2.3.4
    
  • assertionChallenge, in §3.1.2
    
  • assertionExtensions, in §3.1.2
    
  • assertionTimeoutSeconds, in §3.1.2
@@ -2202,9 +2201,9 @@ 
    Attestation Certificate, in §9
    
  • attestationChallenge, in §3.1.1
-   
  • AttestationCore, in §3.10
-   
  • AttestationHeader, in §3.9
-   
  • AttestationStatement, in §3.8
+   
  • AttestationCore, in §3.9
+   
  • AttestationHeader, in §3.8
+   
  • AttestationStatement, in §3.7
    
  • Authenticator, in §9
    
  • authenticator argument, in §5.3
    
  • authenticatorCancel, in §4.1.3
@@ -2212,7 +2211,7 @@ 
    attribute for WebAuthnAssertion, in §3
-     
  • dfn for WebAuthnAssertion, in §3.5
+     
  • definition of, in §4.3.1
     
    
  • authenticatorGetAssertion, in §4.1.2
    
  • authenticatorMakeCredential, in §4.1.1
@@ -2227,14 +2226,14 @@ 
    dict-member for ClientData, in §3
-     
  • dfn for ClientData, in §3.6
+     
  • dict-member for ClientData, in §4.3
+     
  • dfn for ClientData, in §4.3
     
    
  • 
     claimedAAGUID
     
    
  • Client, in §9
    
  • client argument, in §5.3
@@ -2244,10 +2243,11 @@ 
    attribute for WebAuthnAssertion, in §3
      
  • attribute for AttestationCore, in §3
      
  • dfn for WebAuthnAssertion, in §3.5
-     
  • dfn for AttestationCore, in §3.10
+     
  • dfn for AttestationCore, in §3.9
     
-   
  • ClientData, in §3.6
-   
  • clientDataJSON, in §4.2.2
+   
  • ClientData, in §4.3
+   
  • clientDataHash, in §4.3.2
+   
  • clientDataJSON, in §4.3.2
    
  • Conforming User Agent, in §9
    
  • content, in §6.1
    
  • contentType, in §6.1
@@ -2255,9 +2255,9 @@ 
    attribute for AttestationStatement, in §3
-     
  • dfn for AttestationStatement, in §3.8
+     
  • dfn for AttestationStatement, in §3.7
     
-   
  • Credential, in §3.11.2
+   
  • Credential, in §3.10.2
    
  • 
     credential
     
    
  • External authenticators, in §1
    
  • 
     facet
     
    
  • getAssertion(assertionChallenge), in §3.1.2
    
  • getAssertion(assertionChallenge, assertionTimeoutSeconds), in §3.1.2
@@ -2299,14 +2299,14 @@ 
    dict-member for ClientData, in §3
-     
  • dfn for ClientData, in §3.6
+     
  • dict-member for ClientData, in §4.3
+     
  • dfn for ClientData, in §4.3
     
    
  • 
     header
     
    
  • 
     id
@@ -2314,7 +2314,7 @@ 
    dict-member for Account, in §3
      
  • attribute for Credential, in §3
      
  • dfn for Account, in §3.3
-     
  • dfn for Credential, in §3.11.2
+     
  • dfn for Credential, in §3.10.2
     
    
  • 
     imageURL
@@ -2325,8 +2325,8 @@ 
    dict-member for AndroidAttestationClientData, in §4.3.2.3.4
-     
  • dfn for AndroidAttestationClientData, in §4.3.2.3.4
+     
  • dict-member for AndroidAttestationClientData, in §4.4.2.3.4
+     
  • dfn for AndroidAttestationClientData, in §4.4.2.3.4
     
    
  • JsonWebKey, in §2.1
    
  • makeCredential(accountInformation, cryptoParameters, attestationChallenge), in §3.1.1
@@ -2346,14 +2346,14 @@ 
    attribute for ScopedCredentialInfo, in §3
      
  • dfn for ScopedCredentialInfo, in §3.2
-     
  • dict-member for AndroidAttestationClientData, in §4.3.2.3.4
-     
  • dfn for AndroidAttestationClientData, in §4.3.2.3.4
+     
  • dict-member for AndroidAttestationClientData, in §4.4.2.3.4
+     
  • dfn for AndroidAttestationClientData, in §4.4.2.3.4
     
    
  • 
     rawData
     
    
  • Relying Party Identifier, in §4
    
  • 
@@ -2362,7 +2362,12 @@ 
    dict-member for Account, in §3
      
  • dfn for Account, in §3.3
     
-   
  • ScopedCred, in §3.11.1
+   
  • 
+    ScopedCred
+    
    
  • "ScopedCred", in §3
    
  • ScopedCredentialInfo, in §3.2
    
  • ScopedCredentialParameters, in §3.4
@@ -2373,13 +2378,13 @@ 
    attribute for WebAuthnAssertion, in §3
      
  • attribute for AttestationStatement, in §3
      
  • dfn for WebAuthnAssertion, in §3.5
-     
  • dfn for AttestationStatement, in §3.8
+     
  • dfn for AttestationStatement, in §3.7
     
    
  • 
     tokenBinding
     
    
  • 
     type
@@ -2388,32 +2393,32 @@ 
    attribute for AttestationCore, in §3
      
  • attribute for Credential, in §3
      
  • dfn for ScopedCredentialParameters, in §3.4
-     
  • dfn for AttestationCore, in §3.10
-     
  • dfn for Credential, in §3.11.2
+     
  • dfn for AttestationCore, in §3.9
+     
  • dfn for Credential, in §3.10.2
     
    
  • 
     userAuthentication
     
    
  • 
     userAuthenticationValidityDurationSeconds
     
    
  • 
     version
     
    
  • WebAuthentication, in §3.1
    
  • webauthn, in §3
    
  • WebAuthnAssertion, in §3.5
    
  • WebAuthn Client, in §9
-   
  • WebAuthnExtensions, in §3.7
+   
  • WebAuthnExtensions, in §3.6
    
  • WebAuthn Relying Party, in §9
    
  • whitelist, in §3.1.2
    
  • Window, in §2.1
@@ -2421,7 +2426,7 @@ 
    attribute for AttestationHeader, in §3
-     
  • dfn for AttestationHeader, in §3.9
+     
  • dfn for AttestationHeader, in §3.8
     
   
   
    Terms defined by reference
    
@@ -2431,6 +2436,11 @@ 
    
      
  • Window
     
+   
  • 
+    [WebIDL-1] defines the following terms:
+    
   
   
    References
    
   
    Normative References
    
@@ -2458,7 +2468,7 @@ 
    N
    
    [WebCryptoAPI]
    
    Ryan Sleevi; Mark Watson. Web Cryptography API. 11 December 2014. CR. URL: http://www.w3.org/TR/WebCryptoAPI/
    
    [WebIDL-1]
-   
    Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 8 March 2016. CR. URL: http://www.w3.org/TR/WebIDL-1/
+   
    Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 8 March 2016. CR. URL: https://heycam.github.io/webidl/
   
    • 
   
    Informative References
    
   
    
@@ -2508,14 +2518,14 @@ 
    I
     Promise < ScopedCredentialInfo > makeCredential (
         Account                                 accountInformation,
         sequence < ScopedCredentialParameters > cryptoParameters,
-        DOMString                               attestationChallenge,
+        BufferSource                            attestationChallenge,
         optional unsigned long                  credentialTimeoutSeconds,
         optional sequence < Credential >        blacklist,
         optional WebAuthnExtensions             credentialExtensions
     );
 
     Promise < WebAuthnAssertion > getAssertion (
-        DOMString                        assertionChallenge,
+        BufferSource                     assertionChallenge,
         optional unsigned long           assertionTimeoutSeconds,
         optional sequence < Credential > whitelist,
         optional WebAuthnExtensions      assertionExtensions
@@ -2542,18 +2552,10 @@ 
    I
 };
 
 interface WebAuthnAssertion {
-    readonly attribute Credential credential;
-    readonly attribute DOMString  clientData;
-    readonly attribute DOMString  authenticatorData;
-    readonly attribute DOMString  signature;
-};
-
-dictionary ClientData {
-    required DOMString       challenge;
-    required DOMString       facet;
-    required JsonWebKey      tokenBinding;
-    required AlgorithmIdentifier hashAlg;
-    WebAuthnExtensions          extensions;
+    readonly attribute Credential  credential;
+    readonly attribute ArrayBuffer clientData;
+    readonly attribute ArrayBuffer authenticatorData;
+    readonly attribute ArrayBuffer signature;
 };
 
 dictionary WebAuthnExtensions {
@@ -2562,18 +2564,18 @@ 
    I
 interface AttestationStatement {
     readonly    attribute AttestationHeader header;
     readonly    attribute AttestationCore   core;
-    readonly    attribute DOMString         signature;
+    readonly    attribute ArrayBuffer       signature;
 };
 
 interface AttestationCore {
     readonly    attribute DOMString     type;
     readonly    attribute unsigned long version;
-    readonly    attribute DOMString     rawData;
-    readonly    attribute DOMString     clientData;
+    readonly    attribute ArrayBuffer   rawData;
+    readonly    attribute ArrayBuffer   clientData;
 };
 
 interface AttestationHeader {
-    readonly    attribute DOMString   claimedAAGUID;
+    readonly    attribute ArrayBuffer claimedAAGUID;
     readonly    attribute DOMString[] x5c;
     readonly    attribute DOMString   alg;
 };
@@ -2584,7 +2586,15 @@ 
    I
 
 interface Credential {
     readonly attribute CredentialType type;
-    readonly attribute DOMString      id;
+    readonly attribute BufferSource   id;
+};
+
+dictionary ClientData {
+    required DOMString           challenge;
+    required DOMString           facet;
+    required AlgorithmIdentifier hashAlg;
+    JsonWebKey                   tokenBinding;
+    WebAuthnExtensions           extensions;
 };
 
 dictionary AndroidAttestationClientData : ClientData {
@@ -2607,6 +2617,10 @@ 
    I
             var el = e.target;
             var target;
             while(el.parentElement) {
+                if(el.tagName == "A") {
+                    // Clicked on a link; intercept this early in case it was nested in a 
+                    return true;
+                }
                 if(el.tagName == "DFN") {
                     target = "dfn";
                     break;