aries-cloudagent-python: Proof request with none_revoked restriction returns valid=true even though the credential has been revoked
I tested this with the latest Lissi wallet and aca-py 0.7.2-rc0.
Steps to reproduce.
- aca-py is started with a configured tails server, a cred def with revocation registry is created
- Connect aca-py with the Lissi wallet
- Issue a credential
- Revoke the credential
- Send a proof request with none_revoked restriction and a timestamp that is after the revocation from step 4
- Lissi wallet says credential has been revoked, but we send it anyway
- aca-py says proof is valid, but the verified field should be set to false in this case
In the aca-py logs I see the following
2021-10-21 13:57:37,745 aries_cloudagent.indy.verifier INFO Amended presentation request (nonce=1056466064839133135704935): removed non-revocation interval at requested_attributes referent Mz2w979BSbBb8SGihvYbYy:2:Bank Account:1.0; corresponding credential in proof is irrevocable
2021-10-21 13:57:37,745 aries_cloudagent.indy.verifier WARNING Amended presentation request (nonce=1056466064839133135704935); removed global non-revocation interval; no revocable credentials in proof
This is most likely a version incompatibility issue between agents. When I look into the verifier.py I see that it checks for the existence of a timestamp field in the identifiers section of the presentation request that is retrieved via the sub_proof_index. If this field is missing from the response of the other agent the none revocation check is skipped.
Response from Lissi that is not working
"presentation": {
"requested_proof": {
"revealed_attrs": {},
"revealed_attr_groups": {
"Mz2w979BSbBb8SGihvYbYy:2:Bank Account:1.0": {
"sub_proof_index": 0,
"values": {
"Name": {
"raw": "revocationtest01",
"encoded": "54732868580499211735974961366354315864941016766578192688462230293521237042341"
}
}
}
},
"self_attested_attrs": {},
"unrevealed_attrs": {},
"predicates": {}
},
"identifiers": [
{
"schema_id": "Mz2w979BSbBb8SGihvYbYy:2:Bank Account:1.0",
"cred_def_id": "NBUXM1kVv4yNVc6ezpaa94:3:CL:232:demo-bank-02",
"rev_reg_id": "NBUXM1kVv4yNVc6ezpaa94:4:NBUXM1kVv4yNVc6ezpaa94:3:CL:232:demo-bank-02:CL_ACCUM:4e70d6ee-f5cd-4920-8465-b30225c64192"
}
]
}
Response from another aca-py that is working:
"presentation": {
"requested_proof": {
"revealed_attrs": {},
"revealed_attr_groups": {
"M6Mbe3qx7vB4wpZF4sBRjt:2:bank_account:1.0": {
"sub_proof_index": 0,
"values": {
"iban": {
"raw": "FR76300060000112345678901892222",
"encoded": "6148709647731321911179338611335436659224044805103852311744105627476491120195"
},
"bic": {
"raw": "AGRIFRPP2222",
"encoded": "91116420062241147916189842285176128956310697178501382826806302166580532590101"
}
}
}
},
"self_attested_attrs": {},
"unrevealed_attrs": {},
"predicates": {}
},
"identifiers": [
{
"schema_id": "M6Mbe3qx7vB4wpZF4sBRjt:2:bank_account:1.0",
"cred_def_id": "F6dB7dMVHUQSC64qemnBi7:3:CL:571:phil-bank-21",
"rev_reg_id": "F6dB7dMVHUQSC64qemnBi7:4:F6dB7dMVHUQSC64qemnBi7:3:CL:571:phil-bank-21:CL_ACCUM:f78a6628-57f9-4098-a1de-ecd534a50bb6",
"timestamp": 1632320402
}
]
},
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 20 (18 by maintainers)
Aca-py is dropping revocation constraints for presented credentials that are non-revocable, because indy-sdk will fail validation in this scenario. However the current logic is not correct …
I still can reproduce this with the Lissi wallet. I turned on debugging and it is definitely like I described it above, the incoming proof-presentation that is received from Lissi has no timestamp field in the identifiers section. I even see the indy-sdk doing all the things I would expect it to do: getting the creddef from the ledger, checking if it is revocable, hitting the revocation registry and after that doing all the math. So my verdict is still that one can bypass the revocation check in aca-py if one simply withholds the timestamp field in the identifiers section of the proof-presentation. Is it possible to put this into a test case somewhere simply to prove me wrong or right? 😃
Hmmm…it shouldn’t be removing it if the prover has offered it. The tricky aspect of this is that one must be able to prove a presentation request that includes a non-revocation interval using a VC that is not revokable and vice-versa. We did a bunch of work in this area trying to get those scenarios working. We may need to look again.
@esune – can you find the PRs and code areas where this was worked, and @ianco – perhaps you can follow through to see if there is an issue in ACA-Py. We have to make sure that all 4 scenarios work:
asking for Revocation
not asking for Revocation
@ianco what I do in the BPA is to store the rev_reg_id that is returned when issuing the credential. If the credential is revoked I use the same id. So you mean this id can change if the registry is full? What confuses me though is that both Apps say that the credential is revoked, so everything looks ok to me until that point. Also aca-py simply ignores the none revocation check in this case. Wouldn’t it make more sense to fail validation if a proof of none revocation is requested, but it can not be fulfilled for whatever reasons? And still if I did the revocation with the wrong id I would not expect aca-py to log the message:
removed global non-revocation interval; no revocable credentials in proof. I will do some more testing here. Also the esatus/lissi developers said that they do not think it is the mediator.