Explicit reference should be added about binding the VC to the holder

[swcurran]

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).

[mwherman2000]

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?

0. Alice is an Actor
1. Alice has a Public-Private Key Pair (KP)
2. Alice is assigned a Holder Role (aka Alice's Holder Persona)
3. As a Holder, Alice has an Agent A and A has a Wallet W (aka Credential Repository)
4. Alice needs to hold Verifiable Credential VC in Alice's Wallet
5. Alice has a personal Identifier I associated with Alice's Holder Persona (aka Holder Role) - typically a DID but not necessarily
6. The credentialSubject id of VC has the same value as Alice's Identifier I
7. VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
8. VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
9. P is Verifiable - based on Alice's Public Key that is associated with KP
10. Anything else?

NOTE: Refresh this page. I've changed this posting at least 10 times.

[David-Chadwick]

@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).

[swcurran]

@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.

[David-Chadwick]

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).

[kdenhartog]

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.

[swcurran]

@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?

[andrewhughes3000]

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 .

[agropper]

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 .

[andrewhughes3000]

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 .

[swcurran]

@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.

[agropper]

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 .

[mwherman2000]

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.

[mwherman2000]

@swcurran

Background In classic process analysis, a process step (desk procedure, task list, or statement of the work to be performs) includes 3 components:

1. Entry criteria (preconditions for the process step to start)
2. Desk procedure/task list/statement of the work to be performed
3. 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".

[dlongley]

@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]

@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]

@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

[swcurran]

@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]

@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

[kdenhartog]

@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.

[dlongley]

@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.

[kdenhartog]

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.

[swcurran]

@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?

[dlongley]

@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.

[kdenhartog]

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).

[mwherman2000]

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

[msporny]

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.

[kdenhartog]

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:

1. ACME corp under the issuer DID did:example:acme issues credential A to Alice under holder did did:example:holder
2. ACME University under the issuer DID did:example:uni issues credential B to Alice under the holder did did:example:holder
3. Alice adds Bob's key to did:example:holder and gives credential A to Bob

4. 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.

[David-Chadwick]

@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]

@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.

[David-Chadwick]

@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.

[dlongley]

@kdenhartog and @David-Chadwick,

Alice could also just provide Bob with an API that allows him to sign with her key, without having to expose her key material to Bob. There are use cases where relying solely on the ability to generate a cryptographic signature is insufficient; additional identity proofing at presentation time is required. My point is that any spec text around this topic should be very clear that there's no crypto binding that will solve every problem on its own here.

[andrewhughes3000]

For information - at ISO SC17 for mobile driving license we are wrestling with this problem as well. Please excuse the off-topic content.

The framing of it has been: the current holder/presenter verification is done in-person using a face image match to the physical face. We want to move the holder/presenter verification activity so that the verifier is not the party doing the matching - the matching will happen either on-device or at issuance time. Remember that for mDL, issuers have special rights. The discussions are interesting - no clear answer is emerging but clearly one path is to use the device biometric hardware in some trustable manner. We are also wrestling with how to and how much information the issuer should embed in the mdl regarding the specific steps they performed at proofing/issuance time. Then how much of this information to allow the verifier to receive at presentation time.

On Mon, Aug 16, 2021 at 6:37 AM Dave Longley @.***> wrote:

@kdenhartog https://github.com/kdenhartog and @David-Chadwick https://github.com/David-Chadwick,

Alice could also just provide Bob with an API that allows him to sign with her key, without having to expose her key material to Bob. There are use cases where relying solely on the ability to generate a cryptographic signature is insufficient; additional identity proofing at presentation time is required. My point is that any spec text around this topic should be very clear that there's no crypto binding that will solve every problem on its own here.

— 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-899518043, or unsubscribe https://github.com/notifications/unsubscribe-auth/AETAZ7FRMFF4UOSGD2XYMX3T5EICBANCNFSM5B7KBK7A . 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 .

-- 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 Digital Identity | International Standards | Information Security

[msporny]

@kdenhartog wrote:

Alice adds Bob's key to did:example:holder and gives credential A to Bob

You might as well say: "Alice enables Bob to masquerade as her." :) ... there is also the Legal Guardian argument (where that might be seen as acceptable... but even in that case, it should be clear who is authenticating -- it's Alice's guardian (Bob), not Alice).

In addition to what @dlongley said -- this discussion is wandering into territory where cryptographic authentication isn't going to help us (and it was never meant to be applied to these use cases).

@kdenhartog wrote:

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?

While useful, that doesn't address the issue, for the reasons @dlongley outlined above.

No one seems to have mentioned the evidence property, which is what is intended to express the sort of information that was contemplated by the issuer before issuing the VC:

https://w3c.github.io/vc-data-model/#evidence

Granted, we would need to do more work in that area to provide some basic options for Issuers.

[agropper]

@andrewhughes3000, your real-world (as opposed to our early, largely imagined SSI use-cases) is the reason I'm calling for a privacy engineering review of our W3C and DIF protocol work https://github.com/decentralized-identity/waci-presentation-exchange/issues/93

Your "...one path is to use the device biometric hardware in some trustable manner." makes my point about the risk of introducing certified "holders" into SSI protocols.

The combination of a certified holder with biometrics is indistinguishable from a certified ankle bracelet or implant.

DIDs and VCs, as the standard data models they are, do not depend on either "holder" or "biometrics" to be a huge advance in digital privacy.

Our obsession with "holder" as part of the SSI protocol foundation is now combined with the obvious need to consider the consequences of various biometrics and the real-world role of notaries as independent trust brokers around coercive identity (as Dave Huesby and I have called for).

This current thread and so many others like it should be a wake-up call for us to revisit our protocol assumptions before we consider any privacy-related changes to the VC and DID specs.

• Adrian

On Mon, Aug 16, 2021 at 10:02 AM andrewhughes3000 @.***> wrote:

For information - at ISO SC17 for mobile driving license we are wrestling with this problem as well. Please excuse the off-topic content.

The framing of it has been: the current holder/presenter verification is done in-person using a face image match to the physical face. We want to move the holder/presenter verification activity so that the verifier is not the party doing the matching - the matching will happen either on-device or at issuance time. Remember that for mDL, issuers have special rights. The discussions are interesting - no clear answer is emerging but clearly one path is to use the device biometric hardware in some trustable manner. We are also wrestling with how to and how much information the issuer should embed in the mdl regarding the specific steps they performed at proofing/issuance time. Then how much of this information to allow the verifier to receive at presentation time.

On Mon, Aug 16, 2021 at 6:37 AM Dave Longley @.***> wrote:

@kdenhartog https://github.com/kdenhartog and @David-Chadwick https://github.com/David-Chadwick,

Alice could also just provide Bob with an API that allows him to sign with her key, without having to expose her key material to Bob. There are use cases where relying solely on the ability to generate a cryptographic signature is insufficient; additional identity proofing at presentation time is required. My point is that any spec text around this topic should be very clear that there's no crypto binding that will solve every problem on its own here.

— 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-899518043 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AETAZ7FRMFF4UOSGD2XYMX3T5EICBANCNFSM5B7KBK7A

. 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

.

-- 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 Digital Identity | International Standards | Information Security

— 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-899536025, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YPMUBVQXEEAYPYNYZ3T5EK6VANCNFSM5B7KBK7A . 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 .

[kdenhartog]

@David-Chadwick wrote:

@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.

Yeah my general thinking about referencing NIST 800-63-3. It's worth noting that ISO has written a similar document in ISO/IEC 29115 as well.

These would have to be optional in many cases though or we risk pigeon holing the spec into only a limited subset of use cases.

@msporny wrote:

@kdenhartog wrote:

Alice adds Bob's key to did:example:holder and gives credential A to Bob

You might as well say: "Alice enables Bob to masquerade as her." :) ... there is also the Legal Guardian argument (where that might be seen as acceptable... but even in that case, it should be clear who is authenticating -- it's Alice's guardian (Bob), not Alice).

In addition to what @dlongley said -- this discussion is wandering into territory where cryptographic authentication isn't going to help us (and it was never meant to be applied to these use cases).

Agreed. Looking at section 5.2 in that NIST document, my general assumption is the majority of credentials today that would use the holder functionality would fall under the AAL category and reasonably I've only heard of people enabling AAL1 categories with VCs. I think it could be extended to AAL3 in the presentation though.

@msporny wrote:

@kdenhartog wrote:

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?

While useful, that doesn't address the issue, for the reasons @dlongley outlined above.

Yup, agreed. In NIST terms it's effectively just an AAL1 classification and @dlongley point makes me think the NIST didn't consider cases like what he brought up about Alice and Bob intentionally coordinating.

@msporny wrote:

No one seems to have mentioned the evidence property, which is what is intended to express the sort of information that was contemplated by the issuer before issuing the VC:

https://w3c.github.io/vc-data-model/#evidence

Granted, we would need to do more work in that area to provide some basic options for Issuers.

Yeah, I hadn't thought to apply that term to this discussion but you're right that does directly address the case I was thinking about. Referencing it back to the NIST 800-63-3 document, I think this is how IAL class information would be represented as well. The FAL category could fall in here as well, but I'd think it would be better applied at the protocol layer (and therefore not fall within the scope of this WG to define).

Essentially IAL classifications are what I'm referring to as "subject bindings" and AAL are what I'm distinguishing as "holder bindings".

[dhh1128]

Regarding the disagreement that Dave and I have about the security of link secrets, I just want to say that, while Dave stands by his paper, I also stand by mine, and I do not accept the assertion that I misunderstood his critique. So insofar as this comment thread is relevant to that controversy, I suggest people read the articles and make their own judgments.

I don't think this materially changes the validity of Stephen's request, however. We can find common ground on that.

[agropper]

Binding VCs to a holder is coercive and often unnecessary. Please see https://github.com/decentralized-identity/waci-presentation-exchange/issues/93#issuecomment-901512330 and maybe respond in this thread if appropriate.

[iherman]

The issue was discussed in a meeting on 2021-08-25

• no resolutions were taken

View the transcript

#### 5.2. Explicit reference should be added about binding the VC to the holder (issue vc-data-model#789) _See github issue [#789](https://github.com/w3c/vc-data-model/issues/789)._ > *Manu Sporny:* +1 to defer v2 **Brent Zundel:** this should be defer to v2.0 > *David Chadwick:* +1

[OR13]

is this relevant to JWP or BBS+ ? cc @tplooker @dwaite

[iherman]

The issue was discussed in a meeting on 2022-08-10

• no resolutions were taken

View the transcript

#### 5.1. Define v2 context (issue vc-data-model#789) _See github issue [vc-data-model#789](https://github.com/w3c/vc-data-model/issues/789)._ **Kristina Yasuda:** This is about explicit holder binding. This has been brought up a few times.. **Manu Sporny:** Stephen and I talked about it several times. I'm still a bit confused what the issue is about, other than figure out how to reference the holder in a way that is more compatible with how Aries does it. But I'm not certain.. … There have been multiple calls about referring to the holder in other ways.. … I'm not sure how intermixed the things are. _See github issue [vc-data-model#882](https://github.com/w3c/vc-data-model/issues/882)._ **Manu Sporny:** My suggestion is we involve Stephen. > *Michael Prorock:* +1 30day. **Kristina Yasuda:** Should we do a 30 day period like in a previous issue?. **Manu Sporny:** My concern is that this is a complex topic that will take longer, and we should give Stephen more time to have the discussion. **Ivan Herman:** Perhaps we can get him to TPAC as a guest? For a longer discussion?. > *Manu Sporny:* markus_sabadello: Is this a duplicate of issue 882?. _See github issue [vc-data-model#882](https://github.com/w3c/vc-data-model/issues/882)._ > *Brent Zundel:* I will reach out to see if Stephen is available to join us at TPAC. > *Juan Caballero:* it would allow for a CL/AnonCreds profile/type, non?. **Oliver Terbu:** There was a long discussion, we haven't resolve it, still ongoing.. … General idea is that in the current VC data model spec, it's not possible how to tell the verifier how they can verify a binding of the presentation of the credential.. … Verifier wants to know if the holder is the actual entity the issuer made claims about. The "holder" property can be anything. The data model allows that any holder can present the VC.. … Verifier could look up a property in the presentation to check how to verify the binding between the presentation and the credential.. … A simple mechanism is to check the "id" property in the VC and the proof.. … Discussion hasn't been resolved yet. **Manu Sporny:** Oliver's issue is valid and needs to be discussed. Not sure if this is the same as what Stephen raised.. > *Dave Longley:* there seems to be a general desire to allow the issuer to say who the holder (really the presenter) should be when the VC is presented (which is separate from actually proving that to be the case). > *Juan Caballero:* right, no one mentions linked secrets or AnonCreds on that PR thread, so it would be good to get explicit buy-in from the AC folks that one entry in that registry would solve the open issue. > *Michael Prorock:* 50 or 55.

[kdenhartog]

stated in the notes from last WG meeting:

Oliver Terbu: There was a long discussion, we haven't resolve it, still ongoing.. … General idea is that in the current VC data model spec, it's not possible how to tell the verifier how they can verify a binding of the presentation of the credential.. … Verifier wants to know if the holder is the actual entity the issuer made claims about. The "holder" property can be anything. The data model allows that any holder can present the VC.. … Verifier could look up a property in the presentation to check how to verify the binding between the presentation and the credential.. … A simple mechanism is to check the "id" property in the VC and the proof.. … Discussion hasn't been resolved yet. Manu Sporny: Oliver's issue is valid and needs to be discussed. Not sure if this is the same as what Stephen raised..

This is why I was trying to advocate for the IAL and AAL model that NIST has already thought through and would suit this work well.

In this case, Oliver's approach fits squarely within defining a mechanism specifically with DIDs/PKI/Webauthn authenticator would fall under AAL category. If there's a way to present evidence that a mobile device used maintains the key within a secure element via an attestation like webauthn does this would elevate it to AAL3 I believe.

However, if say for example a (password, canonicalized credential) tuple was used with a PAKE such as OPAQUE (although I think OPAQUE would require issuer/verifier coordination but a similar PAKE could likely be developed) so that the it can be verified that the knowledge known during the issuance of the credential (password) is the same piece of knowledge used on verification (password). This could then qualify as AAL1, maybe AAL2 (assuming the credential counts as PoP and OPAQUE qualifies as an "approved cryptographic technique").

In the case of what @swcurran is describing link secrets remain a PoP techinique that would qualify as "prov[ing] possession and control of the authenticator through a secure authentication protocol." This too falls directly in the AAL category as well, so why not reuse their framework for the problem?

Neither of these goes in the direction of addressing IAL (essentially that the claims are valid and the business processes used to verify it are good), but it all fits well within this evidence property as @msporny pointed out and it's already super well defined by NIST. I don't think we should be trying to re-invent the wheel here and instead we should be leaning on the good work NIST has already done to make this work. We just need to define how AAL and IAL categories can be represented with the evidence property.

The bigger question in my mind is to what extent should IAL/AAL considerations come into play for the data model layer vs the protocol layer and what tradeoffs do we make by putting them in one vs the other. As is with Webauthn it's both a combination of the well defined COSE data models as well as the protocol that ultimately makes up the security of the system. In this case, we're defining an extensible data model meant to be protocol agnostic so I tend to think pushing more into the data model layer is better, but it definitely can't be only defined here. Well IAL seems to fit squarely within the scope of the data model assuming the semantics are strongly defined in my opinion. However AAL seems a bit more complicated so we probably need better coordination with protocols moving VCs like OIDC/FedCM/GNAP/DIDComm to have a better understanding of the patterns that emerge across different protocols. This is similar to the relationship of JWTs and OAuth/OIDC.

So does that mean in the data model layer our goal should be focused on setting the boundaries of how protocols should operate and if so what do they look like?

[peacekeeper]

Related to https://github.com/w3c/vc-data-model/issues/882

[David-Chadwick]

This issue is related to #942 because once we have the identity/identifier of a persistent entity inside the VC (i.e. the issuee), put there by the issuer, then the veriifer has a rock solid anchor to base the verification from. If the holder (from VP) == issuee (from VC) then the verifier knows that the holder is the rightful possessor of the VC and did not get if from a third party. If the holder NE issuee, then the verifier can check if there is a direct chain of trust from the issuee to the holder. Note that this verification mechanism is independent of who the credential subject is. So the method works perfectly well for the parent holding their child's VC as well as a person holding a pet's VC.

[awoie]

I agree with @David-Chadwick. This issue is related to #942 and a number of other issues that relate to this. I believe there is a lot of interest in making this binding or the binding type more visible to the verifier, so a verifier can run certain policies easier. Without proper support in the VCDM there is no deterministic way of doing it. Therefor we should ask the question where folks do see such a binding mechanism being added to the VCDM.

The binding ultimately establishes a link between the VCs, the issuee and the presenter of the VP.

I can see two options:

• the issuer provides some information in the VC itself (similar to nonTransferable but more flexible), e.g., a cryptographic identifier, claims, biometrics etc.
• the holder (or presenter) provides some information in the VP (to give the verifier guidance on which binding mechanism was used, e.g., some additional proofs that link the presenter with the issuee such as a delegation object)

Both options are not mutually exclusive in my mind and both options should be optional.

[iherman]

The issue was discussed in a meeting on 2022-11-30

• no resolutions were taken

View the transcript

### 3. holder binding. > *Kristina Yasuda:* [https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Aholder-binding](https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Aholder-binding). _See github issue [vc-data-model#789](https://github.com/w3c/vc-data-model/issues/789)._ **Oliver Terbu:** There's a lot of interest in this binding type so verifier can run checks easier.. … we have two options: 1) include some info in the VC or in the VP or both; VC: biometrics, identifiers, etc. VP: additional proofs or other property. _See github issue [vc-data-model#923](https://github.com/w3c/vc-data-model/issues/923)._ > *Kerri Lemoie:* Options described here: [https://github.com/w3c/vc-data-model/issues/789#issuecomment-1332318257](https://github.com/w3c/vc-data-model/issues/789#issuecomment-1332318257). **Oliver Terbu:** listing issues. … the question is should holder binding be added to the VC, VP or both?. **Kristina Yasuda:** suggest poll. **Manu Sporny:** db is supportive of discussing holder binding; evidence was suggested prior but it doesn't entirely address concerns in the issue.. … maybe a special topic call?. > *Kristina Yasuda:* [https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verfiable-credentials-holder-binding.md](https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verfiable-credentials-holder-binding.md). **Manu Sporny:** (to oliver) do you have enough info to put together a PR or do you need guidance from the WG?. > *Ted Thibodeau Jr.:* +1 the stuff referred to as "holder binding" is an application of business logic. **Joe Andrieu:** there's nothing in the charter or spec that discuss control of VCs- use is out of scope. Control handling is a business decision to check.. … to add certainty to holder verification - define a claims vocab to describe privileges. Need a concrete way for a user to make a claim to claims.. … against adding any of this to the core data model.. > *David Chadwick:* issuer can state facts: I am saying `` about `` to ``. > *Joe Andrieu:* +1 to fleshing out evidence types. **Orie Steele:** in relation to evidence to holder binding -- opportunity to have evidence that describes holder and binding while also defending use of evidence property.. > *Manu Sporny:* +1 to Oliver to create a PR -- understanding that it's probably going to get some push back for trying to do it via `evidence` -- but we do need to discuss this, so supportive of it.. **Oliver Terbu:** (to manu) needs more info but can create a PR based on discussions in issues and then take it from there.. **Kristina Yasuda:** yes - creating a pr is a good idea. **Christopher Allen:** potential issues with privacy & correlation for parties to lock in people if this is in the core data model. would like to see some privacy considerations be clearly articulated. More comfortable with it in the VP than VC.. > *Orie Steele:* ChristopherA why is this an issue for this WG? W3C already defined WebAuthN and platform authenticators use it.. **Kristina Yasuda:** please add those comments in oliver's pr.. ---

[msporny]

@awoie wrote:

I can see two options:

• the issuer provides some information in the VC itself (similar to nonTransferable but more flexible), e.g., a cryptographic identifier, claims, biometrics etc.
• the holder (or presenter) provides some information in the VP (to give the verifier guidance on which binding mechanism was used, e.g., some additional proofs that link the presenter with the issuee such as a delegation object)

The first option feels like it would be less prone to attack than the 2nd option. The 2nd option feels like one might be able to construct an attack by mixing/matching additional proofs w/ a credential that it might not be tied to. Can't say more without seeing more details, but that's an initial gut reaction on how difficult defending the first option would be vs. the 2nd option.

The 1st option was what we were trying to accomplish with the evidence property. @jandrieu had suggested including a DIDAuth in evidence. Others had suggested including information related to a physical document that was checked, and a DIDAuth binding that was done (as two pieces of evidence). Just more info for the discussion, not saying we need to use the same mechanism yet.

[OR13]

I'm a +1 for figuring out how to make holder binding use evidence.

Another use case for evidence is a platform authenticator or passkey reference...

In that case, the evidence represents an authentication that happened for the subject at the time of credential issuance.

This kind of thing can leak data in ways that impact user privacy, see this section of webauth:

https://www.w3.org/TR/webauthn-2/#sctn-non-correlatable-credentials

[David-Chadwick]

Just to remind folks that in our recently completed NGI-Atlantic project (Next Generation SSI Protocols) we defined using the Evidence field to signal the strength of authentication (or LoA) by integrating both the NIST standard and the eIDAS standard values. I copy it below in case others might find it useful

 "evidence":[
      {
         "type":["https://eur-lex.europa.eu/eli/reg/2014/910/oj"],
         "description":"this is the URI of the eIDASv1 regulation. It will need updating to the URI of eIDASv2 when it is available",
         "loa":"low|substantial|high"
      },
      {
         "type":["https://doi.org/10.6028/NIST.SP.800-63-3"],
         "description":"this is the URI of the NIST Special Publication 800-63 scheme",
         "aal":"refers to the authentication process, has values 1, 2 or 3",
         "ial":"refers to the identity proofing process, has values 1,2 or 3",
         "fal":"(optional) refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information. Has values 1,2 or 3"
      }
    ]

[msporny]

we defined using the Evidence field to signal the strength of authentication (or LoA) by integrating both the NIST standard and the eIDAS standard values.

Yes, and that approach is aligned with the intention of the evidence property (though the markup provided looks a bit questionable... it's in the right ballpark). I expect that we might be able to do something there wrt. "holder binding".

[jandrieu]

The first option feels like it would be less prone to attack than the 2nd option.

The 2nd option is required and that has nothing to do with security. It has to do with semantics and business logic.

We currently have ambiguous semantics about what it means when a holder presents a credential. In some cases, we assert that you can check the signature and the subject ids to prove "holder binding". That's great as far as it goes (it is MUCH better than username/password binding), but that is a limited approach that fails known, documented use cases. See https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage

Until we add a mechanism for the holder to explicitly express their intention with regard to the act of presentation, none of this will be able to support the actual business rules that verifier/validators need to check.

That said, I concur with @OR13's suggestion

the evidence represents an authentication that happened for the subject at the time of credential issuance.

That is a perfectly good way for the issuer to document the level of authentication they achieved prior to issuing that specific credential.

Then we have to find a way for the holder to express WHY they are presenting the VC to the verifier and we should have both sides of the question well addressed.