vc-data-model
vc-data-model copied to clipboard
w3c
Making explicit the binding of the holder to a VC
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.id may have become the de facto way to authenticate the holder, rather than using holder.id. Starting from scratch, I think it makes far more sense to use holder.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 of credentialSubject.id vs. holder.id is a by-product of that decision.
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 id fields can be used/applied in the context of a business document represented as a VC (e.g. a purchase order originating from an accounting system (the system of record) that gave this particular purchase order a purchase order number (e.g. id) of 2222).
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 did:vcenvelope:1111 and credentialSubject id might have a value of did:purchaseorder:2222. The credentialSubject id (aka purchase order id identifier) is unique and generated by the accounting system of record (as is typical). Each time a purchase order did:purchaseorder:2222 is sent to a Holder, it is "placed in a new envelope" that has a new did:vcenvelope identifier (e.g. did:vcenvelope:1111, did:vcenvelope:1121, did:vcenvelope:1211, ...).
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 @context for example (i.e. the top part of the VC) ...e.g. in the packing label.
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.
[Updated August 23, 2021]
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 https://github.com/w3c/vc-data-model/pull/795#discussion_r693356344:
@@ -3970,9 +4000,11 @@
Identifier-Based Correlation
<p>Subjects of verifiable credentials are identified using the -
credential.credentialSubject.idfield. The identifiers used to -identify a subject create a greater risk of correlation when the -identifiers are long-lived or used across more than one web domain. +credential.credentialSubject.idfield. Holders of +verifiable credentials are identified using the +credential.holder.idfield. 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 https://github.com/w3c/vc-data-model/pull/795#discussion_r693356344, 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 .
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).
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 https://github.com/w3c/vc-data-model/pull/795#issuecomment-903169024, 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
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.
@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.
- PO sample schema: http://docs.oasis-open.org/ubl/os-UBL-2.2/UBL-2.2.html#S-INVOICE-SCHEMA
- PO XML example: http://docs.oasis-open.org/ubl/os-UBL-2.2/xml/UBL-Invoice-2.1-Example.xml
- Invoice JSON examples: http://docs.oasis-open.org/ubl/UBL-2.1-JSON/v1.0/cnd02/UBL-2.1-JSON-v1.0-cnd02.html#S-EXAMPLE-UBL-JSON-DOCUMENTS
...or am I missing something?
A real-world example of a capability is the Release of Information (ROI) form that...
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 -- VC AND THEN ONLY DEPEND ON THAT CRYPTOGRAPHIC BINDING does that statement go back to Dave Longley's article, or is it more than that? The caps imply that written in stone vs. opinion and I would like to be clear on what you mean.
@David-Chadwick
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
In this scenario, let's say the delayed purchase order had the value of credential.credentialSubject.id set to did:abcgrocery:po:1234. Are you suggesting that someone could create a fake PO with the same credential.credentialSubject.id? It's possible but it won't be verifiable as originating from ABC Grocery.
(Just in case it helps further the discussion the outer VC envelope would have a credential.id of, say, did:abcgrocery:envelope:123-456-789.)
does that statement go back to Dave Longley's article, or is it more than that?
Yes, it does.
The caps imply that written in stone vs. opinion and I would like to be clear on what you mean.
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 https://github.com/w3c/vc-data-model/pull/795#issuecomment-903243099, 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 .
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.
I beg to differ @agropper using your own POA example.
Just like in your POA example, the value of credentialSubject id is the identifier for the auto registration document itself; then there is a claim in that document that will reference/deference to, for example, the vehicle's VIN number.
(The value of credential id is the identifier associated with the credential envelope that the auto registration document was delivered in.)
@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.
@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 https://github.com/w3c/vc-data-model/pull/795#issuecomment-903940622, 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 https://github.com/w3c/vc-data-model/pull/795#issuecomment-904032024, 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 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.
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 https://github.com/w3c/vc-data-model/pull/795#issuecomment-904068267, 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 .
The issue was discussed in a meeting on 2021-08-25
- no resolutions were taken
View the transcript
4.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
… so it should be put in 2.0
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
… Steven has said he will close the PR after he has added this issue for v2.0
Brent Zundel: I am adding the defer v2.0 label
… now I would like to focus on v1.1 PRs
Based on the conversation that occurred at the 2021-08-25 meeting, the consensus was that this PR be closed without merging and the topic introduced into the V2.0 discussions.
@msporny @iherman -- am I to close this PR?
Based on the conversation that occurred at the 2021-08-25 meeting, the consensus was that this PR be closed without merging and the topic introduced into the V2.0 discussions.
@msporny @iherman -- am I to close this PR?
I wouldn't close it until there is an issue open to continue tracking the topic
I opened https://github.com/w3c/vc-data-model/issues/923.
can we close this now?
The issue was discussed in a meeting on 2022-09-07
- no resolutions were taken
View the transcript
1.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.