Making explicit the binding of the holder to a VC #795
Conversation
* Add PR review process for 2021. * Avoid GitHub id auto-linking. Co-authored-by: David I. Lehn <[email protected]> * Update README.md Co-authored-by: Manu Sporny <[email protected]> Co-authored-by: Manu Sporny <[email protected]> Co-authored-by: David I. Lehn <[email protected]> Co-authored-by: Brent Zundel <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
There was a problem hiding this comment.
I did a quick-scan of this PR and, overall, I'm fine with most of the text. The only exception is the new "Holder" section, which asserts things about the mental model of holders that I don't think we have consensus in the WG on (and thus, it'll need to be discussed).
| 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 |
There was a problem hiding this comment.
| <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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@msporny -- that is not what I meant. I would expect that information to be put in by the issuer into the VC.
There was a problem hiding this comment.
@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".
There was a problem hiding this comment.
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
| 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>. |
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
Removed. I see that the property is only referenced in the (IMHO) very confusing Appendix C, and is probably not the way to go.
There was a problem hiding this comment.
Alternatively, when the holder is the subject, the credentialSubject.id property could be used for the same purpose, ideally paired with the nonTransferable property.
- when the holder is the subject - how is the prescriptive test for this (in software)? Which properties are being compared?
- 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?
| 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>, |
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
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.
| 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>. |
There was a problem hiding this comment.
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.
| @@ -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 | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
| 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.
There was a problem hiding this comment.
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>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 |
There was a problem hiding this comment.
As above.
| <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 |
| @@ -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>. | |||
There was a problem hiding this comment.
Binding again. Also appears to presume that association with Holder is default for VCs.
| <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>. |
| 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>. |
There was a problem hiding this comment.
Presumes Holder-sameAs-Subject facts not in evidence. Also binding, again.
| 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>. |
| @@ -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 | |||
There was a problem hiding this comment.
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.
| <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 |
| <h3>Credential Subject</h3> | ||
| <h3>Holder</h3> |
There was a problem hiding this comment.
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?
|
First, a caveat, I haven't been following this thread in detail but @David-Chadwick and I had a discussion this "morning" that might be relevant/useful. It was regarding how the different In a generic purchase order scenario (I haven't coded one up yet), credential id is used as the identifier for the VC envelope that wraps the credentialSubject. The credentialSubject id represents the subject of the claims that are also contained in the credentialSubject. The identifier of the subject stored in credentialSubject id is used to encode the purchase order id identifier. The credentialSubject is also where the purchase order data is stored (e.g. purchase order id identifier plus the purchase order form data represented as claims). Each VC envelope has a unique credential id. Each credentialSubject has a unique credentialSubject id (this latter value generated by the accounting system of record). In a specific purchase order scenario, credential id might have a value of What about the Holder id part of the discussion? First, the Holder id is not the same as the VC envelope id (aka credential id) nor the purchase order credentialSubject id (aka purchase order id identifier). In the purchase order scenario, Holder id isn't needed (at least not for now in this scenario). The originator of the purchase order (the purchaser) will be encoded in the purchase order claims data as is normal business practice ...as will the supplier, shipper, etc. etc. If a Holder id is required for other use case, it can be encoded before or after the Although the following isn't a purchase order example, I'm including it because IMO it suggests some useful names for the anatomy of a VC.
p.s. What does a full-blown digital purchase order look like? Check out http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/UBL-Invoice-2.1-Example.xml |
|
From a privacy engineering perspective, introducing Holder as a normative
element is a problem no matter how it's done because it gives the Issuer
power that they do not currently have with legacy credentials, some of
which use biometrics to bind the subject to the verifiable integrity
mechanism of the credential itself.
There will be use-cases where the Subject is not the Holder. A VC that
represents a capability would be one example and this was discussed some
months ago. I believe the consensus that emerged is that there's no good
reason to code capabilities as standard VCs, but I could be wrong.
A real-world example of a capability is the Release of Information (ROI)
form that, for example, gives the Social Security Disability Office (SSDO)
the right to request a health record directly from a hospital. The
patient/subject is asked to configure (hospital name, authorized delegate
name, records date range, HIV exclusion, etc...) and sign the ROI and
return it to the SSDO as the authorized delegate. A similar sequence is
used to delegate a car dealer's bank to access a credit report on the
purchaser.
In these fairly common use-cases, there is no obvious holder. The health
record or credit report VC is issued, by design, directly to the Verifier.
The delegate name on the ROI form is the Verifier.
My point goes back to Manu's statement:
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.
We know it's possible to bind a Subject to a VC by adding a biometric
attribute or a link to a biometric attribute to the VC. What are the
use-cases where the Issuer needs to "bind" a holder to a VC?
- Adrian
…On Sat, Aug 21, 2021 at 9:41 AM Manu Sporny ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In index.html
<#795 (comment)>:
> @@ -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
@msporny <https://github.com/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
<https://github.com/David-Chadwick> is putting forward around "Terms of
Use" or "Evidence".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#795 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YJQV3M24CWKFGEPACDT56UIFANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
Yes, sorry, what I meant was "I do also think that we need to make sure that no one believes that it's possible to CRYPTOGRAPHICALLY "bind" a holder to a VC AND THEN ONLY DEPEND ON THAT CRYPTOGRAPHIC BINDING". What you get in that case is something that's completely untraceable and open to wide-scale abuse (almost perfect anonymity, which is ok for some low-risk use cases like movie tickets and single use bus passes -- things greatly constrained by time and space). |
|
What about
https://github.com/HIEofOne/Trustee-Community/blob/master/Biometric-Health-Card.pdf
?
…On Sat, Aug 21, 2021 at 3:56 PM Manu Sporny ***@***.***> wrote:
We know it's possible to bind a Subject to a VC by adding a biometric
attribute or a link to a biometric attribute to the VC.
Yes, sorry, what I meant was "I do also think that we need to make sure
that no one believes that it's possible to *CRYPTOGRAPHICALLY* "bind" a
holder to a *VC AND THEN ONLY DEPEND ON THAT CRYPTOGRAPHIC BINDING*".
What you get in that case is something that's completely untraceable and
open to wide-scale abuse (almost perfect anonymity, which is ok for some
low-risk use cases like movie tickets and single use bus passes -- things
greatly constrained by time and space).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#795 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YKU2UFMU7JBJFJMB2LT6AAGLANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
On 21/08/2021 19:43, Adrian Gropper
wrote:
What
are the
use-cases where the Issuer needs to "bind" a holder to a VC?
These can only be use cases in which the holder NE subject
(because when holder==subject, binding to subject is sufficient to
simultaneously bind to holder).
There are many use cases where the issuer gives the VC to a
holder NE subject, and the verifier needs to know that the
presenter is the original authorised holder, and not someone who
copied the VC from the genuine holder and is passing this off as
belonging to them. Examples include: holder is acting as power of
attorney (proxy) for the subject, holder is the authorised
representative of an inanimate object (such as an organisation).
In other words, where the subject is not able to act on its own
behalf and cannot perform the delegation/authorisation itself.
kind regards
David
|
@David-Chadwick I think most of the business document use cases we've been discussing also fall into this camp (e.g. a Purchase Order). |
|
@mwherman2000 Yes if a purchase order is an inanimate object, given to a buyer by the company (issuer) to hold until next month say, the supplier does not want a fraudsters to present the PO now, causing it to produce the goods, when the buyer did not intend the goods to be bought until next month. One can envisage many other examples like this, where wrongly presented business documents could cause financial damage to either the issuer or the verifier. |
|
Agreed but to some extent this depends on the completeness and immutability of the purchase order object represented inside the credentialSubject. Delivery terms, conditions, dates, payment terms, conditions, parties, etc. can and should be specified in the purchase order object (they are). Nothing can be added or changed to a signed, verifiable purchase order.
...or am I missing something? |
My opinion on this example, is that what is described ("issued...to the Verifier") is not a verifiable credential use case. Unless the recipient (the SSDO) needs to prove the data to another party (an actual verifier), then that is not a vc -- it's just releasing data to the SSDO. If they use a VC data format, that's (perhaps) convenience, but does not make it a (lower case) vc. If the SSDO does need to prove the data in the future, then it is a vc, and the holder is the SSDO, and the verifier should know that. |
|
@msporny -- |
In this scenario, let's say the delayed purchase order had the value of (Just in case it helps further the discussion the outer VC envelope would have a |
Yes, it does.
The only thing the caps were meant to imply was clarifying the loose language I used the first time around. The caps were added to try and add some clarity to what I was saying to my initial statement (not to imply something written in stone). |
|
Thanks. I'm definitely not an expert in this, but my understanding is that the claim (in your comment) that such a cryptographic binding is impossible is not considered fact, and opinions differ. Since it would be extremely helpful if a practical mechanism was found that sufficiently mitigates the risk of using such a cryptographic binding, I don't want anyone to turn away from trying to accomplish that because some think it can't be practical. |
|
@mwherman2000 "Are you suggesting that someone could create a fake PO ". No I never said or implied that. I simply said that anyone having possession of the genuine PO can present it, even if that person was not the holder that the issuer gave it to. |
|
RE: I simply said that anyone having possession of the genuine PO can present it Yes, there's good solutions for that too ...like only accepting business documents over trusted, verifiable channels established between a particular Purchaser (ABC Grocery) and a particular Supplier (David's Cabbages) (e.g. using DIDComm-like or HTTPS communications channels). Worst case, it would be detected as a duplicate PO. |
|
There's other VC transmission strategies too. For example, instead of the Originator's Agent (Originating Holder's Agent) sending (shooting) over the actual PO VC to the Receiver's Agent (Receiving Holder's Agent), the Originator('s Agent) sends the Receiver('s Agent) a Notification VC containing the DID of the Originator and the DID of the particular PO envelope. The Receiver then looks up the URI of the Originator (and its Agent's Service Endpoint) on a VDR and uses that trusted URI to call back to the Originator to download the PO envelope containing the PO content (PO number and the claims describing the claims that comprise the PO). The latter may be a recursive process if the PO is represented as a hierarchy or graph of related PO component VCs. ...or something like that. Of course, there's all sorts of cross verifications made a long the way. |
|
The Power of Attorney document lists the identity of the delegate as a
claim and signs it (often with a witness). The identity of the holder is
completely irrelevant.
An auto registration is an example of your inanimate “thing”. The subject
is the thing. The responsible parties include the owner of the thing (for
transfer of title purposes), the person who registered the thing (to get
the parking tickets), and the insurance company (in case anyone wants to
validate insurance). These are three separate identities as claims and I
don’t see a holder in this case either.
My point remains that identifying a holder is a privacy engineering problem
because it limits the choices of the subject or whoever lease has the VC.
The “double spend” or VC copy issue (a theater ticket) is not mitigated by
identifying a holder or a subject.
What am I missing?
On Sun, Aug 22, 2021 at 5:57 AM David Chadwick ***@***.***>
wrote:
…
On 21/08/2021 19:43, Adrian Gropper
wrote:
What
are the
use-cases where the Issuer needs to "bind" a holder to a VC?
These can only be use cases in which the holder NE subject
(because when holder==subject, binding to subject is sufficient to
simultaneously bind to holder).
There are many use cases where the issuer gives the VC to a
holder NE subject, and the verifier needs to know that the
presenter is the original authorised holder, and not someone who
copied the VC from the genuine holder and is passing this off as
belonging to them. Examples include: holder is acting as power of
attorney (proxy) for the subject, holder is the authorised
representative of an inanimate object (such as an organisation).
In other words, where the subject is not able to act on its own
behalf and cannot perform the delegation/authorisation itself.
kind regards
David
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#795 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YNKRX7Z7NYE6CWEYPTT6DCW3ANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
I beg to differ @agropper using your own POA example. Just like in your POA example, the value of (The value of |
The holder is who the issuer intended should have the credential, and we think that is important. Obviously, when the subject and holder are the same, it's easy. Where they are not, then the holder matters. If/when delegation is supported and standardized, the holder of the original VC becomes an issuer to a new holder of a new VC. I don't understand how delegation can be done by simply transferring a VC to another, with no indication of intent. Depending on how you model the POA VC, the holder would be extremely if they are one being given the POA for another, and that other is considered the subject. IMHO VCs are not suitable for solving general "double spend" problems. It works if there is only one verifier (e.g., the movie ticket), but does not work for something like a prescription, where the holder can take it to many independent pharmacies. |
|
@swcurran said:
“The holder is who the issuer intended should have the credential, and we
think that is important.”
So, an example would be a Letter of Recommendation (the subject should not
see the content of the VC) or a Credit Report (the issuer wants to be paid
each time the report is requested). How is the holder involved in these
cases?
Delegated authorization deals with the Letter of Recommendation and Credit
Report issuance effortlessly.
Please provide some real-world examples of holder different from subject or
delegate.
- Adrian
…On Mon, Aug 23, 2021 at 12:47 PM Stephen Curran ***@***.***> wrote:
@agropper <https://github.com/agropper>
... The identity of the holder is completely irrelevant. ...
The holder is who the issuer intended should have the credential, and we
think that is important. Obviously, when the subject and holder are the
same, it's easy. Where they are not, then the holder matters. If/when
delegation is supported and standardized, the holder of the original VC
becomes an issuer to a new holder of a new VC. I don't understand how
delegation can be done by simply transferring a VC to another, with no
indication of intent.
Depending on how you model the POA VC, the holder would be extremely if
they are one being given the POA for another, and that other is considered
the subject.
IMHO VCs are not suitable for solving general "double spend" problems. It
works if there is only one verifier (e.g., the movie ticket), but does not
work for something like a prescription, where the holder can take it to
many independent pharmacies.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#795 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YNQV6FAIXLDDDRAE6DT6J3RVANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
I know I'm being terrible simplistic but in this conversation, the "Holder" can/should/could be viewed as anyone who is holder of the VC (or a copy of the VC) at any point in its lifecycle from issuance to revocation.
|
|
@agropper "Please provide some real-world examples of holder different from subject or delegate." I already did. And so did you by adding different claims to a VC that specified the attorney or the owner or other claims identifying a third party who is not the subject. What you are effectively doing is saying 'these claims identify authorised entities' and then the verifier can determine from the VP if the holder is one of these authorised entities. But your solution is specific to the type of VC, and varies for each type, whereas what we are trying to do is define a generic method that is applicable to all types of VC where the holder NE subject. |
|
So, the holder becomes a special case of Terms of Use for a credential
where the ToU happens to be an identity?
…On Mon, Aug 23, 2021 at 3:03 PM David Chadwick ***@***.***> wrote:
@agropper <https://github.com/agropper> "Please provide some real-world
examples of holder different from subject or delegate." I already did. And
so did you by adding different claims to a VC that specified the attorney
or the owner or other claims identifying a third party who is not the
subject. What you are effectively doing is saying 'these claims identify
authorised entities' and then the verifier can determine from the VP if the
holder is one of these authorised entities. But your solution is specific
to the type of VC, and varies for each type, whereas what we are trying to
do is define a generic method that is applicable to all types of VC where
the holder NE subject.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#795 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YLKXXSIDYZNYSVFQNLT6KLQVANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
ToU is one possibility. So is having a Holder property. It is for the W3C group to decide |
|
Thanks for the clarification! Either way, the decision looks like an added
privilege of the Issuer and might raise privacy issues.
ToU seems much clearer to me than Holder. In general, for any given type of
credential, as a Subject, I would want any constraints added by the Issuer
to be very obvious.
Holder, on the other hand, is an identity attribute and, as such, dilutes
the minimum privilege benefits of a capabilities architecture. Also, Holder
as an added optional identity in the VC, is unusually confusing as our
years of debate has shown and continues to show.
…On Mon, Aug 23, 2021 at 3:43 PM David Chadwick ***@***.***> wrote:
ToU is one possibility. So is having a Holder property. It is for the W3C
group to decide
a) if a standardised generic method is needed for the issuer to signal who
it gave the VC to, and
b) if it is, what this mechanism should be.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#795 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABB4YKLDCWIX3QYRIDULEDT6KQGRANCNFSM5CKKN23A>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
brentzundel
added
defer-v2
and removed
PossibleErratum
|
The issue was discussed in a meeting on 2021-08-25
View the transcript4.1. Making explicit the binding of the holder to a VC (pr vc-data-model#795)See github pull request #795. Brent Zundel: this is not errata but is making normative changes Manu Sporny: I talked to Steven and he agrees that this PR should be removed and an issue raised to bring it into v2.0 Brent Zundel: I am adding the defer v2.0 label |
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Signed-off-by: Stephen Curran <[email protected]> Co-authored-by: Manu Sporny <[email protected]>
Signed-off-by: Stephen Curran <[email protected]> Co-authored-by: Ted Thibodeau Jr <[email protected]>
|
I opened #923. can we close this now? |
|
The issue was discussed in a meeting on 2022-09-07
View the transcript1.1. Making explicit the binding of the holder to a VC (pr vc-data-model#795)See github pull request vc-data-model#795. Manu Sporny: 795 is going to remain open until we discuss the holder stuff at TPAC. |
| </dl> | ||
| 3. W3C CCG is notified of PRs that will be merged in the next 14 days if there | ||
| are no objections. | ||
| 4. When it's determined a new reccomendation should go out, the W3C Verifiable |
There was a problem hiding this comment.
| 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 |
| <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 |
|
I'm closing this PR as the VCWG, led by @awoie, has taken up trying to address issues #789 and #882 in a more generalized way. The expectation is that once #882 results in a more thoroughly documented direction (a Rebooting the Web of Trust paper with examples is expected in the coming months), we'll try and generalize the solution such that it can be used in the VCDM. |
This PR is an attempt to address #789 , adding, where appropriate (at least in my opinion), explicit references to the binding of a the holder (who will often be the subject) of the VC such that in a verifiable presentation the verifier can authenticate that the holder was issued the verifiable credential.
I've tried to follow the use of links to glossary items, but no doubt under- or over-used those links in places. Likewise for where I have tagged JSON properties with the "code" tag. Any guidance on that would be appreciated.
My main concern about this PR comes from the @David-Chadwick comment that
credentialSubject.idmay have become the de facto way to authenticate the holder, rather than usingholder.id. Starting from scratch, I think it makes far more sense to useholder.id, but I wonder if it is too late. IMHO, I would much prefer that the VC Data Model had no opinion on the contents of the credential (it's just data) vs. explicitly saying there must be a subject and forcing all use cases to map (sometimes artificially) to the structure. However, I understand that is not appropriate to change in the V1.x context. IMHO the use ofcredentialSubject.idvs.holder.idis a by-product of that decision.Preview | Diff