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

[RieksJ]

I can see how you could stuff a property in the evidence field that is the combination of an id property and an authenticator property as suggested by #760. The authenticator property might be extended to include a LoA field.

[OR13]

Perhaps we should take alignment with WebAuthN / FIDO to its own issue?

[awoie]

There was a lot of good discussion and it feels like people generally think that we need to make room for "holder binding" in the VCDM.

Coming back to my proposed two options:

1. the issuer provides some information in the VC itself (similar to nonTransferable but more flexible), e.g., a cryptographic identifier, claims, biometrics etc.
2. 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)

Again, I want to emphasize that both options are not mutually exclusive in my mind and I believe everybody believes that both options (or holder binding) should be made optional in general.

IMO, option 1 is the more obvious choice which doesn't mean that we don't need option 2. If option 1 and option 2 are combined then for example, the issuer can say that the VC is bound to a number of binding methods, e.g., cryptographic identifier (such as a DID, or public key), and then in the VP the presenter would still need to provide guidance on what method should actually apply. For the sake of discussion, I believe it is easier to focus on option 1 first which could be an optional feature, and then let's have another discussion on option 2. IMO, option 2 is needed but it probably needs more discussion.

Regarding option 1, we will need to agree on the definition, data model and then obviously also add a section on privacy, vendor lock-in etc. considerations like described in #988.

Below, there are two proposals for option 1, A and B.

The proposals are the result of the discussions of the group that works on the Holder Binding paper that was initiated during RWOT. Final paper will be submitted soon, authors: Oliver Terbu, Paul Bastian, Snorre Lothar von Gohren Edwin, Rieks Joosten, Antonio Antonino, Nikos Fotiou, Zaïda Rivai, Stephen Curran, Ahamed Azeem.

A. Provisionally we can call it binding, the purpose of which is to enable parties (specifically those in the role of verifier), to determine which entity a particular identifier (i.e. credentialSubject.id) refers to when it is used in a VC or VP.

Example (usage of binding in credentialSubject):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "binding":[
            "<array of binding-elements>"
         ],
         "hasPassedExam":"SOL"
      }
   ]
}

Concrete binding examples (not a normative proposal -> can be added to registry later):

{
   "binding":[
      {
         "id":"somevaliduri",
         "type":"DidAuthenticationKeyBinding",
         "keyId":"did:example:deadbeefcafe#keys-3"
      },
      {
         "id":"somevaliduri",
         "type":"PassportBinding",
         "nationality":"NL",
         "passportNr":"012345678",
         "contentHash":"3338be69 ... 2398f392"
      },
      {
         "id":"somevaliduri",
         "type":"PersonalCharacteristicsBinding",
         "characteristics":[
            "scan on left hand",
            "grey hair",
            "female",
            "needs walking stick to walk",
            "speaks swahili"
         ]
      }
   ]
}

B. Alternatively, we can reuse the evidence property, which has the downside that it is less flexible.

Example (usage of binding in evidence):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "hasPassedExam":"SOL"
      }
   ],
   "evidence":[
      {
         "type":[
            "Binding",
            "<ConcreteBindingMethod>"
         ],
         "id": "somevaliduri"
      }
   ]
}

Concrete binding examples (not a normative proposal -> can be added to registry later):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "hasPassedExam":"SOL"
      }
   ],
   "evidence":[
      {
         "type":[
            "Binding",
            "DidKeyAuthenticationBinding"
         ],
         "id":"somevaliduri",
         "did":"did:example:123456"
      },
      {
         "type":[
            "Binding",
            "PassportBinding"
         ],
         "id":"somevaliduri",
         "nationality":"NL",
         "passportNr":"012345678",
         "contentHash":"3338be69 ... 2398f392"
      },
      {
         "type":[
            "Binding",
            "personalCharacteristics"
         ],
         "id":"somevaliduri",
         "characteristics":[
            "scan on left hand",
            "grey hair",
            "female",
            "needs walking stick to walk",
            "speaks swahili"
         ]
      }
   ]
}

Do people agree that we should focus on option 1 first?

Does A or B resonate better with people as concrete proposals for option 1?

[awoie]

The above proposes the binding property to be specified as an array of elements that enable the identification and authentication of some entity, where each element consists of:

• an (optional) id field, i.e. the identifier that refers to the entity that can be identified and authenticated by the contents of this binding-element. If the id property is not specified, then the binding-element can be used to identify and authenticate the entity to which the sibling-properties of binding are attributed.
• a (required) type field, i.e. an identifier that specifies the method for identifying and authenticating the entity, using the key-value pairs (see following item).
• a set of key-value pairs, where they keys are particular to the specified binding type, and the values will be used as the method specified in the type field specifies, so as to identify and/or authenticate the entity, as intended by the author of the binding property

A similar definition would apply to evidence.

[paulbastian]

As the proposals above are from the RWOT group on "Holder Binding", I would like to express my personal view that I believe the source of truth is the usually the issuer, and therefore the binding property should be stated in the VC and signed by the issuer. Use cases where binding information is stated in the VP by the holder seem more complex and are unclear to me. I would propose to separate the discussions on (holder) binding on these variants as the topic is already complex enough

[mwherman2000]

I would like to express my personal view that I believe the source of truth is the usually the issuer

Maybe "usually" but I believe more and more this will not be the case: the "source of the truth" will be a second party. First, at a minimum, let's agree the Issuer is the entity that attaches a verifiable proof to a VC. Then consider a commercial scenario where ABC Grocery wants to "issue" a Purchase Order Verifiable Credential to David's Cabbages (like the one below).

ABC Grocery is likely to enlist the Issuing services of a mutually trusted Izzy Issuer to take ABC Grocery's purchase order credential and embed it into a Verifiable Credential that Izzy Issuer signs (attaches a Proof). In this scenario, ABC Grocery is the "source of the truth" but is not the Issuer. Conversely, Izzy Issuer is the Issuer but not the "source of the trust". Izzy Issuer is an Issuer that ABC Grocery and David's Cabbages both trust; perhaps they are all members of the same trading consortium.

[jandrieu]

I would like to express my personal view that I believe the source of truth is the usually the issuer, and therefore the binding property should be stated in the VC and signed by the issuer.

I agree that the issuer is the source of truth for the claims.

However, they cannot be the source of truth for the holder, because the actual holder at the point of presentation is not knowable. Fundamentally.

Imagining that the issuer is the source of truth for more than the attestation made in the claims will create forms of control that are inappropriate for this work.

So to the extent that verification depends on the holder being "approved" by the issuer, it is inappropriate.

To the extent that the issuer is either

1. providing guidance about how the subject might be authenticated, or
2. providing evidence or claims about how the issuer authenticated the user prior to issuance

Then we have usage that I can support.

The distinction made today on the call about the difference between verification and validation are vital to understanding the right way to factor the data model. What we need are more flexible ways to express expectations for validation, and in the VP, statements by the holder to support validation that satisfies a breadth of use cases, including the application for citizenship that is in the current use cases document.

[dlongley]

To the extent that the issuer is either

1. providing guidance about how the subject might be authenticated, or
2. providing evidence or claims about how the issuer authenticated the user prior to issuance

Then we have usage that I can support.

+1 to this.

[RieksJ]

To the extent that the issuer is either

providing guidance about how the subject might be authenticated, or providing evidence or claims about how the issuer authenticated the user prior to issuance

I would rephrase that as

To the extent that the issuer is either

1. providing guidance about how any subject (of any claim in a VC) might be authenticated, or
2. providing evidence or claims about how the issuer has identified and/or authenticated such a subject prior to issuance.

Since the term 'user' is not defined, and there is no link specified to this 'user' and any of the subjects of claims in a VC. This is different in AnonCreds (assuming that 'user' would be the person requesting the issuance of a credential), but then, this is about VCs and not about AnonCreds.

Note that these assumptions of users (or holders) occur regularly outside the scope of the VCDM. For example, Dutch law about drivers licenses and passports say that the holder ('houder' in Dutch) of such documents ARE the subject to which the attributes in the document pertains (as with AnonCreds). VCDM explicitly states that this is not the case for VCs (which can hold multiple claims for different subjects). Also, VCDM has a different definition for 'holder' and that's ok - it happens all the time that a term means different things in different contexts. The point is that in a particular context (e.g.: VCDM) a term should only be used in the meaning as it is defined for that context. See also https://github.com/w3c/vc-data-model/issues/902#issuecomment-1338929926.

[RieksJ]

What an issuer is for a VC is a holder for a VP. So It seems reasonable to assume that the same mechanisms that would enable a verifier to request data from claims/VCs that originate from a specific issuer, would similarly apply to enabling verifiers to request data from claims/VCs in a VP that is presented (issued) by a particular holder.

This could imply that apart from the holder's signature, it might add additional stuff in a presentation to enable verifiers to do this. That might, e.g., be in the form of a VC that contains a binding as proposed in this RWOT-11 paper.

[Sakurann]

PR for #882 that we agreed to do during Miami F2F should cover this issue too.

[awoie]

IMO, this is a duplicate of #882 and can be closed, or the other way around.

[msporny]

IMO, this is a duplicate of #882 and can be closed, or the other way around.

If @swcurran agrees, we can close it. I agree that they're dupes.

Given that we have a PR under debate for the feature: https://github.com/w3c/vc-data-model/pull/1054 -- we might hold off until we see what happens to that PR, or we might just de-dupe now. I'm fine w/ either.

@swcurran, thoughts?

[swcurran]

I’m fine either way.

[msporny]

I’m fine either way.

Ok, I'll mark this as pending close due to the dupe (we're trying to clean up / close issues as we head into the Candidate Recommendation phase).

We'll close in a week unless there are objections.

The discussion will continue in #882 and #1054.

[Sakurann]

closing since one week has passed