Skip to content

Commit

Permalink
Fix more grammar and flow in Section 8.
Browse files Browse the repository at this point in the history
  • Loading branch information
@decentralgabe @msporny
decentralgabe authored and msporny committed Sep 15, 2024
1 parent d373941 commit b62b620
Showing 1 changed file with 72 additions and 68 deletions.
140 changes: 72 additions & 68 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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>

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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>

Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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>

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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>
Expand All @@ -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>
Expand Down Expand Up @@ -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>
Expand All @@ -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">
Expand All @@ -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>
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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">
Expand Down Expand Up @@ -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>

Expand Down

0 comments on commit b62b620

Please sign in to comment.