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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

If no holderBinding is present -> do exactly what you did before
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)
If holder being a String -> see 1.
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 commented 2 years ago

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:

handshake about the holder's identity => both sender and receiver know the identity
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 commented 2 years ago

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 commented 2 years ago

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:

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.
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.
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 commented 2 years ago

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 commented 2 years ago

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:

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.

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.

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

peacekeeper commented 1 year ago

I wonder if this issue is the same as https://github.com/w3c/vc-data-model/issues/789.

iherman commented 1 year ago

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.

iherman commented 1 year ago

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.

nikosft commented 1 year ago

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"
       }
    }
 }
}

This is very interesting @OR13 I was wondering how do you use the information in the holder object to verify that the holder is indeed a legitimate holder of the VC(s) included in the corresponding VP. Do you use out of band rules? Another mechanism?

OR13 commented 1 year ago

In the case where there is no proof we rely on the channel authentication for the holder... thats the sub in an access token from OAuth client credentials flow, typically used in M2M use cases:

https://auth0.com/blog/using-m2m-authorization/

iherman commented 1 year ago

The issue was discussed in a meeting on 2023-01-18

no resolutions were taken

View the transcript

#### 4.3. 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 (issue vc-data-model#882) _See github issue [vc-data-model#882](https://github.com/w3c/vc-data-model/issues/882)._ **Kristina Yasuda:** next issue, extension methods for holder binding.... **Orie Steele:** We have a series of holder binding related issues.... … We had previously agreed to have a special topic call to discuss them, I'm in favor of grouping them together and discussing them. I also feel that it's possible that there isn't anything underneath them. I have yet to hear/see something concrete on this front. I've heard people say they're working on it.. > *Dave Longley:* +1 to Orie... seems like we need external incubation based on specific use cases.. **Orie Steele:** Given it has substantial security/privacy implications, so if this comes up as we're transitioning to the next stage, I will most likely to be opposed to it. Because of the security implications of it, it's dangerous to allow this to loom around.. … I don't think we should allow this to float around in our backlog, we need to address it.. **Manu Sporny:** +1 to what orie says above.. **Kristina Yasuda:** the next steps were specific use cases, we have yet to receive them. … we should group them, and action on them as a whole. … we are parking this issue until use case or special topic call..

awoie commented 1 year ago

Update:

RWOT Holder Binding group finished their paper and will be published soon.
I'm working on updating the W3C VC use case doc based on input from people from the eIDAS 2.0 group where holder binding (holder authentication) will be also a requirement.
ISO 23220-4 (aka the mdoc standard) will also have a holder binding / holder authentication / holder confirmation binding feature, so not including this in the W3C VC standard would clearly be a mistake since a lot of companies seem to have the need for that.

agropper commented 1 year ago

The strategy of using holder binding for both supply chain and human credentials is unnecessarily risky because human credentials are often biometric and supply chain. credentials are not. Simply put, humans will resist being barcoded like a thing or tied to a wallet like a convict.

In the context of the Open Wallet Foundation, I presented a candidate proposal that derives how to use DIDs and VCs on the basis of the human right to free association. Because that group requires sign-in, here is the gdoc https://docs.google.com/document/d/11RNM74vIyNVqv_siwBm5mBELX3RoQ3nuzLGWxM3f7Lk/edit open for comments.

and the full text if you prefer to comment here:

Open Wallet Candidate 1

Adrian Gropper

OWF Candidate 1 is based on the human rights freedom of association principle and places the right to choose one’s agent at the core of the standards stack.

a. From a wallet perspective, there are two places where choice of agent is in play and standards are most relevant: cloud agent and biometric agent. A cloud agent is obviously never biometric. A biometric agent may be off-grid. Both agents can hold and present digital credentials. Only the biometric agent can do a non-repudiable signature.

b. Local biometrics are encouraged for convenience as well as security. By design, biometrics are never assumed to be stored other than locally.

c. Biometrics are treated as public because they can be collected and used without consent. Candidate 1 does not assume any particular regulation of biometrics. When a service provider wants to store a persistent human identifier, they should use a public key or DID with the corresponding private key or DID controller managed via either a cloud or biometric agent.

d. Digital credentials may be requested, held, and presented by either a cloud or biometric agent. The issuer of a digital credential should not assume that a credential is held in a biometric agent because that would be equivalent to implanting a chip or placing an ankle bracelet. The choice of whether to hold a credential in a cloud or biometric agent or both is left to the subject. Credentials can be backed up.

e. Issue or presentation of digital credentials may require biometric verification. If the credential does not include a biometric it can include a public key or DID linked to a biometric. It is assumed that supervised biometrics are good enough to non-repudiably identify a person. This may require a combination of multiple biometrics and well-known templates. Supervised biometrics may be different from the local biometrics of a personal agent.

f. Candidate 1 recognizes that consent is burdensome to individuals and allows individuals to delegate consent to agents and fiduciaries that they choose. Issuance and presentation requests are made to the cloud or biometric agent of the responsible entity or and should include:

-

scope of credentials or resources requested

purpose of the request

a payment or deposit to offset the cost of agent processing

credentials of the requesting party

a digital signature of the requesting party to hold them accountable

A QR code or URI may be used to point the issuer or verifier of a credential to the agent of an entity.

g. Candidate 1 recommends that the protocol for requesting a credential be the same as the protocol for requesting any other protected resource. This adds potential value to both cloud and biometric agents and makes it more likely to result in a vibrant and efficient market for people to choose their agents, including agents with significant machine learning and artificial intelligence capabilities. IETF GNAP is recommended as the credential and resource request protocol for both cloud and biometric agents.

Adrian

On Wed, Jan 25, 2023 at 10:15 AM Oliver Terbu @.***> wrote:

Update:

RWOT Holder Binding group finished their paper and will be published soon.

I'm working on updating the W3C VC use case doc based on input from people from the eIDAS 2.0 group where holder binding (holder authentication) will be also a requirement.

ISO 23220-4 (aka the mdoc standard) will also have a holder binding / holder authentication / holder confirmation binding feature, so not including this in the W3C VC standard would clearly be a mistake since a lot of companies seem to have the need for that.

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

TallTed commented 1 year ago

Only the biometric agent can do a non-repudiable signature.

Why can a cloud agent not be equipped with a public/private key pair, and substitute its mechanimetrics for the human's biometrics, and use those to produce non-repudiable signatures on its outputs?

I can't see that such outputs would be any more insecurely produced than similar outputs from biometric agents...

agropper commented 1 year ago

Good question. It depends on how you think about holding private keys in the cloud and decentralization. The experience with Intel SGX is my only reference point for holding private keys and secure computation in the cloud. It’s a mixed bag and centralized in the sense that Intel holds some keys. https://en.wikipedia.org/wiki/Software_Guard_Extensions

Then, we have the issue of certification of the biometric secure element. We would prefer to avoid certification as much as possible. I can compile my biometric secure element user agent from source and use it with a public template. An issuer or verifier can also compile their biometric secure element from source and use the same public template. No certification of the hardware is required as long as both use the same template to come up with the same biometric identifier. This is truly decentralized because no certification of either the issuer / verifier or subject’s agent is necessary.

Therefore, a supervised biometric done by an issuer’s or verifier’s agent hardware would come up with the same biometric identifier as equivalent hardware used by the subject of the credential.

The goal is to discourage centralized biometric registries like the FBI fingerprint database as much as possible. It’s likely impossible to keep law enforcement from keeping these, but it’s reasonable to expect everyone else that wants to keep centralized identity registries to use a DID created by the subject’s biometric secure agent. To paraphrase DHS “We want subjects to bring their own DIDs.” Any context that would otherwise keep a centralized biometric registry in order to avoid Sybil attacks would then post a context identifier that a subject could use along with their own biometric secure element to create a context-specific DID linked to the biometric. In this way, centralized deduplication registries would be context-specific and much more privacy-preserving.

Back to Ted’s original question, my point is not to try and convince anyone that secure cloud agents can never replace supervised and local hardware for both the issuer/verifier (the real sovereigns :-) and the subject. My point is to show that personal agency, both cloud and in-person, can protect the human right of free association (or avoid forced association) in a way that other current proposals do not.

Adrian

On Wed, Jan 25, 2023 at 8:08 PM Ted Thibodeau Jr @.***> wrote:

Only the biometric agent can do a non-repudiable signature.

Why can a cloud agent not be equipped with a public/private key pair, and substitute its mechanimetrics for the human's biometrics, and use those to produce non-repudiable signatures on its outputs?

I can't see that such outputs would be any more insecurely produced than similar outputs from biometric agents...

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

Sakurann commented 1 year ago

agreed during miami F2F

awoie commented 1 year ago

PR #1054 is pending, so may be fixed by #1054.

awoie commented 1 year ago

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

awoie commented 1 year ago

@swcurran @paulbastian It seems that certain WG members objected to including confirmationMethod (confidenceMethod) in the VCDM core. It will become a reserved term in the VCDM without a normative definition. I suggest we ask W3C CCG to adopt the current confidenceMethod proposal and close this issue. @swcurran would you be fine with that approach?

swcurran commented 1 year ago

I don’t understand exactly what you mean by your comment above @awoie nor what @brentzundel means in this comment on the related PR #1054.

@awoie — Do you mean that the plan is that because of the objections the PR #1504 will not be merged, but confi*Method will be reserved, with a separate W3C CCG spec created solely for that?

@brentzundel — when you say “in favour of another path forward” — it would be helpful to say what that other path is. I think you are referencing @mprorock’s idea of “put it somewhere else”? Is that correct?

As I’m not a member of the VCWG and I’ve not been at the meetings covering this topic, my input is of little value — especially at this point in the process. I stand by my belief (see #789 ) that without such a capability, the issue will be addressed in multiple ways by different groups. The issue is core to many use cases, it has to be solved. Its just a question of how many ways will it be solved, and how difficult will it be for holders and verifiers.

OR13 commented 1 year ago

I objected.

Holder binding is already solved for many different ways... Adding JSON-LD vocabulary and terms to w3id.org won't change that...

Nor will reserving terms in the core data model, without defining any concrete testable RDF classes.

Nor will exposing holder binding for Data Integrity Proofs, JWTs, Gordion knots, ACDCs, anon creds, COSE sign1s or mdocs... Different formats will handle security details differently, the core data model is not a place to do security work.

It leads to confusing, and dangerous mappings between the base cryptographic layers and semantic / RDF data model.

I suggest the work be incubated and tested concretely in community groups as data integrity proofs were for years.

When there is sufficient interoperable implementation to justify standardization and working group interest and expertise to do a good job, then the work should be picked up.

Verifiable presentations remain extremely poorly defined... Perhaps now we can focus on fixing the flaws in the existing data model instead of introducing more experimental terminology to an already very weak draft.

swcurran commented 1 year ago

Reasonable arguments, @OR13, thanks. Unfortunate that we can’t build a solution on a common base. It will be solved elsewhere.

OR13 commented 1 year ago

Unfortunate that we can’t build a solution on a common base. It will be solved elsewhere.

+1 to this, I think this suggests that Verifiable Presentations may need to be updated, or removed from the TR.

We should focus on fixing that first.

jandrieu commented 1 year ago

Verifiable presentations remain extremely poorly defined... Perhaps now we can focus on fixing the flaws in the existing data model instead of introducing more experimental terminology to an already very weak draft.

@OR13 I agree with the poor definition. That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

VPs exist because we needed a vehicle to capture the semantics of presentation--the act of presenting your credentials is itself a legally cognizable act, hence deserving of clarification of intention.

At the time of definition, it was accepted that DIDs and DID Auth provided a coherent strategy for cryptographic proof that the presenter is in control of secrets only the subject is expected to have.

That simplistic perspective hasn't held up. Its clear that if any URI can be a subject identifier, then we need a more flexible way to gain confidence that the presenter is the subject.

The solution that is emerging here is two fold.

predicates that allow the issuer to provide guidance for how a verifier my increase their confidence
predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

The first is addressed by confidenceMethod as discussed in #1054

The second is discussed in issue #860.

If you want to "fix" VPs, I invite you to start with supporting confidenceMethod and issue #860.

agropper commented 1 year ago

Just because the request for and presentation of credentials are legally recognizable acts does not mean that they should be standardized as part of SSI.

w3c / vc-data-model