Skip to content

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

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 6 commits into from
Closed

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
1f574ef
Add PR review process for 2021 (#774)
wyc Jul 13, 2021
da7b669
Addresses #789 -- further documenting the holder in VC data model
swcurran Aug 17, 2021
89cd047
Update index.html
swcurran Aug 26, 2021
2bf820f
Update index.html
swcurran Aug 26, 2021
5afbe49
Update index.html
swcurran Aug 26, 2021
6cc2160
Update index.html
swcurran Aug 26, 2021
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
30 changes: 30 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,3 +29,33 @@ mailing list as well.

### Other useful links
* [Public group email archive](https://lists.w3.org/Archives/Public/public-vc-wg/)

## Process Overview for VC Data Model Pull Requests
1. For now, we will focus only on merging new errata PRs into this repository,
but encourage activity related to new features.
2. Once a PR is opened, chairs and editors make judgement call on whether
changes are substantive or editorial.
<dl>
<dt>Editorial</dt>
<dd>Mark with "editorial" tag, merge into branch "v1.1"</dd>
<dt>Substantive</dt>
<dd>Mark with "substantial" tag. Bugfixes are merged into separate branch "v1.2". New Features stay around as an open PR.</dd>
</dl>
3. W3C CCG is notified of PRs that will be merged in the next 14 days if there
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how?

are no objections.
4. When it's determined a new reccomendation should go out, the W3C Verifiable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
4. When it's determined a new reccomendation should go out, the W3C Verifiable
4. When it's determined a new recommendation should go out, the W3C Verifiable

Credentials Working Group members meet, review all the PRs that have been
merged, and make a formal recommendation if agreement is reached.

### Roadmap for 2021
- 1 editorial update (v1.1?)
- 1 substantive update (v1.2?)
- VC Test Suite Refactoring
- Start planning VC v2 Work, request a rechartering 3-6 months before end of
year to keep VC WG functioning.

### Focus areas
- [v1] Fixing a specific bug
- [v1] Update examples in the spec to make them modern
- [v2] VC `@context` needs updating, possibly with security vocab modularized
into smaller components instead of all included into a large context file.
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to find some other language here that states that the issuer can assert what they saw vs. saying that the issuer can "bind a VC to a holder". At least one plain reading of that statement would render it false as the issuer has no such power. We'd need a clear definition of "bind" that avoided that issue.

What we know is that the issuer can create some kind of assertion about what they saw when issuing the VC -- and that a presentation may include a proof such that some kind of narrowing conclusions can be drawn from it. For example the issuer may have required the holder to prove they have access to some API and then the verifier can then require the presenter (who may not be the holder) to prove that they also have access to that API. Of course, that sort of language would highlight that the holder does not have to be the same as the presenter (they are not actually "bound") and, on its own, would make the feature seem powerless to the reader. This is the other side of the spectrum of what's written in this PR now: that the issuer or this "binding" has more power than it actually does.

Maybe we need to discuss how issuers can make assertions that can create additional constraints for the verifier to take advantage of via presentation requirements -- and that each of these constraints must be weighed carefully so as not to be over-estimated in what they accomplish?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We already have the ToU property for the issuer to place constraints on the issued VC. So instead of having a new holder property in the VC, that ranks pari-parsu with the credentialSubject we could place the holder property in a new ToU type.
Remembering of course that the verifier can always accept any VC regardless of who presents it, or what the ToUs may state, or what its validity period is, or what its revocation status is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So instead of having a new holder property in the VC, that ranks pari-parsu with the credentialSubject we could place the holder property in a new ToU type.

I would far prefer that we go down this route. Thank you for suggesting it @David-Chadwick.

I do also think that we need to make sure that no one believes that it's possible to "bind" a holder to a VC and believe that any sort of cryptographic binding solves the problem of "is the person I'm interacting w/ remotely/in person the same as the holder". That problem is not solved by cryptography.

<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 sometimes associated by the <a>issuer</a> with
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
Comment on lines +1043 to +1046
Copy link
Member

@TallTed TallTed Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
In this example, the <a>issuer</a> has associated 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

Aside from the continuing issue of inappropriate use of "binding", there is NOTHING in the existing doc (unless it snuck by me, which I hope it did not!) that says that the credentialSubject.id does double-duty as a holder.id, associating a VC with a specific Holder at issuance. We spent many hours discussing this, and Holder-sameAs-Subject was neither determined to be the most-common nor the default scenario. If anything, I remember us coming up with more Holder-NOT-sameAs-Subject scenarios.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the inappropriate-ness of using credentialSubject.id s a replacement for holder.id, but it has become a de facto standard approach for the verifier to confirm the holder is presenting the data in the subject-is-holder use case.

What I would really like to see is dropping entirely the concept of "subject" (replaced with, for example, credentialData) in the VC spec (v2.0), as its use pre-supposes a purpose for all data using the verifiable credential pattern -- data that is issued to a holder and subsequently presented by the holder to verifiers. That change would allow the VC spec emphasis to be on the holder (as shown in Figure 1), makes irrelevant any discussion of subject is/is not holder (the spec is agnostic on the topic), and leaves the entire meaning of the payload up to those using the VC spec. -- handled by data semantics and trust relationship governance.

<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
Comment on lines +1965 to +1966
Copy link
Member

@TallTed TallTed Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above.

Suggested change
<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
<a>presentation</a> is <a>verifiable</a>. Where the issuer has associated the
<a>verifiable credential</a> being presented with 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>.
Copy link
Member

@TallTed TallTed Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Binding again. Also appears to presume that association with Holder is default for VCs.

Suggested change
<a>verifiable credentials</a> that have not been bound by the <a>issuer</a> to that <a>holder</a>.
<a>verifiable credentials</a> that have not been associated by the <a>issuer</a> with 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>.
Comment on lines +2213 to +2217
Copy link
Member

@TallTed TallTed Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Presumes Holder-sameAs-Subject facts not in evidence. Also binding, again.

Suggested change
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>.
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> association
in the
<a>verifiable credential</a> with 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
Copy link
Member

@TallTed TallTed Aug 20, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You cannot replace subject with holder like this. It might work out if you added holder to subject, but only if you use associated or similar instead of bound; there may be other issues with new draft text.

Suggested change
<a>verifiable credential</a> or <a>holder</a> identifiers to the
<a>verifiable credential</a>, <a>subject</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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<code>credential.holder.id</code> field. The identifiers used to identify a
<code>presentation.holder.id</code> field. The identifiers used to identify a

Is this what you meant?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like this PR to add a credentialHolder property (between sections 4.4 and 4.5) with identical syntax to the credentialSubject property i.e. the credentialHolder can contain an optional id and optional holder properties. In this way the issuer can identify the holder by either an id (linked to cryptographic material) or via human readable properties (e.g. name, address, passport number) or both.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny -- that is not what I meant. I would expect that information to be put in by the issuer into the VC.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@msporny -- that is not what I meant. I would expect that information to be put in by the issuer into the VC.

Yes, understood now. When I made the suggestion, I misunderstood what you were going for... but since then, I think we're noting that doing this is problematic. I like the proposal @David-Chadwick is putting forward around "Terms of Use" or "Evidence".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During the year since I made my comment above that we should add a credentialHolder property, I now believe that it should be renamed to the issuee property. Rationale: The issuer cannot bind a VC to a holder, since the holder is a transient entity. The issuer can however bind the VC to the issuee, which is a persistent entity. Other than the change of name, the rest of my my comment is still good. (see issue #942

<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>credentialSubject.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-using 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>
Comment on lines -5029 to +5060
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not interchangeable in this way. Maybe an added Holder section will work. Replacing the Credential Subject section does not work for me at all.

...

Now I've read further along, and I see that you did add a Holder section. You just confused me by putting this new section ahead of the existing Credential Subject section, which order doesn't seem logical to me. What is this ordering based on?


<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>,
Comment on lines +5064 to +5065
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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>,
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>,

Hmm, I don't think we have agreement on this in the WG. Putting holder in a VC isn't contemplated at all in the spec at present. This would be a substantive change in the interpretation of the specification.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I find amazing and is the core of this change. Figure 1 has holder in it, so someone thought it might be important. It is included in the base context.

I've heard this from another person from the original working group, so despite it's inclusion in the context, I gather it is not intended to be used.

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>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
purpose, ideally paired with the <code>nonTransferable</code> <a>property</a>.
purpose, ideally paired with the <code>nonTransferable</code> <a>property</a>.

Oof, now we're pulling nonTransferable in... -1 to doing that until we have buy-in from the WG that we really do want to make nonTransferable a property on a VC. I don't think we have buy-in on that yet.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed. I see that the property is only referenced in the (IMHO) very confusing Appendix C, and is probably not the way to go.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, when the holder is the subject, the credentialSubject.id property could be used for the same purpose, ideally paired with the nonTransferable property.

  1. when the holder is the subject - how is the prescriptive test for this (in software)? Which properties are being compared?
  2. the credentialSubject.id property could be used for the same purpose - can be more direct in stating that the same purpose is ...just write out?

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 <a>holder</a>-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>.
Comment on lines +5074 to +5076
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implies that one must now always set both credential.holder and credential.credentialSubject.id in order to do holder authentication... which goes contrary to what we say elsewhere in the Validation section. This will need to be reconciled before we can merge.

</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