Specify how multiple claims should be included in a Verifiable Presentation

[Kristina Yasuda]

When RP is requesting multiple claims, there are two options for the OP/wallet how to return them with proof of possession:

1. sign each claim in individually as multiple VPs
2. sign all claims as one VP

To avoind processing confusion on the RP side, the OP behavior should be specified in the text.

I would imagine option 2 of wrapping all claims in one proof of possession (VP) is a simpler option, but I might be missing a use-case. If not, I will try propose a text.

[David W Chadwick]

The VP construct has specifically been designed for including multiple VCs in one VP, and the holder signing the entire VP package (just once) for PoP.

Thus option 2 should be the default behaviour for VPs. I cannot think of a use case where case 1 would be appropriate. (and since the user/wallet is collecting all the VCs together before presenting them to the RP, then regardless of the use case, a single VP would be the end result).

‌

[Jeremie Miller]

Claims inside of credentials coming from different sources may (likely) have different proof-of-possession mechanisms, such that the presenter has no choice but to create different VPs using only the cryptographic techniques supported by the originating credentials.

IMO that kind of flexibility/agility is required here in order to support different types of credentials. The RP MUST be able to accept multiple VPs returned from a single presentation request. These would of course be limited to the formats it supports as defined in the RP's metadata.

[David W Chadwick]

There is nothing to stop a VP having multiple PoPs attached to it. Indeed the W3C spec acknowledges that multiple proofs may be attached to both a VP and a VC.

But to require a wallet to support many different PoP mechanisms when RPs are more limited in what they can or will support (with their much large web service resources), is placing a lot of burden on mobile phones and app providers.

[Jeremie Miller]

I think I definitely mis-spoke and was thinking at the wrong level.

The OIDC4VP draft already defines verifiable_presentations to be an array, and each of the items in the array can have their own PoP mechanism based on the crypto they use.

The vp_token that contains that array would be signed, but that signature is only a binding to the actor involved in responding to the presentation exchange, it itself is not the PoP of the claims contained within each presentation object in the array. Those individual objects will carry their own proof based on the nonce presented during the request.

[Torsten Lodderstedt]

The current request mechanisms lets the RP specify what credential types (and claims of the respective credential) it wants to obtain (with options for alternatives) but leaves the packaging in VPs to the OP. So if the RP asks for 2 different credentials types A and B, the OP could put them into a single VP or into two different VPs. The response format supports both options by way of making the container an array of VPs.

[Michael Jones]

Closed during the 15-Jun-21 call since the array format in the specification already enables this.