Issue Credential: initiate with issue message

[dbluhm]

Issue Credential as a protocol was formulated with support for credential formats like AnonCreds that require exchange of key cryptographic primitives prior to issuance. This resulted in the offer-request-issue-ack and proposal-offer-request-issue-ack flows we have today. However, not all credential formats have these requirements. LDP-VC credentials can skip straight to the issuing a credential in many circumstances. The protocol as specified right now requires that all issuer-initiated flows start from the offer message, despite the differing requirements between credential formats.

This has been discussed on the Aries WG call and the resolution was that it's fine for credential formats that don't require prior steps to begin with the issue message.

We should update the protocol to reflect this resolution.

Implications to discuss: how does this affect the version of the protocol?

cc @TelegramSam

[dbluhm]

cc @chumbert

[swcurran]

According to what I see in the text of the RFC, offer is an optional step — https://github.com/hyperledger/aries-rfcs/tree/main/features/0453-issue-credential-v2#messages

offer-credential - Issuer to potential Holder (optional for some credential implementations; required for Hyperledger Indy).

I certainly remember when we defined this protocol that Offer was not supposed to be required for all credential formats, so I believe that is the expectation. I’m good with this being a clarification.

[talltree]

100% agree. Also, the revised language should no longer refer to "Hyperledger Indy" as if that defined a specific credential format, right? If I understand correctly, Hyperledger Indy is evolving into a digital wallet and credential framework that can support multiple credential formats. So the language should say something like, "...required for Hyperledger AnonCreds and other interactive credential issuance formats".

[swcurran]

Yes — we need to convert all the language in the RFCs to replace Indy with AnonCreds where it references the AnonCreds credential format. That gets a tad tricky where the refrerences are in data models. In that case, we change the text, but include a note to indicate why the data items reference “indy”.

[dbluhm]

@swcurran based on current wording, I think the statement that the offer is optional implies that the exchange can start with a request but no alternatives where the issuer initiates are given. As a result of this language, as a concrete example, ACA-Py expects (requires) that a credential request must always be sent/received no matter the credential type or who initiated it. I think we could probably still get away with having this just be a clarification and not a version bump but if implementations were strictly adhering to this language like ACA-Py does, we might see some compatibility issues.

[swcurran]

In the last comment — did you mean to say "expects (requires) that a credential request offer must always be…”?

The challenge happens with credential types that don’t specify what is needed to issue a credential. AnonCreds defines both data models and the interactions needed to issue a credential. That level of opinion makes it easier to know what to do. With a JSON-LD W3C credential using LD-Signatures), where only a data model is defined, there is no guidance on any steps in the issuance. An issuer doesn’t even need a credential request. If the issuer wanted some sort of SubjectID to put into the credential, they might require a credential request from the holder. They might even explicitly ask for that from the holder via a credential offer (which is what happens in AnonCreds — including the use of a nonce to prevent a replay attack by the holder).

I think the approach that is needed is that the base protocol issue-credential should define the options, and it is up to the RFCs that defines the usage for a specific credential type.

I agree that if there is a credential type that supports starting with a credential request, it should be possible in the concrete implementations. I’d be interested in knowing what assumptions are built into ACA-Py’s support for JSON-LD W3C credentials with LD-Signatures and BBS+ signatures.

[dbluhm]

In the last comment — did you mean to say "expects (requires) that a credential request offer must always be…”?

I do actually mean credential request. The Issue Credential protocol already permits starting from a request message making the list of potential entry points for the protocol:

• propose-credential (holder initiated)
• offer-credential (issuer initiated)
• request-credential (holder initiated)

What's missing is a flow that permits the Issuer to initiate at the issue-credential message. If the issuer already has access to all the necessary information to issue the credential (from a previous exchange, from some other out-of-band system, renewing an old credential, etc.) and the credential type supports it, we have the technical and cryptographic capability to go ahead and issue the credential but the issuer would have to start at offer-credential since that's the only valid starting point for the issuer.

ACA-Py's JSON-LD W3C Credential implementation strictly expects these protocol entry points and, as the recipient of a credential, will reject an issue-credential message that was not preceded by at least a request-credential message. So what I was trying to point out was that other implementations may be similarly strict.

[swcurran]

Sorry — I thought you were saying you wanted to start at the request-credential, but you are talking about starting at issue-credential without the prior steps. I don’t think that was necessarily anticipated in the discussions we had at the time we defined this protocol, but I don’t see that is against the spirit of the protocol. The idea is support the needs of different formats. I would be interested in what RFC 0593 (LD Signatures) and RFC 0646 (BBS+ Signatures) say they should support. Do they talk about being able to start with an “issue”? Yes, I know — I could look… :-)

I would be open to a PR that clarifies the starting point as being flexible, and then once we see the wording (and perhaps how you want to use it) we can see if that is a clarification of the existing protocol, or would require a version change. I’m betting on clarification, but we’ll see :-).

[TimoGlastra]

Starting at issue credential makes sense to me. Also because the jsonld format doesn't provide a way to do proof of possesion of the subject did, so that would need to be handled separately. That's how an offer/request flow would be most useful

[TelegramSam]

If it happens to be the same DID as the DIDComm connection, then proof of possession is automatic. If not, we'd need to include a separate proof of possession as @TimoGlastra describes.