diff --git a/index.html b/index.html
index c3adc46ae..362f8b51e 100644
--- a/index.html
+++ b/index.html
@@ -1070,7 +1070,7 @@ <h3>Getting Started</h3>
 the `credentialSubject` object expresses a particular attribute of the
 credential subject. Once a developer has added a number of these property-value
 combinations, the modified object can be sent to <a>verifiable credential</a>
-issuer sofware and a <a>verifiable credential</a> will be created for the
+issuer software and a <a>verifiable credential</a> will be created for the
 developer. From a prototyping standpoint, that is all a developer needs to do.
         </p>
 
@@ -2325,7 +2325,7 @@ <h4>Presentations Including Holder Claims</h4>
     },
     { <span class="comment">...</span> }
   }],
-  "proof": [{ <span class="comment">...</span> }]</span>
+  "proof": [{ <span class="comment">...</span> }]
 }
           </pre>
           <p>
@@ -2354,7 +2354,7 @@ <h4>Presentations Including Holder Claims</h4>
     },
     { <span class="comment">...</span> }
   }],
-  "proof": [{ <span class="comment">...</span> }]</span>
+  "proof": [{ <span class="comment">...</span> }]
 }
           </pre>
         </section>
@@ -2956,6 +2956,7 @@ <h2>Integrity of Related Resources</h2>
 Candidates for this mechanism include `digestSRI` and `digestMultibase`. There
 are arguments for and against unification that the WG is currently debating.
         </p>
+        <p>
 There MUST NOT be more than one object in the <code>relatedResource</code> per
 <code>id</code>.
         </p>
@@ -3029,9 +3030,7 @@ <h2>Integrity of Related Resources</h2>
   },
   ...
 }
-            </pre>
-          </aside>
-        </p>
+        </pre>
       </section>
 
       <section>
@@ -5204,7 +5203,7 @@ <h4>Man-in-the-Middle (MITM) Attack</h4>
 A <a>verifier</a> might need to ensure it is the intended recipient of a
 <a>verifiable presentation</a> and not the target of a
 <a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle attack</a>.
-Some <a href=#securing-verifiable-credentials>securing mechanisms</a>,
+Some <a href="#securing-verifiable-credentials">securing mechanisms</a>,
 like [[VC-JOSE-COSE]] or [[VC-DATA-INTEGRITY]], provide an option to specify
 the intended audience or domain of a <a>presentation</a>, which can help reduce
 this risk.
@@ -5322,7 +5321,7 @@ <h3>Device Theft and Impersonation</h3>
 for their actions or transactions, thereby reinforcing accountability and deterring
 malicious behaviors. The attainment of non-repudiation is a multifaceted endeavor,
 encompassing an array of techniques ranging from
-<a href=#securing-verifiable-credentials>securing mechanisms</a>, proofs of possession,
+<a href="#securing-verifiable-credentials">securing mechanisms</a>, proofs of possession,
 and authentication schemes in a variety of protocols designed to foster trust and reliability.
         </p>
       </section>
diff --git a/privacy.html b/privacy.html
index e50a04933..b04831969 100644
--- a/privacy.html
+++ b/privacy.html
@@ -153,7 +153,7 @@ <h2>Does this specification introduce new state for an origin that persists acro
       <section>
         <h2>Does this specification expose persistent, cross-origin state to the web?</h2>
         <p>
-Yes. Verifiable Claims contain a random though potentially persistent identifier of the subject. This is passed between the issuer and the inspector. Consequently collusion between them could identify the subject to the inspector, even though the Verifiable Claim itself does not. This is because in many cases the issuer will know the complete identity of the subject, even if the Verifiable Claim only contains a small proportion of it (such as age).
+Yes. Verifiable Claims contain a random though potentially persistent identifier (PId) of the subject. This is passed between the issuer and the inspector. Consequently collusion between them could identify the subject to the inspector, even though the Verifiable Claim itself does not. This is because in many cases the issuer will know the complete identity of the subject, even if the Verifiable Claim only contains a small proportion of it (such as age).
         </p>
         <p>
 Recommendation: The subject should limit the distribution of Verifiable Claims containing the same PId to a minimal number of origins. The subject should obtain Verifiable Claims with different PId to send to different origins wherever possible.
@@ -260,7 +260,7 @@ <h2>How should this specification work in the context of a user agent’s "incog
       <section>
         <h2>Does this specification persist data to a user’s local device?</h2>
         <p>
-The overall life cycle of Verifiable Claims envisages that they are stored persistently on the user’s local device or on a remote device under the user’s control. However, Verifiable Claims on their own, if captured by a hostile entity, should not be of any value to it, except in so far as the Verifiable Claim may potentially reveal a small amount of Personally Identifiable Information (PII). about the subject.
+The overall life cycle of Verifiable Claims envisages that they are stored persistently on the user’s local device or on a remote device under the user’s control. However, Verifiable Claims on their own, if captured by a hostile entity, should not be of any value to it, except in so far as the Verifiable Claim may potentially reveal a small amount of Personally Identifiable Information (PII) about the subject.
         </p>
         <p>
 Recommendation: Verifiable Claims should be encrypted during storage to prevent them being stolen by an attacker