feat: add anoncreds-rs package

[genaris]

Finally, the long-awaited @aries-framework/anoncreds-rs has come! It implements the main three services and can be start being used for integration with the new AnonCreds API.

Summary of the changes done:

• Add AnonCredsRsModule, which registers automatically anoncreds-rs bindings (as in askar and indy-vdr) and its three services to DependencyManager. We were discussing about making this module inherit AnonCredsApi but this is not done yet
• AnonCredsRsHolderService fully implements AnonCredsHolderService interface. We are not yet supporting all restriction types: we miss attr::<attribute-name>::marker and attr::<attribute-name>::<attribute-value>
• AnonCredsRsIssuerService implements all methods from AnonCredsIssuerService interface, but currently does not support revocation parameters
• AnonCredsRsVerifierService implements the only method from AnonCredsVerifierService
• AnonCredsCredentialRecord and AnonCredsCredentialRepository have been added to @aries-framework/anoncreds package. In order to fully support restriction queries, maybe it will be needed to add more tag types
• In addition, there is a change in the data model of Revocation Registry Definition (it should be now according to spec).
• CI has been updated to use Ubuntu 22.04 as a base, because anoncreds-rs currently requires glibc 2.33 (released in 2021). In order to achieve that, some tweaks have been done, as indy-sdk uses libssl 1.1 and Ubuntu 22.04 enforces libssl 3

As you can see, there are a lot of JSON.stringify and JSON.parse when calling anoncreds-rs. I think it will be nice to update its JS wrapper API to be more adapted to typical usage (for instance, create fromJSON() and toJSON() with JS objects as input/output and fromString() and toString() with strings as input/output).

In terms of performance, it would be nice to avoid some FFI calls to optimize it, but I'm under the impression that in this case the performance is more limited by crypto calculations than memory management between Node and Rust layers.

[AlexAndrei98]

@genaris awesome work! Excited for the refactoring! As I am looking though the files it’s still not clear to me where the ledger transactions are happening? If I wanted to plug in cheqd and the cardano drivers what’s the entry point to do that? It seems to me that the Indy driver is embedded in the anoncreds-rs repo but I may be wrong since I’m not familiar with rust! Thank you!

[genaris]

@genaris awesome work! Excited for the refactoring! As I am looking though the files it’s still not clear to me where the ledger transactions are happening? If I wanted to plug in cheqd and the cardano drivers what’s the entry point to do that? It seems to me that the Indy driver is embedded in the anoncreds-rs repo but I may be wrong since I’m not familiar with rust! Thank you!

Thanks! We are pretty close to complete the puzzle. We can probably discuss about it in next WG call, but basically the idea is that AnonCreds module (@aries-framework/anoncreds) is the 'orchestrator' of all AnonCreds stuff, and allows to plug-in different services for credential processing (issuance/proof/verification) and also registries (interfaces to fetch and register objects in ledgers, such as schemas and credential definitions). This PR is about the first: uses anoncreds-rs for all low-level cryptography needed to process credentials. This is valid for any AnonCreds registry (a.k.a. ledger) you might use: actually, in the unit tests we are simply using a local, in-memory AnonCreds registry.

For integration with Cardano, Cheqd and other VDRs, you will need to create your own implementation of AnonCredsRegistry interface and register it into the AnonCreds module. This is the equivalent of the work being done in #1270 for Indy VDR.

In addition, you may need to create a DID Registrar and a DID Resolver for your ledger and register them in Agent's didsModule. So I would say that a future @aries-framework/cardano or @aries-framework/cheqd-sdk will have a similar structure to @aries-framework/indy-vdr. And hopefully it will be very straightforward to integrate once we have a fully working Agent setup using aries-askar and anoncreds-rs as backends for storage and credential processing respectively.

[TimoGlastra]

@karimStekelenburg if you want to have some input on the name, now is the time!

[TimoGlastra]

As you can see, there are a lot of JSON.stringify and JSON.parse when calling anoncreds-rs. I think it will be nice to update its JS wrapper API to be more adapted to typical usage (for instance, create fromJSON() and toJSON() with JS objects as input/output and fromString() and toString() with strings as input/output).

I made this issue: hyperledger/anoncreds-rs#103. The API is a bit weird here

[TimoGlastra]

Awesome!! Great work @genaris

[TimoGlastra]

We also have deleteById now I think. Or do you do this so an error is thrown if it doesn't exist?

[genaris]

This is because I'm not using AnonCredsCredentialRecord.id but a separate AnonCredsCredentialRecord.credentialId. However, I don't see the benefit on having a dedicated property for credentialId in this case, so I'm thinking on simplifying it and just use the id. What do you think?

[TimoGlastra]

I think it could work. However it has caused issues for me in the past. E.g with using the did as an id for a record 🤦

But as we always generate an uuid I think we should be fine here?

[genaris]

Yeah exactly, we are always doing so internally, either at xxxFormatService or xxxHolderService.

[genaris]

But still, based on previous experiences maybe it will be better to keep it as is and conceptually separate the storage record Id from other queries.

[TimoGlastra]

Shouldn't this be inversed?

So

Suggested change

	$and: [{ $or: [{ schemaId: 'schemaid:uri' }, { schemaName: 'schemaName' }] }, { schemaVersion: '1.0' }],
	$or: [{ $and: [{ schemaId: 'schemaid:uri' }, { schemaName: 'schemaName' }] }, { schemaVersion: '1.0' }],

The restrictions array is an or, but if you have multiple properties in a single restrictritction object they should all be present on the same credential.

[TimoGlastra]

And couldn't we simplify the query by just creating a single object with the different properties for a single restriction object?

[TimoGlastra]

So write it like this:

Suggested change

	$and: [{ $or: [{ schemaId: 'schemaid:uri' }, { schemaName: 'schemaName' }] }, { schemaVersion: '1.0' }],
	$or: [
	{
	schemaId: 'schemaid:uri',
	schemaName: 'schemaName'
	},
	{
	schemaVersion: '1.0'
	}
	]

[genaris]

This is the part I struggled the most, as it was not clear for me the logic expression ordering based on the specification. In AnonCreds spec it provides an example and states: The properties in each list item are OR’d together, and the array elements are AND’d together.. Is it an error in the spec or am I interpreting incorrectly?

[TimoGlastra]

I've asked Stephen in discord. That seems incorrect to me

[TimoGlastra]

This will only store the credential attribute names right? I think to support all query types we have to store both the attribute name (so we can check if it exists), but also the value.

We can also do that in post filtering, as we do with JSON-LD creds, but it's a bit less efficient

[genaris]

Yes, I kept only the names for the moment. I'm a bit reluctant on storing values as tags because I feel it's very arbitrary in terms of content length and amount, and with current implementation we are restricted to a single tag containing strings that are supposed to be short.

Also I don't imagine a case where a holder has hundreds or thousands credentials matching a query, that usually will include not only attribute names but also issuer/credentialDefinition/schema Ids. Do you think it could become common?

In regards to this topic, note that AnonCredsRsHolderService.getCredentialsForProofRequest currently is not taking into account predicates p_type and p_value (e.g. for a given predicate, it will return all credentials that matches its name and restrictions). Is this OK (meaning that this will be checked in another layer) or should it manually process all predicates and only return those matching the logical conditions?

[genaris]

Update: I see I missed the attr::<attribute-name>::marker and attr::<attribute-name>::<attribute-value> from the spec. So we should either:

• add as many tags as attributes the credential has, or
• filter it in AnonCredsRsHolderService after doing the findByQuery