Fix more grammar and flow in Section 8.

Author: decentralgabe

index.html

@@ -5095,8 +5095,7 @@ <h3>Signature-Based Correlation</h3>
           </li>
           <li>
 cryptographic material associated with the digital signature, such as
-a public key identifier
-digital signature.
+a public key identifier.
           </li>
         </ul>
 
@@ -5518,8 +5517,8 @@ <h3>Aggregation of Credentials</h3>
         </p>
 
         <p>
-The solution to the privacy implications of correlation or aggregation tends not
-to be technological in nature, but policy-driven instead. Therefore, if a
+The solution to the privacy implications of correlation or aggregation tends
+not to be technological in nature, but policy-driven instead. Therefore, if a
 [=holder=] wishes to avoid the aggregation of their information, they must
 express this in the [=verifiable presentations=] they transmit, and
 by the [=holders=] and [=verifiers=] to whom they transmit their
@@ -5599,8 +5598,8 @@ <h3>Patterns of Use</h3>
 and instead use, for example, a privacy-preserving revocation list.
           </li>
           <li>
-[=Issuers=] avoiding the association of personally identifiable information with
-any specific long-lived [=subject=] identifier.
+[=Issuers=] avoiding the association of personally identifiable information
+with any specific long-lived [=subject=] identifier.
           </li>
         </ul>
 
@@ -5718,9 +5717,9 @@ <h3>Data Theft</h3>
 extracted from hardware or other devices. It is further suggested that
 [=holders=] store and manipulate their data only on devices they
 control, away from centralized systems, to reduce the likelihood of
-an attack on their data or inclusion in a large-scale theft if an attack is successful.
-Furthermore, [=holders=] are encouraged to rigorously control access to
-their credentials and presentations, allowing access only to those
+an attack on their data or inclusion in a large-scale theft if an attack is
+successful. Furthermore, [=holders=] are encouraged to rigorously control
+access to their credentials and presentations, allowing access only to those
 with explicit authorization.
         </p>
         <p>
@@ -5853,10 +5852,10 @@ <h3>Issuer Cooperation Impacts on Privacy</h3>
 information that might have been leaked by the [=issuer=], such as the
 [=subject's=] home address. To mitigate such leakage, [=issuers=] might
 use common identifiers to mask specific location information or other sensitive
-metadata; for example, a shared [=issuer=] identifier at a state or national level
-instead of at the level of a county, city, town, or other smaller municipality.
-Further, [=verifiers=] can use [=holder=] attestation mechanisms to
-preserve privacy, by providing proof that an [=issuer=] exists in a set of
+metadata; for example, a shared [=issuer=] identifier at a state or national
+level instead of at the level of a county, city, town, or other smaller
+municipality. Further, [=verifiers=] can use [=holder=] attestation mechanisms
+to preserve privacy, by providing proof that an [=issuer=] exists in a set of
 trusted entities without needing to disclose the exact [=issuer=].
         </p>
       </section>
@@ -5912,8 +5911,8 @@ <h3>Key Management</h3>
 referred to [[NIST-SP-800-57-Part-1]] for more extensive recommendations and
 discussion. 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 as well
-as signing.
+purposes, for example, a private signing key is not to be used for encryption
+as well as signing.
         </p>
         <p>
 [[NIST-SP-800-57-Part-1]] strongly advises that private signing keys and
@@ -5958,9 +5957,9 @@ <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 protection
-mechanism provided by this specification if a security issue could occur
-if the external resource is changed.
+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>
 
       </section>
@@ -6119,9 +6118,9 @@ <h3>Device Theft and Impersonation</h3>
         </ul>
 
         <p>
-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
+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
 implementation of non-repudiation mechanisms. These mechanisms solidify an
 [=entity's=] responsibility for their actions or transactions, thereby
@@ -6151,9 +6150,9 @@ <h4>Unauthorized Use</h4>
 violation</i>. Consider an example where a [=holder=] shares a [=verifiable
 presentation=] with a [=verifier=] to establish their age and residency
 status. If the [=verifier=] then proceeds to exploit the [=holder's=] data
-without proper consent, such as by selling the data to a data broker, that would
-constitute an unauthorized use of the data, violating an expectation of privacy
-that the [=holder=] might have in the transaction.
+without proper consent, such as by selling the data to a data broker, that
+would constitute an unauthorized use of the data, violating an expectation of
+privacy that the [=holder=] might have in the transaction.
         </p>
         <p>
 Similarly, an [=issuer=] could make use of a
@@ -6217,9 +6216,9 @@ <h3>Code Injection</h3>
 processing language and base direction information.
           </li>
           <li>
-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.
+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>
         </ul>
 
@@ -6561,10 +6560,10 @@ <h4>Holder</h4>
 [=verifier=]. For example, a [=holder=] can publish information containing
 the [=verification material=] used to secure [=verifiable presentations=]. This
 metadata is used when checking proofs on [=verifiable presentations=].
-Some cryptographic identifiers contain all necessary metadata in the identifier itself.
-In those cases, no additional metadata is required. Other identifiers use verifiable data
-registries where such metadata is automatically published for use by
-[=verifiers=], without any additional action by the [=holder=].
+Some cryptographic identifiers contain all necessary metadata in the identifier
+itself. In those cases, no additional metadata is required. Other identifiers
+use verifiable data registries where such metadata is automatically published
+for use by [=verifiers=], without any additional action by the [=holder=].
         </p>
         <p>
 See the <a data-cite="VC-IMP-GUIDE/#subject-holder-relationships"></a> and
@@ -6738,11 +6737,11 @@ <h3>Fitness for Purpose</h3>
         <h3>"Artificial Intelligence" and "Machine Learning"</h3>
 
         <p>
-Systems using what is today commonly referred to as "artificial intelligence" and/or "machine learning" might be capable of performing
-complex tasks at a level that meets or exceeds human performance.
-This might include tasks such as the acquisition and use of
-[=verifiable credentials=].
-Using such tasks to distinguish between human and automated "bot" activity, as is
+Systems using what is today commonly referred to as "artificial intelligence"
+and/or "machine learning" might be capable of performing complex tasks at a
+level that meets or exceeds human performance. This might include tasks such as
+the acquisition and use of [=verifiable credentials=]. Using such tasks to
+distinguish between human and automated "bot" activity, as is
 commonly done today with a <a href="https://en.wikipedia.org/wiki/CAPTCHA">CAPTCHA</a>,
 for instance, might thereby cease to provide adequate or acceptable protection.
         </p>
@@ -6751,12 +6750,13 @@ <h3>"Artificial Intelligence" and "Machine Learning"</h3>
 Implementers of security architectures that use [=verifiable credentials=]
 and/or perform validation on their content are urged to consider the existence
 of machine-based actors, such as those which are today commonly referred to as
-"artificial intelligence", that might legitimately hold [=verifiable credentials=]
-for use in interactions with other systems. Implementers might also consider how
-threat actors could couple such "artificial intelligence" systems with [=verifiable
-credentials=] to pose as humans when interacting with their systems. Such systems
-might include, but not be limited to, global infrastructure such as social media,
-election, energy distribution, supply chain, and autonomous vehicle systems.
+"artificial intelligence", that might legitimately hold [=verifiable
+credentials=] for use in interactions with other systems. Implementers might
+also consider how threat actors could couple such "artificial intelligence"
+systems with [=verifiable credentials=] to pose as humans when interacting with
+their systems. Such systems might include, but not be limited to, global
+infrastructure such as social media, election, energy distribution, supply
+chain, and autonomous vehicle systems.
         </p>
 
       </section>
@@ -7128,13 +7128,13 @@ <h3>Differences between Contexts, Types, and CredentialSchemas</h3>
         </p>
 
         <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, `"@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 not to be used.
+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, 
+`"@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
+not to be used.
           </p>
 
         <p>
@@ -7150,8 +7150,8 @@ <h3>Differences between Contexts, Types, and CredentialSchemas</h3>
       <h2>IANA Considerations</h2>
 
       <p>
-This section will be submitted to the Internet Engineering Steering Group (IESG)
-for review, approval, and registration with IANA.
+This section will be submitted to the Internet Engineering Steering Group
+(IESG) for review, approval, and registration with IANA.
       </p>
 
       <section id="vc-ld-media-type">
@@ -7178,8 +7178,8 @@ <h2>application/vc</h2>
             <td>
 Resources that use the `application/vc` media type are required to conform to
 all of the requirements for the `application/ld+json` media type and are
-therefore subject to the same encoding considerations specified in Section 11 of
-[[[RFC7159]]].
+therefore subject to the same encoding considerations specified in Section 11
+of [[[RFC7159]]].
             </td>
           </tr>
           <tr>
@@ -7209,9 +7209,9 @@ <h2>application/vc</h2>
         <p>
 The credential is expected to be a valid
 <a data-cite="JSON-LD11#dfn-json-ld-document">JSON-LD document</a>.
-[=Verifiable credentials=] served with the `application/vc` media type are expected
-to have all [[[JSON-LD11]]] context information, including references to
-external contexts, within the body of the document. Contexts linked via a
+[=Verifiable credentials=] served with the `application/vc` media type are
+expected to have all [[[JSON-LD11]]] context information, including references
+to external contexts, within the body of the document. Contexts linked via a
 `http://www.w3.org/ns/json-ld#context` HTTP Link Header
 (see <a data-cite="JSON-LD11#interpreting-json-as-json-ld">Section 6.1</a>
 of [[[JSON-LD11]]]) are ignored.
@@ -7242,8 +7242,8 @@ <h2>application/vp</h2>
             <td>
 Resources that use the `application/vp` media type are required to conform to
 all of the requirements for the `application/ld+json` media type and are
-therefore subject to the same encoding considerations specified in Section 11 of
-[[[RFC7159]]].
+therefore subject to the same encoding considerations specified in Section 11
+of [[[RFC7159]]].
             </td>
           </tr>
           <tr>
@@ -7325,19 +7325,21 @@ <h2>Additional Diagrams for Verifiable Presentations</h2>
 parenthetical remark '(a named graph)'
             ">
       <figcaption style="text-align: center;">
-        A variant of [[[#info-graph-vp]]]: information [=graphs=] associated with a [=verifiable presentation=]
-        referring to two
-        verifiable credentials, using an [=embedded proof=] based on [[[VC-DATA-INTEGRITY]]] [[?VC-DATA-INTEGRITY]].
+        A variant of [[[#info-graph-vp]]]: information [=graphs=] associated
+        with a [=verifiable presentation=] referring to two verifiable
+        credentials, using an [=embedded proof=] based on
+        [[[VC-DATA-INTEGRITY]]] [[?VC-DATA-INTEGRITY]].
       </figcaption>
       </figure>
 
       <p>
-        [[[#info-graph-vp-jwt-mult-creds]]] below shows the same [=verifiable presentation=]
-        as [[[#info-graph-vp-mult-creds]]], but using an [=enveloping proof=] based on [[?VC-JOSE-COSE]].
+        [[[#info-graph-vp-jwt-mult-creds]]] below shows the same
+        [=verifiable presentation=] as [[[#info-graph-vp-mult-creds]]], but
+        using an [=enveloping proof=] based on [[?VC-JOSE-COSE]].
         Each [=verifiable credential graph=] contains a single
-        <a href="#defn-EnvelopedVerifiableCredential">`EnvelopedVerifiableCredential`</a> instance,
-        referring, via a `data:` URL [[RFC2397]], to a verifiable credential secured via
-        an [=enveloping proof=].
+        <a href="#defn-EnvelopedVerifiableCredential">`EnvelopedVerifiableCredential`</a>
+        instance, referring, via a `data:` URL [[RFC2397]], to a verifiable
+        credential secured via an [=enveloping proof=].
       </p>
 
       <figure id="info-graph-vp-jwt-mult-creds">
@@ -7369,8 +7371,10 @@ <h2>Additional Diagrams for Verifiable Presentations</h2>
 'cYjaSdfIoJH45NIqw3MYnasGIba...'.
         ">
         <figcaption style="text-align: center;">
-          A variant of [[[#info-graph-vp-jwt]]]: information [=graphs=] associated with a [=verifiable presentation=]
-          referring to two verifiable credentials using [=enveloping proofs=] based on JOSE [[?VC-JOSE-COSE]].
+          A variant of [[[#info-graph-vp-jwt]]]: information [=graphs=]
+          associated with a [=verifiable presentation=] referring to two
+          verifiable credentials using [=enveloping proofs=] based on JOSE
+          [[?VC-JOSE-COSE]].
         </figcaption>
       </figure>