Support for potential 3-step issuance flows (AnonCreds)

[TimoGlastra]

In a past version of OID4VCI I know there were some mentions and references of AnonCreds credentials and those have since been removed.

The use of credential format profiles allows to extend the protocol with new formats, outside of the defined scope of this specification, however with the removal of the inline credential offers (#77, which I fully supported) I think we lost the ability to define a working credential format profile for AnonCreds.

In AnonCreds it's required for the issuer to create a credential offer first, which needs to include a cred_def_id, key_correctness_proof and a nonce. AFAIK only the nonce needs to be dynamic, and thus the other fields could be included in the credentials_supported entry for a new ac_vc credential format.

It MAY be possible to use the c_nonce value from this spec as the nonce for the AnonCreds request as well, and define a new proof.type of ac_link_secret. This would allow the credential to be bound then to the link secret provided in the credential request proof, after which the credential can be issued.

So if my assumptions are correct, it should possible still to do AnonCreds issuance using this protocol, but just wanted to open this issue for confirmation and history. If this is the case, we may define an AnonCreds credential format profile outside of this specification

@andrewwhitehead is it correct that the key_correctness_proof in an AnonCreds credential offer is static, and thus it would be possible to include these in the issuer metadata endpoint?

[Sakurann]

I don't think we have ever defined AnonCreds profile in OID4VCI, so nothing was removed :) AnonCreds profile has been defined in OID4VP and it is still there: openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#appendix-A.2.

Removal of the inline credential offer does not prohibit anoncreds profile - issuer metadata that is obtained via credential_issuer parameter in the Offer just have to contain credential_configurations_supported entry with format ac_vc where the key in the map matches to the credential_configuration_ids (being renamed in PR #220) from the Offer.

The baseline of what needs to create a new credential format profile i a) define credential format identifier (ac_vc), and b) how a concept like type/vct/doctype is expressed throughout the protocol, and it's the same for anoncreds just like for any other credential format. in the case of anoncreds though, a new proof type might work better, just like we defined ldp_vp proof type for LDP.

[c2bo]

I am definetely not an expert for these topics, but if I remember correctly the key_correctness_proof in AnonCreds is calculated only over the private key, public key and credential definition --> i am pretty sure it's static for a credential definition. No idea about the proposed AnonCredsv2 though. I do believe AnonCreds issuance with OpenID4VCI should be doable with the current flows and a new profile.

[Sakurann]

let us know if there are still concerns, otherwise, will close in a week :)