-
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
Proof presentation with check for revocation, always invalid when requesting multiple credentials #2036
Comments
Thanks for the report -- this a big deal if true. Do you have a test case that you can share? If not, we will build one up, but it would good to know if you had it in place already. I'm hoping we can use Aries Agent Test Harness and BDD tests to cover the range of tests needed. |
FYI -- @WadeBarnes reports that they have run tests with multiple revocable credentials with ACA-Py and have been successful at getting the presentations to verify when the credentials are not revoked. |
Details here in this (bcgov/bc-wallet-mobile#762) ticket, specifically the |
thanks, I will check this. So far we have done manual tests with the Lissi agent to create the credentials and presentation requests, and as holder simply an ACA-Py instance that automatically accepts and responds to requests. This is what one of the requests looks like:
|
I also just tested it by requesting two credentials + non-revocation checks. Unfortunately, AcaPy is returning that the presentation is invalid. When requesting each credential + non-revocation check individually, the AcaPy reports two valid presentations. The presentation result returned by the AcaPy is the following
|
@ianco -- I think this has to bump in priority vs. the mediator testing this week. I think the best approach to resolve this is probably what I proposed in Aries Agent Test Harness Issue 605, so we can debug what is happening and see if the problem has always been there or was added in a specific version. And we can test other Frameworks for the same issue. @nodlesh -- heads up on this and the priority of that test. |
ok |
Timestamp parameters are things I don't understand fully. So, I'm not sure but the fact that the timestamp in the proof request was I suppose the timestamps of the proof should be larger values than the requested timestamp for non-revocation. |
Ah.. I found out where the error comes. |
@ianco -- ^^^ |
Sorry. I was wrong. My previous comment about creating revocation state was also incorrect, so please ignore that too. 😞 |
I've added some integration tests to cover the multi-credential-proof scenarios, here is a summary, let me know if you think there are other scenarios we need to include in the tests:
These tests are all aca-py to aca-py, it sounds like you're testing with the Lissi wallet (?) ... It would be great if you could replicate using aca-py (or let me know the specific scenario and I can try to tweak the integration tests) as this is easier for us to verify/automate. |
We tested as well using aca-py to make sure it was not an issue of the wallet.
|
I've add this scenario like this:
And I ran the test like this:
The test failed with the following error logs:
Is there a way to print out debug messages from indy-sdk? I tried adding |
I also ran the test |
Hi, has there been any evolution regarding this issue? I'm doing some tests with two non-revoked revocable credentials and I have the problem of which I attach below the stack trace. I used two Aca-py askar and they all have the same problem. Thanks for any kind of support you can give me. 2023-06-23 10:19:11,202 aries_cloudagent.indy.credx.verifier ERROR Validation of presentation on nonce=82000675796637021791301 failed with error |
The issue was found to be in Indy CredX, part of the indy-shared-rs repo (https://github.com/hyperledger/indy-shared-rs). The issue is fixed in Release 0.3.3. Updating the ACA-Py requirements should address this. |
When doing more tests with revocable credentials (but not revoked), we have noticed that if we request more than one credential with a revocation check, the result is always invalid.
For the following requests we expected a valid proof, but they were invalid:
It appears that if more than one credential needs to be checked for revocation, the proof is invalid. We reported a similar issue when one of the credentials was non-revocable, #1651 .
The text was updated successfully, but these errors were encountered: