Unify markup of multi-paragraph NOTEs

index.bs

@@ -387,7 +387,8 @@ Beyond that, the intended audiences for this document are the following main gro
     They should also carefully read [[#sctn-security-considerations-authenticator]] and [[#sctn-privacy-considerations-authenticator]].
 
 <div class="note">
-    Note: Along with the [[#sctn-api|Web Authentication API]] itself, this specification defines a
+    <span class="marker">Note:</span>
+    Along with the [[#sctn-api|Web Authentication API]] itself, this specification defines a
     request-response <em>cryptographic protocol</em>&mdash;the
     <dfn export>WebAuthn/FIDO2 protocol</dfn>&mdash;between
     a [=[WRP]=] server and an [=authenticator=], where the [=[RP]=]'s request consists of a
@@ -1236,7 +1237,8 @@ BCP 14 [[!RFC2119]] [[!RFC8174]] when, and only when, they appear in all capital
     [=authentication assertion=]. Which one is generally determined by context.
 
     <div class="note">
-        Note: This is a [=willful violation=] of [[RFC4949]]. In English, a "credential" is both a) the thing presented to prove
+        <span class="marker">Note:</span>
+        This is a [=willful violation=] of [[RFC4949]]. In English, a "credential" is both a) the thing presented to prove
         a statement and b) intended to be used multiple times. It's impossible to achieve both criteria securely with a single
         piece of data in a public key system. [[RFC4949]] chooses to define a credential as the thing that can be used multiple
         times (the public key), while this specification gives "credential" the English term's flexibility. This specification
@@ -1567,7 +1569,8 @@ that are returned to the caller when a new credential is created, or a new asser
         as if the value were null.
 
         <div class="note">
-        Note: If, as the result of a [=registration ceremony|registration=] or [=authentication ceremony=], {{PublicKeyCredential/authenticatorAttachment}}'s value is "cross-platform" and
+        <span class="marker">Note:</span>
+        If, as the result of a [=registration ceremony|registration=] or [=authentication ceremony=], {{PublicKeyCredential/authenticatorAttachment}}'s value is "cross-platform" and
         concurrently {{isUserVerifyingPlatformAuthenticatorAvailable}} returns [TRUE], then the user employed a [=roaming authenticator=] for this [=ceremony=] while there is an available
         [=platform authenticator=]. Thus the [=[RP]=] has the opportunity to prompt the user to register the available [=platform authenticator=], which may enable more streamlined user experience flows.
 
@@ -2524,7 +2527,8 @@ When this method is invoked, the user agent MUST execute the following algorithm
                   [=non-autofill credential type=] is `"webauthn"`,
                 </dt>
         ::  <div class="note">
-                NOTE: The `"webauthn"` [=autofill detail token=] must appear immediately after the last [=autofill detail token=]
+                <span class="marker">Note:</span>
+                The `"webauthn"` [=autofill detail token=] must appear immediately after the last [=autofill detail token=]
                 of type "Normal" or "Contact". For example:
 
                 - `"username webauthn"`
@@ -4808,7 +4812,8 @@ the requested [=public key credential|credential=] is [=scoped=] to exactly matc
 </figure>
 
 <div class="note">
-    Note: The [=authenticator data=] describes its own length: If the [=AT=] and [=authData/flags/ED=] [=flags=] are not set, it is always 37 bytes long.
+    <span class="marker">Note:</span>
+    The [=authenticator data=] describes its own length: If the [=AT=] and [=authData/flags/ED=] [=flags=] are not set, it is always 37 bytes long.
     The [=attested credential data=] (which is only present if the [=AT=] [=flag=] is set) describes its own length. If the [=authData/flags/ED=] [=flag=] is set, then the total length is 37 bytes plus the length of the [=attested credential data=] (if the [=AT=] [=flag=] is set), plus the length of the [=authData/extensions=] output (a [=CBOR=] map) that
     follows.
 
@@ -5590,8 +5595,9 @@ In these cases, the [=authenticator=] provides no guarantees about its operation
     data=]) and the [=attestation statement=].</figcaption>
 </figure>
 <div class="note">
-  This figure illustrates only the `packed` [=attestation statement format=]. Several additional [=attestation statement
-  formats=] are defined in [[#sctn-defined-attestation-formats]].
+    <span class="marker">Note:</span>
+    This figure illustrates only the `packed` [=attestation statement format=]. Several additional [=attestation statement
+    formats=] are defined in [[#sctn-defined-attestation-formats]].
 </div>
 
 An important component of the [=attestation object=] is the <dfn>attestation statement</dfn>. This is a specific type of signed
@@ -6039,7 +6045,8 @@ a numbered step. If outdented, it (today) is rendered as a bullet in the midst o
 
 1. Verify that the <code>[=credentialId=]</code> is not yet registered for any user. If the <code>[=credentialId=]</code> is already known then the [=[RP]=] SHOULD fail this [=registration ceremony=].
 
-    NOTE: The rationale for [=[RPS]=] rejecting duplicate [=credential IDs=] is as follows: [=credential IDs=] contain sufficient entropy that accidental duplication is very unlikely. However, [=attestation types=] other than [=self attestation=] do not include a self-signature to explicitly prove possession of the [=credential private key=] at [=registration=] time. Thus an attacker who has managed to obtain a user's [=credential ID=] and [=credential public key=] for a site (this could be potentially accomplished in various ways), could attempt to register a victim's credential as their own at that site. If the [=[RP]=] accepts this new registration and replaces the victim's existing credential registration, and the [=discoverable credentials|credentials are discoverable=], then the victim could be forced to sign into the attacker's account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.
+    Note: The rationale for [=[RPS]=] rejecting duplicate [=credential IDs=] is as follows:
+    [=credential IDs=] contain sufficient entropy that accidental duplication is very unlikely. However, [=attestation types=] other than [=self attestation=] do not include a self-signature to explicitly prove possession of the [=credential private key=] at [=registration=] time. Thus an attacker who has managed to obtain a user's [=credential ID=] and [=credential public key=] for a site (this could be potentially accomplished in various ways), could attempt to register a victim's credential as their own at that site. If the [=[RP]=] accepts this new registration and replaces the victim's existing credential registration, and the [=discoverable credentials|credentials are discoverable=], then the victim could be forced to sign into the attacker's account at their next attempt. Data saved to the site by the victim in that state would then be available to the attacker.
 
     <li id="reg-ceremony-store-credential-record">
         If the attestation statement |attStmt| verified successfully and is found to be trustworthy,