Skip to content

Making explicit the binding of the holder to a VC #794

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

Closed
wants to merge 1 commit into from
Closed

Making explicit the binding of the holder to a VC #794

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
109 changes: 79 additions & 30 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -335,6 +335,9 @@ <h3>Ecosystem Overview</h3>
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. Example holders include students, employees, and customers.
Issuers can bind a <a>verifiable credential</a> to the holder to which it is issued,
and the holder can prove that binding using the <code>proof</code> property of a
<a>verifiable presentation</a>.
</dd>
<dt><a>issuer</a></dt>
<dd>
Expand Down Expand Up @@ -445,6 +448,10 @@ <h3>Use Cases and Requirements</h3>
<a>verifiable presentation</a>.
</li>
<li>
<a>Verifiable credentials</a> are often bound by the <a>issuer</a> to a specific
<a>holder</a> at issuance time.
</li>
<li>
<a>Issuers</a> can issue <a>verifiable credentials</a> about any <a>subject</a>.
</li>
<li>
Expand Down Expand Up @@ -1032,7 +1039,15 @@ <h3>Concrete Lifecycle Example</h3>
}
}
</pre>

<p>
In this example, the <a>issuer</a> has bound the <a>verifiable credential</a> to
the <a>holder</a> (Pat) using the
<code>credentialSubject.id</code> property (rather than using the
<code>holder.id</code> property). The second <code>proof</code> property in the
<a>verifiable presentation</a> (with <code>proofPurpose</code> of
<code>"authentication"</code>) is used by Pat to prove their relationship to the
<a>credentialSubject.id</a> and thus, that they are the intended <a>holder</a>.
</p>
<p class="note">
Implementers that are interested in understanding more about the
<code>proof</code> mechanism used above can learn more in
Expand Down Expand Up @@ -1946,9 +1961,13 @@ <h3>Presentations</h3>
</dd>
<dt><var>proof</var></dt>
<dd>
If present, the value of the <code>proof</code> <a>property</a> ensures that
the <a>presentation</a> is <a>verifiable</a>. For details related to the use of
this property, see Section <a href="#proofs-signatures"></a>.
If present, the value of the <code>proof</code> <a>property</a> ensures that the
<a>presentation</a> is <a>verifiable</a>. Where the issuer has bound the
<a>verifiable credential</a> being presented to a specific <a>holder</a>, the
<code>proof</code> <a>property</a>
contains <a>verifiable</a> data to prove the indicated <a>holder</a> is
presenting the proof. For details related to the use of this property, see
Section <a href="#proofs-signatures"></a>.
</dd>
</dl>

Expand Down Expand Up @@ -2070,6 +2089,10 @@ <h3>Lifecycle Details</h3>
any other actions involving a <a>credential</a>.
</li>
<li>
In some cases, a <a>holder</a> might transfer to another <a>holder</a> one or more of its
<a>verifiable credentials</a> that have not been bound by the <a>issuer</a> to that <a>holder</a>.
</li>
<li>
A <a>holder</a> might <dfn data-lt="transfers">transfer</dfn> one or more of
its <a>verifiable credentials</a> to another <a>holder</a>.
</li>
Expand Down Expand Up @@ -2187,6 +2210,13 @@ <h2>Trust Model</h2>
<a>entities</a>.
</li>
<li>
In many cases, the <a>verifier</a> trusts the <a>issuer</a> to issue each
<a>verifiable credential</a> to its intended <a>holder</a> (often the
<a>subject</a>) and, where appropriate, to provide a <a>verifiable</a> binding
in the
<a>verifiable credential</a> to that <a>holder</a>.
</li>
<li>
The <a>holder</a> and <a>verifier</a> trust the <a>issuer</a> to issue
true (that is, not false) <a>credentials</a> about the <a>subject</a>, and to
revoke them quickly when appropriate.
Expand Down Expand Up @@ -2931,7 +2961,7 @@ <h3>Zero-Knowledge Proofs</h3>
<li>
Combine multiple <a>verifiable credentials</a> from multiple <a>issuers</a> into
a single <a>verifiable presentation</a> without revealing
<a>verifiable credential</a> or <a>subject</a> identifiers to the
<a>verifiable credential</a> or <a>holder</a> identifiers to the
<a>verifier</a>. This makes it more difficult for the <a>verifier</a> to collude
with any of the issuers regarding the issued <a>verifiable credentials</a>.
</li>
Expand Down Expand Up @@ -3970,9 +4000,11 @@ <h3>Identifier-Based Correlation</h3>

<p>
<a>Subjects</a> of <a>verifiable credentials</a> are identified using the
<code>credential.credentialSubject.id</code> field. The identifiers used to
identify a <a>subject</a> create a greater risk of correlation when the
identifiers are long-lived or used across more than one web domain.
<code>credential.credentialSubject.id</code> field. <a>Holders</a> of
<a>verifiable credentials</a> are identified using the
<code>credential.holder.id</code> field. The identifiers used to identify a
<a>subject</a> and/or <a>holder</a> create a greater risk of correlation when
the identifiers are long-lived or used across more than one web domain.
</p>

<p>
Expand Down Expand Up @@ -4035,10 +4067,10 @@ <h3>Signature-Based Correlation</h3>
<h3>Long-Lived Identifier-Based Correlation</h3>

<p>
<a>Verifiable credentials</a> might contain long-lived identifiers that could
be used to correlate individuals. These types of identifiers include
<a>subject</a> identifiers, email addresses, government-issued identifiers,
organization-issued identifiers, addresses, healthcare vitals,
<a>Verifiable credentials</a> might contain long-lived identifiers that could be
used to correlate individuals. These types of identifiers include
<a>subject</a> and <a>holder</a> identifiers, email addresses, government-issued
identifiers, organization-issued identifiers, addresses, healthcare vitals,
<a>verifiable credential</a>-specific JSON-LD contexts, and many other sorts of
long-lived identifiers.
</p>
Expand Down Expand Up @@ -4181,9 +4213,8 @@ <h3>Bearer Credentials</h3>

<p>
<a>Verifiable credentials</a> that are <a>bearer credentials</a> are made
possible by not specifying the <a>subject</a> identifier, expressed using the
<code>id</code> <a>property</a>, which is nested in the
<code>credentialSubject</code> <a>property</a>. For example, the following
possible by not specifying either the <code>subjectCredential.id</code> or
<code>holder.id</code> identifiers. For example, the following
<a>verifiable credential</a> is a <a>bearer credential</a>:
</p>

Expand Down Expand Up @@ -4405,8 +4436,8 @@ <h3>Usage Patterns</h3>
<a>subject</a> across multiple <a>presentations</a> or <a>verifiers</a>. Even
when different <a>credentials</a> are presented, if the <a>subject</a>
identifier is the same, <a>verifiers</a> (and those with access to
<a>verifier</a> logs) could infer that the <a>holder</a> of the
<a>credential</a> is the same person.
<a>verifier</a> logs) could infer that the <a>subject</a> of the
<a>credential</a> is the same person. Likewise for <a>holder</a> identifiers.
</li>
<li>
The underlying information in a <a>credential</a> can be used to identify an
Expand Down Expand Up @@ -4435,8 +4466,8 @@ <h3>Usage Patterns</h3>

<ul>
<li>
Using a globally-unique identifier as the <a>subject</a> for any given
<a>credential</a> and never re-use that <a>credential</a>.
Using a globally-unique identifier as the <a>subject</a> and/or <a>holder</a>
for any given <a>credential</a> and never re-use that <a>credential</a>.
</li>
<li>
If the <a>credential</a> supports revocation, using a globally-distributed
Expand Down Expand Up @@ -5026,19 +5057,23 @@ <h2>Validation</h2>
</p>

<section class="informative">
<h3>Credential Subject</h3>
<h3>Holder</h3>

<p>
In the <a>verifiable credentials</a> presented by a <a>holder</a>, the value
associated with the <code>id</code> <a>property</a> for each
<code>credentialSubject</code> is expected to identify a <a>subject</a> to the
<a>verifier</a>. If the <a>holder</a> is also the <a>subject</a>, then
the <a>verifier</a> could authenticate the <a>holder</a> if they have
public key metadata related to the <a>holder</a>. The <a>verifier</a> could then
authenticate the <a>holder</a> using a signature generated by the <a>holder</a>
contained in the <a>verifiable presentation</a>. The <code>id</code>
<a>property</a> is optional. <a>Verifiers</a> could use other <a>properties</a>
in a <a>verifiable credential</a> to uniquely identify a <a>subject</a>.
An <a>issuer</a> may indicate that a <a>verifiable credential</a> has been
issued to a specific <a>holder</a> using the <code>holder</code>
<a>property</a>. Alternatively, when the <a>holder</a> is the <a>subject</a>,
the <code>credentialSubject.id</code> <a>property</a> could be used for the same
purpose, ideally paired with the <code>nonTransferable</code> <a>property</a>.
When such <a>verifiable credentials</a> are used to produce a <a>verifiable
presentation</a>, the
<a>verifier</a> may authenticate the <a>holder</a> (or holder <a>subject</a>)
using a holder-generated signature in the <code>proof</code> <a>property</a> of
the <a>verifiable presentation</a>.

Where there is no <a>issuer</a>-designated <a>holder</a> the <a>verifiable
credential</a> can be transferred to other <a>holders</a>, and no <a>holder</a>
authentication is necessary by the <a>verifier</a>.
</p>

<p class="note">
Expand All @@ -5049,6 +5084,20 @@ <h3>Credential Subject</h3>

</section>

<section class="informative">
<h3>Credential Subject</h3>

<p>
In the <a>verifiable credentials</a> presented by a <a>holder</a>, the value
associated with the <code>id</code> property for each
<code>credentialSubject</code> is expected to identify a <a>subject</a> to the
<a>verifier</a>. The <code>id</code> property is optional. <a>Verifiers</a>
could use other properties in a <a>verifiable credential</a> to uniquely
identify a subject.
</p>

</section>

<section class="informative">
<h3>Issuer</h3>

Expand Down