Define ledger agnostic AnonCreds interfaces for ACA-Py

[TimoGlastra]

Placeholder issue to define the AnonCreds interfaces for ACA-Py.

TODO

• [ ] AnonCreds routes.py
• [ ] anoncreds issuer, holder, verifier
• [ ] anoncreds service that manages multiple anoncreds registries
• [ ] anoncreds registry

https://hackmd.io/Ailjb-WDTeC48EjF0gjrGA

[TimoGlastra]

@swcurran @andrewwhitehead @ianco question about the backwards compatibility we need to keep.

AFJ

I'll describe here how we tackle backwards compatibility in AFJ for reference. In AFJ we are removing the ledger api (which used to do all operations related to indy ledgers dids, schemas, creds defs, etc..) and instead creating more focused apis. So we have the did api that allows to create/resolve dids and the anoncreds api that allows to create / retrieve anoncreds objects. This replaces the 'ledger' classes. The notion of ledger is removed and we have just implementations of specific topics. So the IndySdkDidResolver, or the AnonCredsRsIssuer, but not something focused around a ledger anymore (as all these topics could work without ledger).

We are implementing the AnonCreds apis for the new AnonCreds-RS library, as well as the indy-sdk. The indy-sdk anoncreds implementation will only be able to support legacy, unqualified indy style anoncreds objects. If you want to use it with did:indy or other anoncreds methods you have to use the anoncreds-rs implementations (And thus the other shared components libraries).

ACA-Py

As ACA-Py already supports the shared components, the question is, whether support for the indy-shared-rs (credx) library must be retained. Indy SDK allows for legacy indy wallets to be used that haven't gotten the chance to update yet, but the anoncreds-rs lib will be able to replace the indy-credx library. So I'm currently leaning to implementing the ledger agnostic anoncreds interfaces in ACA-Py twice. Once with the indy-sdk and once with the anoncreds-rs lib. Same as with AFJ, indy-sdk will only support legacy indy objects identfiiers, anoncreds-rs will support legacy, did:indy and other methods.

We will probably rename the indy folder to anoncreds and update the current issuer/holder/verifier interfaces to be ledger agnsotic, and create a registry service (like the did resolver) that allows to interact with multiple anoncreds registries (indy ledger, cheqd ledger, etc..). this is mostly internal changes and shouldn't cause any problems.

The public API is where it get's interesting.

Ideally we would create an AnonCreds api in ACA-Py that is designed for ledger agnositc anoncreds:

• GET /anoncreds/schema/{schema_id}
• POST /anoncreds/schema
• GET /anoncreds/credential-definition/{cred_def_id}
• POST /anoncreds/credential-definition

We could also look at keeping the existing API endpoints, however as the models are going to change slightly (and more for revocation), we are going to need to make breaking changes either way and this is a great chance to do it properly for the 1.0.0 release of ACA-Py (that could have some breaking changes I guess).

We are probably also going to make some changes to the revocation API. A lot can stay the same, but some (like the revocation list model) will cause breaking changes). We could create a new API under /anoncreds/revocation, that is based on the existing api. If we move them under /revocation/anoncreds they're not in the generic 'revocation' domain, but focused solely on anoncreds revocation.

Lot of things to consider here. I think my main questions is: Can we create a new /anoncreds/ API in ACA-Py that is ideal for the new ledger agnostic anoncreds, or do we need to try to minimize breaking changes and adhere to the existing API as much as possible? If we want to make ACA-Py as generic as possible I'm leaning to break things now for the better, but I see the strategy of minimizing breaking changes to make updating easier.

cc @karimStekelenburg @blu3beri

[ianco]

Is it an option to leave all the existing API's as is (but deprecate them) and add a new anoncreds api which is ledger agnostic? @swcurran ?

Regarding continuing support for credx that's a question for @andrewwhitehead I think.

[TimoGlastra]

Is it an option to leave all the existing API's as is (but deprecate them) and add a new anoncreds api which is ledger agnostic?

I think that should be possible. We should probably change the underlying implementation a bit

[swcurran]

Here are my thoughts in reading this -- some ideas, nothing more.

I'd like us to consider dropping the indy-sdk entirely in ACA-Py 1.0 and only support the shared components. Any thoughts on that? Not particularly relevant to this question, but while we're talking about such a big breaking change, here are some others:

In a breaking change 1.0 release, we should consider making more adjustments to the startup parameters (e.g. making "emit-https-message-prefix" the default), and to the admin API to drop "old stuff". We might also consider determining what startup parameters should be updatable on the fly, and what ones should be updatable in a per tenant context. I don't think there are a lot of them, but we should check.

I do think we need to try to retain the existing Admin API handling "indyanoncreds-style" issuing and presenting. If we find that to be too complex, we have the "breaking change" excuse to fall back on. I don't know how the code is structured around the protocol messages and the handling of attachments, but I assume the attachment handling is where the impact will be. I'd like to note that I hope/expect we will be seeing "W3C Format AnonCreds" in the near future and the restructuring of the implementation issue-credential, present-proof attachment handling should include or anticipate that.

[swcurran]

With anoncreds-rs nearing completion, it is nearing time to replace the CredX implementation of AnonCreds with the new one in ACA-Py. We need to decide on the right way to add the new implementation such that anoncreds becomes ledger agnostic. We do not want to continue to use CredX from indy-shared-rs -- we want ACA-Py to only use the "proper" anoncreds-rs implementation.

Adding to what @TimoGlastra wrote above, my assumption is that in ACA-Py we want to support:

• The existing "Legacy Indy" implementation we have today. All AnonCreds operations will continue to work as is. The implementation must address the differences between the current Indy data structures and those expected by the anoncreds-rs implementation.
• A new did:indy based implementation will be added. In that, the new format for Indy DIDs (see this from did:indy spec) will be used, as will the new format for all of the object identifiers (see this from the did:indy spec.).
• Ideally, we will add a did:web AnonCreds Method resolver capability, supporting the objects being stored on a web server as per the did:web specification. The DID URLs for for the various AnonCreds objects should be the same as is specified for did:indy.
  • We would have to do something more advanced to do the registering of DIDs and AnonCreds objects using did:web. AFAIK, how that is to be done is undefined,.
  • We could also do the same for did:github, where the DIDs and AnonCreds objects are stored on GitHub.
• Document how to add support for new AnonCreds methods, to support others (such as Cheqd and Cardano) adding support in ACA-Py, likely through plugins

The reason for supporting numerous AnonCreds Methods out of the box is so that we are certain we have the right abstraction in the code -- that it is as easy as possible to add support for other Methods.

We also need a way to allow someone to define what AnonCreds Method they are going to use for an issuer -- for writing AnonCreds objects.

I had expected that the AnonCreds Methods would be from an external, shared repository that ACA-Py, other Aries Frameworks and other non-Aries components would call, and that component would call the appropriate SDK for the VDR they are using. E.g. the Indy one might support both legacy Indy and did:indy and both would use Indy VDR. However, in talking with @TimoGlastra and @blu3beri, they expect that the "AnonCreds Methods" will be added in ACA-Py, and not in a common repo, if for now other reason than having to have another set of Rust wrappers would be a pain.

Discuss...

@andrewwhitehead @ianco

[PatStLouis]

Here's a bold idea that was brewing in my head.

Originally, aca-py was exclusively dealing with indy cred (credx?) until a contribution was made by Animo to include json-ld VC. We are now looking at extracting Indy creds from the Aries library and re-implementing it as a stand-alone credential type/model.

Would it make sense to review the existing /credentials* endpoints with this fresh perspective? I've been following the w3c-ccg vc-api folks for some time and as an example they define the POST /credentials/issue endpoint. This endpoint takes a credential field and an options field, then returns a signed credential. Currently only w3c VC are defined but they made it clear they want to extend this to other credential types such as mDL (and, who knows, maybe eventually AnonCreds????). They definitely find the direction AnonCreds are going very interesting.

Now where I see potential is to define such endpoint (there is no POST /credentials/issue at the moment on aca-py, therefore wouldn't change any of the existing functionalities) and enable the issuance of both json-ld and anoncred through this endpoint, effectively implementing one of the vc-api endpoints, enabling 2 types of credential to be issued. It's also foreseeable that eventually, aca-py might benefit from issuing mDL credentials (another topic on its own).

This would also make Hyperledger and ACA-py an official implementation of the vc-api and open the door for other vc-api implementers to experiment with AnonCreds based on the shared components model defined by Animo's work, furthering global interoperability on the credential models scope.

The /anoncred endpoints suggested could still exist to lay the foundation necessary to issue such credentials (dealing with schemas/cred defs).

Here's an issue I opened sometime ago regarding multi-credential formats on the vc-api. As you can see, it's still unsure how this would be implemented but this would make a great use case to propose something back to the w3c-ccg vc-api group, at the very least identifying challenges and limitations to this approach. There will be some overlapping misconception based on each frameworks way of doing things (looking at you, CredentialStatusList2017 / revocation mechanisms). Which will require some work to iron out.

Curious to hear your opinions on this @swcurran @TimoGlastra @ianco

[swcurran]

Interesting ideas — definitely worth a discussion.

ACA-Py already has a version of the endpoint that you are talking about. /issue-credential/send is the end to end “issue credential” endpoint that supports AnonCreds and W3C Verifiable Credentials Data Model Standard credentials. It could be used as a kind of equivalent to the vc-api. However, I suspect that with vc-api, there is not a concept of issuer/holder back-and-forth messages to accomplish the issuance.

One simplification to the API that we might consider is to eliminate (or deprecate) the other per Aries Issue Credential protocol admin endpoints, and just assume that ACA-Py will handle the whole process. We’ve always had the other endpoints, but I’d be willing to bet no one is using them. The controller would only be contacted if something goes wrong. Something to consider.

As well, if we move AnonCreds to use the W3C Verifiable Credentials Data Model Standard, then we can further merge the processing.

Interesting topics.

[PatStLouis]

@swcurran Great points, here's some observations I can add for context based on questions I've myself asked and bits of information I was made aware of:

ACA-Py already has a version of the endpoint that you are talking about (POST /issue-credential/send)

• There are currently 3 POST /issue-credential/send endpoints defined (v1, v2 and v3) and afaik only v2/v3 support multi-format credential issuance/delivery.
• These endpoints differ from the POST /credentials/issue (vc-api) endpoint in that they also enable the delivery of said credential.
• The POST /credentials/issue (vc-api) is closer to the POST /jsonld/sign (aca-py) endpoint in design (which I believe was actually inspired by the vc-api).

However, I suspect that with vc-api, there is not a concept of issuer/holder back-and-forth messages to accomplish the issuance.

• This is exactly what the vc-api is trying to address. Looking at the VCWG charter:

  • One or more HTTP protocol definitions for Verifiable Credential Exchange (such as the VC-API), along with OIDC/GNAP

• In w3c/vc-api terminology, the issuance of a credential refers to the act of the issuer signing a credential and adding a verifiable proof. The action of getting this resulting VC into the holder's wallet is referred as delivery and would be done through an exchange endpoint POST /exchanges/{exchange_id}, which I suspect correlates to didcomm messaging. This is a vocabulary divergence we unfortunately have to live with. This is also where Aries/Aca-py is miles ahead, but currently somewhat limited to it's own ecosystem.

• The exchange endpoint could also cover some authentication mechanism such as Oauth2.