various attestation text polishing, fixes #395

index.bs

@@ -228,11 +228,11 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 :: See [=Authentication Assertion=].
 
 : <dfn>Attestation</dfn>
-:: Generally, a statement that serves to bear witness, confirm, or authenticate.
-    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 [=attestation statement format=], and [=attestation type=].
+:: Generally, <em>attestation</em> is a statement serving to bear witness, confirm, or authenticate.
+    In the WebAuthn context, [=attestation=] is employed to <em>attest</em> to the <em>provenance</em> of an [=authenticator=]
+    and the data it emits; including, for example: credential IDs, [=credential key pairs=], signature counters, etc. An
+    [=attestation statement=] is conveyed in an [=attestation object=] during [=registration=]. See also [[#sctn-attestation]]
+    and [Figure 3](#fig-attStructs).
 
 : <dfn>Attestation Certificate</dfn>
 :: A X.509 Certificate for the <dfn>attestation key pair</dfn> used by an [=authenticator=] to attest to its manufacture
@@ -869,18 +869,18 @@ during registration.
 <div dfn-type="attribute" dfn-for="AuthenticatorAttestationResponse">
     :   {{AuthenticatorResponse/clientDataJSON}}
     ::  This attribute, inherited from {{AuthenticatorResponse}}, contains the [=JSON-serialized client data=] (see
-        [[#cred-attestation]]) passed to the authenticator by the client in order to generate this credential. The
+        [[#sctn-attestation]]) passed to the authenticator by the client in order to generate this credential. The
         exact JSON serialization must be preserved, as the [=hash of the serialized client data=] has been computed
         over it.
 
     :   <dfn>attestationObject</dfn>
     ::  This attribute contains an [=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
+        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 [RP]'s server requires to validate the
-        attestation statement, as well as to decode and validate the [=authenticator data=] along with the
-        [=JSON-serialized client data=]. For more details, see [[#cred-attestation]] as well as
+        [=attestation statement=], as well as to decode and validate the [=authenticator data=] along with the
+        [=JSON-serialized client data=]. For more details, see [[#sctn-attestation]] as well as
         [Figure 3](#fig-attStructs).
 </div>
 
@@ -1333,7 +1333,7 @@ Authenticators produce cryptographic signatures for two distinct purposes:
 1. An <dfn>attestation signature</dfn> is produced when a new credential is created, and provides cryptographic proof of certain
     properties of the credential and the authenticator. For instance, an attestation signature asserts the type of authenticator
     (as denoted by its AAGUID) and the public key of the credential. The attestation signature is signed by an attestation key,
-    which is chosen depending on the type of attestation desired. For more details on attestation, see [[#cred-attestation]].
+    which is chosen depending on the type of [=attestation=] desired. For more details on [=attestation=], see [[#sctn-attestation]].
 2. An <dfn>assertion signature</dfn> 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 which possesses a particular credential private key
@@ -1478,7 +1478,7 @@ When this operation is invoked, the authenticator must perform the following pro
 - Process all the supported extensions requested by the client, and generate the [=authenticator data=] with
     [=attestation data=] as specified in [[#sec-authenticator-data]]. Use this [=authenticator data=] and the
     [=hash of the serialized client data=] to create an [=attestation object=] for the new credential using the procedure
-    specified in [[#generating-an-attestation-object]]. For more details on attestation, see [[#cred-attestation]].
+    specified in [[#generating-an-attestation-object]]. For more details on attestation, see [[#sctn-attestation]].
 
 On successful completion of this operation, the authenticator returns the [=attestation object=] to the client.
 
@@ -1542,54 +1542,55 @@ This operation is ignored if it is invoked in an authenticator session which doe
 or [=authenticatorGetAssertion=] operation currently in progress.
 
 
-## Credential Attestation ## {#cred-attestation}
+## Attestation ## {#sctn-attestation}
 
-Authenticators must also provide some form of attestation. The basic requirement is that the authenticator can produce, for each
-credential public key, attestation information that can be verified by a Relying Party. Typically, this information contains a
-signature by an attestation private key over the attested credential public key and a challenge, as well as a certificate or
-similar information providing provenance information for the attestation public key, enabling a trust decision to be made.
-However, if an attestation key pair is not available, then the authenticator MUST perform self attestation of the credential
-public key with the corresponding credential private key. All this information is returned by the authenticator any time a new
-credential is generated, in the form of an [=attestation object=]. The relationship of [=authenticator data=] and the
-[=attestation data=], attestation object, and attestation statement data structures is illustrated in
-[the figure below](#fig-attStructs).
+[=Authenticators=] must also provide some form of [=attestation=]. The basic requirement is that the [=authenticator=] can
+produce, for each [=credential public key=], an [=attestation statement=] verifable by the [RP]. Typically, this [=attestation
+statement=] contains a signature by an [=attestation private key=] over the attested [=credential public key=] and a challenge,
+as well as a certificate or similar data providing provenance information for the [=attestation public key=], enabling the [RP]
+to make a trust decision. However, if an [=attestation key pair=] is not available, then the authenticator MUST perform [=self
+attestation=] of the [=credential public key=] with the corresponding [=credential private key=]. All this information is
+returned by [=authenticators=] any time a new [=public key credential=] is generated, in the overall form of an <dfn>attestation
+object</dfn>. The relationship of the [=attestation object=] with [=authenticator data=] (containing [=attestation data=]) and
+the [=attestation statement=] is illustrated in [figure 3](#fig-attStructs), below.
 
 <figure id="fig-attStructs">
     <img src="images/fido-attestation-structures.svg"/>
     <figcaption>[=Attestation object=] layout illustrating its inclusion of [=authenticator data=] (containing [=attestation data=]) and the [=attestation statement=].</figcaption>
 </figure>
 
-An important component of the [=attestation object=] is the credential attestation statement. This is a specific type of
-signed data object, containing statements about a credential itself and the authenticator that created it. It contains an
-attestation signature created using the key of the attesting authority (except for the case of [=self attestation=], when it
-is created using the private key associated with the credential). In order to correctly interpret an attestation statement, a
-[=[RP]=] needs to understand two aspects of the attestation:
+An important component of the [=attestation object=] is the <dfn>attestation statement</dfn>. This is a specific type of signed
+data object, containing statements about a [=public key credential=] itself and the [=authenticator=] that created it. It
+contains an [=attestation signature=] created using the key of the attesting authority (except for the case of [=self
+attestation=], when it is created using the [=credential private key=]). In order to correctly interpret an [=attestation
+statement=], a [=[RP]=] needs to understand two aspects of the attestation:
 
 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 [=authenticator=]. 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. This
-    specification supports a number of attestation types, as described in [[#sctn-attestation-types]].
+2. The <dfn>attestation type</dfn> defines the semantics of [=attestation statements=] and their underlying trust models. 
+    Specifically, it defines how a [=[RP]=] establishes trust in a particular [=attestation statement=], after verifying that it
+    is cryptographically valid. This specification supports a number of [=attestation types=], as described in
+    [[#sctn-attestation-types]].
 
-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.
+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 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
+The privacy, security and operational characteristics of [=attestation=] depend on:
+- The [=attestation type=], which determines the trust model,
+- 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 attestation statement formats,
-while [RPS] will decide what attestation types are acceptable to them by policy. [=[RP]=]  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 data ### {#sec-attestation-data}