Use anoncreds library models instead of ledger models

[TimoGlastra]

The spec currently shows an example of a credential definition as it is registered on the indy ledger (with an example link to indyscan): https://anoncreds-wg.github.io/anoncreds-spec/#generating-a-cred_def-without-revocation-support

However the AnonCreds part of the indy-sdk and also the credential definition type as defined in indy-data-types is different from this model, and is the model that you pass when working with the indy-credx/indy-sdk libraries.

I think we should follow the library type interfaces as those are the ones need by the anoncreds library. What is stored on the ledger could be different.

See https://github.com/hyperledger/indy-shared-rs/blob/main/indy-data-types/src/anoncreds/cred_def.rs#L54-L60

Here's an example of the cred def as we're storing it on cheqd. The AnonCredsCredDef part is exactly what is used by indy (with a cheqd identifier in this case). https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:z5S1LLTkKwdQkRFr7FQNw5pAtBXxdRhp/resources/b59553eb-afb9-4c35-bacc-3ae749617b03

[swcurran]

I'm good with that -- agree it is needed. It was more or less my goal in the items from an Indy ledger that I included, but making it even more AnonCreds-centric is the right thing to do. Obviously, the value item needs to be fully expanded, which is nicely shown in the Cheqd example.

So what we need is the full set of data models at the AnonCreds interface -- what gets handed to the AnonCreds VDR Method, and what gets received from that. Most of that is pretty straight forward AFAIK, perhaps with the exception of the RevRegEntry.

@TimoGlastra -- perhaps you could please find the rest of the data models referenced in the indy-shared-rs implementation?

@andrewwhitehead -- heads up about this, and the idea of restructuring the CredX implementation to make clear the interface between AnonCreds and the AnonCreds VDR Methods (including legacy Indy, did:indy, cheqd and so on). This is relevant for this "ledger agnosticism" PR in ACA-Py.

Input welcome from others that have created non-Indy AnonCreds implementations, such as @pasquale95, @lauravuo-techlab, @techlab-lainio and @DaevMithran. Our goal is to enable the placement of AnonCreds objects in a variety of places. What would your implementation look like if you had a clear interface between AnonCreds and the VDR you choose?

[pasquale95]

Not really sure I understood the problem, but I'll try to answer anyway regarding our implementation on ACA-Py from a developer perspective.

The aries_cloudagent.ledger.base.BaseLedger class exposes two methods:

• create_and_send_credential_definition (https://github.com/pasquale95/aries-cloudagent-python/blob/feature/ledger_agnosticism/aries_cloudagent/ledger/base.py#L408-L417) to create and write the credential definition on the ledger;
• get_credential_definition (https://github.com/pasquale95/aries-cloudagent-python/blob/feature/ledger_agnosticism/aries_cloudagent/ledger/base.py#L533) to retrieve a credential definition.

The writing function prototype is quite self-explaining in defining what inputs are needed to generate a credential definition, but the same cannot be claimed for the reading function prototype which only forces to return a generic dict. Having a well-defined and common interface for a credential definition (let's say an interface named AnonCredsCredDef) could be used to be more specific when we define the reading method that would become then something like:

async def get_credential_definition(self, credential_definition_id: str) -> AnonCredsCredDef:

At this point it would be responsibility of the specific VDR class implementation to adjust the data coming from the ledger inside the common AnonCreds credential definition interface and the developer implementing such class will know already what's the common data model to follow.

An example how what I mean can be this return value in the Indy VDR ledger implementation:
https://github.com/pasquale95/aries-cloudagent-python/blob/feature/ledger_agnosticism/aries_cloudagent/ledger/indy_vdr.py#L572-L579

This reasoning would apply also to the other resources on the ledger (schemas, revocation registry definitons and deltas).

Hope I touched the right points, if not the case just let me know.

[DaevMithran]

@swcurran I agree with @TimoGlastra on this, the identifiers should be independent to the anoncreds module, using the library type interfaces will make it more abstract and generic

[swcurran]

At the Working Group Meeting today, we agreed that we need an Abstract API that defines the interface between the AnonCreds library with the write/read methods. Once we have that we can tune the specification to be explicit the use of that.

So -- we need the definition for the (I think) 8 API points -- Read/write for each of Schema, CredDef, RevRegDef and RevRegEntry. As note above, I'm looking for a volunteer to formalize those. Initially, I think adding them to this issue is fine, and then we'll get them into the spec.

[DaevMithran]

I'll nominate @Zzocker to do this.

[swcurran]

I believe this is done, but will verify in a last pass of the specification.