Skip to content

Commit

Permalink
updated verify claim and added validate claim. images still need update
Browse files Browse the repository at this point in the history
  • Loading branch information
@jandrieu
jandrieu committed Sep 14, 2023
1 parent 02d306b commit db6f526
Showing 1 changed file with 125 additions and 14 deletions.
139 changes: 125 additions & 14 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -513,29 +513,140 @@ <h3>Assert Claim</h3>
</dl>
</section>
<section>
<h3>Verify Claim</h3>
<h3>Verify Credential</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for a <a>verifier</a> to verify that the credential is an
authentic statement of an <a>issuer's</a> <a>claims</a> about the
<a>subject</a>. The verifying <a>entity</a> must have the capability to
connect the issuer’s identity to its credential identifier and the
<a>subject's</a> identity to their identifier as indicated in the credential.
The issuer’s verification information, such as its public key, must be
discoverable from the credential record and verifiably linked to the issuer.
It MUST be possible to do this in an automated fashion.
It MUST be possible for a <a>verifier</a> to verify that the
credential is an authentic statement of an <a>issuer's</a>
<a>claims</a> about the
<a>subject</a>. Verifiers must have the capability to
cryptographically prove that a credential has not been tampered
with since issuance (authenticity) and that the issuer continues
to assert the claims as true (currency).

To check authenticity, the issuer's verification methods, such as
a public key, must be discoverable from the credential itself. It
is expected that the issuer identifier either is
cryptographically verifiable itself or that it can be used to
reliably discover the cryptographic material necessary to confirm
that the content of a credential has not been changed since
issuance. It is understood that verification depends on the
verifier's acceptance of the robustness of the cryptographic
mechanisms used for testing authenticity and for discovering
verification methods. An untrusted verification method cannot be
relied upon for verification.

To check the currency of a credential, verifiers must be able to
inquire about the current status of a credential without
revealing to the issuer
<ol type="a">
<li>Who is requesting status</li>
<li>Which credential is being checked</li>
<li>The subject of the credential being checked</li>
</ol>
This status check allows issuers to revoke, suspend, or otherwise
moderate the status of the credential.

Similarly, if a discovery mechanism is used to retrieve
verification methods for a given issuer, verifiers must be able
to do so without revealing unnecessary information to the issuer.

In short, it must be possible to fully verify a credential
without leaking usage data to the issuer or anyone else. This
avoids the so-called "phone home" problem.
</dd>
<dt>Motivations</dt>
<dd>
In many environments (such as order processing) information such
as a payer's address, citizenship, or age need to be
automatically verified in order to complete the transaction.

It MUST be possible to verify in an automated fashion.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.2</uref>, <uref>C.1</uref>, <uref>E.2</uref>, <uref>R.1
</uref>,
<uref>F.5</uref>, <uref>H.2</uref>, <uref>C.6</uref>
</dd>
</dl>
</section>
<section>
<h3>Validate Claim</h3>
<dl class="dl-horizontal">
<dt>Requirement</dt>
<dd>
It MUST be possible for a <a>verifier</a> to validate that the a
given claim is appropriate for particular use. That is, given the
credential is authentic and current, the verifier must then
interpret the claims in the context of their own 'business rules'
about which parties are acceptable authorities and which
cryptographic mechanisms are acceptable for different situations.
<ol>
<li>Is the issuer someone we know?</li>
<li>Are the claims made by this issuer appropriate for that
particular issuer's authority?</li>
<li>Is the holder's presentation an appropriate use of the
credential?</li>
</ol>
The first and second question will be answered either because the
verifier already knows the public identifiers for the issuers it
recognizes for specific claims, or there is a discovery mechanism
whereby verifiers can find appropriate issuers given their
business requirements.

The business rules may allow the use of certain credentials for
specific situations even when they are expired. For example a
suspended professional license may be accepted by an employer as
evidence of past experience without treating it as a current
qualification for roles that require that license. For this
reason, currency (as part of verification) only deals with the
status of the credential as maintained by the Issuer. Timeliness
is the domain of validation.

It's important to note that the bounds of authority for a given
issuer are specific claim types made by them and relied upon by
others. While the DMV might be an acceptable authority for an
individual's driving privilege, it should probably not be treated
as authoritative for an individual's hair color or current
address, even though DMVs regularly include such claims in
today's driver's licenses.

Unlike verification, validation cannot be guaranteed to be
automatable. Some use cases require human review before accepting
a particular credential for a particular use. For example, a
digital proof of age system might need a trusted human agent to
visually compare the holder/presenter in real-space to a
reference photo securely referenced in the VC, before accepting a
credential as valid.
</dd>
<dt>Motivations</dt>
<dd>
In many environments (such as order processing) information such as a payer's
address, citizenship, or age need to be automatically verified in order to
complete the transaction.
Verifiers need to be able to apply their own policies and rules
to the information they rely on to run their business. (And we
mean business broadly to encompass all focused activity towards a
goal.)

As such, any given VC could be verified but unusable in a
particular situation. For example, a self-issued driver's license
would likely not be acceptable for a car rental by most car
rental agencies, even though the verification succeeds.

However, in some cases, such as at a go-cart racing facility, it
may be entirely appropriate to accept the name and image from a
self-issued license for the purpose of leaderboards,
announcements, and correspondence.

These business rules are entirely up to the verifier. Only after
satisfying these rules should a verifier rely upon a claim as an
accepted fact for specific use.
</dd>
<dt>Needs</dt>
<dd>
<uref>F.2</uref>, <uref>C.1</uref>, <uref>E.2</uref>, <uref>R.1</uref>,
<uref>F.5</uref>, <uref>H.2</uref>, <uref>C.6</uref>
<uref>F.2</uref>, <uref>C.1</uref>, <uref>E.2</uref>, <uref>R.1
</uref>,
<uref>F.5</uref>, <uref>H.2</uref>, <uref>C.6</uref>
</dd>
</dl>
</section>
Expand Down

0 comments on commit db6f526

Please sign in to comment.