LedgerService to AnonCredsResource Service

[TimoGlastra]

As we want to support other ledger types with AnonCreds credentials we need to generalize the IndyLedgerService. #971 already extracts the indy ledger service methods into a ledger service interface. To fully make it generic I propose we also take the following steps:

• Rename LedgerService -> AnonCredsResourceService. This better reflects that it is only about anon creds, removing ledger means the resources could possibly be hosted on an http server. This is just to remove assumptions about the anoncreds setup
• Remove the did methods from the interface (registerPublicDid, getPublicDid, and getEndpointsForDid this should be handled through the DidsModule from now on.
• Add an initialization method that generically initializes the service. The indy anoncreds resource serevice could use this to connect to the pools, which is not needed for all implementations
• [Optional]. Not sure if this is the right approach, but maybe we should separate creating the credential definition from submitting it to the resource service. This would mean the implementation of a resource service would become much simpler as it is only about read / write. However different ledgers have different id formats so it would be something we'd need to figure out how to do generically.
• Option to register multiple anon creds resource services in a module. It should also be possible to somehow link a resource service to a specific identifier. E.g. if we have did:indy it should use the indy one. I think a regex would work best here that a resource interface has to implement. We could also tie it to a did method, but that would mean we can't use anoncreds resources that are not based on dids.
• We should add another layer that combines all the resource services and pick the correct one when resolving/registering an anon creds resource. Like we have for dids where I use the resolver service and it pick the correct resolver based on the did method (in this case it will be the regex). this is also what should create/store the records created for schema/cred defs as @morrieinmaas recently implemented, so the records are also created/checked for internal calls.

This is the first ticket for generalizing services for anon creds, the indy issuer/holder/verifier services will follow afterwards.

Thoughts?

[swcurran]

Good to see this initiated. Please make sure as you progress on this that you let the AnonCreds Specification Working Group know what you discover (see the in progress AnonCreds Specification, and the associated repository ). We're having a number of conversations there, and in the ACA-Py User Group about this, and folks in the ACA-Py community are building a similar capability. I hope to get an AnonCreds Objects RFC into the Aries RFC repo Real Soon Now to make sure we're all going down the same path. AATH also needs to add tests for this across Aries Frameworks.

As part of that work, we're defining an "AnonCreds Objects Methods" registry -- that is comparable to the DID Method registry -- for now, there is a pull request that has an example of the registry (I'll update this when the repo for the registry is created). The registry entries link to definitions of how to register AnonCreds objects to a given Verifiable Data Registry (VDR), and how to resolve AnonCreds objects, given an identifier for those objects. As you note, those registration/resolution MAY be part of a DID Method, but they don't have to be.

We've already proposed 4 AnonCreds Objects Methods, each with different forms of identifiers that should be relatively easy to at least resolve (writing/registering may be more interesting):

• Legacy Indy (the identifiers we know and use to this point) -- this is the ONLY identifier that is NOT a URI
  • The rest of the Methods must use URIs, but we keep this one for backwards compatibility
• did:indy identifiers -- which are different from what we use today (see: https://hyperledger.github.io/indy-did-method/#other-indy-ledger-object-identifiers)
• HTTP -- e.g. the identifier is a URL
• cheqd -- based on the AnonCreds work on the ledger being done by cheqd folks.

I think did:web would be relatively easy to add, but I don't know the spec well enough yet.

Comments welcome!!

[berendsliedrecht]

Definitely in favour of this separation. In regards to point 4, I think we should do that if it does not cause too much overhead. Making a new resourceService should be as easy as possible. A couple of AFJWG calls back we saw an integration with Fabric. They did a lot of custom work around and it if we really want to see more support for different resources we should definitely put some work in the interface.

[genaris]

Absolutely agree on going on with this generalization now, especially considering that we are not so far away from starting integration with Indy shared components.

In Aries world I'm more familiar to the term Verifiable Data Registry as a generic replacement of Ledger, so I'd prefer the service rename to AnonCredsVDRService or AnonCredsRegistryService. I think other Aries frameworks (such as the Go) are using this naming also.

[berendsliedrecht]

In Aries world I'm more familiar to the term Verifiable Data Registry as a generic replacement of Ledger, so I'd prefer the service rename to AnonCredsVDRService or AnonCredsRegistryService. I think other Aries frameworks (such as the Go) are using this naming also.

I would also give my preference to either of those. Maybe I would lean slightly towards AnonCredsVDRService as the Verifiable is an important part. If we would allow "non-verifiable", not sure on the use case, then AnonCredsRegistryService would be better.

[TimoGlastra]

As you can see in this PR to the AnonCreds spec: https://github.com/AnonCreds-WG/anoncreds-spec/pull/64

there will be support for fetching anon creds objects from an http server in which case it won't be verifiable. So we should probably go with AnonCredsRegistryService then. This will be the generic service that allow to work with multiple AnonCredsRegistry implementations (like we have DidResolverService and then multiple DidResolver implementations for the different did methods.