Add anoncreds issuance and presentation format

[jamshale]

This adds issuance and presentation anoncreds formats which use the anoncreds registry.

Any anoncreds issuer must use this format as the anoncreds objects the format uses are saved in the wallet in the anoncreds way.

There is some backwards compatibility for a holder which isn't anoncreds capable. It will fall back to the indy handlers. Any holder that needs to use anoncreds objects which are not indy will need to use the askar-anoncreds profile. Any holder that uses the anoncreds format will need to be updated to a version of acapy which includes this PR.

There is a lot of duplication because I copied the Indy objects and added them to the anoncreds module and removed any indy references. I think this is better than trying to rename them and share them amongst indy and anoncreds modules. The indy module should be able to be pulled out as a plugin once depreciated.

The object examples have anoncreds examples now. They have there own validation, but it's not actually validating anoncreds objects. I'm not sure if there is validation patterns we can use for anoncreds schemas, cred defs and revocation objects or not.

There is a scenario test for anoncreds issuer doing issuance and presentation with a anoncreds and a non-anoncreds holder.

These will need to get interop OWL-ATH tests.

[dbluhm]

LGTM. The duplication is indeed a bit of a bummer but I agree that it's probably better than trying to get everything to line up cleanly and makes popping the indy implementation out of ACA-Py into a plugin in the future easier.

[dbluhm]

I approved but we have test failures that should be resolved before merging.

[jamshale]

Added support for the demo but still need to fix the integration tests. Not sure why the scenario test is failing with github actions and the BDD tests need to be updated.

The OATH tests should be updated with an askar-anoncreds wallet. These should be testable against a credo holder, and should work with a credo issuer and acapy holder as well if the objects are consistent with the indy format.

[jamshale]

I removed the BDD tests for issuance and presentation after the anoncreds upgrade because the anoncreds check uses the agent context object which hasn't been updated. I'm going to try and figure out how to do that and add them back.

The classes I moved and renamed from the indy module to the anoncreds module aren't unit tested. I don't think this is much of an issue because they are pretty much the same as the ones in the indy module that are unit tested. I might try and copy some tests as well as they would be good to have if they indy module gets pulled out. Don't think this should be required to get this merged though.

[ianco]

Question regarding interoperability - should an agent using an "askar" wallet be able to send/receive a presentation request/presentation from a holder that has received an anoncreds credential? (And the other way - an "askar-anoncreds" agent asking an agent with an "askar" wallet for a proof?)

Also what should happen if an "askar-anoncreds" agent issues to an "askar" holder and the other way around?

[jamshale]

Question regarding interoperability - should an agent using an "askar" wallet be able to send/receive a presentation request/presentation from a holder that has received an anoncreds credential? (And the other way - an "askar-anoncreds" agent asking an agent with an "askar" wallet for a proof?)

Also what should happen if an "askar-anoncreds" agent issues to an "askar" holder and the other way around?

Issuer (askar) --> Holder (askar-anoncreds): This issuer won't be able to issue or request a presentation using the anoncreds format because of the wrong wallet type (schema and cred def tables are different). However, the agent can use the indy format still and the credential will work. I think this is still tested but I should make sure.

Issuer (askar-anoncreds) --> Holder (askar): This works and is tested. The holder falls back to the indy handler in specific areas where it needs to, for both issuance and presentation flows.

Both issuer and holder need to be on the lastest version (have this code) for the anoncreds format to work regardless of wallet type.

[jamshale]

@ianco

I just looked at Issuer (askar) --> Holder (askar-anoncreds) and it looks like there's a problem here with issuance. There was a test but it was only running on release. I'll try and fix this scenario.

[ianco]

FYI @jamshale the "1a" was added to the demo to support this kind of interoperability testing. (Available to an askar-anoncreds issuer only - this toggles between Anoncreds/Indy credentials and presentation requests. So as Faber I can issue an Anoncreds credential, select "1a" to switch to Indy, then issue an Indy presentation request. And vice versa.)

I did a quick test and when I sent the Indy presentation request I got an error: Problem report message: This issuer is anoncreds capable. Please use the anonreds format..

We should probably setup a table with the various options to define what is supported or not (and also we need to confirm that other Aries wallets support the same scenarios.)

• issuer wallet type
• holder wallet type
• credential type (Indy or Anoncreds)
• verifier wallet type
• presentation type (Indy or Anoncreds)

Maybe this is already defined somewhere? @swcurran ?

Also I recall that we also assume that all Indy credentials are updated to Anoncreds format when the wallet is upgraded? (At least I think the Javascript framework does this, I don't recall if we implemented this for Aca-Py or not.)

PS Regarding the 1a description above, I also recall adding this to a couple of integration tests ...

[jamshale]

That error was expected. I don't think it's possible for an askar-anoncreds agent to use the indy format handler after it's been upgraded to anoncreds. Before the indy format was just re-routing it to the anoncreds handler. I thought forcing the anoncreds issuer to use the explicit format would be better than keeping the indy format switching over to the anoncreds handler.

The original plan was to completely remove the indy format according to the comments. I wanted to keep both for backwards compatibility. But having both and trying to force indy format to re-route to anoncreds handler caused problems.

Also, I don't believe the credentials need to be changed for an anoncreds upgrade. I'll take a closer look at the wallets, but I'm pretty sure they are consistent.

[jamshale]

I'll create a table with the compatibility matrix after I fix this issue of issuer (askar) --> holder (askar-anoncreds)

[jamshale]

Added an ugly commit. Will be working on further testing and refactoring still.

Issuer (anoncreds) --> use anoncreds format --> works with both (indy, askar wallet type) and anoncreds holder.
Issuer (indy, askar wallet type) --> use indy format --> works works with both (indy, askar wallet type) and anoncreds holder.

[ianco]

Added an ugly commit. Will be working on further testing and refactoring still.

Issuer (anoncreds) --> use anoncreds format --> works with both (indy, askar wallet type) and anoncreds holder. Issuer (indy, askar wallet type) --> use indy format --> works works with both (indy, askar wallet type) and anoncreds holder.

Tested using the alice/faber demo, everything is looking good ...

Question - is this a "breaking" change? (i.e. will the controller need to be updated if they are currently using the "old" indy format?

[jamshale]

It is a breaking change for anoncreds (wallet type askar-anoncreds) issuers. They will need to change their formats to anoncreds for issuance and presentations.

Any other type of agent is unaffected. Although holders will need to be upgraded to the latest version to handle the anoncreds format. I don't think there's any way to avoid this.

[jamshale]

Scenario test has been expanded. It won't pass currently because of a bug with tails upload. See #3346.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 Security Hotspots
8.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[ianco]

@jamshale is this PR ready to go or are you still working on it?

[jamshale]

@ianco It should be good to go. It has pretty thorough testing now.

I'll add some more documentation at some point but that can be a separate PR.

[jamshale]

Some of the stuff I had to do for compatibility is a bit ugly. But one day it can be removed.

[ianco]

Some of the stuff I had to do for compatibility is a bit ugly. But one day it can be removed.

I agree we should make it easy to pull out the "indy" specific code.

[ianco]

LGTM