Skip to content

Rebase PR #1297 #1334

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Nov 4, 2023
Merged

Rebase PR #1297 #1334

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
ca7e866
Update validation/verification language.
jandrieu Sep 6, 2023
390c896
updated terms.html to use new validation langauge
jandrieu Oct 2, 2023
365ebdc
Apply grammar/fixes to validation.
jandrieu Oct 18, 2023
3b384e0
Update entity to include abstract nouns.
jandrieu Oct 31, 2023
1ec2c90
Apply suggestions from code review
jandrieu Sep 14, 2023
cfa8fb9
Update validation/verification language/grammar.
jandrieu Sep 14, 2023
e62a0d5
Update terms.html to use new validation langauge.
jandrieu Oct 2, 2023
0f3c005
Fix grammar around validation language.
jandrieu Oct 18, 2023
4711713
Fix broken reference to validation section.
jandrieu Oct 18, 2023
d82d1fd
Fix grammar in validation language.
jandrieu Oct 18, 2023
292d0a0
Applying Manu's suggestions, removing normative statements.
jandrieu Oct 24, 2023
3aabe34
Note that verifier policies might include one or more policies.
jandrieu Oct 24, 2023
ac99905
Replace RFC language with "might".
jandrieu Oct 31, 2023
aa91f4d
Update terms.html
jandrieu Oct 31, 2023
3f7d32b
Fix formatting in terms.html.
msporny Nov 4, 2023
85f2e30
Fix formatting from validation rewrite.
msporny Nov 4, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
126 changes: 89 additions & 37 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -305,10 +305,12 @@ <h3>What is a Verifiable Credential?</h3>
refers to the characteristic of a <a>credential</a> or <a>presentation</a>
as being able to be <a>verified</a> by a <a>verifier</a>,
as defined in this document. Verifiability of a credential does not imply
that the truth of <a>claims</a> encoded therein can be evaluated; however,
the issuer can include values in the <a>evidence</a> property to help the verifier
apply their business logic to determine whether the claims have sufficient
veracity for their needs.
that truth of <a>claims</a> encoded therein. Rather, once the authenticity and
currency of a <a>verifiable credential</a> or <a>verifiable presentation</a> are
established, a <a>verifier</a> validates the included claims using their own
business rules before relying on them. Such reliance only occurs after
evaluating the issuer, the proof, the subject, and the claims, against one or
more verifier policies.
</p>
</section>

Expand Down Expand Up @@ -912,6 +914,9 @@ <h3>Concrete Lifecycle Example</h3>
<a>Verification</a> of the <a>verifiable presentation</a> by the
<a>verifier</a>.
</li>
<li>
<a>Validation</a> by the <a>verifier</a> of relevant <a>claims</a> contained in the <a>verifiable presentation</a>.
</li>
</ol>

<p>
Expand Down Expand Up @@ -964,7 +969,22 @@ <h3>Concrete Lifecycle Example</h3>
<a>verifiable presentation</a>. The <a>verifiable presentation</a> is sent to
the <a>verifier</a> and <a>verified</a>.
</p>
<pre class="example nohighlight" title="A simple example of the contents of a verifiable presentation">
<p>
Once verified as authentic and current, the seller of the season ticket then
validates that the issuer of the <a>verifiable credential</a> is recognized for
the claim of alumni status&mdash;it is, as it is issued by Example
University&mdash;and that today's date lies within the validity period defined
by the values of the validFrom and validUntil properties. Since the holder is
expected to be the subject of the <a>verifiable credential</a>, the
<a>verifier</a> also confirms that the id for the alumni claim matches the id of
the creator of the <a>verifiable presentation.</a>
</p>
<p>
Having verified the credential and the presentation, and validated the
relevant claims, the ticket seller safely enables the alumni discount for Pat,
confident that Pat is legitimately entitled to it.
</p>
<pre class="example nohighlight" title="A simple example of a verifiable presentation">
{
"@context": [
"https://www.w3.org/ns/credentials/v2",
Expand Down Expand Up @@ -2370,7 +2390,7 @@ <h3>Data Schemas</h3>

<ul>
<li>
Data verification schemas, which are used to <a>verify</a> that the structure
Data verification schemas, which are used to establish that the structure
and contents of a <a>credential</a> or <a>verifiable credential</a> conform to a
published schema.
</li>
Expand Down Expand Up @@ -2460,12 +2480,12 @@ <h3>Data Schemas</h3>
In the example above, the <a>issuer</a> is specifying a
<code>credentialSchema</code>, which points to a [[?VC-JSON-SCHEMA]] file that
can be used by a <a>verifier</a> to determine if the
<a>verifiable credential</a> is well formed.
<a>verifiable credential</a> is well-formed.
</p>

<p class="note" >
For information about linkages to JSON Schema [[?VC-JSON-SCHEMA]] or other
optional <a>verification</a> mechanisms, see the Verifiable Credentials
For information about linkages to JSON Schema [[?VC-JSON-SCHEMA-2023]] or other
optional schema validation mechanisms, see the Verifiable Credentials
Implementation Guidelines [[VC-IMP-GUIDE]] document.
</p>

Expand Down Expand Up @@ -2505,7 +2525,7 @@ <h3>Data Schemas</h3>
In the example above, the <a>issuer</a> is specifying a
<code>credentialSchema</code> pointing to a means of transforming the input
data into a format which can then be used by a <a>verifier</a> to determine if
the proof provided with the <a>verifiable credential</a> is valid.
the proof provided with the <a>verifiable credential</a> is well-formed.
</p>


Expand Down Expand Up @@ -2540,6 +2560,9 @@ <h3>Lifecycle Details</h3>
verifiable data registry">
<figcaption style="text-align: center;">
The roles and information flows for this specification.
<p class="issue" title="Validation needs to be added to image.">
Validation needs to be added to image
</p>
</figcaption>
</figure>

Expand All @@ -2566,10 +2589,16 @@ <h3>Lifecycle Details</h3>
</li>
<li>
A <a>verifier</a> <a>verifies</a> the authenticity of the presented
<a>verifiable presentation</a> and <a>verifiable credentials</a>. This should
include checking the <a href="#status">credential status</a> for revocation
<a>verifiable presentation</a> and <a>verifiable credentials</a> and
checks any <a href="#status">credential status</a>
of the <a>verifiable credentials</a>.
</li>
<li>
After <a>verification</a>, a <a>verifier</a> validates the relevant claims in
presented <a>verifiable credentials</a>, using their own business logic to
evaluate which issuers are appropriate for which claims and which subjects are
appropriate for the requested use.
</li>
<li>
An <a>issuer</a> might <dfn class="lint-ignore" data-lt="revoke">revoke</dfn> a
<a>verifiable credential</a>.
Expand All @@ -2592,14 +2621,20 @@ <h3>Lifecycle Details</h3>

<ol>
<li>
An <a>issuer</a> <a href="#lifecycle-details">issues</a> to a <a>holder</a>.
An <a>issuer</a> <a href="#lifecycle-details">issues</a> a <a>verifiable credential</a> to a <a>holder</a>.
</li>
<li>
The <a>holder</a> <a href="#lifecycle-details">presents</a> to a <a>verifier</a>.
</li>
<li>
The <a>verifier</a> <a href="#lifecycle-details">verifies</a>.
</li>
<li>
The <a>verifier</a> <a href="#lifecycle-details">validates</a> claims.
</li>
<li>
The <a>verifier</a> applies valid claims</a>.
</li>
</ol>

<p>
Expand All @@ -2610,13 +2645,15 @@ <h3>Lifecycle Details</h3>
</p>

<p>
This specification also does not define an authorization framework nor the
decisions that a <a>verifier</a> might make after <a>verifying</a> a
<a>verifiable credential</a> or <a>verifiable presentation</a>,
taking into account the <a>holder</a>, the <a>issuers</a> of the
<a>verifiable credentials</a>, the contents of the
<a>verifiable credentials</a>, and its own policies.
</p>
This specification neither defines an authorization framework nor
does it restrict the business decisions that a <a>verifier</a> might make
after <a>verifying</a> a <a>verifiable credential</a> or <a>verifiable
presentation</a>. However, <a>verifiers</a>
apply their own business rules before treating any claims as valid,
taking into account the <a>holder</a>, the <a>issuers</a> of the
<a>verifiable credentials</a>, the claims of the
<a>verifiable credentials</a>, and its own policies.
</p>

<p>
In particular, Sections <a href="#terms-of-use"></a> and
Expand Down Expand Up @@ -4684,13 +4721,16 @@ <h3>Bearer Credentials</h3>
</section>

<section class="informative">
<h3>Validity Checks</h3>
<h3>Validation</h3>

<p>
When processing <a>verifiable credentials</a>, <a>verifiers</a> are expected to
perform many of the checks listed in Appendix <a href="#validation"></a> as
well as a variety of specific business process checks. Validity checks might
include checking:
When processing <a>verifiable credentials</a>, <a>verifiers</a>
evaluate any relevant <a>claims</a> before relying upon them. This
evaluation might be done in any manner desired, as long as it satisfies
the requirements of the <a>verifier</a> doing the validation.
Many verifiers will perform the checks listed in Appendix <a
href="#validation-0"></a> as well as a variety of specific business process
checks such as:
</p>

<ul>
Expand All @@ -4715,8 +4755,9 @@ <h3>Validity Checks</h3>
<p>
The process of performing these checks might result in information leakage that
leads to a privacy violation of the <a>holder</a>. For example, a simple
operation such as checking a revocation list can notify the <a>issuer</a> that a
specific business is likely interacting with the <a>holder</a>. This could
operation such as checking an improperly configured revocation list can
notify the <a>issuer</a> that a specific business is likely interacting
with the <a>holder</a>. This could
enable <a>issuers</a> to collude and correlate individuals without their
knowledge.
</p>
Expand Down Expand Up @@ -5403,15 +5444,20 @@ <h4>Unauthorized Use</h4>
</p>
<h4>Inappropriate Use</h4>
<p>
While valid cryptographic signatures and successful <a href="#validation">validity checks</a>
While valid cryptographic signatures and successful status checks
signify the reliability of credentials, they do not signify that all credentials
are interchangeable for all contexts. Toward the pursuit of appropriate use,
it is crucial to consider the source and authenticity of the information. For
instance, in scenarios where a certified medical diagnosis is required, a self-asserted
<a>credential</a> carrying the necessary data might not suffice because it lacks validity from an
authoritative medical source. To ensure the propriety of <a>credential</a> use,
stakeholders are urged to assess the <a>credential</a>s' relevance and authority within
the specific context of their intended application.
are interchangeable for all contexts. It is crucial for verifiers to
also validate any claims which might be relevant, considering the source and
nature of the claim as well as privilege or service for which the credential is
presented.
</p>
<p>
For instance, in scenarios where a certified medical diagnosis is required, a
self-asserted <a>credential</a> carrying the necessary data might not suffice
because it lacks validity from an authoritative medical source. To ensure the
propriety of <a>credential</a> use, stakeholders are urged to assess the
<a>credential</a>s' relevance and authority within the specific context of their
intended application.
</p>
</section>
</section>
Expand Down Expand Up @@ -5800,7 +5846,9 @@ <h3>Proofs (Signatures)</h3>
The digital signature provides a number of protections, other than tamper
resistance, which are not immediately obvious. For example, a Linked Data
Signature <code>created</code> <a>property</a> establishes a date and time
before which the <a>credential</a> should not be considered <a>verified</a>. The
before which the <a>credential</a> should not be considered <a>verified</a>,
separate from the validity period of the credential. This property describes the
validity of the proof, not of the credential.<br/> The
<code>verificationMethod</code> <a>property</a> specifies, for example, the
public key that can be used to verify the digital signature. Dereferencing a
public key URL reveals information about the controller of the key, which can
Expand All @@ -5819,7 +5867,11 @@ <h3>Validity Periods</h3>
The <code>validFrom</code> and <code>validUntil</code> properties are expected
to be within an expected range for the <a>verifier</a>. For example, a
<a>verifier</a> can check that the end of the validity period of a <a>verifiable
credential</a> is not in the past.
credential</a> is not in the past. Because some credentials can be useful for
secondary purposes even if their original validity period has expired, validity
period, as expressed using the <code>validFrom</code> and
<code>validUntil</code> properties, is always considered a component of
validation, which is performed <em>after</em> verification.
</p>
</section>

Expand Down
49 changes: 26 additions & 23 deletions terms.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,10 +53,11 @@
<dd>
Anything that can be referenced in statements as an abstract or concrete noun.
Entities include but are not limited to people, organizations, physical things,
documents, abstract concepts, numbers, and strings. Any entity might perform
roles in the ecosystem, if it is capable of doing so. Note that some entities
fundamentally cannot take actions; for example, the string "abc" cannot issue
credentials. </dd>
documents, abstract concepts, fictional characters, and arbitrary text. Any
entity might perform roles in the ecosystem, if it is capable of doing so. Note
that some entities fundamentally cannot take actions, e.g., the string "abc"
cannot issue credentials.
</dd>
<dt><dfn data-lt="graphs">graph</dfn></dt>
<dd>
A network of information composed of <a>subjects</a> and their relationship
Expand All @@ -65,11 +66,10 @@
<dt><dfn data-lt="holders|holder's|holders'">holder</dfn></dt>
<dd>
A role an <a>entity</a> might perform by possessing one or more
<a>verifiable credentials</a> and generating <a>verifiable presentations</a> from
them.
A holder is often, but not always, a <a>subject</a> of the <a>verifiable
credentials</a> they are holding. Holders store their <a>credentials</a> in
<a>credential repositories</a>.
<a>verifiable credentials</a> and generating <a>verifiable presentations</a>
from them. A holder is often, but not always, a <a>subject</a> of the
<a>verifiable credentials</a> they are holding. Holders store their
<a>credentials</a> in <a>credential repositories</a>.
</dd>
<dt><dfn class="lint-ignore"
data-lt="identities|identity's">identity</dfn></dt>
Expand Down Expand Up @@ -127,14 +127,18 @@
A program, such as a browser or other Web client, that mediates the
communication between <a>holders</a>, <a>issuers</a>, and <a>verifiers</a>.
</dd>
<dt><dfn data-lt="credential validation">validation</dfn></dt>
<dt><dfn data-lt="claim validation">validation</dfn></dt>
<dd>
The assurance that a <a>verifiable credential</a> or a
<a>verifiable presentation</a> meets the needs of a <a>verifier</a> and other
dependent stakeholders. This specification is constrained to <a>verifying</a>
<a>verifiable credentials</a> and <a>verifiable presentations</a> regardless of
their usage. Validating <a>verifiable credentials</a> or
<a>verifiable presentations</a> is outside the scope of this specification.
The assurance that a <a>claim</a> from a specific <a>issuer</a> satisfies the
business requirements of a <a>verifier<a> for a particular use. This
specification defines how verifiers verify <a>verifiable credentials</a> and
<a>verifiable presentations</a>.<br/>
It also specifies that <a>verifiers</a> validate claims in <a>verifiable
credentials</a> before relying on them. However, the means for such validation
vary widely and are outside the scope of this specification. It is expected
that <a>verifiers</a> will trust certain <a>issuers</a> for certain claims and
apply their own rules to determine which claims in which <a>credentials</a>
are suitable for use by their systems.
</dd>
<dt><dfn data-lt="verifiable credential|verifiable credentials|vc|vcs">verifiable credential</dfn></dt>
<dd>
Expand Down Expand Up @@ -162,13 +166,12 @@
</dd>
<dt><dfn data-lt="verify|verified|verifying|verifiable|verifiability">verification</dfn></dt>
<dd>
The evaluation of whether a <a>verifiable credential</a> or <a>verifiable presentation</a>
is an authentic and timely statement of the issuer or presenter, respectively.
This includes checking that: the credential (or presentation) conforms to the specification; the proof method is
satisfied; and, if present, the status check succeeds.
Verification of a credential does not imply evaluation of the truth
of <a>claims</a> encoded in the credential.</a>.

The evaluation of whether a <a>verifiable credential</a> or <a>verifiable
presentation</a> is an authentic and current statement of the issuer or
presenter, respectively. This includes checking that: the credential (or
presentation) conforms to the specification; the proof method is satisfied; and,
if present, the status check succeeds. Verification of a credential does not
imply evaluation of the truth of <a>claims</a> encoded in the credential.
</dd>
<dt><dfn data-lt="verifier|verifiers|verifier's|credential verifiers|credential verifier's">verifier</dfn></dt>
<dd>
Expand Down