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

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.

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.

Quality Gate failed

Failed conditions
1 Security Hotspot
9.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

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?

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.

@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.

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 ...

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.

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