vc-data-model
vc-data-model copied to clipboard
w3c
Explicit reference should be added about binding the VC to the holder
The W3C V1.0 Data Model has little focus on the role of the holder, despite it's inclusion in Figure 1 of the spec. There is little normative text about the holder, and the data item "holder" is only in the JSON-LD example in the Appendix. Further, the view that "Anyone can hold any VC and prove it to a verifier" comes through loud and clear in the spec, with almost nothing about the idea of binding the VC to the Holder. We think that's a big issue -- that in many cases the verifier would really like cryptographic confidence of the binding of the VC to the holder -- that the issuer explicitly issued the VC to that holder. If the verifier trusts the issuer, that could include that the issuer had a reason to issue the VC to the bound holder.
As we in Aries have moved from using only Indy AnonCreds to adding support for the W3C standard, we've discovered that huge difference in the cryptographic trust model between the two. In the AnonCreds model, the holder is a cryptographic component of the Trust Triangle, while in the W3C VC model, it is not -- at least that is the takeaway from reading the spec. In AnonCreds, the Issuer MUST include in the verifiable credential a proof of the Holder on issuance, the Holder must prove that binding in the presentation, allowing the verifier cryptographic assurance that the presentation comes from the intended Holder. In the W3C VC data model, there is no such required binding to the Holder -- anyone can hold an issued VC. It may be that you can bind it to the holder (and we think many would) but that is at best implied in the spec. We think it should be explicit.
Taking it further, what if the emphasis of the spec. shifted to the holder (as presented in Figure 1), and the question of what the VC was about was left to the semantics of the VC defined by the issuer? In other words, reduce the emphasis on "subject" in the core spec (since subject is not part of Figure 1). Obviously, the holder = subject is easily handled, since the holder/subject is bound to the VC. However, the holder != subject is easily covered by the semantics of the issued VC. Where the holder is irrelevant, the holder binding is left off, allowing the VC to be held by any holder.
That view is probably a bridge too far in the VC 1.x spec. Adding a section about being explicit about a proof of the binding between the holder and VC would be a big help. We plan on proposing a PR to address this issue.
This issue arose from a discussion starting here on PR #788 , but is a separate issue from that PR. Other relevant comments on that PR are from @dlongley (here), @andrewhughes3000 (here), @msporny (here) and @agropper (here).
Duplicate of https://github.com/w3c/vc-data-model/pull/788#issuecomment-897089956 ...
@swcurran Given your world view Stephen, what are the Preconditions for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?
For example, which (or all) of the following Preconditions are necessary for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?
- Alice is an Actor
- Alice has a Public-Private Key Pair (KP)
- Alice is assigned a Holder Role (aka Alice's Holder Persona)
- As a Holder, Alice has an Agent A and A has a Wallet W (aka Credential Repository)
- Alice needs to hold Verifiable Credential VC in Alice's Wallet
- Alice has a personal Identifier I associated with Alice's Holder Persona (aka Holder Role) - typically a DID but not necessarily
- The credentialSubject id of VC has the same value as Alice's Identifier I
- VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
- VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
- P is Verifiable - based on Alice's Public Key that is associated with KP
- Anything else?
NOTE: Refresh this page. I've changed this posting at least 10 times.
@swcurran Interestingly this is more or less the model we have implemented, where the subjectID is actually used as the proof of possession of the VC and the subject properties say what the VC is about. So if the Issuer gave the holder the VC, and the holder can prove possession of it, then the Verifier knows the correct entity is presenting the VC to it (regardless of the VC's actual contents).
@David-Chadwick -- thanks for the example. As I noted, Indy AnonCreds has the same model. I've heard of others doing what you are doing when using W3C VCs (e.g. BBS+). I think using subjectID for that is a workaround, and it makes way more sense to use holderID for proof of possession to establish that binding. By using subjectID for "proof of holder", it can't really be used for any subject not holder -- or subject not relevant -- use cases.
If the subjectID is an ephemeral public key, then the verifier has no idea who the actual subject is (apart from the VC's properties). All the verifier knows is that the entity that signed the VP is the same entity that holds the public key in the VC subject ID field and that the Issuer knows who it gave the VC to (and obviously was entitled to have it). So it can be used for any subject not holder and subject not relevant use cases, because the subject is an ephemeral public key.
In one of our use case, a person presents the company's registration certificate from Companies House to the verifier. The verifier knows that whoever presented this VC is entitled to do so because Companies House issued the VC to them. This and other VCs' contents may tell the verifier what the relationship of this person is to the company (e.g. could be a director, secretary, or employee).
Labeling this as a possibleErratum now for the small non-normative suggestions you're going to put in a PR. Then we'll have to address the larger portions in a V2 at a later time.
@David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.
From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?
My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.
It can't go in the verifiable credential itself, since the VC is constructed by the issuer. Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?
Over in ISO 18013-5 mDL land, in case you were wondering...
3.8 mDL holder individual to whom an mDL (3.6) is issued, i.e. legitimate holder of the driving privileges reflected on an mDL
And because mDLs are issued by licensing offices which universally do identity proofing and verification prior to issuance, [ "mDL holder" == "subject" ] of the credential (in this case the mobile driving license).
*Andrew Hughes *CISM CISSP In Turn Information Management Consulting
o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 @.*** https://www.linkedin.com/in/andrew-hughes-682058a https://www.linkedin.com/in/andrew-hughes-682058a *Digital Identity | International Standards | Information Security *
On Thu, Aug 12, 2021 at 9:21 AM Stephen Curran @.***> wrote:
@David-Chadwick https://github.com/David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.
From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?
My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.
It can't go in the verifiable credential itself, since the VC is constructed by the issuer. Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/789#issuecomment-897776546, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETAZ7HHW3GXIVVAXI3VTSTT4PYJ5ANCNFSM5B7KBK7A . 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 .
How is the mDL Holder == subject identified? Is there a biometric in the credential the way we have in a physical license?
On Thu, Aug 12, 2021 at 12:29 PM andrewhughes3000 @.***> wrote:
Over in ISO 18013-5 mDL land, in case you were wondering...
3.8 mDL holder individual to whom an mDL (3.6) is issued, i.e. legitimate holder of the driving privileges reflected on an mDL
And because mDLs are issued by licensing offices which universally do identity proofing and verification prior to issuance, [ "mDL holder" == "subject" ] of the credential (in this case the mobile driving license).
*Andrew Hughes *CISM CISSP In Turn Information Management Consulting
o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 @.*** https://www.linkedin.com/in/andrew-hughes-682058a https://www.linkedin.com/in/andrew-hughes-682058a *Digital Identity | International Standards | Information Security *
On Thu, Aug 12, 2021 at 9:21 AM Stephen Curran @.***> wrote:
@David-Chadwick https://github.com/David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.
From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?
My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.
It can't go in the verifiable credential itself, since the VC is constructed by the issuer. Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/w3c/vc-data-model/issues/789#issuecomment-897776546 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AETAZ7HHW3GXIVVAXI3VTSTT4PYJ5ANCNFSM5B7KBK7A
. 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
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/789#issuecomment-897786065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YI676PFH7ZCJBOEJW3T4PZGNANCNFSM5B7KBK7A . 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 set of data elements is the same as the set of data elements for international driving licenses (the physical kind) plus several more. Therefore, roughly speaking, all the data elements that are present on physical driving licenses are also present in mDL There are means to include or override data elements as needed to satisfy local regulations, but the core is the same everywhere.
*Andrew Hughes *CISM CISSP In Turn Information Management Consulting
o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 @.*** https://www.linkedin.com/in/andrew-hughes-682058a https://www.linkedin.com/in/andrew-hughes-682058a *Digital Identity | International Standards | Information Security *
On Thu, Aug 12, 2021 at 9:34 AM Adrian Gropper @.***> wrote:
How is the mDL Holder == subject identified? Is there a biometric in the credential the way we have in a physical license?
On Thu, Aug 12, 2021 at 12:29 PM andrewhughes3000 @.***> wrote:
Over in ISO 18013-5 mDL land, in case you were wondering...
3.8 mDL holder individual to whom an mDL (3.6) is issued, i.e. legitimate holder of the driving privileges reflected on an mDL
And because mDLs are issued by licensing offices which universally do identity proofing and verification prior to issuance, [ "mDL holder" == "subject" ] of the credential (in this case the mobile driving license).
*Andrew Hughes *CISM CISSP In Turn Information Management Consulting
o +1 650.209.7542 m +1 250.888.9474 5043 Del Monte Ave., Victoria, BC V8Y 1W9 @.*** https://www.linkedin.com/in/andrew-hughes-682058a https://www.linkedin.com/in/andrew-hughes-682058a *Digital Identity | International Standards | Information Security *
On Thu, Aug 12, 2021 at 9:21 AM Stephen Curran @.***> wrote:
@David-Chadwick https://github.com/David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.
From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?
My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.
It can't go in the verifiable credential itself, since the VC is constructed by the issuer. Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/w3c/vc-data-model/issues/789#issuecomment-897776546 , or unsubscribe <
https://github.com/notifications/unsubscribe-auth/AETAZ7HHW3GXIVVAXI3VTSTT4PYJ5ANCNFSM5B7KBK7A
. 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
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/w3c/vc-data-model/issues/789#issuecomment-897786065 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AABB4YI676PFH7ZCJBOEJW3T4PZGNANCNFSM5B7KBK7A
. 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
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/789#issuecomment-897789516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETAZ7BWQ7DK4ZISHGJGHB3T4PZZFANCNFSM5B7KBK7A . 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 .
@mwherman2000 -- regarding your list. It is hard to understand, but I'll try to set what I see as the flow. I'll assume that "Alice" is an agent she controls -- software that allows her to be issued VCs and prove VPs.
Alice wants a credential from an issuer Faber. As part of a protocol, she gives Faber a piece of data that only she can prove -- perhaps something associated with a private key she holds. Faber prepares the VC and includes in it the piece of data provided by Alice as a claim, signs the VC (including the "proof-of-holder" claim) and provides it to Alice, as the holder. The claims within the VC can be about anything -- Alice, or about something else. Later, Acme asks Alice for a prove that can be satisfied by the VC Alice holds from Faber. Alice prepares a VP derived from the VC from Faber. Along with (or in?) the VP is a proof of the piece of data that Faber embedded in the VC -- proving that Alice is the intended holder (hence -- authorized by the Issuer to present the claims).
In a paper driver's license, that is a picture of the person. In Indy AnonCreds, it is a blinded link secret that the holder proves in the presentation. It could be a DID with an associated key that the holder proves control over.
My concern is that I don't think how a mechanism like this could work is defined in the VC spec.
There's a huge difference between a picture of a person and control of a link secret or private key. I can't share my Driver's License (or mDL) with another person because of the biometric. I can share a link secret or private key with anyone I want. If the reputation associated with the private key is semi-disposable, I can do that without much worry.
In order to use link secrets as we would a biometric, the link secret would have to be tied to the individual person somehow. That could be an ankle bracelet or a secondary biometric credential.
On Thu, Aug 12, 2021 at 12:40 PM Stephen Curran @.***> wrote:
@mwherman2000 https://github.com/mwherman2000 -- regarding your list. It is hard to understand, but I'll try to set what I see as the flow. I'll assume that "Alice" is an agent she controls -- software that allows her to be issued VCs and prove VPs.
Alice wants a credential from an issuer Faber. As part of a protocol, she gives Faber a piece of data that only she can prove -- perhaps something associated with a private key she holds. Faber prepares the VC and includes in it the piece of data provided by Alice as a claim, signs the VC (including the "proof-of-holder" claim) and provides it to Alice, as the holder. The claims within the VC can be about anything -- Alice, or about something else. Later, Acme asks Alice for a prove that can be satisfied by the VC Alice holds from Faber. Alice prepares a VP derived from the VC from Faber. Along with (or in?) the VP is a proof of the piece of data that Faber embedded in the VC -- proving that Alice is the intended holder (hence -- authorized by the Issuer to present the claims).
In a paper driver's license, that is a picture of the person. In Indy AnonCreds, it is a blinded link secret that the holder proves in the presentation. It could be a DID with an associated key that the holder proves control over.
My concern is that I don't think how a mechanism like this could work is defined in the VC spec.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/789#issuecomment-897793522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YNNCE2NMZ3N2I6T72LT4P2O3ANCNFSM5B7KBK7A . 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 .
RE: I can't share my Driver's License (or mDL) with another person because of the biometric.
I disagree… you can share your Driver’s License (or mDL) with anyone. It won’t be valid nor positively verifiable (as well as possibly illegal) but in theory as well as reality, you can choose to share virtually any (all?) credentials with anyone.
@swcurran
Background In classic process analysis, a process step (desk procedure, task list, or statement of the work to be performs) includes 3 components:
- Entry criteria (preconditions for the process step to start)
- Desk procedure/task list/statement of the work to be performed
- Exit criteria (postconditions that must be met for the process step to end and transition to the next process step (subject to it's entry criteria).
Here's an illustration from https://www.researchgate.net/publication/242573971_Basic_Concepts_and_Techniques ...
Discussion
Stephen, back to your original question/comment, I thought you were highlighting the entry criteria (preconditions) necessary for an Actor to create and present a Verifiable Presentation VP to another party (e.g. an Actor in a Verifier role) ...assuming the underlying Verifiable Credential VC has been created, issued, and exists "somewhere".
As an example of these preconditions, the Actor Alice needed to belong to or possess the Holder role (i.e. the Actor has an Agent A and in turn A has a Wallet W), etc. The rest of the list of preconditions (quite detailed) is what I wrote down here: https://github.com/w3c/vc-data-model/pull/788#issuecomment-897089956
Does this connect with your thinking? In this thread, I was asking for your review of the list of 10 preconditions for completeness as well as outright errors for the scenario;
...entry criteria (preconditions) necessary for an Actor to create and present a Verifiable Presentation VP to another party (e.g. an Actor in a Verifier role) ...assuming the underlying Verifiable Credential VC has been created, issued, and exists "somewhere".
@agropper,
I can share a link secret or private key with anyone I want. If the reputation associated with the private key is semi-disposable, I can do that without much worry.
I agree and this touches on one of the important things that would need to be noted in any language added to the spec around this concept.
If the presentation is unlinkable, there isn't even a reputational aspect that could be used to discourage sharing (i.e., to enable "cheaters to get caught"). We'll need to understand whether a "bound VC" is intended to be unlinkably presented or not. There are several different ways a binding could be done and each of those ways have different security/privacy characteristics.
For example, if the same link secret is used where reputation is important for some presentations and not others, a remote API can be constructed that allows covert shared use of that link secret without having to share the link secret material itself. This enables use of such a link secret to be selectively shared without detection by the verifier. I agree that some form of identity proofing (e.g., biometrics) can be used to prevent this style of attack so as to ensure valuable reputation is at risk for attackers.
@mwherman2000,
I disagree… you can share your Driver’s License (or mDL) with anyone. It won’t be valid nor positively verifiable (as well as possibly illegal) but in theory as well as reality, you can choose to share virtually any (all?) credentials with anyone.
I think the disagreement is over the definition of "share". Perhaps "misuse" or "misuse with / without detection" would be better terminology. @agropper's point was that it is significantly more challenging to misuse a credential (without detection) where a verifier requires a binding biometric check than it is to misuse a credential (without detection) where the verifier does not have that requirement.
@David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.
this is not necessary because the subject properties (i.e. claims) can both identify the subject (e.g. company name) and provide an identifier for the subject (e.g. company registration number).
So my feeling now is that subjectID should really become the proof of possession identifier.
From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?
All I can say is that it is what we are doing. I cannot speak for any other implementors
My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.
Again, the issuer can identify the holder in the claims by providing either its identity or identifier or both. There is no restriction on the number or type of claims that can be included in a VC.
It can't go in the verifiable credential itself, since the VC is constructed by the issuer.
Thats precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).
Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?
Simple. The issuer of the VP is the holder, and the holder is the subject ID of the VCs embedded in the VP. So it is trivial to check they are the same, especially if it is a public key or DID
@David-Chadwick -- sounds like we agree on the needs and reality (using subjectID to mean holderID), but differ on whether it matters.
Regards:
That's precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).
What I meant was that the proof that the holder is presenting can't go in the VC. A piece of data can go into the VC from the issuer to indicate "this is the holder I issued this VC to" can go into the VC, but a proof from the holder binding it to that piece of data is also needed from the holder with the presentation.
@David-Chadwick -- sounds like we agree on the needs and reality (using subjectID to mean holderID), but differ on whether it matters.
Why do we differ on whether it matters or not? Ideally the property should be labelled with its semantic meaning, so in this respect it does matter. But I am asserting that the claims themselves (and VC type) can enable the verify to determine the difference. In the case of a bearer credential, the property is missing entirely because mere possession of the VC is proof enough that you possess it. So no further proof is needed and it does not matter in this case what the property is called as it is not there.
Regards:
That's precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).
What I meant was that the proof that the holder is presenting can't go in the VC. A piece of data can go into the VC from the issuer to indicate "this is the holder I issued this VC to" can go into the VC, but a proof from the holder binding it to that piece of data is also needed from the holder with the presentation.
Agreed
@agropper,
I can share a link secret or private key with anyone I want. If the reputation associated with the private key is semi-disposable, I can do that without much worry.
I agree and this touches on one of the important things that would need to be noted in any language added to the spec around this concept.
If the presentation is unlinkable, there isn't even a reputational aspect that could be used to discourage sharing (i.e., to enable "cheaters to get caught"). We'll need to understand whether a "bound VC" is intended to be unlinkably presented or not. There are several different ways a binding could be done and each of those ways have different security/privacy characteristics.
For example, if the same link secret is used where reputation is important for some presentations and not others, a remote API can be constructed that allows covert shared use of that link secret without having to share the link secret material itself. This enables use of such a link secret to be selectively shared without detection by the verifier. I agree that some form of identity proofing (e.g., biometrics) can be used to prevent this style of attack so as to ensure valuable reputation is at risk for attackers.
@dlongley I agree with the premise here around reputation, but not the conclusion that the verifier can't detect it. There's been work to show that it's possible for a verifier to detect it without breaking the anonymity. So the point about having some form of skin in the game, I think is pertinent here, but I think the premise that a link secret doesn't support this is misleading. The key differentiating factor that I see between reputation based on a globally known identifier and an anonymous link secret is that a globally known identifier can be flagged and published so that ANY verifier could rely upon it without any additional complexity (a REALLY good thing when dealing with authorization logic), where as a link secret limits only the verifier who detects the reuse can rely upon it.
There's some caveats that could be used to work around this, but it requires a greater level of complexity in coordination between verifiers. This is done, by effectively building a coordinated federation of verifiers who register all the challenges and proofs that they request. With the link secret system the verifiers would have to coordinate challenge request information to prevent false positives from occurring and then on verification they also need to do the proof checking. None of this additional coordination complexity is necessary when the identifier is globally discoverable - which makes it much easier to scale.
So in summation, I'd say it is possible but the link secret system requires more complexity to achieve the same outcome, with the obvious tradeoff being that the additional complexity in the management of these coordinated challenge requests and proof verification is the holder is able to maintain their anonymity of the identifier.
@kdenhartog,
I agree with the premise here around reputation, but not the conclusion that the verifier can't detect it. There's been work to show that it's possible for a verifier to detect it without breaking the anonymity. So the point about having some form of skin in the game, I think is pertinent here, but I think the premise that a link secret doesn't support this is misleading.
The proposals from that paper were responded to in a publication here: https://ieeexplore.ieee.org/document/9031545
IIRC, that method effectively substitutes a Pedersen commitment for an El Gamal one, eliminating the perfect hiding property (you only get to choose one: "perfect hiding + computational binding" or "computational hiding + perfect binding"). So, while that may achieve the goal of a perfect binding, it also creates a scenario where it becomes much more likely that future computational attacks could probabilistically reveal the user's identity in a number of interactions that were supposed to be safe even into the future. This approach is therefore particularly problematic in systems where a single link secret is shared across many different identities. If some of the guarantees that make link secrets of interest to begin with are lost with this approach -- then I believe it's hard to say it's all that viable of a solution.
then I believe it's hard to say it's all that viable of a solution.
That's a fair point, I had forgotten about that correlation issue that comes about with it. So, I agree it's not universally viable which means that each use case needs to evaluate if it is applicable for their needs. I can see how you've ended up on the conclusion that in that case it's probably best to not recommend it due to all of the additional complexity and the unclear responsibilities that allow for the use case to adversely impact the cryptographic guarantees which are dealt with at a completely different layer. If we were to put any recommendations around it, we'd definitely want to mention that caveat.
@dlongley -- and the paper you wrote/referenced above was rebutted here. There is disagreement.
My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec. In my reading of the spec, it would appear to be discouraged.
Related, but less fundamental to the VC model, is whether such a holder binding requires a unique identifier for the Holder be exposed, or if other approaches are possible. I personally think that it is worth pursuing an approach where simply presenting a VC does not require such an exposure and would not like the spec to forbid that approach. I gather you would not try to use such a feature, and that too should not be forbidden.
Is that a reasonable summary?
@swcurran,
and the paper you wrote/referenced above was rebutted here. There is disagreement.
Yeah, the points the paper makes are largely misunderstood in that rebuttal. It also has an unseemly introduction that focuses on casting aspersions on the authors. I stand by the published paper.
You don't want to change your commitments from perfectly hiding to computationally hiding when you could instead reveal a use-case appropriate correlational/binding identifier. It's a bad idea to mislead people into thinking their secrets will stay safe indefinitely when obfuscated and handed over to the very party they don't want to see them. My advice is to never intentionally hand someone a computationally hidden secret that you never want them to know.
I will repeat that computationally hiding is not the same thing as perfect/statistical/unconditional hiding here -- since that point has been lost in the past. The IEEE paper was criticizing computationally hiding commitments (this very approach to solving the reputation/link secret reuse problem that we're discussing here in this issue and that the paper was written in response to). I only repeat this again because the rebuttal paper had a whole section on perfectly hiding commitments (the other kind of commitment) which was written with the perspective that the authors of the IEEE paper must just misunderstand them, but it was the rebuttal that was off target.
Now, of course, if you have to reveal a correlational identifier in a majority of use cases, one has to question whether it's worth creating a complex system of link secrets and credential definitions to avoid revealing one... just so one can claim that the system uses zero knowledge proofs (i.e., the proving system itself leaks no additional information beyond what is to be proved). Every benefit must be weighed against its drawbacks. This main point of practicality continues to be lost (or just rejected?) on some. There are all kinds of systems one can add or build off of that would be self-contained. But are they worth the cost if their benefits are largely lost or if they require new mitigations for the majority of use cases?
The argument the paper made was that it was not worth it; every attempt made to hide information just ended up requiring more information to be put back somehow to meet most use cases (and usually put back in a more complicated way). These are the sorts of things spec readers will want to know if we give any guidance here.
Thankfully, BBS+ dispenses with many of the aforementioned costs and provides for selective disclosure that can reveal what is needed to solve the trust and reputation problem -- without the overhead of the link secret approach. It is important to note that a correlational identifier of some sort still must be revealed/provided to get the kind of trust characteristics desired by verifiers in most "attribute-based credential" use cases. But you're not paying the same complexity and infrastructure cost in adopting BBS+ to get the desired selective disclosure, making the trade off palatable. I should add that I haven't yet done a deep dive on the BBS+ approach, but I am aware that it is a "slot in" in the existing VC ecosystem vs. requiring a whole separate ecosystem and supporting infrastructure to be created.
Related, but less fundamental to the VC model, is whether such a holder binding requires a unique identifier for the Holder be exposed, or if other approaches are possible. I personally think that it is worth pursuing an approach where simply presenting a VC does not require such an exposure and would not like the spec to forbid that approach. I gather you would not try to use such a feature, and that too should not be forbidden.
Is that a reasonable summary?
Yes. I have no problem with the spec discussing the benefits and drawbacks of any approach.
My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec. In my reading of the spec, it would appear to be discouraged.
Yeah I've come to figure out that we're coupling the identifier in credentialSubject.id in a few different ways and it's caused confusion about it's purpose. I tried to explain that in this https://github.com/w3c/vc-data-model/issues/790#issuecomment-898229690
After writing that up, I'm thinking it would be useful to explicitly identify the credentialHolder in a separate part of the credential separate from the credentialSubject to better decouple these concepts. And in the case when subject == holder, they could share an identifier to convey that - and we'd probably need to figure out a way to make this align with ZKPs. Curious what peoples initial thoughts are on doing something like that (and @msporny was this discussed previously in the group).
I think the disagreement is over the definition of "share".
Let's start with this first issue. Here's a working definition of share (that works for me):
The words partake and participate are common synonyms of share. While all three words mean "to have, get, or use in common with another or others," share usually implies that one as the original holder grants to another the partial use, enjoyment, or possession of a thing. Reference: https://www.merriam-webster.com/thesaurus/share
I'm thinking it would be useful to explicitly identify the credentialHolder ... @msporny was this discussed previously in the group)
There was discussion about this and we decided to put the concept of "credentialHolder" in presentation: https://w3c.github.io/vc-data-model/#presentations-0
I'm also very supportive of clearing up @swcurran's concern in the specification:
@swcurran wrote:
My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec.
... and the most likely place to do this in the current spec is this section:
https://w3c.github.io/vc-data-model/#validation
... perhaps by adding a section called "Holder" and elaborating in there on all the ways you can do this sort of validation. I do think we need to do quite a bit of clean up on Appendix C Subject-Holder Relationships... because there is messy overlap between the two sections. I'll also note that some parts of this establishment gets into protocol, and talking too much about that in a normative way in the VC spec is problematic (as the spec then jumps into protocol, which the group wasn't chartered to do at the time (and will almost certainly not be re-chartered to do in the next 12 months or so).
So, we should address @swcurran's issue, probably in Appendix A. Validation, by adding a new section on Holder.
I would like @swcurran to take an action to write up some text so the Editors don't have to guess on what he would like clarified in the specification. I can certainly help (as will the other editors) put it into context in the specification.
I accidently edited @msporny original point rather than creating my own comment which is below. Going to have to revert his discussion point as well for coherence. Sorry about the confusion.
I'm thinking it would be useful to explicitly identify the credentialHolder ... @msporny was this discussed previously in the group)
There was discussion about this and we decided to put the concept of "credentialHolder" in presentation: https://w3c.github.io/vc-data-model/#presentations-0
Interesting point, I'm realizing now this may inadvertently not align with where we've been looking at things lately. In some cases, we've found it important for the verifier to know that the issuer did their due diligence in binding the credential to the subject. One of the most common ways this could be done today is through the use of an image, but I could imagine ways that this could be done with knowledge challenges as well. An example would be verifier asks for the birthday name to match the information on the credential. There's likely more ways to improve in the "what you know" and "what you are" authentication classes to improve subject binding more.
However, the thing I'm realizing is that the "what you have" authentication class is actually more specifically tied to holder bindings. In some cases, authenticating the holder is good enough to also authenticate the subject (this is the premise of webauthn after all). I think this conflation between subject binding and holder binding though combines with us not doing any upfront holder authentication and binding allows for a slight disconnect here. In the case of the holder property in the presentation this is almost always (in DID+VC use cases where holder = subject) being used in a way to check that the holder matches the subject of the credential AND that the presumption between holder binding being "good enough" for subject binding. These architecture couplings have been useful for the majority of the use cases so far, but I'm thinking these discussions that we should consider separating these things out.
In particular, as a verifier, there's likely a case where we'd like to be able to verify that the holder binding done at the time of issuance matches with the holder binding at the time of presentation. An example where this could be abused (and the reason it's important) is the following use case:
- ACME corp under the issuer DID
did:example:acmeissues credential A to Alice under holder diddid:example:holder - ACME University under the issuer DID
did:example:uniissues credential B to Alice under the holder diddid:example:holder - Alice adds Bob's key to
did:example:holderand gives credential A to Bob - Verifier Corp asks Bob for a credential that matches credential A - so Bob gives credential A and uses the key added to
did:example:holder
In this case, there was no holder binding that occurred during the issuance phase (even if subject binding did - e.g. Alice is claim x in credential A) allowing Alice to transfer the credential to Bob. By separating out the subject binding from holder binding and allowing for the issuer to assert this binding (and how they conducted the binding maybe?) we're allowing for the verifier to detect these concerns more explicitly.
@swcurran is this the thing that you're trying to highlight better?
I agree with @msporny here that having you write up an initial PR on the topic will help and afterwards we can work on figuring out what's the best way to handle it from there.
@kdenhartog The example you provide of using DIDs to identify the holder, where arbitrary keys can be added to the DID document by the holder, shows the security vulnerability in this particular type of DIDs. Any number of users can collude in this way and break the entire system. One solution is to define a DID that is linked to one key, and one key only (which incidentally is what we have done in our implementation) to stop this type of collusion from happening. But of course this still does not stop multiple users from colluding and sharing the same key pair, especially if the private keys are held in software. So this argues for only holding private keys in hardware that cannot be shared (or is very inconvenient or costly to share).
@kdenhartog The example you provide of using DIDs to identify the holder, where arbitrary keys can be added to the DID document by the holder, shows the security vulnerability in this particular type of DIDs. Any number of users can collude in this way and break the entire system. One solution is to define a DID that is linked to one key, and one key only (which incidentally is what we have done in our implementation) to stop this type of collusion from happening. But of course this still does not stop multiple users from colluding and sharing the same key pair, especially if the private keys are held in software. So this argues for only holding private keys in hardware that cannot be shared (or is very inconvenient or costly to share).
Correct, and the question then becomes how does verifier know what assurances were made to the holders key management before issuing the credential to the identifier? Hence the point about the credential needing to make assertions about this holder binding as well and not just the presentation. It should be noted these types of things really only need to be done in cases where the holder binding is important of the security of the system which almost always devolve to authentication and authorization systems of some sort.
@kdenhartog Looks like a new standard is needed here to define the different types of key management that can be supported (unless this standard already exists). Plus a new VC property to hold the standardised values.