Fix broken ReSpec markup introduced by Patterns of Use changes.

Author: msporny

index.html

@@ -269,9 +269,9 @@
       <p>
 [=Credentials=] are integral to our daily lives: driver's licenses confirm
 our capability to operate motor vehicles; university degrees assert our level
-of education; and government-issued passports attest to our citizenship when 
+of education; and government-issued passports attest to our citizenship when
 traveling between countries. This specification provides a mechanism for
-expressing these sorts of [=credentials=] on the Web in a way that is 
+expressing these sorts of [=credentials=] on the Web in a way that is
 cryptographically secure, privacy respecting, and machine verifiable. These
 [=credentials=] provide benefits to us when used in the physical world, but
 their use on the Web continues to be elusive.
@@ -307,9 +307,9 @@ <h2>Introduction</h2>
       <p>
 [=Credentials=] are integral to our daily lives: driver's licenses confirm
 our capability to operate motor vehicles; university degrees assert our level
-of education; and government-issued passports attest to our citizenship when 
+of education; and government-issued passports attest to our citizenship when
 traveling between countries. This specification provides a mechanism for
-expressing these sorts of [=credentials=] on the Web in a way that is 
+expressing these sorts of [=credentials=] on the Web in a way that is
 cryptographically secure, privacy respecting, and machine verifiable. These
 [=credentials=] provide benefits to us when used in the physical world, but
 their use on the Web continues to be elusive.
@@ -5548,7 +5548,7 @@ <h3>Patterns of Use</h3>
 [=subject=] across multiple [=presentations=] or [=verifiers=]. Even
 when different [=credentials=] are presented, if the [=subject=]
 identifier is the same, [=verifiers=] (and those with access to
-[=verifier=] logs) could infer that the [=credentials'=] [=subjects=]
+[=verifier=] logs) could infer that the [=credentials=]' [=subjects=]
 are the same entity.
           </li>
           <li>
@@ -5562,12 +5562,11 @@ <h3>Patterns of Use</h3>
 established profile. For more information, see [[DEMOGRAPHICS]].
           </li>
           <li>
-Passing the identifier of a [=credential=] to a centralized revocation
-server. The centralized server can correlate the [=credential's=] use across
-interactions. For example, if a [=credential=] is used to prove age in
-this manner, the centralized service could know everywhere that
-[=credential=] was presented (all liquor stores, bars, adult stores,
-lottery sellers, and so on).
+Passing the identifier of a [=credential=] to a centralized revocation server.
+The centralized server can correlate the [=credential|credential's=] use across
+interactions. For example, if a [=credential=] is used to prove age in this
+manner, the centralized service could know everywhere that [=credential=] was
+presented (all liquor stores, bars, adult stores, lottery sellers, and so on).
           </li>
         </ul>
 
@@ -5740,7 +5739,7 @@ <h3>Data Theft</h3>
         <h3>Frequency of Claim Issuance</h3>
 
         <p>
-As detailed in Section [[[#usage-patterns]]], patterns of use can be
+As detailed in Section [[[#patterns-of-use]]], patterns of use can be
 correlated with certain types of behavior. This correlation is partially
 mitigated when a [=holder=] uses a [=verifiable credential=] without the
 knowledge of the [=issuer=]. [=Issuers=] can defeat this protection
@@ -5951,7 +5950,7 @@ <h3>Content Integrity Protection</h3>
         <p>
 Implementers are urged to understand how links to external machine-readable
 content that are not content-integrity protected could result in successful
-attacks against their applications, and utilize the content integrity 
+attacks against their applications, and utilize the content integrity
 protection mechanism provided by this specification if a security issue could
 occur if the external resource is changed.
         </p>
@@ -6112,7 +6111,7 @@ <h3>Device Theft and Impersonation</h3>
         </ul>
 
         <p>
-Furthermore, instances of impersonation can manifest in various forms, 
+Furthermore, instances of impersonation can manifest in various forms,
 including situations where an [=entity=] attempts to disavow their actions.
 Elevating the level of trust and security within the realm of [=verifiable
 credentials=] entails more than just averting impersonation; it involves the
@@ -6210,7 +6209,7 @@ <h3>Code Injection</h3>
 processing language and base direction information.
           </li>
           <li>
-It increases the security attack surface when utilizing this data model, 
+It increases the security attack surface when utilizing this data model,
 because naively processing HTML could result in the execution of a `script`
 tag that an attacker injected at some point during the data production process.
           </li>
@@ -7124,7 +7123,7 @@ <h3>Differences between Contexts, Types, and CredentialSchemas</h3>
         <p>
 While it is possible to use some [[JSON-LD11]] features to allude to the
 contents of the [=verifiable credential=], it's not generally suggested to use
-`@context` to constrain the data types of the data model. For example, 
+`@context` to constrain the data types of the data model. For example,
 `"@type": "@json"` is useful for leaving the semantics open-ended and not
 strictly defined. This can be dangerous if the implementer is looking to
 constrain the data type of the claims in the [=credential=], and is expected