Description
Summary:
This issue addresses the challenge of handling scenarios where a verifier requests multiple verifiable credentials (VCs) that reside in potentially different digital wallets within the context of DC API for Presentations. For example, when age proof together with payment authentication are requested in a single DC API call.
When a Verifier sends a presentation request for multiple VCs held across different credential providers, our current architecture encounters difficulties in aggregating and returning these credentials. The primary obstacle lies in the response encryption mechanism, which is not designed to handle data originating from multiple independent wallets. Consequently, we cannot combine the encrypted responses from each wallet into a single, decryptable result for the Verifier.
Proposed Solutions:
1- Returning an Array of VC Objects
This approach suggests modifying the API to return an array of individual DC objects, where each object represents a credential retrieved from a different wallet.
Pros:
- Simpler to implement on the platform/credential selector level.
- Can be easily compared to sending multiple presentation requests and aggregating the responses.
Cons:
- Exposes complexity to the API level that are specific to rare use cases and are only supported by some protocols.
- Could potentially cause the Android API and the Web API to diverge. Web DC API returns an array, and the Android DC API returns a single VC.
- Could be confusing since the request contains an array of requests, and if the response also contains an array of responses, it could give the illusion that multiple requests have been satisfied, although one one requests of the requests array is satisfied (it just happened that this satisfied request, asked for multiple VCs) .
2- Protocol-Level Modification
Instead of exposing such complexity on the API-level, this approach suggests keeping that complexity hidden on the protocol level. Openid4vp for example can define its response to be either a single VC or an array of VCs depending on the contents of the request, and it is up to the verifier to inspect the response.
Pros:
- Keep the Web API simple, and aligned with the platform API. (Unless the platform API will also change)
- Keeps the API optimized for the mainstream use case of requesting one VC per DC API call.
Cons:
- Complicates the aggregation of multiple VCs on the platform level.
- Could result in more complex protocol definitions.