Enabling Multiple Presentations from a Presentation Request

[swcurran]

From BC Gov and Kiva (@mattraffel , Jacob Saur)

We’ve seen multiple instances of the following kind of use case:

• A verifier requests a presentation (via RFC 0454 Present Proof v2) knowing that the prover may have multiple instances of a credential, and wanting to a presentations of the credentials in return, for example:
  • As part of a job application, a request is made for multiple proofs of employment (or proofs of certifications)
  • As part of a loan application, a request is made for a list of bank accounts held by the user.
  • As part of opening a business account, a request is made for the list of directors of the organization.

We propose adding the following items to the messages in the present-proof v2 messages:

• To the “propose-presentation” and “request-presentation” message add the item “present_multiple” set to “true” to indicate that the verifier will accept multiple presentations. If missing, default to “false”.
• To the “presentation” message add the item “last_presentation” set to “false” for all but the last presentation to be sent in response to the presentation request. If missing, default to “true”. Each presentation message sent would be part of the same thread.

A recommendation should be included that when using the “present_multiple” with value “true”, the presentation request should not include other than a simple presentation request of (usually) a single credential type. A combination of credential types, each with the prover holding multiple instances will be difficult for the wallet, worse for the user.

For the UX, we would expect the prover to provide a list of presentations that could be sent and allow the user to select the ones to be sent (or more perhaps, unselect the ones not to send). Once done, the “presentation” messages would be sent without further input from the controller.

There are multiple other ways to accomplish this that might be considered:

• In the “presentation” message, have all of the presentations to be sent as an array.
• Use goal-codes to convey the request to “present_multiple”.
• Allow the verifier to be more specific about the request for multiple, such as “send all” or “send up to 3”.
• Have the prover just send multiple presentations without indicating that more are to be sent.
• Use other data items in the messages, such as in the “presentation” message, the combination of items “presentation_number” and “total_presentations” so the verifier knows from the first response how many messages are coming.

As well, one could introduce the concept of “present_multiple” in the DIF Presentation Exchange protocol, so specifying it at the Aries protocol level. That would not work for Indy and would introduce the same dynamics as sending all the presentations in one message. Alternatively, the concept could be added at both the Aries Protocol and DIF PE levels.

[rolsonquadras]

We are working on a similar problem statement where one presentation request results in multiple presentations.

Use Case: Verifier requires a Driver License (DL) and the latest Credit Report (CR) from the user to complete some transaction.

The verifier asks for the credentials and, the wallet decides whether it can submit all in one or multiple presentations. In this scenario, the wallet holds a Driver’s License (DL) and a Service Holder holds the Credit Report(CR) on behalf of the user.
We are working on a document to build multiple presentations scenario on top of DIF WACI v0.1 spec.
WACI uses DIDComm v2 present-proof protocol.

The wallet uses the present-proof-propose message to ask the verifier to split the DIF Presentation Exchange Definition requests into multiple presentation definitions inside the present-proof-request message. In this way, the verifier can independently validate multiple presentation submissions against presentation definitions.

Below is the screenshot of the extensions that we are thinking for present-proof message.

[swcurran]

Hmmm...in all of the work we've done so far, that use case would be handled as a "one Presentation message" and so does not fit into the reason for raising this issue. In both Indy AnonCreds and DIF PE, this use case can be accomplished with a single "request-presentation" and "presentation" message pair. Why the need to split that into two?

This issue was raised for the use case of (for example), wanting one DL and several CRs, where the request for "several CRs" in the single protocol instance must be stated by the verifier, and the prover needs to be able to send multiple presentations, one for each CR.