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

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

@jandrieu

That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it.

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.

This is great example of how adding semantics doesn't add security.

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.

And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right.

I do agree that "DID Auth" could solve for this, but where is that documented?

it could be in the core data model (its not)
it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes
it could be in sd-jwt (it is)
it could be in (your fancy new security format for vc+ld+json) (it can be).

If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus.

Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist).

See this SD-JWT PR which discusses this concept in greater detail: https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/246

This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help.

Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood.

That simplistic perspective hasn't held up. It's 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.

I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link.

I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively.

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

Like "credentialSubject.id" ? (half a solution, see the current draft)

predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model)

Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity.

@agropper

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.

+1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this.

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.

I would be +1 removing it from the spec since it is completely underspecified and leads to confusion.

I would oppose removing Verifiable Presentations without the addition of language that makes clear the difference between a VC sent from and issuer to a holder and a VC sent from a holder to a verifier.

Also, perhaps this proposal should exist as its own issue.

It is also not clear to me that a proposal to remove verifiable presentations wouldn't be considered new work, i.e., it may fall afoul of our current feature-freeze status.

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

@jandrieu

That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it.

On the contrary, I believe you are conflating security with identity. This is an identity assurance question, not a security one.

Where do you see "theater" in the issuer and verifier having mechanisms to increase the confidence in recognizing the current presenter as a legitimate presenter given the use case? All of the data used for semantic evaluation is secured so I'm not seeing the disconnect you are.

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.

This is great example of how adding semantics doesn't add security.

Why would it? This isn't a security question. It's an identity assurance question.

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.

And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right.

Yes. That was the point of my explanation. VPs with DID Auth performed a limited but critical function in an obscure and poorly documented mechanism. What we need to do is to clarify that function with clear and rigorously documented mechanism.

I do agree that "DID Auth" could solve for this, but where is that documented?

It's currently documented in two places.

https://www.w3.org/TR/vc-data-model/#subject-is-the-holder which was apparently removed in a fit of minimalism.
https://w3c-ccg.github.io/vp-request-spec/#did-authentication in the Verifiable Presentation Request specification

it could be in the core data model (its not)

Yes. Because you fought it. It is there in the current publication https://www.w3.org/TR/vc-data-model/#subject-is-the-holder . I posit that the problems with that section aren't addressed by removing it.

it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes

No, it can't. This is not an integrity mechanism. It has nothing to do with the tamper-evidence of the digital object. It has to do with mechanisms for assuring the verifier that the VC is being used by an appropriate party.

it could be in sd-jwt (it is)

The mechanism in sd-jwt appears to be limited to "Proving control over the same private key during the issuance and presentation". I agree that's functionally equivalent to DID Auth (ignoring that there's no way for a holder in SD-JWT to rotate their keys).

In fact, SD-JWT_RELEASE is functioning as a Verifiable Presentation, which supports my argument that the problem isn't that VPs are bad, it's that they need better definition.

it could be in (your fancy new security format for vc+ld+json) (it can be).

It's not a security format. It's an identity assurance mechanism. It's not a fancy new anything. It's two properties that allow issuers and holders to make statements that help verifiers apply their own business rules to determine if the VP and VCs presented are fit for their purpose.

If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus.

I don't follow your argument (even to disagree with it).

Proof purpose is about the reason a particular signature is applied. It is restricted to a few limited purposes: attestation, authentication, key agreement, capability invocation, and capability delegation.

What we need is a way, for example, for the citizenship applicant in Citizenship by Parentage to express arbitrary statements about why they are presenting the claims in the VP. Proof purpose can't explain:

the assertions that —

He is the child in the birth certificate.

The mother in the birth certificate, the person in the passport, the spouse in the marriage license are all the same person.

Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist).

Sure. But that's the obscure, undocumented, and incomplete way to thing about identity assurance, which is documented in the current published spec as non-normative text. This conversation is about trying to draft normative text that is neither obscure nor incomplete. You're approach ignores the situations where the issuer wants to enable assurance mechanisms other than DID Auth.

See this SD-JWT PR which discusses this concept in greater detail: oauth-wg/oauth-selective-disclosure-jwt#246

Not sure what you wanted me to read in that. It's already been merged and I just read the current draft to respond to your earlier comments.

This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help.

If you mean SD-JWT-RELEASE, then ok. I can't speak to whether or not anyone has demonstrated interoperability.

However, if you mean DID auth and VPs, that is incorrect. The JFF plugfest has demonstrated plenty of interoperability for DID Auth used in exactly this manner.

Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood.

DID Auth is a solved problem with demonstrated interoperability as defined and used in the Verifiable Presentation Request specification. What we haven't done is map that functionality to the newly proposed, generic confidenceMethod. This is work in progress, just like the SD-JWT-RELEASE you're working on elsewhere.
Please make your case for why these two mechanisms for identity assurance harms security. It is not a security function. It seems to me that the theatrics are about the over use most attempts to bind security and identity,

That simplistic perspective hasn't held up. It's 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.

I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link.

No. They haven't. Data integrity doesn't have the semantics of "why" at the level of claim evaluation. It only has the "why" at the level of the signature. It's per the spec that we can use any URI for a subject identifier, but the only assurance mechanisms on the table right now are either DIDs (with DID Auth) or public keys (with SD-JWT-RELEASE).

I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively.

No. @awoie's confidenceMethod and issue #860. Something for the verifier to express their intention and something for the holder to express their intention, both of which are signed over by respective cryptography.

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

Like "credentialSubject.id" ? (half a solution, see the current draft)

No. That only identifies the subject. It does not, on its own, define any mechanism for convincing the verifier that the presenter is the party intended by the issuer.

DIDs have a built-in authentication affordance. No other URIs have that.

So, we really have two choices here:

Restrict credentialSubject.id to DIDs
Enable issuers to add assurance mechanisms they advocate for evaluating the presenter's claims of legitimate use.

predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model)

No. As mentioned above, proofPurpose only refers to the purpose of the cryptographic proof. It does not explain the purpose of why the claims are presented in the first place.

Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity.

This isn't about proofs. And it isn't about security.

I think this highlights the core disconnect between the JWT advocates and the JSON-LD folks. The JWT sensbility is that keys secure data. Done. That's a fine mechanism in a two party interaction, where you already know who the signing party is and why the JWT was issued, because you are either the issuer or the recipient.

However, in a three party model, I have to deal with the semantics of the situation as a different matter. There is no gauranteed, privacy respecting mechanism to ensure that the actual entity on the other side of a transaction is, in fact, RIGHT NOW, the entity is the one you imagine. Full stop. All we can ever do is evaluate available data to establish a high enough confidence level that the current presenter is, in fact, a legitimate presenter.

That legitimacy depends on

What the issuer intended (especially wrt identifying the subject)
What the holder intended (especially wrt the relating themselves to the claims in the presented VCs)
What the verifier requires (especially what mechanisms would satisfy their need for confidence in the presenter's identity)

#3 is an internal matter for the verifier and belongs in neither the VC nor the VP. For #1 and #2, we have the two mechanisms already proposed.

@agropper

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.

+1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this.

We aren't here to "standardize SSI". We're here to work on a specific specification that enables aspects of SSI.

It seems to me that implementers can choose to use VCs with total disregard for VPs. For example, we’re using VCs in a user-centric request model where the presentation protocol is GNAP.

Issuers can deliver VCs to anyone based on GNAP requests. Verifiers can process GNAP requests that include one or more VCs along with purpose and accountability components.

What am I missing?

On Tue, Jun 6, 2023 at 6:14 PM Joe Andrieu @.***> wrote:

@jandrieu https://github.com/jandrieu

That's what confidenceMethod is addressing, but you oppose including that in the VCDM.

Because it's not actually addressing it, its security theater that harms users... It just looks like a solution because its JSON-LD with paragraphs of text around it.

On the contrary, I believe you are conflating security with identity. This is an identity assurance question, not a security one.

Where do you see "theater" in the issuer and verifier having mechanisms to increase the confidence in recognizing the current presenter as a legitimate presenter given the use case? All of the data used for semantic evaluation is secured so I'm not seeing the disconnect you are.

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.

This is great example of how adding semantics doesn't add security.

Why would it? This isn't a security question. It's an identity assurance question.

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.

And now? Seems like we have some spec updating too do... Also, IIRC, DIDs were never a requirement for VCs so this does not sit right.

Yes. That was the point of my explanation. VPs with DID Auth performed a limited but critical function in an obscure and poorly documented mechanism. What we need to do is to clarify that function with clear and rigorously documented mechanism.

I do agree that "DID Auth" could solve for this, but where is that documented?

It's currently documented in two places.

https://www.w3.org/TR/vc-data-model/#subject-is-the-holder which was apparently removed in a fit of minimalism.

https://w3c-ccg.github.io/vp-request-spec/#did-authentication in the Verifiable Presentation Request specification

it could be in the core data model (its not)

Yes. Because you fought it. It is there in the current publication https://www.w3.org/TR/vc-data-model/#subject-is-the-holder . I posit that the problems with that section aren't addressed by removing it.

it could be in data integrity proofs and related to the "authentication proof purpose". (it is) - https://www.w3.org/TR/vc-data-integrity/#proof-purposes

No, it can't. This is not an integrity mechanism. It has nothing to do with the tamper-evidence of the digital object. It has to do with mechanisms for assuring the verifier that the VC is being used by an appropriate party.

it could be in sd-jwt (it is)

The mechanism in sd-jwt appears to be limited to "Proving control over the same private key during the issuance and presentation". I agree that's functionally equivalent to DID Auth (ignoring that there's no way for a holder in SD-JWT to rotate their keys).

In fact, SD-JWT_RELEASE is functioning as a Verifiable Presentation, which supports my argument that the problem isn't that VPs are bad, it's that they need better definition.

it could be in (your fancy new security format for vc+ld+json) (it can be).

It's not a security format. It's an identity assurance mechanism. It's not a fancy new anything. It's two properties that allow issuers and holders to make statements that help verifiers apply their own business rules to determine if the VP and VCs presented are fit for their purpose.

If the argument is, we need to add proof purposes too did core to enable DID Auth, and define proof normatively in order to enable holder binding... seems like we don't need confidenceMethod... and that we could do that in the core spec, with consensus.

I don't follow your argument (even to disagree with it).

Proof purpose is about the reason a particular signature is applied. It is restricted to a few limited purposes: attestation, authentication, key agreement, capability invocation, and capability delegation.

What we need is a way, for example, for the citizenship applicant in Citizenship by Parentage https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage to express arbitrary statements about why they are presenting the claims in the VP. Proof purpose can't explain:

the assertions that —

He is the child in the birth certificate.

The mother in the birth certificate, the person in the passport, the spouse in the marriage license are all the same person.

Just to spell it out... if the issuer didn't want to ENABLE the holder to use "DID Auth" for certain VERIFIERS.... they would not issue credentials to a DID, or bind the credentialSubject to a particular public key (in any number of the 1000 key formats that exist).

Sure. But that's the obscure, undocumented, and incomplete way to thing about identity assurance, which is documented in the current published spec as non-normative text. This conversation is about trying to draft normative text that is neither obscure nor incomplete. You're approach ignores the situations where the issuer wants to enable assurance mechanisms other than DID Auth.

See this SD-JWT PR which discusses this concept in greater detail: oauth-wg/oauth-selective-disclosure-jwt#246 https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/246

Not sure what you wanted me to read in that. It's already been merged and I just read the current draft to respond to your earlier comments.

This is the simplest form of holder binding, and we have still not demonstrated ANY interoperability on it... Adding more complexity will not help.

If you mean SD-JWT-RELEASE, then ok. I can't speak to whether or not anyone has demonstrated interoperability.

However, if you mean DID auth and VPs, that is incorrect. The JFF plugfest has demonstrated plenty of interoperability for DID Auth used in exactly this manner.

Let's see the community solve this problem and bring us demonstrated interoperability before we grant a reserved property that nobody is required to understand, and that harms security when not understood.

DID Auth is a solved problem with demonstrated interoperability as defined and used in the Verifiable Presentation Request specification. What we haven't done is map that functionality to the newly proposed, generic confidenceMethod. This is work in progress, just like the SD-JWT-RELEASE you're working on elsewhere.

Please make your case for why these two mechanisms for identity assurance harms security. It is not a security function. It seems to me that the theatrics are about the over use most attempts to bind security and identity,

That simplistic perspective hasn't held up. It's 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.

I'm not sure I agree with this, I can see data integrity proofs have this solved already, see above link.

No. They haven't. Data integrity doesn't have the semantics of "why" at the level of claim evaluation. It only has the "why" at the level of the signature. It's per the spec that we can use any URI for a subject identifier, but the only assurance mechanisms on the table right now are either DIDs (with DID Auth) or public keys (with SD-JWT-RELEASE).

I'm not sure, but its possible you are wanting "evidence" with "proofPurpose", that could also be made clearer... in the spec that defines proofPurpose normatively.

No. @awoie https://github.com/awoie's confidenceMethod and issue #860 https://github.com/w3c/vc-data-model/issues/860. Something for the verifier to express their intention and something for the holder to express their intention, both of which are signed over by respective cryptography.

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

Like "credentialSubject.id" ? (half a solution, see the current draft)

No. That only identifies the subject. It does not, on its own, define any mechanism for convincing the verifier that the presenter is the party intended by the issuer.

DIDs have a built-in authentication affordance. No other URIs have that.

So, we really have two choices here:

Restrict credentialSubject.id to DIDs

Enable issuers to add assurance mechanisms they advocate for evaluating the presenter's claims of legitimate use.

predicates that allow the holder to provide assertions that enable a verifier to understand why they are presenting those claims.

Like "proofPurpose" ? (not a solution since proofPurpose is not normatively defined properly in the core data model)

No. As mentioned above, proofPurpose only refers to the purpose of the cryptographic proof. It does not explain the purpose of why the claims are presented in the first place.

Let's fix proof before spending any more time on "extensions", proof is already an "extension" that causes security problems when not understood properly.... and it has quasi normative status in the vc data model and normative status in data integrity.

This isn't about proofs. And it isn't about security.

I think this highlights the core disconnect between the JWT advocates and the JSON-LD folks. The JWT sensbility is that keys secure data. Done. That's a fine mechanism in a two party interaction, where you already know who the signing party is and why the JWT was issued, because you are either the issuer or the recipient.

However, in a three party model, I have to deal with the semantics of the situation as a different matter. There is no gauranteed, privacy respecting mechanism to ensure that the actual entity on the other side of a transaction is, in fact, RIGHT NOW, the entity is the one you imagine. Full stop. All we can ever do is evaluate available data to establish a high enough confidence level that the current presenter is, in fact, a legitimate presenter.

That legitimacy depends on

What the issuer intended (especially wrt identifying the subject)

What the holder intended (especially wrt the relating themselves to the claims in the presented VCs)

What the verifier requires (especially what mechanisms would satisfy their need for confidence in the presenter's identity)

3 is an internal matter for the verifier and belongs in neither the VC

nor the VP. For #1 and #2,

@agropper https://github.com/agropper

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.

+1 to this... and that is exactly what the working group was trying to do... Legal requirements in JSON-LD... instead of cryptographic requirements, in a securing format... See Data Integrity & SD-JWT drafts for the right way to handle this.

We aren't here to "standardize SSI". We're here to work on a specific specification that enables aspects of SSI.

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

What am I missing?

Primarily, I think you're forgetting selective disclosure.

This should surprise us a lot, given many of your previous comments in this group and elsewhere.

I don’t see why selective disclosure would be harder or even differently with GNAP requests instead of VPs.

On Tue, Jun 6, 2023 at 11:14 PM Ted Thibodeau Jr @.***> wrote:

What am I missing?

Primarily, I think you're forgetting selective disclosure.

This should surprise us a lot, given many of your previous comments in this group and elsewhere.

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

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

Adding VPs in the first place was a mistake imo. Even with Data Integrity we are having a situation where certain proof types don't use VPs at all. It would even compromise the unlinkability guarantees/privacy in the case of BBS+ if the derived VC were put into another signed envelope.

It is confusing for a verifier to expect VPs and/or VCs. IMO, if the holder simply adds another proof to the VC, you would achieve the same thing as VPs using simple ECDSA proofs. Note that the proof contains a verification method that allows the verifier to check who originated the proof. In that case, there is really no big difference between using a VP and a VC with an additional proof created by the holder key.

I oppose removing Verifiable Presentations. We should keep building incrementally on what we have so far; we should not tear things down.

Adding VPs in the first place was a mistake imo. Even with Data Integrity we are having a situation where certain proof types don't use VPs at all. It would even compromise the unlinkability guarantees/privacy in the case of BBS+ if the derived VC were put into another signed envelope.

It is confusing for a verifier to expect VPs and/or VCs. IMO, if the holder simply adds another proof to the VC, you would achieve the same thing as VPs using simple ECDSA proofs. Note that the proof contains a verification method that allows the verifier to check who originated the proof. In that case, there is really no big difference between using a VP and a VC with an additional proof created by the holder key.

The discussions so far should have highlighted that the issuer's intention is not only to limit who can present the VC but also to protect against cloning and simple replay attacks and improve the overall security of VPs. Adding holder binding or authentication on top of that further enhances the security measures but might be an additional process. For the former, it means that the VC needs to be linked to specific key material or a DID or similar in the first place (which the conf'method was about).

In my opinion, VPs would lose their significance without incorporating these security controls. Without them, a holder could easily add another proof to the VC and achieve the same result that VPs aim to provide in terms of semantics.

By implementing these security measures, we can ensure the integrity and authenticity of VCs and VPs, guarding against cloning and certain MITM attacks.

Neither the VCDM, nor the Data Integrity data model caters for this atm, so I created this #1138.

A potential solution might be that someone could define a XyzKeyBoundPresentationSignature2023 which semantically says that the presentation is secured by a signature that proves control over a specific claim endorsed by the issuer that is contained in the VC. In that case I might be convinced that VPs do have some purpose. Just inventing an envelope for multiple VCs is not really a meaningful reason that justifies having another top-level standalone object such as presentation or VP.

Just inventing an envelope for multiple VCs is not really a meaningful reason that justifies having another top-level standalone object such as presentation or VP.

VPs are not just "an envelope for multiple VCs". They also enable Selective Disclosure, among other things we've discussed elsewhere.

Verifiable Presentations only normative requirements:

@context
type

Everything else is optional.

The current spec version of a VP is essentially a JWT with alg none, being a legal value.

VPs don't enable anything, how could they, look at their requirements.

They are simply JSON-LD envelopes.

If we want them to have more significant meaning than "ld+json" we have a lot of normative changes to make.

https://github.com/transmute-industries/vc-jwt-test-suite/blob/main/data/report.json

VPs have been successfully used for lots of things based on their non existent requirements.

The list includes:

Securing multiple credentials with a new signature from the current holder.
Transformed / verifier bound representations of credentials (CL-Signatures)
Subject is holder, authentication proof purposes.
Delivering credentials to and from wallets (chapi).

I guess it's natural that we don't really have a proof requirement for Verifiable Presentations, since we don't have one for Verifiable Credentials.

In the case that we do have a proof on a presentation, it can be used to demonstrate proof of possession.

Another areas a challenge... The "verifiableCredential" graph container.

It can hold by reference or by value, but it can't hold JWT by value because they are not valid IRIs (graph node identifiers) or objects (graph nodes).

We could fix this by making a URN format for JWTs or by asserting that JWT VPs simply don't exist, and you should instead use a separate credential for proof of possession, like sd-jwt already does.

This would make presentations very different for the various "security formats" further eroding the value of VPs.

I think the truth is, VPs are basically a data integrity proof specific container.

Keeping them as they are, gives data integrity proofs tremendous flexibility, while forcing developers to handle a security data format that can be basically anything.

Another option for VP and VC by reference is data URIs.

Now that we have a requested content type, expect to see this everywhere:

data:application/vc+ld+json, base64;ey...

data:application/vc+ld+jwt, base64;ey...

This issue can be closed when https://github.com/w3c/vc-data-model/pull/1141/files is merged.

PR #1141 has been merged, closing

w3c / vc-data-model

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 #882

3 is an internal matter for the verifier and belongs in neither the VC