Implement Rolf's naming suggestions

Clearly differentiate attestation statements and attestation objects.

index.bs

@@ -203,7 +203,7 @@ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
     In the WebAuthn context, attestation is employed to attest to the provenance of an authenticator and the data it emits;
     including, for example: credential IDs, credential key pairs, signature counters, etc. <dfn>Attestation information</dfn> is
     conveyed in <dfn>attestation objects</dfn>.
-    See also <a>attestation format</a>, and <a>attestation type</a>.
+    See also <a>attestation statement format</a>, and <a>attestation type</a>.
 
 : <dfn>Attestation Certificate</dfn>
 :: A X.509 Certificate for the <dfn>attestation key pair</dfn> used by an <a>Authenticator</a> to attest to its manufacture
@@ -565,7 +565,7 @@ authorizing an authenticator with which to complete the operation.
     [SecureContext]
     interface ScopedCredentialInfo {
         readonly    attribute ArrayBuffer   clientData;
-        readonly    attribute ArrayBuffer   attestation;
+        readonly    attribute ArrayBuffer   attestationObject;
     };
 </pre>
 
@@ -578,12 +578,12 @@ authorizing an authenticator with which to complete the operation.
     by the client in order to generate this credential. The exact JSON encoding must be preserved as a cryptographic hash
     (<a>clientDataHash</a>) has been computed over it.
 
-    The <dfn>attestation</dfn> element contains the <a>attestation object</a>. The contents of this object are determined by
-    the <a>attestation format</a> used by the authenticator. This object is opaque to, and cryptographically protected against
-    tampering by, the client. It contains the unique identifier of the credential, the <a>credential public key</a>, and an
-    attestation statement. It also contains any additional information that the [RP]'s server requires to validate the
-    attestation statement, as well as to decode and validate the bindings of both the client and authenticator data. For more
-    details, see [[#cred-attestation]].
+    The <dfn>attestationObject</dfn> element contains the <a>attestation object</a>. The contents of this object are determined
+    by the <a>attestation statement format</a> used by the authenticator. This object is opaque to, and cryptographically
+    protected against tampering by, the client. It contains the unique identifier of the credential, the <a>credential public
+    key</a>, and an attestation statement. It also contains any additional information that the [RP]'s server requires to
+    validate the attestation statement, as well as to decode and validate the bindings of both the client and authenticator
+    data. For more details, see [[#cred-attestation]].
 </div>
 
 
@@ -911,22 +911,16 @@ these methods.
 </pre>
 
 <div dfn-for="Transport">
-    Authenticators may communicate with Clients using a variety of transports.
-    This enumeration defines a hint 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 [RP]'s best belief as to
-    how an Authenticator may be reached.  A [RP] may obtain a list of
-    transports hints from some attestation formats or via some out-of-band
-    mechanism; it is outside the scope of this specification to define that
-    mechanism.
+    Authenticators may communicate with Clients using a variety of transports. This enumeration defines a hint 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 [RP]'s best belief as to how an Authenticator may be reached.  A [RP] may obtain a list of
+    transports hints from some attestation statement formats or via some out-of-band mechanism; it is outside the scope of this
+    specification to define that mechanism.
 
     <ul>
-        <li><dfn>usb</dfn> - the respective Authenticator may be contacted over
-            USB.
-        <li><dfn>nfc</dfn> - the respective Authenticator may be contacted over
-            Near Field Communication (NFC).
-        <li><dfn>ble</dfn> - the respective Authenticator may be contacted over
-            Bluetooth Smart (Bluetooth Low Energy / BLE).
+        <li><dfn>usb</dfn> - the respective Authenticator may be contacted over USB.
+        <li><dfn>nfc</dfn> - the respective Authenticator may be contacted over Near Field Communication (NFC).
+        <li><dfn>ble</dfn> - the respective Authenticator may be contacted over Bluetooth Smart (Bluetooth Low Energy / BLE).
     </ul>
 </div>
 
@@ -1297,35 +1291,36 @@ attestation signature created using the key of the attesting authority (except f
 is created using the private key associated with the credential). In order to correctly interpret an attestation statement, a
 <a>[RP]</a> needs to understand two aspects of the attestation:
 
-1. The <dfn>attestation format</dfn> is the manner in which the signature is represented and the various contextual bindings are
-    incorporated into the attestation statement by the <a>authenticator</a>. In other words, this defines the syntax of the
-    statement. Various existing devices and platforms (such as TPMs and the Android OS) have previously defined attestation
-    formats. This specification supports a variety of such formats in an extensible way, as defined in [[#attestation-formats]].
+1. The <dfn>attestation statement format</dfn> is the manner in which the signature is represented and the various contextual
+    bindings are incorporated into the attestation statement by the <a>authenticator</a>. In other words, this defines the
+    syntax of the statement. Various existing devices and platforms (such as TPMs and the Android OS) have previously defined
+    attestation statement formats. This specification supports a variety of such formats in an extensible way, as defined in
+    [[#attestation-formats]].
 
 2. The <dfn>attestation type</dfn> defines the semantics of the attestation statement and its underlying trust model. It defines
     how a [RP] establishes trust in a particular attestation statement, after verifying that it is cryptographically valid.
 
-In general, there is no simple mapping between attestation formats and attestation types. For example the "packed" attestation
-format defined in [[#packed-attestation]] can be used in conjunction with all attestation types, while other formats and types
-have more limited applicability.
+In general, there is no simple mapping between attestation statement formats and attestation types. For example the "packed"
+attestation statement format defined in [[#packed-attestation]] can be used in conjunction with all attestation types, while
+other formats and types have more limited applicability.
 
 The privacy, security and operational characteristics of attestation depend on:
 - The attestation type, which determines the trust model,
-- The attestation format, which may constrain the strength of the attestation by limiting what can be expressed in an
+- The attestation statement format, which may constrain the strength of the attestation by limiting what can be expressed in an
     attestation statement, and
 - The characteristics of the individual authenticator, such as its construction, whether part or all of it runs in a secure
     operating environment, and so on.
 
-It is expected that most authenticators will support a small number of attestation types and formats, while [RPS] will decide
-what attestation types are acceptable to them by policy. [RPS] 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.
+It is expected that most authenticators will support a small number of attestation types and attestation statement formats,
+while [RPS] will decide what attestation types are acceptable to them by policy. [RPS] 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.
 
 
-### Attestation Formats ### {#attestation-formats}
+### Attestation Statement Formats ### {#attestation-formats}
 
-As described above, an attestation format is a data format which represents a cryptographic signature by an authenticator over a
-set of contextual bindings. Each attestation format is defined by the following attributes:
+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 is defined by the following attributes:
 
 - Its <a>attestation format identifier</a>.
 
@@ -1342,7 +1337,7 @@ set of contextual bindings. Each attestation format is defined by the following
     - The attestation type, and the trust path of the attestation. This trust path is either empty (in case of
         self-attestation), a DAA root key (in the case of Direct Anonymous Attestation), or a set of X.509 certificates.
 
-The initial list of supported formats is in [[#defined-attestation-formats]].
+The initial list of supported attestation statement formats is in [[#defined-attestation-formats]].
 
 
 <!-- Editors Note: differentiating section IDs from non-section IDs is useful because at times we need to seperately reference
@@ -1380,15 +1375,15 @@ WebAuthn supports multiple attestation types:
 
 ### Generating an Attestation Object ### {#generating-an-attestation-object}
 
-This section specifies the algorithm for generating an <a>attestation object</a> for any <a>attestation format</a>.
+This section specifies the algorithm for generating an <a>attestation object</a> for any <a>attestation statement format</a>.
 
-In order to construct an <a>attestation object</a> for a given credential using a particular <a>attestation format</a>, the
-authenticator MUST first generate an <a>authenticatorData</a> structure,
+In order to construct an <a>attestation object</a> for a given credential using a particular <a>attestation statement
+format</a>, the authenticator MUST first generate an <a>authenticatorData</a> structure,
 
 The authenticator MUST then concatenate this <a>authenticatorData</a> and the client-supplied <a>clientDataHash</a> as specified
 in [[#authenticator-signature]] to form <dfn>attToBeSigned</dfn>. It must then run the signing procedure for the desired
-attestation format with <a>attToBeSigned</a> as input, and use this to construct an attestation statement in that attestation
-format.
+attestation statement format with <a>attToBeSigned</a> as input, and use this to construct an attestation statement in that
+attestation statement format.
 
 Finally, the authenticator MUST construct the <a>attestation object</a> as a CBOR map comprising the following fields:
 
@@ -1398,7 +1393,7 @@ Finally, the authenticator MUST construct the <a>attestation object</a> as a CBO
 : authenticatorData
 :: The authenticator data used to generate the attestation statement.
 
-: attestation
+: attestationStatement
 :: The attestation statement constructed above.
 
 
@@ -1488,19 +1483,19 @@ When requested to register a new credential with a {{ScopedCredentialInfo}} stru
 6. Compute the <a>clientDataHash</a> over {{ScopedCredentialInfo/clientData}} using the {{ClientData/hashAlg}} algorithm found
     in the {{ClientData}} structure.
 
-7. Perform CBOR decoding on the {{ScopedCredentialInfo/attestation}} field of the {{ScopedCredentialInfo}} object to obtain the
-    attestation format |fmt|, the authenticator data |data|, and the attestation statement |stmt|.
+7. Perform CBOR decoding on the {{ScopedCredentialInfo/attestationObject}} field of the {{ScopedCredentialInfo}} structure to
+    obtain the attestation statement format |fmt|, the authenticator data |data|, and the attestation statement |stmt|.
 
 8. Verify that the RP ID hash in |data| is indeed the SHA-256 hash of the RP ID expected by the RP.
 
-9. Perform an <a>ASCII case-insensitive match</a> on |fmt| to determine the attestation format.
+9. Perform an <a>ASCII case-insensitive match</a> on |fmt| to determine the attestation statement format.
 
-10. Using the verification process for the above attestation format, validate that |stmt| is a valid attestation statement for
-    authenticator data |data| and the <a>clientDataHash</a> computed in step 6.
+10. Using the verification process for the above attestation statement format, validate that |stmt| is a valid attestation
+    statement for authenticator data |data| and the <a>clientDataHash</a> computed in step 6.
 
 11. If validation is successful, obtain a list of acceptable trust anchors (attestation root certificates or DAA root keys) for
-    that attestation type and format |fmt|, from a trusted source or from policy. For example, the FIDO Metadata Service
-    [[FIDOMetadataService]] provides one way to access such information, using the AAGUID in |data|.
+    that attestation type and attestation statement format |fmt|, from a trusted source or from policy. For example, the FIDO
+    Metadata Service [[FIDOMetadataService]] provides one way to access such information, using the AAGUID in |data|.
 
 12. Verify the trustworthiness of the attestation using the outputs of the verification process in step 10 as follows:
         - If self-attestation was used, check if self-attestation is acceptable under [RP] policy.
@@ -1545,37 +1540,36 @@ When requested to perform authentication with an {{AuthenticationAssertion}} str
 3. If the above verification succeeds, authenticate the user looked up in step 1. Otherwise, reject the authentication request.
 
 
-# Defined Attestation Formats # {#defined-attestation-formats}
+# Defined Attestation Statement Formats # {#defined-attestation-formats}
 
-WebAuthn supports pluggable attestation data formats. This section defines an initial set of such formats.
+WebAuthn supports pluggable attestation statement formats. This section defines an initial set of such formats.
 
 ## Attestation Format Identifiers ## {#sctn-attstn-fmt-ids}
 
-Attestation formats are identified by a string, called a <dfn>attestation format identifier</dfn>, chosen by the attestation
-format author.
+Attestation statement formats are identified by a string, called a <dfn>attestation format identifier</dfn>, chosen by the
+author of the attestation statement format.
 
 Attestation format identifiers SHOULD be registered per [[WebAuthn-Registries]] "Registries for Web Authentication (WebAuthn)".
 All registered attestation format identifiers are unique amongst themselves as a matter of course.
 
-Unregistered attestation format identifiers SHOULD use reverse domain-name naming, using a domain
-name registered by the attestation type developer, in order to assure uniqueness of the identifier.
-All attestation format identifiers MUST be a maximum of 32 octets in length and MUST
-consist only of printable USASCII characters, i.e., VCHAR as defined in [[!RFC5234]] (note: this means attestation format
-identifiers based on domain names MUST incorporate only LDH Labels [[!RFC5890]]).
-Implementations MUST match WebAuthn attestation format identifiers in a case-insensitive fashion.
+Unregistered attestation format identifiers SHOULD use reverse domain-name naming, using a domain name registered by the
+developer, in order to assure uniqueness of the identifier. All attestation format identifiers MUST be a maximum of 32 octets in
+length and MUST consist only of printable USASCII characters, i.e., VCHAR as defined in [[!RFC5234]] (note: this means
+attestation format identifiers based on domain names MUST incorporate only LDH Labels [[!RFC5890]]). Implementations MUST match
+WebAuthn attestation format identifiers in a case-insensitive fashion.
 
-Attestation formats that may exist in multiple versions SHOULD include a version in their identifier. In effect, different
-versions are thus treated as different extensions, e.g., `packed2` as a new version of the `packed` attestation format.
+Attestation statement formats that may exist in multiple versions SHOULD include a version in their identifier. In effect,
+different versions are thus treated as different formats, e.g., `packed2` as a new version of the `packed` attestation statement
+format.
 
-The following sections present a set of currently-defined and registered attestation formats and their identifiers. See the
-WebAuthn Attestation Format Identifier Registry defined in [[WebAuthn-Registries]] for an up-to-date list of registered WebAuthn
-Attestation Formats.
+The following sections present a set of currently-defined and registered attestation statement formats and their identifiers.
+See the WebAuthn Attestation Format Identifier Registry defined in [[WebAuthn-Registries]] for an up-to-date list of registered
+attestation statement formats.
 
-## Packed Attestation Format ## {#packed-attestation}
+## Packed Attestation Statement Format ## {#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 <a>authenticators</a> with very limited resources (e.g., secure
-elements).
+This is a WebAuthn optimized attestation statement format. It uses a very compact but still extensible encoding method. Encoding
+this format can even be implemented by <a>authenticators</a> with very limited resources (e.g., secure elements).
 
 
 : Attestation format identifier
@@ -1675,9 +1669,10 @@ The attestation certificate MUST have the following fields/extensions:
     See, for example, the FIDO Metadata Service [[FIDOMetadataService]].
 
 
-## TPM Attestation Format ## {#tpm-attestation}
+## TPM Attestation Statement Format ## {#tpm-attestation}
 
-This attestation format is generally used by authenticators that use a Trusted Platform Module as their cryptographic engine.
+This attestation statement format is generally used by authenticators that use a Trusted Platform Module as their cryptographic
+engine.
 
 : Attestation format identifier
 :: tpm
@@ -1778,7 +1773,7 @@ TPM <a>attestation certificate</a> MUST have the following fields/extensions:
     See, for example, the FIDO Metadata Service [[FIDOMetadataService]].
 
 
-## Android Key Attestation Format ## {#android-key-attestation}
+## Android Key Attestation Statement Format ## {#android-key-attestation}
 
 When the <a>Authenticator</a> in question is a platform-provided Authenticator on the Android "N" or later platform, the
 attestation statement is based on the
@@ -1822,7 +1817,7 @@ with the fields of the attestation certificate's extension data.
     - If successful, return attestation type Basic with the trust path set to the entire attestation statement.
 
 
-## Android SafetyNet Attestation Format ## {#android-safetynet-attestation}
+## Android SafetyNet Attestation Statement Format ## {#android-safetynet-attestation}
 
 When the <a>Authenticator</a> in question is a platform-provided Authenticator on certain Android platforms, the attestation
 statement is based on the [SafetyNet API](https://developer.android.com/training/safetynet/index.html#compat-check-response). In
@@ -1865,10 +1860,9 @@ identity of the calling application.
     - If successful, return attestation type Basic with the trust path set to the above attestation certificate.
 
 
-## FIDO U2F Attestation Format ## {#fido-u2f-attestation}
+## FIDO U2F Attestation Statement Format ## {#fido-u2f-attestation}
 
-This attestation format is used to represent attestation statements from FIDO U2F authenticators using the formats defined in
-[[FIDO-U2F-Message-Formats]].
+This attestation statement format is used with FIDO U2F authenticators using the formats defined in [[FIDO-U2F-Message-Formats]].
 
 : Attestation format identifier
 :: fido-u2f