Support Aries RFC 454 present_proof v2.1 -- sending multiple presentations in a single protocol instance

[meadoch1]

In aries-rfcs 0454 Present Proof v2.1 the request-presentation message includes the boolean element present_multiple which is intended to cause the prover to include all credentials which meet the conditions of a request-presentation message when it is set to true. ACA-Py does not currently support this feature. The purpose of this feature request is to implement changes to allow ACA-Py to understand and respond appropriately when this value is true.

Example case:

Roles:

• Alice: Issues credentials to Bob
• Bob: Holds credentials and proves them upon request
• Cook: Requests verifications from Bob

Assume Alice can issue multiple "food" credentials to Bob. A food credential has the following characteristics:

• attributes: [name, meal, is_favorite]

Alice issues the following credentials to Bob.

[
  {
    "name": "scrambled eggs",
    "is_favorite": false,
    "meal": "breakfast"
  },
  {
    "name": "cookie crisp",
    "is_favorite": true,
    "meal": "breakfast"
  },
  {
    "name": "ham sandwich",
    "is_favorite": true,
    "meal": "lunch"
  },
  {
    "name": "fried rice",
    "is_favorite": true,
    "meal": "dinner"
  },
  {
    "name": "boiled cabbage",
    "is_favorite": false,
    "meal": "dinner"
  }
]

When Cook uses the Present Proof v2 protocol to ask Bob about his credentials we could imagine the following cases:

1. Cook asks what are Bob's favorite foods. Bob returns the information for "cookie crisp", "ham sandwich", and "fried rice".
2. Cook asks what Bob can have for dinner. Bob returns the information for "fried rice" and "boiled cabbage".
3. Cook asks what Bob has as favorite foods for breakfast. Bob returns the information for "cookie crisp" only.

[swcurran]

Help wanted on this one:

The next step in implementing this is creating a design document/plan to determine how to support this. There are multiple considerations that must be covered in the design.

• In general, the implementation must ensure that protocol instances that use the v2.0 protocol still work. E.g. if running the protocol with another agent and that agent does not support the v2.1 protocol, ACA-Py must be able to continue to work.
  • If the other party is the verifier and initiates the protocol (using v2.0), this should be straight forward.
  • If ACA-Py is the verifier and starts the protocol using v2.1, and the other party (the holder) responds with a v2.0 response message, the ACA-Py instance must adjust gracefully by assuming that v2.1 features have been ignored and cannot be used. This must be conveyed to the controller to decide what to do.
• When not using the extended v2.1 features, what protocol version should the ACA-Py instance claim? I believe the answer is v2.1, but we likely need to test that (using AATH) to verify that.
• Should there be a start-up parameter added to allow an ACA-Py instance to default to use the v2.0 or v2.1 protocol version?
• What Admin API updates are needed to support the multiple presentation capabilities?
  • If a startup config parameter is used to indicate only the v2.0 version should be used, what should happen if the v2.1 protocol Admin API parameters are used?
• What webhook changes are needed to keep the controller in the loop as the presentations are needed (the holder) or received (the verifier).
• What should happen if one of the presentations fails verification?
• What AATH tests need to be added to the test suite.
  • Once v2.1 support is added, all existing tests should continue to work.
  • At minimum, we need a happy path test -- use the v2.1 protocol, with the test succeeding if both sides support v2.1 and multiple presentations are made or if either (or both) sides support v2.0 and only one presentation is provided.

[Ennovate-com]

Should there be a start-up parameter added to allow an ACA-Py instance to default to use the v2.0 or v2.1 protocol version?

I would vote "No". The logic is that if ...

the ACA-Py instance must adjust gracefully by assuming that v2.1 features have been ignored and cannot be used. then ...

The agent can default to v2.1 and 1) if the agents themselves use none of the v2.1 features, there's no adverse consequence and 2) when ...

the other party (the holder) responds with a v2.0 response message

the agent "must" fall back to v2.0 and will therefore be operating as if v2.0 was the default, without the need for a start-up parameter. This makes the assumption that, on receipt of the response message, the agent can determine the version in use overall by the partner agent, even if no v2.1 features are used in the specific message. Which brings up the question ...

Question: How does the controller detect that the incoming message is v2.0 rather than v2.1? Will the callback (webhook) request URL contain present_proof_v2_1 instead of present_proof_v2_0 or would the minor version be indicated in some other way, such as a request parameter (ex: ?version=2.1)?

When not using the extended v2.1 features, what protocol version should the ACA-Py instance claim? I believe the answer is v2.1, but we likely need to test that (using AATH) to verify that.

The comments above are based on an opinion where I agree with that answer and am figuring that the tests with v2.1 as default will likely be successful.

When the present_multiple element is implemented, the related element last_presentation should be implemented at the same time (I did not see that mentioned in the OP and previous comment).