-
Notifications
You must be signed in to change notification settings - Fork 516
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add anoncreds issuance and presentation format #3331
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I approved but we have test failures that should be resolved before merging. |
bb4441a
to
7eacdfa
Compare
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. |
e9a0785
to
e922f06
Compare
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. |
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 Issuer (askar-anoncreds) --> Holder (askar): This works and is tested. The holder falls back to the Both issuer and holder need to be on the lastest version (have this code) for the anoncreds format to work regardless of wallet type. |
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 I did a quick test and when I sent the Indy presentation request I got an error: 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.)
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 |
That error was expected. I don't think it's possible for an askar-anoncreds agent to use the The original plan was to completely remove the 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) |
Added an ugly commit. Will be working on further testing and refactoring still. Issuer (anoncreds) --> use |
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? |
It is a breaking change for anoncreds (wallet type askar-anoncreds) issuers. They will need to change their formats to Any other type of agent is unaffected. Although holders will need to be upgraded to the latest version to handle the |
Scenario test has been expanded. It won't pass currently because of a bug with tails upload. See #3346. |
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Signed-off-by: jamshale <[email protected]>
Quality Gate failedFailed conditions |
@jamshale is this PR ready to go or are you still working on it? |
@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. |
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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.