step 1: renamed attestation type to attestation format

index.bs

@@ -591,14 +591,14 @@ providing provenance information for the attesting key, enabling a trust decisio
 
 <div dfn-for="WebAuthnAttestation">
     The <dfn>type</dfn> member specifies the type of attestation statement contained in this structure. This specification
-    defines a number of attestation types, in [[#defined-attestation-types]]. Other attestation types may be defined in later
+    defines a number of attestation formats, in [[#defined-attestation-formats]]. Other attestation formats may be defined in later
     versions of this specification.
 
     The <dfn>clientData</dfn> member contains the <a>clientDataJSON</a> (see [[#signature-format]]). The exact JSON encoding
     must be preserved as the hash (clientDataHash) has been computed over it.
 
     The <dfn>statement</dfn> element contains the actual attestation statement. The structure of this object depends on the
-    attestation type. For more details, see [[#attestation]].
+    attestation format. For more details, see [[#attestation]].
 </div>
 
 This attestation statement is delivered to the <a>[RP]</a> by the [RP]'s script running on the client, using methods outside
@@ -896,17 +896,17 @@ authenticator that holds it. Therefore, the procedures for generating attestatio
 generating WebAuthn assertions as described in [[#signature-format]], though the semantics of the contextual bindings are quite
 different.
 
-This specification defines a number of attestation types, i.e., ways to serialize the data being attested to by the
+This specification defines a number of attestation formats, i.e., ways to serialize the data being attested to by the
 <a>Authenticator</a>. 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
+attestation format provides the ability to cryptographically attest to a public key, the authenticator model, and contextual data
 to a remote party. They differ in the details of how the attestation statement is laid out, and how its components are computed.
-The different attestation types are defined in [[#defined-attestation-types]].
+The different attestation formats are defined in [[#defined-attestation-formats]].
 
 This specification also defines a number of attestation models. These define how a [RP] establishes trust in a particular
 attestation statement, after verifying that it is cryptographically valid.
 
-Attestation types are orthogonal to attestation models, i.e. attestation types in general are not restricted to a single
-attestation model. Broadly speaking, attestation types pertain to the syntax of the attestation statement, while attestation
+Attestation formats are orthogonal to attestation models, i.e. attestation formats in general are not restricted to a single
+attestation model. Broadly speaking, attestation formats pertain to the formatting of the attestation statement, while attestation
 models pertain to the semantics.
 
 
@@ -946,16 +946,16 @@ Compliant servers MUST support all attestation models. Authenticators can choose
 Note: [RPS] can always decide what attestation models are acceptable to them by policy.
 
 
-### Defined Attestation Types ### {#defined-attestation-types}
+### Defined Attestation Formats ### {#defined-attestation-formats}
 
-WebAuthn supports pluggable attestation data types. This allows support of TPM generated attestation data as well as support of
+WebAuthn supports pluggable attestation data formats. This allows support of TPM generated attestation data as well as support of
 other WebAuthn <a>authenticators</a>. As mentioned in [[#attestation]], these differ in how the attestation statement is
 computed and formatted. This section defines these details.
 
 The contents of the attestation data must be controlled (i.e., generated or at least verified) by the authenticator itself.
 
 
-#### Packed Attestation (type="packed") #### {#packed-attestation}
+#### Packed Attestation ("packed") #### {#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
@@ -1131,9 +1131,9 @@ The attestation certificate MUST have the following fields/extensions:
     [[FIDOMetadataService]].
 
 
-#### TPM Attestation (type="tpm") #### {#tpm-attestation}
+#### TPM Attestation ("tpm") #### {#tpm-attestation}
 
-This attestation type returns an attestation statement in the same format as defined in [[#packed-attestation]]. However the
+This attestation format returns an attestation statement in the same format as defined in [[#packed-attestation]]. However the
 `rawData` and `signature` fields are computed differently, as described below.
 
 
@@ -1217,7 +1217,7 @@ This type of attestation statement is formatted as follows:
 
 ##### Signature ##### {#sec-android-attestation-signature}
 
-For this attestation type, the ClientData dictionary is extended in the following way:
+For this attestation format, the ClientData dictionary is extended in the following way:
 
 <pre class="idl">
     dictionary AndroidAttestationClientData : ClientData {
@@ -1281,7 +1281,7 @@ A [RP] shall verify the clientData contextual bindings (see step 4 in [[#verifyi
 
 ### Verifying an Attestation Statement ### {#verifying-an-attestation-statement}
 
-This section outlines the recommended algorithm for verifying an attestation statement, independent of attestation type.
+This section outlines the recommended algorithm for verifying an attestation statement, independent of attestation format.
 
 Upon receiving an attestation statement, the [RP] shall:
 
@@ -1293,7 +1293,7 @@ Upon receiving an attestation statement, the [RP] shall:
     - Verify that the attestation certificate chain is valid and chains up to a trusted root (following [[RFC5280]]).
     - Verify that the attestation certificate has the right Extended Key Usage (EKU) based on the WebAuthn Authenticator type
         (as denoted by the `type` member). In case of a type="tpm", this EKU shall be OID "2.23.133.8.3".
-    - If the attestation type is "android", verify that the attestation certificate is issued to the hostname
+    - If the attestation format is "android", verify that the attestation certificate is issued to the hostname
         "attest.android.com" (see <a href="https://developer.android.com/training/safetynet/index.html#compat-check-response">
         SafetyNet online documentation</a>).
     - Verify that all issuing CA certificates in the chain are valid and not revoked.
@@ -1631,10 +1631,10 @@ credential. It is intended primarily for [RPS] that wish to tightly control the
         typedef sequence < AAGUID > AuthenticatorSelectionList;
     </pre>
 
-    Each AAGUID corresponds to an authenticator attestation that is acceptable to the [RP] for this credential creation. The
+    Each AAGUID corresponds to an authenticator model that is acceptable to the [RP] for this credential creation. The
     list is ordered by decreasing preference.
 
-    An AAGUID is defined as an array containing the globally unique identifier of the authenticator attestation being sought.
+    An AAGUID is defined as an array containing the globally unique identifier of the authenticator model being sought.
 
     <pre class="idl highlight">
         typedef BufferSource AAGUID;