diff --git a/index.html b/index.html
index e92195713..95f6b14b4 100644
--- a/index.html
+++ b/index.html
@@ -490,7 +490,7 @@ <h3>Ecosystem Overview</h3>
                three parties can use information from a logical
                verifiable data registry">
           <figcaption style="text-align: center;">
-            The roles and information flows forming the basis for this 
+            The roles and information flows forming the basis for this
             specification.
           </figcaption>
         </figure>
@@ -956,7 +956,7 @@ <h3>Credentials</h3>
           ">
           <figcaption style="text-align: center;">
             Information graphs associated with a basic verifiable credential,
-            using an [=enveloping proof=] based on [[[VC-JOSE-COSE]]] 
+            using an [=enveloping proof=] based on [[[VC-JOSE-COSE]]]
             [[?VC-JOSE-COSE]].
           </figcaption>
         </figure>
@@ -2002,7 +2002,7 @@ <h3>Validity Period</h3>
 the past. Note that this value represents the earliest point in time at which
 the information associated with the `credentialSubject`
 [=property=] becomes valid. If a `validUntil` value also exists, the
-`validFrom` value MUST express a point in time that is temporally the same or 
+`validFrom` value MUST express a point in time that is temporally the same or
 earlier than the point in time expressed by the `validUntil` value.
           </dd>
           <dt><var id="defn-validUntil">validUntil</var></dt>
@@ -4112,18 +4112,18 @@ <h3>Securing Mechanism Specifications</h3>
 
         <p>
 A securing mechanism specification that creates a new type of [=embedded proof=]
-MUST specify a [=property=] that relates the [=verifiable credential=] or 
+MUST specify a [=property=] that relates the [=verifiable credential=] or
 [=verifiable presentation=] to a [=proof graph=].
 The requirements on the securing mechanism are as follow:
         </p>
         <ul>
           <li>
-The securing mechanism MUST define all terms used by the [=proof graph=]. For 
+The securing mechanism MUST define all terms used by the [=proof graph=]. For
 example, the mechanism could define vocabulary specifications and `@context`
 files in the same manner as they are used by this specification.
           </li>
           <li>
-The securing mechanism MUST secure all graphs in the [=verifiable credential=] 
+The securing mechanism MUST secure all graphs in the [=verifiable credential=]
 or the [=verifiable presentation=], except for any [=proof graphs=] securing
 the [=verifiable credential=] or the [=verifiable presentation=] itself.
           </li>
@@ -4131,8 +4131,8 @@ <h3>Securing Mechanism Specifications</h3>
         </ul>
 
       <p class="note">
-The last requirement means that the securing mechanism secures the [=default 
-graph=] and, for [=verifiable presentations=], each [=verifiable credential=] 
+The last requirement means that the securing mechanism secures the [=default
+graph=] and, for [=verifiable presentations=], each [=verifiable credential=]
 of the presentation, together with their respective [=proof graphs=].
 See also [[[#info-graph-vp]]] or [[[#info-graph-vp-mult-creds]]].
       </p>
@@ -4288,9 +4288,9 @@ <h3>Restrictions on JSON-LD</h3>
 keywords in the `@context` value are used to globally affect values in a
 [=verifiable credential=] or [=verifiable presentation=], such as by
 setting either or both of the `@base` or `@vocab` keywords. For example, setting
-these values might trigger a failure in a mis-implemented JSON Schema test of 
-the `@context` value in an implementation that is performing [=type-specific 
-credential processing=] and not expecting the `@base` and/or `@vocab` value to 
+these values might trigger a failure in a mis-implemented JSON Schema test of
+the `@context` value in an implementation that is performing [=type-specific
+credential processing=] and not expecting the `@base` and/or `@vocab` value to
 be expressed in the `@context` value.
           </p>
 
@@ -5805,8 +5805,8 @@ <h3>Issuer Cooperation Impacts on Privacy</h3>
 [=Verifiable credentials=] rely on a high degree of trust in [=issuers=].
 The degree to which a [=holder=] might take advantage of possible privacy
 protections often depends strongly on the support an [=issuer=] provides for
-such features. In many cases, privacy protections which make use of 
-zero-knowledge proofs, data minimization techniques, bearer credentials, 
+such features. In many cases, privacy protections which make use of
+zero-knowledge proofs, data minimization techniques, bearer credentials,
 abstract claims, and protections against signature-based correlation require
 active support by the [=issuer=], who need to incorporate those capabilities
 into the [=verifiable credentials=] they issue.
@@ -5850,7 +5850,7 @@ <h3>Issuer Cooperation Impacts on Privacy</h3>
       <h2>Security Considerations</h2>
 
       <p>
-[=Issuers=], [=holders=], and [=verifiers=] should be aware of a number of 
+[=Issuers=], [=holders=], and [=verifiers=] should be aware of a number of
 security considerations when processing data described by this specification.
 Ignoring or not understanding the implications of this section can result in
 security vulnerabilities.
@@ -5893,7 +5893,7 @@ <h3>Key Management</h3>
 credentials=] and [=verifiable presentations=], depends on the quality and
 protection of their <em>private signing keys</em>. The management of
 cryptographic keys encompasses a vast and complex field. For comprehensive
-recommendations and in-depth discussion, readers are directed to 
+recommendations and in-depth discussion, readers are directed to
 [[NIST-SP-800-57-Part-1]]. As strongly recommended in both [[FIPS-186-5]] and
 [[NIST-SP-800-57-Part-1]], a private signing key is not to be used for multiple
 purposes; for example, a private signing key is not to be used for encryption
@@ -5924,7 +5924,7 @@ <h3>Content Integrity Protection</h3>
 [=Verifiable credentials=] often contain URLs to data that resides outside
 the [=verifiable credential=]. Linked content that exists outside a
 [=verifiable credential=] &mdash; such as images, JSON-LD extension contexts,
-JSON Schemas, and other machine-readable data &mdash; is not protected 
+JSON Schemas, and other machine-readable data &mdash; is not protected
 against tampering because the data resides outside of the protection of the
 <a href="#securing-mechanisms">securing mechanism</a> on the
 [=verifiable credential=].
@@ -5971,7 +5971,7 @@ <h3>Man-in-the-Middle (MITM), Replay, and Cloning Attacks</h3>
 <a href="https://en.wikipedia.org/wiki/Replay_attack">replay</a>, and
 <a href="https://en.wikipedia.org/wiki/Spoofing_attack">spoofing</a> attacks.
 Both online and offline use cases might be susceptible to these attacks, where
-an adversary intercepts, modifies, re-uses, and/or replicates the [=verifiable 
+an adversary intercepts, modifies, re-uses, and/or replicates the [=verifiable
 credential=] data during transmission or storage.
         </p>
         <h4>Man-in-the-Middle (MITM) Attack</h4>
@@ -5994,7 +5994,7 @@ <h4>Man-in-the-Middle (MITM) Attack</h4>
         <h4>Replay Attack</h4>
 
         <p>
-A [=verifier=] might wish to limit the number of times that 
+A [=verifier=] might wish to limit the number of times that
 [=verifiable presentation=] can be used. For example, multiple individuals
 presenting the same [=verifiable credential=] representing an event ticket
 might be granted entry to the event, undermining the purpose of the ticket
@@ -6076,7 +6076,7 @@ <h3>Device Theft and Impersonation</h3>
         <p>
 Storing [=verifiable credentials=] on a device poses risks if the device is
 lost or stolen. An attacker gaining possession of such a device potentially
-acquires unauthorized access to systems using the victim's [=verifiable 
+acquires unauthorized access to systems using the victim's [=verifiable
 credentials=]. Ways to mitigate this type of attack include:
         </p>
 
@@ -6109,7 +6109,7 @@ <h3>Device Theft and Impersonation</h3>
 non-repudiation mechanisms. These mechanisms solidify an [=entity's=]
 responsibility for its actions or transactions, reinforcing accountability and
 deterring malicious behavior. Attainment of non-repudiation is a
-multifaceted endeavor, encompassing an array of techniques including 
+multifaceted endeavor, encompassing an array of techniques including
 <a href="#securing-mechanisms">securing mechanisms</a>, proofs of possession,
 and authentication schemes in various protocols designed to foster trust and
 reliability.