Presentation Exchange is Verified but UI shows error

[MonolithicMonk]

Given a requester using the BPA, and the requester requests a proof from a partner, When the partner responds affirmatively to the proof request, and the partner uses a mobile wallet to respond, Then the following should occur:

1. In Partner view, within the Proof Exchanges With This Organization tile, the State should be "verified" with a success icon next to it
2. In Presentation exchange popup after clicking an exchange transaction, the header should read: "This presentation is valid"

Actual result:

1. A failure icon appears

2. Presentation is not valid header appears

[etschelp]

Can you give me more information about what version of the BPA you are using, and with which wallets you are interacting? If you are using the latest version from the main branch it was using acapy-0.7.4-rc2 which had several issues related to presentation exchanges. I upgraded to rc4 where these issues have been fixed.

[MonolithicMonk]

BPA Image used: ghcr.io/hyperledger-labs/business-partner-agent-new:sha-adb2416 ACAPY Image used: bcgovimages/aries-cloudagent:py36-1.16-1_0.7.4-rc0 and prior

[MonolithicMonk]

GET ${ADMIN_URL}/present-proof/records/{pres_ex_id} returns seemingly contradicting information

{ 
  "verified": "false",
  "state": "verified"
}

I wonder if that's causing the error. I will upgrade to newer acapy version as you've suggested

[MonolithicMonk]

After upgraded to images ghcr.io/hyperledger-labs/business-partner-agent-new:sha-2923c3d and bcgovimages/aries-cloudagent:py36-1.16-1_0.7.4-rc4, I am still getting the same error indicators.

In addition the contradicting information from the present-proof url persists

[swcurran]

The "contradiction" you are seeing isn't really -- it is two separate pieces of data. "verified": "false" means that after running the presentation through the verification process, the result was that the it was not a valid presentation -- e.g. something didn't check out in the cryptography. The "state": "verified" means that the cryptographic verification process has been run.

[MonolithicMonk]

@swcurran is there additional logging I should be looking for that will help me debug this issue? I missed a question from @etschelp about the wallet I'm using. I'm using the Lissi Wallet and I don't know if or anything that does to the cryptographic integretity of the credentials.

In my test from BPA to BPA, the proof verification works flawlessly. Which makes me further suspect that the issue lays in the way BPA and wallet's interact

[etschelp]

I can reproduce this with revocable credentials. The issue is:

2022-06-22 15:50:45,137 aries_cloudagent.indy.sdk.verifier ERROR Presentation on nonce=945433899702373895034122 cannot be validated: Timestamp on sub-proof #0 is missing vs. requested attribute group UmZ25DANwS6ngGWB4ye4tN:2:BankAccount:0.1

This is related to https://github.com/hyperledger/aries-cloudagent-python/issues/1455 and is basically correct behaviour as the Lissi wallet sends wrong data.

My last info was that this was fixed on their end, when I have time I will retest with the Android version which is newer.

[MonolithicMonk]

You nailed it @etschelp. I created a non revocable credential definition and proof exchange now works as expected.

I should also add that my tails file links were broken so I am currently looking into serving tails using acapy. I didn't even know acapy had this feature.

[etschelp]

Concerning the broken tails file links this is something I noticed as well, and it happened when upgrading from rc3 to rc4, this needs further investigation.

How can acapy serve tails files, is this another plugin?

[MonolithicMonk]

I misunderstood that a PUT to /revocation/registry/{rev_reg_id}/tails-file endpoint to mean that a tails file can be uploaded to acapy storage using that endpoint and served from the /revocation/registry/{rev_reg_id}/tails-file endpoint.

[MonolithicMonk]

Update...

I initially tested the BPA proof verification flow using Lissi wallet on numerous ledgers ( BCGov Test, BCGov dev, Bosch Test) and verification failed as described above. After updating to the latest version of Esatus wallet (version 1.12), I retested using Esatus and it works as expected.

I should add that testing with Esatus was only possible using built in ledger network like BCGov Test Ledger. Connection request failed using the Bosch test network therefore verification test was impossible.

Please close this issue if appropriate