Address most of @equalsJeffH's review comments

index.bs

@@ -277,7 +277,7 @@ external hardware, or a combination of both.
 ## [RPS] ## {#conforming-relying-parties}
 
 A [=[RP]=] MUST behave as described in [[#rp-operations]] to obtain all the security benefits offered by this specification. See
-[[#sctn-rp-benefits]] for a detailed discussion of this.
+[[#sctn-rp-benefits]] for further discussion of this.
 
 
 ## All Conformance Classes ## {#conforming-all-classes}
@@ -4758,28 +4758,30 @@ The main benefits offered to [=[RPS]=] by this specification include:
 1. The [=[RP]=] can automatically support multiple types of [=user verification=] - for example PIN, biometrics and/or future
     methods - with little or no code change, and can let each user decide which they prefer to use via their choice of
     [=authenticator=].
-1. The [=[RP]=] does not need to store any secrets or sensitive information in order to gain the above benefits.
+1. The [=[RP]=] does not need to store additional secrets in order to gain the above benefits.
 
 As stated in the [[#conforming-relying-parties|Conformance]] section, the [=[RP]=] MUST behave as described in [[#rp-operations]]
 to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described in the
 next section.
 
 
-### Self Attestation and Ignoring Attestation ### {#sctn-no-attestation-security-attestation}
+### Considerations for Self and None Attestation Types and Ignoring Attestation ### {#sctn-no-attestation-security-attestation}
 
 When [[#registering-a-new-credential|registering a new credential]], the [=[RP]=] MAY choose to accept an [=attestation
-statement=] with [=self attestation=] or [=no attestation statement|no attestation=], or to not verify the [=attestation
-statement=] at all. In all of these cases the [=[RP]=] loses much of benefit (3) listed above, but retains the other benefits.
+statement=] of [[#sctn-attestation-types|type]] [=self attestation|Self=] or [=no attestation statement|None=], or to not verify
+the [=attestation statement=]. In all of these cases the [=[RP]=] loses much of benefit (3) listed above, but retains the other
+benefits.
 
 In these cases it is possible for a [=man-in-the-middle attack|man-in-the-middle attacker=] - for example, a malicious [=client=]
-or script - to replace the [=credential public key=] to be registered, and subsequently tamper with any future [=assertion=]
-[=ceremony=] that passes through the same attacker. [=Authentication=] [=ceremonies=] are still highly resistant to
-[=man-in-the-middle attacks=], but only against attackers that were not present at the time of [=registration=]. Accepting these
-kinds of [=attestation statements=] therefore constitutes a [=leap of faith=]. Note, however, that such an attack would be easy to
-detect and very difficult to maintain, since any [=assertion=] [=ceremony=] that the same attacker does not or cannot tamper with
-would always fail.
-
-The [=[RP]=] SHOULD consider the above in its threat model when deciding its policy on what [=attestation statements=] to accept.
+or script - to replace the [=credential public key=] to be registered, and subsequently tamper with future [=authentication
+assertions=] bound for the same [=[RP]=] and passing through the same attacker. Accepting these [[#sctn-attestation-types|types]]
+of [=attestation statements=] therefore constitutes a [=leap of faith=]. In cases where [=registration=] was accomplished
+securely, subsequent [=authentication=] [=ceremonies=] remain resistant to [=man-in-the-middle attacks=], i.e., benefit (3) is
+retained. Note, however, that such an attack would be easy to detect and very difficult to maintain, since any [=authentication=]
+[=ceremony=] that the same attacker does not or cannot tamper with would always fail.
+
+The [=[RP]=] SHOULD consider the above in its threat model when deciding its policy on what [[#sctn-attestation-types|attestation
+types]] to accept or whether to ignore [=attestation=].
 
 
 ## credentialId Unsigned ## {#credentialIdSecurity}