#0453 V2 issue-credential: review

[Patrik-Stas]

Hi all,

while Issue credential V2 protocol has been out there for quite some time, we are starting with its implementation in aries-vcx now hyperledger/aries-vcx#987

As we are discovering what needs to be implemented, what the difference are compared to V1, some questions arise from our side. It appear to us that utility of some features described in the RFC is questionable but I'd like check with implementors&frameworks who been using the protocol for longer time by now.

What I am looking to get out of this Github issue:

• find out if I there's an intersection with other community members thinking,
• find out which protocol features are "the MUST" for implementors of WIP New RFC: Issue Credential v2 #453, and which are widely not supported through social consensus, even if they were part of the RFC originally,
• assuming there's a merit to the comments below, see if we can consider that once V3 will be shaped.

Batch - multi-format issuance

The protocol work with array formats, filters~attach, supplements, ~ attach which enables issuance of multiple credentials, each possibly in a different format.
Both "batcheness" and "multi-formatness" properties bring a more complexity to implementation itself & APIs provided by frameworks/libraries - more complicated framework/library APIs then trickle up to application layers as well. And while arguing against complexity is not enough on its own, I think it could be if a core feature turns out to be generally unused - now this is something I am not sure about, and one of the reasons I writing this issue and raising questions:

• Is there an Aries implementation using these 2 properties?

  • My comment: According to [George's PR](feat: Cred Issuance V2 APIs aries-vcx#987

  aca-py seems to assume single attachments and of the same format thru out the protocol

  In aries-vcx, we are also choosing to not implement support for these, at least for starter, hence we'll be assuming only 1 credential is issued at a time, and credential format won't change during the protocol lifecycle between 2 parties.

• Do you think it will be important to support batch issuance (and especially in junction with different formats in single batch)?

  • My comment 1: In human-involved scenarios, IMO the UX can be easier to reason about if every credential is viewed/acknowledge by the user separately, rather than forcing user to check/re-propose/accept/deny whole set of credentials.
  • My comment 2: In machine2machine scenarios, I also don't see strong argument to deal with batches, rather than sending multiple credentials offers and let them all play out separately (some might get re-negotiated values, some might be accepted, some might be rejected).

Obviously, an issuer can always choose to send credential one by one, if issuer deems that as better option - the protocol is not preventing doing that. But nevertheless, the spec is requiring us to implement the batch issuance nevertheless and I question why would someone choose to use it in practice.

Payments

I don't have as much comments here, but at intuition level I feel like this might also better be a separate protocol perhaps? In this RFC, it's touched on the fact that presentation protocol subthread might be spun off to find out more about the counterparty, prior to issuing credential.
That's reasonable, but why not to use the same approach for payments? I find that embedding payments as a part of issuance protocol is making it heavier/more coupled than it has to be.

[gmulhearn-anonyome]

thanks for raising this. I think the case here is also applicable to present proof v2 too: https://github.com/hyperledger/aries-rfcs/tree/main/features/0454-present-proof-v2 . as it has undergone the same evolution as issue-credential.

However an interesting note is present on the present-proof-v2 RFC around this topic:

The messages that include ~attach attachments may use any form of the embedded attachment. In the examples below, the forms of the attachment are arbitrary.

The ~attach array is to be used to enable a single presentation to be requested/delivered in different verifiable presentation formats. The ability to have multiple attachments must not be used to request/deliver multiple different presentations in a single instance of the protocol.

[Patrik-Stas]

In the end this happened to be largerly addressed in:
#816
#815