more linking & terminology, etc polishing

index.bs

@@ -811,7 +811,7 @@ When this method is invoked, the user agent MUST execute the following algorithm
 
             :   {{PublicKeyCredential/[[identifier]]}}
             ::  A new {{ArrayBuffer}}, created using |global|'s [=%ArrayBuffer%=], containing the bytes of the credential ID
-                returned from the successful [=authenticatorGetAssertion=] operation, as defined in [#op-get-assertion]].
+                returned from the successful [=authenticatorGetAssertion=] operation, as defined in [[#op-get-assertion]].
             :   {{PublicKeyCredential/response}}
             ::  A new {{AuthenticatorAssertionResponse}} object associated with |global| whose fields are:
                 : {{AuthenticatorResponse/clientDataJSON}}
@@ -1259,10 +1259,10 @@ the {{CredentialsContainer/create()}} or {{CredentialsContainer/get()}} methods.
 
 <div dfn-type="enum-value" 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 statement formats or via some out-of-band mechanism; it is outside the scope of this
-    specification to define that mechanism.
+    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.
@@ -1343,9 +1343,10 @@ Authenticators produce cryptographic signatures for two distinct purposes:
     assertion by the [=authenticator=] that the user has [=user consent|consented=] to a specific transaction, such as logging
     in, or completing a purchase. Thus, an [=assertion signature=] asserts that the [=authenticator=] possessing a particular
     [=credential private key=] has established, to the best of its ability, that the user requesting this transaction is the
-    same user who [=user consent|consented=] to creating that particular [=public key credential=]. It also provides additional
-    information that might be useful to the caller, such as the means by which [=user consent=] was provided, and the prompt
-    that was shown to the user by the [=authenticator=].
+    same user who [=user consent|consented=] to creating that particular [=public key credential=]. It also asserts additional
+    information, termed [=client data=], that may be useful to the caller, such as the means by which [=user consent=] was
+    provided, and the prompt shown to the user by the [=authenticator=]. The [=assertion signature=] format is illustrated in
+    [Figure 2, below](#fig-signature).
 
 The formats of these signatures, as well as the procedures for generating them, are specified below.
 
@@ -1511,10 +1512,10 @@ When this method is invoked, the [=authenticator=] must perform the following pr
     [=authenticator=] if it has its own output capability, or by the user agent otherwise.
 - Process all the supported extensions requested by the client, and generate the [=authenticator data=] without
     [=attestation data=] as specified in [[#sec-authenticator-data]]. Concatenate this [=authenticator data=] with the [=hash of
-    the serialized client data=] to generate an [=assertion signature=] using the private key of the selected [=public key
-    credential|credential=] [as shown in Figure 2, below](#fig-signature). A simple, undelimited concatenation is safe to use
-    here because the [=authenticator data=] describes its own length. The [=hash of the serialized client data=] (which
-    potentially has a variable length) is always the last element.
+    the serialized client data=] to generate an [=assertion signature=] using the [=credential private key|private key=] of the
+    selected [=public key credential|credential=] [as shown in Figure 2, below](#fig-signature). A simple, undelimited
+    concatenation is safe to use here because the [=authenticator data=] describes its own length. The [=hash of the serialized
+    client data=] (which potentially has a variable length) is always the last element.
 - If any error occurred while generating the [=assertion signature=], return an error code equivalent to "{{UnknownError}}" and
     terminate the operation.
 
@@ -1561,7 +1562,10 @@ the [=attestation statement=] is illustrated in [figure 3](#fig-attStructs), bel
 
 <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>
+    <figcaption>[=Attestation object=] layout illustrating the included [=authenticator data=] (containing [=attestation data=]) and the [=attestation statement=].</figcaption>
+    <div class="note">
+        This figure illustrates only the `packed` [=attestation statement format=]. Several additional [=attestation statement formats=] are defined in [[#defined-attestation-formats]].
+    </div>
 </figure>
 
 An important component of the [=attestation object=] is the <dfn>attestation statement</dfn>. This is a specific type of signed
@@ -1573,7 +1577,7 @@ statement=], a [=[RP]=] needs to understand these two aspects of [=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 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 [=attestation statements=] and their underlying trust models. 
@@ -1654,17 +1658,17 @@ credential. It has the following format:
 
 ### Attestation Statement Formats ### {#attestation-formats}
 
-As described above, an attestation statement format is a data format which represents a cryptographic signature by an
-authenticator over a set of contextual bindings. Each attestation statement format 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 [=attestation statement format identifier=].
 
-- The set of attestation types supported by the format.
+- The set of [=attestation types=] supported by the format.
 
-- The syntax of an attestation statement produced in this format, defined using CDDL for the extension point `$attStmtFormat`
-    defined in [[#generating-an-attestation-object]].
+- The syntax of an [=attestation statement=] produced in this format, defined using [[!CDDL]] for the extension point
+    `$attStmtFormat` defined in [[#generating-an-attestation-object]].
 
-- The procedure for computing an attestation statement in this format given the credential to be attested, the
+- The <dfn>signing procedure</dfn> for computing an attestation statement in this format given the credential to be attested, the
     [=authenticator data=] structure containing the <dfn>authenticator data for the attestation</dfn>, and the
     [=hash of the serialized client data=].
 
@@ -1717,10 +1721,10 @@ WebAuthn supports multiple attestation types:
 
 This section specifies the algorithm for generating an [=attestation object=] for any [=attestation statement format=].
 
-In order to construct an [=attestation object=] for a given credential using a particular [=attestation statement
-format=], the authenticator MUST first generate the [=authenticator data=].
+In order to construct an [=attestation object=] for a given [=public key credential=] using a particular [=attestation statement
+format=], the [=authenticator=] MUST first generate the [=authenticator data=].
 
-The authenticator MUST then run the signing procedure for the desired attestation statement format with this
+The [=authenticator=] MUST then run the signing procedure for the desired attestation statement format with this
 [=authenticator data=] and the [=hash of the serialized client data=] as input, and use this to construct an attestation
 statement in that attestation statement format.