Add extension mechanism to allow different methods for VP-to-VC / holder binding to next version of standard to allow verification of rightfulness of presentation

[awoie]

A very common use case in the VC ecosystem is the presentment of VCs as VPs. Usually, the verifier is interested in whether the holder is the legitimate subject of the presented VCs, so they can answer questions such as "does the VP at the time of presentment authenticate the subject of the VC and can we assume the issuer made the same VCs about the holder in the VP?". Note, such a decision is simple in case the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder. I believe this is also what a lot of people implemented although there is no normative definition of such a binding. While this is a simple example, there are other examples that might be a bit more complex, e.g., in case there is no credentialSubject.id which is common for ZKP-based VCs, or a subject controls multiple identifiers and those relationships are represented as same-as-relationship-VCs etc. In that situation a verifier needs to guess since it does not know the intended mechanism for binding the proof in the VP to the holder and the subject of the VC which is an issue for interoperability. Having the verifier to have this knowledge pre-populated is also possible but it prevents interoperability as well.

The current W3C VC Data Model 1.1 defines the holder property but its use is quite limited. It also doesn't allow to add new properties since the normative definition is holder MUST be a String.

For that reason I propose to change the holder property to String or Object. If it is an Object, we can add an optional holderBinding property that has an extension mechanism based on a type sub-property to allow implementers to define their own method of how such a relationship can be (ideally cryptographically) verified by the verifier. If the holderBinding is not provided, the default is always there is no binding or the binding can be established based on out-of-band information. For other mechanisms, I propose to introduce an extension registry similar to credentialStatus, evidence etc.

Example:

{
  ...
  "holder": {
    "holderBinding": {
       "type": "ExampleBindingBasedOnVCs",
       "optionalExampleBindingSpecificProperties": {
          ...
       }
    }
  },
  ...
}

Note, we cannot reuse the Data Integrity Proofs extension mechanism since each proof specification defines their own parameters and what options are hashed and signed over. We cannot reuse the evidence property, since it is less specific and currently only defined for the VC object and won't allow this decision to be made at the time of presentment.

tagging: @swcurran (since he opened a similar issue https://github.com/w3c/vc-data-model/issues/789) and @dmitrizagidulin

Updated:

• made holderBinding property optional
• changed default behaviour of holderBinding not being present to original definition which is essentially undefined (i.e. no binding or depending on verifier logic).

[peacekeeper]

In general, I like the idea of changing holder to be either String or Object, in a similar way as issuer can also be String or Object. This seems useful in situations where you want to add more information about a holder/issuer than just an identifier.

However, I am not convinced that your use case of holder binding is appropriate for this. To me, the existing proof property seems to be the correct construct.

According to the spec, proof is used to "detect tampering and verify the authorship". Isn't holder binding a part of that?

Could you explain a bit more what you mean by:

Note, we cannot reuse the Data Integrity Proofs extension mechanism since each proof specification defines their own parameters and what options are hashed and signed over.

[awoie]

@peacekeeper Thanks for your feedback. The Data Integrity Proof extension cannot be used (in a satisfactory manner) for the following reasons:

• We would need to define a new suite and we cannot reuse existing Data Integrity Proof suites. This doesn't scale well regarding implementation and specification efforts. I want to allow existing suites such as Ed25519Signature2020, JsonWebSignature2020 etc. and I see the holderBinding as an additional relationship between the holder of the VP, the proof in the VP and the VC. This is important to support existing implementations that understand how to process those suites. Note that although Data Integrity Proofs support options, so something like the holderBinding as proposed above could be one such option but it is up to the Data Integrity Proof suite such as Ed25519Signature2020 to define what options will be used and integrity protected.
• hard to support JWTs.

[awoie]

According to the spec, proof is used to "detect tampering and verify the authorship".

Let's use this simple example...

We have a VC with a vc.credentialSubject.id = "did:example:1", and a VP that has a vp.holder = "did:example:2" containing the VC. The proof of the VP was made by did:example:2#key-1. Further, let's assume there is a relationship between did:example:1 and did:example:2 in form of a VC that says, both are essentially the same (I know this is a bit sloppy). Even if I included those relationship-VCs in the VP, the verifier would be able to verify authorship and detect tampering, but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC. If we had a holder binding property in the proof (+ some external specification for the corresponding type), the verifier will be able to understand the holder's intention and can verify the relationship VCs in correspondence to the proof in the VP and the holder in the VP. Does this make sense?

[peacekeeper]

Hmm I don't really get it.

You say you cannot use a Data Integrity Proof extension because you would have to define a new suite and that this doesn't scale well, and then you say "If we had a holder binding property in the proof (+ some external specification for the corresponding type)". So you would still have to write an extension specification for your holder binding type, no? How does that scale better?

I also don't understand this part: "but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC". Why not? If there is a relationship VC in the VP, then why can't a verifier verify that the holder is the legitimate holder?

I don't feel strongly about this and wouldn't really oppose it, but to me it feels overly complicated to add this functionality to the holder property. Any other opinions?

[peacekeeper]

As a side note, if you want to express equivalence between did:example:1 and did:example:2, then that could be expressed via DID document properties and metadata, e.g. alsoKnownAs, equivalentId, canonicalId. But doing something similar with a VC is also a nice idea I think.

[awoie]

Hmm I don't really get it.

You say you cannot use a Data Integrity Proof extension because you would have to define a new suite and that this doesn't scale well, and then you say "If we had a holder binding property in the proof (+ some external specification for the corresponding type)". So you would still have to write an extension specification for your holder binding type, no? How does that scale better?

I want to allow people to reuse existing Data Integrity Proof specifications, meaning that the type in the VP proof stays the same. Also note, this approach would be backwards compatible. Furthermore, since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP). This binding would give us a different property than that. IMO, this proof is also orthogonal to the actual proof mechanism.

I also don't understand this part: "but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC". Why not? If there is a relationship VC in the VP, then why can't a verifier verify that the holder is the legitimate holder?

They can, but there are many different methods how to accomplish this. Giving the verifier a single property to check what type of method is used, simplifies implementations by allowing profiles and helps with interop, it also helps with interop if there is a registry of supported methods that accomplish that.

Updated:

Typically, this part of the code that verifies the binding that I described above is typically outside of VC implementations, i.e. something that the verifier has to implement in addition. I want to standardize this through an extension mechanism. So that SSI framework vendors can implement something like (also note that those bindings could be pluggable to support any mechanism):

verifyVp(vp, ...)
verifyVc(vp.verifiableCredential[0..n], ...)

// this part of the code is usually VC profile specific logic and not provided by SSI frameworks (e.g., to check whether the same-as-relationship-VCs are in place). If we define an extension mechanism, then this could be part of SSI frameworks.
verifyBinding(vp)

[awoie]

As a side note, if you want to express equivalence between did:example:1 and did:example:2, then that could be expressed via DID document properties and metadata, e.g. alsoKnownAs, equivalentId, canonicalId. But doing something similar with a VC is also a nice idea I think.

Thanks for bringing this up. This might be certainly great in some cases but cannot be used everywhere, VCs can be used without DIDs, stronger cryptographic binding might be required, some DID methods don't support updates etc.

[peacekeeper]

since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP)

I think I said the opposite, i.e. that holder binding is part of "verifying the authorship", not orthogonal to it. In your initial message you also explain that in VPs with traditional signatures, holder binding is also done via the VP's proof, i.e. in cases when "the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder".

With your proposal, wouldn't we then end up in an inconsistent situation where holder binding is sometimes established via the proof alone, and sometimes via the proof plus something else?

In my mind, the VP proof can be used very broadly and could absolutely include information about the binding between the VC and VP, or some fancy-crypto holder binding, or anything else that's needed or useful for verifying integrity and/or authorship of the VP.

[bumblefudge]

Over the years, I have actually heard about many different solutions (variously elegant) to what I have come to call the "VP Containing VCs With Different credentialSubjects Problem". I think an extension-registry for properties (or values of one property) in VP.proof would be a good scaffolding for broader interoperability-- however you solve the problem in your own system with only 1 or 2 DID methods and VC schemas is all well and good, but without a registry it's very hard to accept multi-credSubj VPs from other systems, no?

[bumblefudge]

This also seems relevant to #879 (even if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know about this!)

[OR13]

We support the holder as an object with an id member use case... its very useful when you want to provide a presentation over a name / address, etc... instead of just over a DID.

We've had a few conversations regarding this, here's the open issue tracking it:

https://github.com/w3c-ccg/traceability-vocab/issues/455

[decentralgabe]

I'm generally in favor of the idea, though I really dislike having OR types in a specification, it makes it really hard to implement properly in a number of programming languages.

It also encourages the any spec, which I refer to as a specification that is so broad, and flexible, that it really ends up defining little: multiple documents that vary wildly can still be 'compliant'. This causes implementation hell.

[bumblefudge]

I really dislike having OR types in a specification

Just spitballing here, but what about this upgrade path:

V1: holder = string V2: holder = string OR object, but string is deprecated V2 Implementation Guide: be warned that if holder is a string, some V2 implementations MAY infer/attribute an implicit id or type. V3: holder = object

makes V2 a little hellish to implement if you're working with production VCs and backwards compatibility issues, but way less hellish for the implementers coming on-board now?

[peacekeeper]

what about this upgrade path:

Whatever the decision is, I think the issuer in a VC and the holder in a VP should have the same rules, e.g. string / string OR object / object, etc.

[awoie]

since you said the VP proof is there for protecting against tampering and verifying the authorship of the VP (not the VC and not the binding between the VC and VP)

I think I said the opposite, i.e. that holder binding is part of "verifying the authorship", not orthogonal to it. In your initial message you also explain that in VPs with traditional signatures, holder binding is also done via the VP's proof, i.e. in cases when "the credentialSubject.id is the same as the holder property and the proof of the VP authenticates the holder".

Existing implementations of VP verification only verify the proof against the holder (if present). They don't verify vp.holder.id equals vc.credentialSubject.id which is fine since there is no normative reference in the W3C VC spec to do so. See here for example: https://github.com/digitalbazaar/vc-js/blob/f473944cb5261b0859457e234f8d22d1df41d269/lib/index.js#L428

A verifier application would need to ensure that vp.holder.id equals vc.credentialSubject.id after they verified the presentation. Note, there is currently no way to tell the verifier what binding was used. If the binding is not based on simple id matching, the verifier needs to guess the selected method. For that reason, I proposed the holderBinding property that allows the holder to indicate the chosen method in the VP, so the verifier can deterministically verify the selected binding method without having to guess or test different methods. IMO, this would also increase security by reducing side-effects.

With your proposal, wouldn't we then end up in an inconsistent situation where holder binding is sometimes established via the proof alone, and sometimes via the proof plus something else?

In my mind, the VP proof can be used very broadly and could absolutely include information about the binding between the VC and VP, or some fancy-crypto holder binding, or anything else that's needed or useful for verifying integrity and/or authorship of the VP.

Yes, I agree but it is a bit fuzzy and again limited. By introducing a new proof type it is just really hard to reuse existing Data Integrity Proofs such as Ed25519Signature2020, JwsSignature2020 etc. One cannot provide additional options to the proof method and expect they are going to be signed or integrity protected since the specific proof method defines what options are used/signed. Furthermore, what if someone wants to establish the binding through something that does not produce a cryptographic signature, e.g., by the evidence field. In that case, it would not count as a valid proof method since the proof method should also ensure data integrity.

The proof should ensure tamper-resistance and authorship. It does not ensure the binding between the VP proof and the VC. From the W3C VC Data Model 1.1 spec:

A verifiable presentation is a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification.

There is no normative reference in the spec how this can be done. Existing implementations don't implement that binding when verifying the VP. This is expected to be done by the verifier after verifying the VPs. By defining a canonical extension mechanism, SSI framework vendors can support those methods, and provide relying parties or verifiers a comfortable and secure way to verify presented VPs correspond to the included VCs.

Updated:

More references from the W3C VC Data Model 1.1 spec:

proof If present, the value of the proof property ensures that the presentation is verifiable. For details related to the use of this property, see Section 4.7 Proofs (Signatures).

on "verifiable" ...

verification The evaluation of whether a verifiable credential or verifiable presentation is an authentic and timely statement of the issuer or presenter, respectively. This includes checking that: the credential (or presentation) conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of claims encoded in the credential.

Then section 4.7 Proofs says ...

proof One or more cryptographic proofs that can be used to detect tampering and verify the authorship of a credential or presentation.

No reference that ensures binding between the holder of the VP and the VC. The authorship of a presentation is verifiable by verifying the proof of the VP against the holder property. No normative reference that anything else must be checked.

[awoie]

I'm generally in favor of the idea, though I really dislike having OR types in a specification, it makes it really hard to implement properly in a number of programming languages.

It also encourages the any spec, which I refer to as a specification that is so broad, and flexible, that it really ends up defining little: multiple documents that vary wildly can still be 'compliant'. This causes implementation hell.

I agree with that but I don't think we will be able to agree on one specific binding for all VP/VCs. vp.holder.id equals vc.credentialbSubject.id is just one method out of many. For example, ZKPs will definitely have different requirements. For that reason I was thinking an extension registry might be the best compromise.

[awoie]

I really dislike having OR types in a specification

Just spitballing here, but what about this upgrade path:

V1: holder = string V2: holder = string OR object, but string is deprecated V2 Implementation Guide: be warned that if holder is a string, some V2 implementations MAY infer/attribute an implicit id or type. V3: holder = object

makes V2 a little hellish to implement if you're working with production VCs and backwards compatibility issues, but way less hellish for the implementers coming on-board now?

Upgrade path might be the following...

1. If no holderBinding is present -> do exactly what you did before
2. If holderBinding is present -> verify binding according to type of the holderBinding after verifying the VP - VP verification just verifies the proof of the VP and the proof of the VCs individually but without verifying the correlation between them)
3. If holder being a String -> see 1.
4. If holder being an Object -> use holder.id and check if holderBinding is present, then do 1. or 2.

Note, there is still the very valid option that holder is completely unrelated to the subject in the VC. This should still be supported.

Also note, I'm also ok with defining a new top-level property for VPs which is not necessarily a sub-property of holder but I thought it would make semantically more sense to be included in the holder.

[bertvannuffelen]

Hi,

I tried to understand the proposed solutions, but maybe this one could also work, or it is a variant of the one being proposed.

---

E.g. lets agree for a VC implementation that the URI: https://system.com/agent/holder is the name for the holder of the credential. (This is called skolemization: one gives a name to a concrete item without knowing the real identity.)

Then

verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://system.example/credentials/1872",
    "type": ["VerifiableCredential"],
    "credentialSubject": {
      "id": "https://system.com/agent/holder"
      "hasValidDiploma" : "true"
    }
}],

represents the claim

<https://system.com/agent/holder> p:hasValidDiploma "true"^^xsd:boolean.

Using this agreement, the following exchange pattern can happen:

1. handshake about the holder's identity => both sender and receiver know the identity
2. exchange the diploma claim without explicit holder identity embedded

How the handshake happens, and if there is a requirement for a shared unique id between both I leave for that part. But lets assume that the receiver knows the identity as "Jane Doe" having as id in the recievers context <https://passportnr.country/2321>.

Then the receiving system processing the claim can replace the skolem with the real identity:

<https://passportnr.country/2321> p:hasValidDiploma "true"^^xsd:boolean.

and integrate that knowledge in the subsequent data exchanges.

---

If I am right, it might be a variant of one of the proposed solutions and the challenge is to know what is the agreed skolem representation. I am not sure, but is that not part a separate interaction (handshake as I called it) between sender and reciever? As consequence the VC model has not to be changed, only a handshake needs to be defined. And that could be considered beyond the VC spec?

[jose-gataca]

n if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know ab

Hi,

I think that part of the premise vp.holder.id equals vc.credentialSubject.id may be wrong. That may be true in most use cases, but we should consider the cases of Identity Delegation, in which the holder is not the subject of the credentials, but has been properly authorized by him to use them in his name.

In fact, I think the problem that should need to be solved would be vp.holder.id is accepted to represent vc.credentialSubject.id for which I am not sure if there are any proposed solutions: moreover considering that vp.holder.id and vc.credentialSubject.id may not be aliases of the same identity. I have read or heard from solutions that may make use of additional documents to the presentation, such as a Verifiable Consent or a Data Agreement, but nothing inside the W3C.

[samu-gataca]

Hi, In addition to that it's necessary to ensure the claims shared by any user belongs to him. Till now, I saw 3 different ways to do that:

1. The user has a unique DID (universal DID) and then all the credentials attached to him have the same DID (holder) so there is no problem to ensure you are the owner for that credentials, but it's a big privacy problem. Although, I heard it in some forums, I think this alternative was discarded by most of SSI players.
2. Trying to solve the problem of privacy, many SSI players offer the possibility to the user to have multiples "profiles" (DIDs) and for each of that profiles the user should get the credentials to be used, so for example, the user to get a driver license to be used with several of that profiles, needs to trigger a different issuance process for any of the profiles he wants to use. The reason is VCs can not be shared between profiles (DIDs). This is what is happening with the current data model.
3. The user should have a different DID for each VC he wants to have, so the relationship between DIDs and VCs is 1:1. This alternative from the privacy perspective is better than the other one, but the problem comes when the user wants to share multiple VCs with one relying party, the party needs to verify all that VCs belong to the same person.

As @awoie says with the current data model I did not see the solution to do this. As @jose-gataca says, we were working on Data Agreement specification (Also it's necessary by GDPR) and maybe it's something that could help to fix the problem.

I don't really like the idea of modifying the current data model, because it has a big impact on the current implementations, so in the current services too. Also, I don't like to allow multiple types for the same property, because it causes confusion and doubts.

Regards

[awoie]

n if that's backwards-looking and this is forward-looking, whoever works on that section of the Imp Guide should know ab

Hi,

I think that part of the premise vp.holder.id equals vc.credentialSubject.id may be wrong. That may be true in most use cases, but we should consider the cases of Identity Delegation, in which the holder is not the subject of the credentials, but has been properly authorized by him to use them in his name.

In fact, I think the problem that should need to be solved would be vp.holder.id is accepted to represent vc.credentialSubject.id for which I am not sure if there are any proposed solutions: moreover considering that vp.holder.id and vc.credentialSubject.id may not be aliases of the same identity. I have read or heard from solutions that may make use of additional documents to the presentation, such as a Verifiable Consent or a Data Agreement, but nothing inside the W3C.

Exactly, an extension mechanism like that would be able to achieve that through a dedicated holder binding method. Similar to different credential status methods exist, different holder binding methods can exist and one can be based on the delegation pattern you just described.

[awoie]

Hi, In addition to that it's necessary to ensure the claims shared by any user belongs to him. Till now, I saw 3 different ways to do that:

1. The user has a unique DID (universal DID) and then all the credentials attached to him have the same DID (holder) so there is no problem to ensure you are the owner for that credentials, but it's a big privacy problem. Although, I heard it in some forums, I think this alternative was discarded by most of SSI players.
2. Trying to solve the problem of privacy, many SSI players offer the possibility to the user to have multiples "profiles" (DIDs) and for each of that profiles the user should get the credentials to be used, so for example, the user to get a driver license to be used with several of that profiles, needs to trigger a different issuance process for any of the profiles he wants to use. The reason is VCs can not be shared between profiles (DIDs). This is what is happening with the current data model.
3. The user should have a different DID for each VC he wants to have, so the relationship between DIDs and VCs is 1:1. This alternative from the privacy perspective is better than the other one, but the problem comes when the user wants to share multiple VCs with one relying party, the party needs to verify all that VCs belong to the same person.

As @awoie says with the current data model I did not see the solution to do this. As @jose-gataca says, we were working on Data Agreement specification (Also it's necessary by GDPR) and maybe it's something that could help to fix the problem.

I don't really like the idea of modifying the current data model, because it has a big impact on the current implementations, so in the current services too. Also, I don't like to allow multiple types for the same property, because it causes confusion and doubts.

Regards

We could make the holder binding property a top-level property, so we won't need to change the holder property itself. This would be 100% backward compatible with existing VPs. Further, you demonstrated three options of how other people approach that and one how you would approach it (based on the data agreement specification). These could be all different types of bindings without changing your spec. If we don't provide a mechanism to allow the verifier to detect such a binding, we would not achieve interop either.

So, I agree with the observed options and there are even more if we consider ZKP-based VCs but I think something like a new property + extension mechanism is necessary for interop. Note, it won't invalidate existing VP/VC implementations, 100% backward compatible.

[peacekeeper]

vp.holder.id equals vc.credentialbSubject.id is just one method out of many.

I think @awoie 's explanations here in this thread are really good, so I wouldn't oppose adding some new construct if really needed.

Maybe the idea I mentioned earlier (using DID Resolution and checking alsoKnownAs, equivalentId, canonicalId) would also be "one method out of many" that could be specified as some kind of extension.

We could make the holder binding property a top-level property, so we won't need to change the holder property itself.

I would support aligning the "holder" property with the "issuer" property in any case, irrespective of what the decision is here about holder binding.

[alenhorvat]

We have a VC with a vc.credentialSubject.id = "did:example:1", and a VP that has a vp.holder = "did:example:2" containing the VC. The proof of the VP was made by did:example:2#key-1. Further, let's assume there is a relationship between did:example:1 and did:example:2 in form of a VC that says, both are essentially the same (I know this is a bit sloppy). Even if I included those relationship-VCs in the VP, the verifier would be able to verify authorship and detect tampering, but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC.

Who asserts the relationship between "did:1" and "did:2" in the additional VC? Is the relation deterministic, cryptographic, other?

Can you describe a case where you cannot achieve the same by including a VC that expresses the relationship between the 2 DIDs? Mandates/delegation are a typical case and you can issue a VC expressing the relationship. Same goes if you'd like to introduce key certificates or key rotation without using a VDR.

Is the VP the right place to express the holder binding and is the holder the one who should do it? Namely, the holder binding is asserted and guaranteed by the issuer (you're identified -> you get your VCs).

Questions, that should be answered are

• Who can assert the relation? (Issuer, Wallet provider?)
• Is sharing 2 (or more) proofs in an authenticated session sufficient to ensure holder binding?

We also need to distinguish between VCs that can be used for identification or authentication and attestations. Usually, you'll authenticate with an RP and you'll share your attestations within an authenticated session.

[awoie]

We have a VC with a vc.credentialSubject.id = "did:example:1", and a VP that has a vp.holder = "did:example:2" containing the VC. The proof of the VP was made by did:example:2#key-1. Further, let's assume there is a relationship between did:example:1 and did:example:2 in form of a VC that says, both are essentially the same (I know this is a bit sloppy). Even if I included those relationship-VCs in the VP, the verifier would be able to verify authorship and detect tampering, but they won't be able to verify whether the holder is the legitimate holder of the VC because they don't know how this can be done based on the given VC.

Who asserts the relationship between "did:1" and "did:2" in the additional VC? Is the relation deterministic, cryptographic, other?

The idea is to make this mechanism flexible. I submitted a paper to RWOT that allows the issuer and/or the holder to describe the type of binding they may wish to communicate to the verifier. The type of binding describes how to verify the binding between the holder, the VCs and the VP. Further, that binding can be provided in the VC and/or the VP. This allows the issuer to define the a set of allowed bindings to ensure certain assurance levels.

If somebody is interested in the RWOT paper: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/advance-readings/verifiable-credentials-holder-binding.md

Can you describe a case where you cannot achieve the same by including a VC that expresses the relationship between the 2 DIDs? Mandates/delegation are a typical case and you can issue a VC expressing the relationship. Same goes if you'd like to introduce key certificates or key rotation without using a VDR.

If you are dealing with VCs that don't have a subject.id for example or if the binding is established by some out-of-band mechanism (e.g., a signed agreement). Other examples (biometrics, capability objects, DID-based binding) are described in the RWOT paper which I mentioned above.

Is the VP the right place to express the holder binding and is the holder the one who should do it? Namely, the holder binding is asserted and guaranteed by the issuer (you're identified -> you get your VCs).

I agree that I see value to allow the issuer to define the binding in the VC itself. IMO, it can be done in the VP and/or the VC (see above). Also note that VP does have some ambiguities in the W3C VC Data Model 1.1 spec.

Questions, that should be answered are

• Who can assert the relation? (Issuer, Wallet provider?)

IMO, depends on the use case. If the issuer wants to limit, then they should define the binding in the VC (see paper above). IMO, if we define such a mechanism, all those cases should be possible.

• Is sharing 2 (or more) proofs in an authenticated session sufficient to ensure holder binding?

I agree. The way I think about it is that the holder can include an array of holderBinding objects that each describe how to verify the binding for a set of VCs in the verifiableCredentials property (if desired).

We also need to distinguish between VCs that can be used for identification or authentication and attestations. Usually, you'll authenticate with an RP and you'll share your attestations within an authenticated session.

Yes, that is possible but sharing the VCs in the authenticated session doesn't solve the holder binding issue. The user could have an authenticated session that uses again an identifier (e.g., client TLS certs) which is different from the presented VCs or the VCs don't have an identifier at all. The W3C VC Data Model 1.1 spec allows anybody to present VCs. There is no mechanism in the data model to allow the user (wallet) to say, "this VP contains VCs where I claim that the issuer made claims about myself, or the identifier in the authenticated session, and this is the mechanism you can verify this binding".

[awoie]

@alenhorvat The holderBinding property would solve the following:

• allowing the holder to explicitly tell the verifier that the VP contains VCs where the holder claims the issuer made those claims about the holder. This enables the holder to use no identifier, or a different identifier.
• allowing the holder to tell the verifier how to verify the binding between the holder and the VCs. This solves the problem of guessing which mechanism was used. The holderBinding should not prescribe one specific way how to do it. I acknowledge that there can be different ways how implementers want to do it (out-of-band agreements, DID-based, VC-based, biometrics, delegation object-based etc.). I believe this could be solved through a holderBinding type registry where each type defines how to identify which holderBinding entry corresponds to the entries in the verifiableCredentials array.
• allowing the issuer to limit the way how a holder can prove the binding between the VCs and the holder to maintain assurance levels. I know that this relates a bit to the termsOfUse property but termsOfUse is very general purpose and I believe the problem is different, specific and common enough to justify a new property.

[agropper]

@awoie's proposal advances our discussion and contributes the useful concept of VC issuers constraining the ways the VC might be presented. Allow me to try and continue this conversation without using the H-word.

A presentation of a VC (or VCs) is a request to the Verifier. Aside from privacy risks on the requesting party, the request imposes processing costs and liability on the Verifier. The Verifier can reduce their processing cost through automated policy evaluation and their liability through keeping the requesting party accountable. For example, a verifier might delegate policy evaluation and non-repudiable identification of the requesting party to a Notary Public.

A User-Centric Request Model is arguably a more general way to consider presentation of VCs because it reduces the Verifier's transaction cost and risk by holding the requesting party (the user in User-Centric Request) accountable for the scope and purpose of their request. In other words, policy evaluation is not only about the intent of the Issuer that @awoie has captured but also the intent of the requesting party.

My RWoT paper proposes this more general way of considering presentations. VCs are just resources available to the requesting party. The VC might be public, as in a medical license. The VC might be "held" in a controlled registry such as a credit bureau. The VC could be controlled by the requesting employer such as a hospital information system. The VC could be part of a biometric chain-of-custody scheme such as a pet's RFID or a biometric secure element such as my iPhone wallet.

Along with VCs, scope, and purpose, policy evaluation for a request could choose to require a non-repudiable signature on the request in order to further reduce the verifier's liability.

My point is that VCs will be more useable and more useful if we abandon the Holder concept in favor of two identities: Subject and User.

[David-Chadwick]

Just a passing thought. We have a type property for the VP. Currently no types other than VerifiablePresentation are defined. We could define different types of VP that say how the VP holder is bound to the VC subjects. So one type could be "holder_is_subject". Another could be "subject_delegated_to_holder". If the VP contains multiple VCs with different bindings then the VP would have multiple types added to the set. In this way the data model is not altered.

[OR13]

We extend VerifiablePresentation as TraceablePresentation specifically to allow for correlation in a B2B setting, see: https://w3c-ccg.github.io/traceability-vocab/#workflow-definition

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/traceability/v1"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type":
  [
    "VerifiablePresentation",
    "TraceablePresentation"
  ],
  "workflow": {
    "definition": [
      "urn:uuid:n1552885-cc91-4bb3-91f1-5466a0be084e" 
    ],
    "instance": [
      "urn:uuid:f5fb6ce4-b0b1-41b8-89b0-331ni58b7ee0"
    ],
  },
  "holder":{
    "id":"did:web:sender.example",
    "type":"Organization",
    "location":{
       "type":"Place",
       "geo":{
          "type":"GeoCoordinates",
          "latitude":"68.7083",
          "longitude":"4.6377"
       },
       "address":{
          "type":"PostalAddress",
          "organizationName":"Ratke - Bergstrom",
          "streetAddress":"21851 Ima Heights",
          "addressLocality":"O'Connellborough",
          "addressRegion":"Missouri",
          "postalCode":"65587",
          "addressCountry":"Cyprus"
       }
    }
 }
}

[agropper]

Aren't all of these suggestions variations on how to describe delegation in an interoperable (as in cost-effective and secure) way? If so, wouldn't it make sense to specify delegation in the request context rather than just presentation? As @awoie suggests, the Issuer MAY choose to restrict the flexibility of a presentation but the Subject and their delegates also need the ability to attenuate the components of a request that includes that VC.

On Tue, Aug 9, 2022 at 4:31 PM Orie Steele @.***> wrote:

We extend VerifiablePresentation as TraceablePresentation specifically to allow for correlation in a B2B setting, see: https://w3c-ccg.github.io/traceability-vocab/#workflow-definition

— Reply to this email directly, view it on GitHub https://github.com/w3c/vc-data-model/issues/882#issuecomment-1209844050, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABB4YK6RTZ4JZYYWAQUJMTVYK53BANCNFSM5ZQKIELQ . You are receiving this because you commented.Message ID: @.***>