Initial code migration from anoncreds-rs branch

[ianco]

No description provided.

[swcurran]

@ianco FYI: all of the AATH ACA-Py to ACA-Py tests pass on for this PR.

[ianco]

@ianco FYI: all of the AATH ACA-Py to ACA-Py tests pass on for this PR.

Thanks for the info! This is basically a non-destructive PR so that's good news. There are still a couple of unit tests failing and I need to "hook in" the anoncreds stuff so it gets initialized on startup (and also review the unit test coverage of the new code) before this PR is finalized ...

[ianco]

I think this PR is ready to merge. It adds the new "anoncreds" code and is non-destructive (demo, unit and integration tests still run).

I still need to hook up the anoncreds code to aca-py startup and inventory the unit tests in the new anoncreds package but I think I can do that in the next PR.

[swcurran]

We need to hold off on this until we get the 0.11.0 release completed, so I moved this back to Draft. Reviews are welcome though!!

[ianco]

We need to hold off on this until we get the 0.11.0 release completed, so I moved this back to Draft. Reviews are welcome though!!

OK sounds good. I'll keep working on this PR in the meantime ...

[ianco]

Added a few comments regarding unit test scope, I think we need to add some but not go overboard. I suggest:

• updating the routes unit tests (adding tests for the main routes)
• adding unit tests for the main issuer, holder and verifier classes

There are already a few tests for the registries, and there are existing tests elsewhere in aca-py similar to the ones we need to add for aca-py, that whoever is going to be working on the unit tests can use as a model.

[ianco]

Question for @dbluhm @andrewwhitehead @swcurran ...

For the V20 credential Format enum (which is defined here: https://github.com/hyperledger/aries-cloudagent-python/blob/main/aries_cloudagent/protocols/issue_credential/v2_0/messages/cred_format.py#L31) ...

... I had initially thought of adding a new Enum for ANONCREDS (in addition to INDY) but after some noodling in the code I now think the INDY enum should depend on which wallet type is selected (askar vs askar-anoncreds).

If askar (the existing code) (or if running wallet type indy although this is deprecated):

        INDY = FormatSpec(
            "hlindy/",
            V20CredExRecordIndy,
            DeferLoad(
                "aries_cloudagent.protocols.issue_credential.v2_0"
                ".formats.indy.handler.IndyCredFormatHandler"
            ),
        )

If askar-anoncreds:

        INDY = FormatSpec(
            "hlindy/",
            V20CredExRecordIndy,
            DeferLoad(
                "aries_cloudagent.protocols.issue_credential.v2_0"
                ".formats.anoncreds.handler.AnonCredsCredFormatHandler"
            ),
        )

@dbluhm are there differences in the attachment when using the new anoncreds library?

(PS the AnonCredsCredFormatHandler is the updated IndyCredFormatHandler from the anoncreds-rs branch)

[dbluhm]

We opted to continue using the existing indy format, at least initially. I think it makes sense to eventually phase out any use of "indy" as a stand in for "anoncreds" but I think that's a later problem. There are no differences in the attachment when using the anoncreds library.

[swcurran]

The fun in this is that if the AnonCreds in W3C format comes in soon enough, perhaps we can just use W3C format for everything…

[ianco]

The fun in this is that if the AnonCreds in W3C format comes in soon enough, perhaps we can just use W3C format for everything…

Is this going to affect the wire protocol (agent-to-agent messages) or just the payload to the issue credential api?

[ianco]

We opted to continue using the existing indy format, at least initially. I think it makes sense to eventually phase out any use of "indy" as a stand in for "anoncreds" but I think that's a later problem. There are no differences in the attachment when using the anoncreds library.

This is good. The api format won't be affected by the switch from askar to askar-anoncreds then.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[ianco]

@swcurran all tests passed

[swcurran]

w00t!!