Clarification on Multiple `ldp_vp` Verifiable Presentations

[KiruthikaJeyashankar]

Hello,

Subject: Request for Guidance on Using Multiple ldp_vp Presentations in a Single VP Response

Problem Statement

We have a use case where a wallet needs to present two JSON-LD Verifiable Credentials (VCs), each with a different holder binding key:

1. Government Identity – holder key of type EC key.
2. University Certificate – holder key of type Ed key.

The requirement is to share both credentials in response to a single presentation request, while ensuring cryptographic proof that each credential is presented by its rightful holder.

Reason

• Verifier wants to ensure that each Verifiable Presentation is cryptographically bound to its respective holder for a ldp_vp Verifiable Presentation.
• A wallet may need to present two VCs (ldp_vc), each with a different holder key, and cryptographically assert the holder’s identity for each corresponding VP.

Scenario

A digital wallet is submitting these credentials (Government Identity & University Certificate) for a job application as response to a single presentation request. The Verifier (Company) requires that the Credentials are presented only by the person to whom it was issued, mandating strong cryptographic holder binding for each credential.

Requirements

• Separate cryptographic proofs per credential – a single signature over both VCs is not possible due to different holder keys.
• Clear binding between each credential and its holder key – the verifier must be able to trust that each credential is controlled by the correct holder.
• Flexible VP structure – supports multiple VCs with different holder keys without compromising security or authenticity.

As an approach to satisfy these requirements, one option could be to construct a separate VP per holder key, grouping credentials accordingly:

Proposed VP response

As per the scenario, since both credentials have different holder keys, Separate VPs constructed for Government Identity & University Certificate
Example using vp_token response type:

{
  vp_token: [
    /** VP - Government Identity**/
    {
      // other VP properties
      "holder": "<ecKeyHolderReference>",
      "verifiableCredential": ["<Government Identity -> Holder key is of type EC key>"],
      "proof": {
        // Proof value generated by the holder using the EC key for signing purposes
      }
    },
    /** VP - University Certificate**/
    {
      // other VP properties
      "holder": "<edKeyHolderReference>",
      "verifiableCredential": ["University Certificate -> Holder key is of type Ed key"],
      "proof": {
        // Proof value generated by the holder using the ED key for signing purposes
      }
    }
  ]
}

Benefits of the proposed response

1. Cryptographic Holder Binding
   - Each VP contains a proof created with the holder’s specific key, ensuring that only the rightful holder can generate it.
   - The Company (Verifier) can verify the signature against the holder’s public key, satisfying the requirement for holder binding.
2. Each VP is independently verifiable.

Request

1. Could you please confirm whether the proposed VP response including multiple ldp_vp presentations within a single VP response is compliant with the specification?
2. Is there a better or recommended approach for handling cryptographic holder binding when sharing multiple ldp_vc credentials with different holder keys in response to a single presentation request?

TIA

[c2bo]

You are not using the correct vp_token syntax:

vp_token: REQUIRED. This is a JSON-encoded object containing entries where the key is the id value used for a Credential Query in the DCQL query and the value is an array of one or more Presentations that match the respective Credential Query. When multiple is omitted, or set to false, the array MUST contain only one Presentation. There MUST NOT be any entry in the JSON-encoded object for optional Credential Queries when there are no matching Credentials for the respective Credential Query. Each Presentation is represented as a string or object, depending on the format as defined in Appendix B. The same rules as above apply for encoding the Presentations.

A dcql query for your scenario would look something like this (this requires presentation of both credentials):

"dcql_query": {
  "credentials": [
    {
      "id": "government_credential",
      "format": "ldp_vc",
      "meta": {
        "type_values": [["IDCredential"]]
      },
      "claims": [
          {"path": ["credentialSubject", "family_name"]},
          {"path": ["credentialSubject", "given_name"]}
      ]
    },
   {
      "id": "university_credential",
      "format": "ldp_vc",
      "meta": {
        "type_values": [["UniversityCredential"]]
      },
      "claims": [
          {"path": ["credentialSubject", "family_name"]},
          {"path": ["credentialSubject", "given_name"]}
      ]
    },
  ]
}

A response to such a query would then contain a vp_token like this:

"vp_token": {
  "government_credential": { <verifiable presentation> },
  "university_credential": { <verifiable presentation> },
}

Where the credential.id used in the query is used to identify the corresponding part in the response.

[KiruthikaJeyashankar]

@c2bo Thanks for the clarification

I am hoping that this pattern of construction of multiple ldp_vp presentations in same VP response is also applicable to DIF Presentation Exchange. Could you please help confirming that?

Considering the VP request being given as

{
  "id": "..e",
  "purpose": "Authentication of Government ID and University Degree for accessing the service.",
  "input_descriptors": [
    {
      "id": "government-id-vc",
      "name": "Government ID Verifiable Credential",
      "format": {
        "ldp_vc": {...}
      },
      "constraints": {
        "fields": [
          {
            "path": [ "$.credentialSubject.id" ],
            "purpose": "To uniquely identify the holder of the credential."
          },
          {
            "path": [ "$.credentialSubject.nationality" ],
            "purpose": "To confirm the nationality of the credential holder."
          }
        ]
      }
    },
    {
      "id": "university-degree-vc",
      "name": "University Degree Verifiable Credential",
      "format": {
        "ldp_vc": {...}
      },
      "constraints": {
        "fields": [
          {
            "path": [ "$.credentialSubject.id" ],
            "purpose": "To uniquely identify the holder of the credential."
          },
          {
            "path": ["$.credentialSubject.degree"],
            "purpose": "To confirm the degree obtained by the credential holder."
          }
        ]
      }
    }
  ]
}

VP response constructed as follows

• 2 Verifiable Presentations are constructed considering the holder binding is required for both the presentations

{
  "vp_token": [
    "<VP - Government Identity - holder binded>",
    "<VP - University Degree - holder binded>"
  ],
  "presentation_submission": {
    "id": "Presentation example",
    "definition_id": "..",
    "descriptor_map": [
      {
        "id": "government-id-vc",
        "format": "ldp_vp",
        "path": "$[0]",
        "path_nested": {
          "format": "ldp_vc",
          "path": "$.verifiableCredential[0]"
        }
      },
      {
        "id": "university-degree-vc",
        "format": "ldp_vp",
        "path": "$[1]",
        "path_nested": {
          "format": "ldp_vc",
          "path": "$.verifiableCredential[0]"
        }
      }
    ]
  }
}

Kindly let us know if there is a better or recommended approach for handling cryptographic holder binding when sharing multiple ldp_vc credentials with different holder keys in response (In case of Presentation Exchange) to a single presentation request

[c2bo]

It seems you've been using a rather old draft of OpenID4VP? presentation_submission doesn't exist anymore and in general using PEX has been deprecated for quite some time now and has been removed from OpenID4VP. The only query language in OpenID4VP 1.0 is DCQL.

It probably wouldn't be hard to mimic the behaviour by also using an object for vp_token where the proofs are identified by their respective ids, but we are talking about something that is not defined in OpenID4VP anymore - this would be a custom variant, not standard OpenID4VP.

[vishwa-vyom]

Hi @c2bo, thanks a lot for the quick and detailed responses — really helpful.

Just to add some context, @KiruthikaJeyashankar and I are part of the same team working on MOSIP (Inji). At the moment, we are still on draft 23 of OpenID4VP, as we have a few country deployments already using this version. Because of that, we’re trying to carefully handle some of these edge cases while maintaining compatibility.

We do plan to move to the 1.0 version of the spec and adopt DCQL as recommended. In the meantime, we’re exploring ways to mimic similar behavior within our current constraints.

One follow-up question from our side: in a scenario where both credentials are bound to the same holder key, would it be acceptable to include them within a single VP token (with one proof), or would it still be expected to return them as separate VP tokens with independent proofs?

Appreciate your guidance on this — it’s been very useful for us.

[c2bo]

I would probably still do 2 separate entries in the vp_token. If I recall correctly we had that discussion and were thinking about using references between entries, but reached the conclusion that it's probably better to keep it simple and basically expect that every id gets an explicit response. I wasn't able to find those discussions in a quick search though, so take that with a grain of salt.

I think for your scenario, I'd prefer one of these 2 options:

• do individual proofs for the subset responses (2 vp_token entries, with individual proofs)
• do one big response with one proof, but copy the same response into both vp_token answers. This inflates the response size but keeps things simple to parse.( 2 vp_token entries, with the same proof)

It depends a bit on your requirements - how costly is a signature, does it require individual user interactions etc. and how expensive is transmission size.

I would try to avoid more complex matching logic to keep it rather easy to associate specific queries to specific response parts.

[vishwa-vyom]

We’ll go ahead with the approach of doing individual proofs for the subset responses (i.e., separate vp_token entries with independent proofs). This feels simpler to reason about and aligns well with how other credential formats like SD-JWT VC treat each credential as an independently verifiable unit with its own proof material.

Also, +1 on keeping the parsing logic straightforward — that resonates with our implementation goals as well.

One additional thought: it might be really helpful to capture such scenarios (especially around multiple credentials, holder binding, and vp_token structuring) more explicitly in the OpenID4VP specification. Having clearer guidance here could go a long way in avoiding interoperability issues across implementations.

Really appreciate your inputs on this — it’s been very helpful for us.