ZKP - Predicate referent did not produce any credentials

[guillesanz21]

When I use ZKP in the credential presentation request by the verifier, it results in an error in the presentation in the holder. However, if I do not include ZKP predicates, the submission is sent and verified correctly.

Environment

I have a scenario deployed in docker (with docker-compose) with several agents (frameworks and controllers). AENA (ports 8035-8036) is the holder and FNMT (ports 8045-8046) acts as issuer and verifier simultaneously.

Regarding the frameworks, I am using the public image: bcgovimages/aries-cloudagent, version py36-1.16-1-1_0.7.2.

I am using AIP 1.0. I am not using revocation (the credential is issued without revocation). I am using a locally deployed VON network.

Let's start from a point where:

1. The credential schema and the credential definition have already been published in the local VON network.
2. The connection between AENA and FNMT is already established.
3. FNMT has already issued the credential to AENA, and AENA has it stored in the wallet. The credential is as follows:

Request

The request I am using is: /present-proof/send-request.

The request's body is the following one:

Note: The response does not contain any errors.

Logs

There are no errors printed in the terminal.

No webhook is sent.

The only error that is shown is the one specified in the "log" file (the file I specified to store logs) of the AENA agent, and it is the following:

172.21.0.1 [09/May/2022:14:04:19 +0000] "POST / HTTP/1.1" 200 155 "-" "Python/3.6 aiohttp/3.7.4.post0"
Received presentation request message: {"@type":"did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation","@id":"40158805-4724-400a-875a-fcb16b28d5b3","request_presentations~attach":[{"@id":"libindy-request-presentation-0","mime-type":"application/json","data":{"base64":"eyJuYW1lIjogIlByb29mIHJlcXVlc3QiLCAibm9uY2UiOiAiMSIsICJyZXF1ZXN0ZWRfYXR0cmlidXRlcyI6IHsiMF9mdWxsX25hbWVfdXVpZCI6IHsibmFtZSI6ICJmdWxsX25hbWUiLCAicmVzdHJpY3Rpb25zIjogW3siY3JlZF9kZWZfaWQiOiAiNXpTakFVVkx1dFptQVRhOTdjNWNOSzozOkNMOjEwOmNvdklEX1BvQ19JZGVudGl0eSJ9XX0sICIwX3Bob3RvX3VybF91dWlkIjogeyJuYW1lIjogInBob3RvX3VybCIsICJyZXN0cmljdGlvbnMiOiBbeyJjcmVkX2RlZl9pZCI6ICI1elNqQVVWTHV0Wm1BVGE5N2M1Y05LOjM6Q0w6MTA6Y292SURfUG9DX0lkZW50aXR5In1dfSwgIjBfZG5pX251bWJlcl91dWlkIjogeyJuYW1lIjogImRuaV9udW1iZXIiLCAicmVzdHJpY3Rpb25zIjogW3siY3JlZF9kZWZfaWQiOiAiNXpTakFVVkx1dFptQVRhOTdjNWNOSzozOkNMOjEwOmNvdklEX1BvQ19JZGVudGl0eSJ9XX19LCAicmVxdWVzdGVkX3ByZWRpY2F0ZXMiOiB7IjBfYmlydGhkYXlfZXBvY2hfR0VfdXVpZCI6IHsibmFtZSI6ICJiaXJ0aGRheV9lcG9jaCIsICJwX3R5cGUiOiAiPj0iLCAicF92YWx1ZSI6IDEwODMxOTY4MDAsICJyZXN0cmljdGlvbnMiOiBbeyJjcmVkX2RlZl9pZCI6ICI1elNqQVVWTHV0Wm1BVGE5N2M1Y05LOjM6Q0w6MTA6Y292SURfUG9DX0lkZW50aXR5In1dfX0sICJ2ZXJzaW9uIjogIjEuMCJ9"}}],"comment":"Identity proof presentation to the FNMT entity"}
    src/services/anoncreds/prover.rs:445 | name: Some("photo_url"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("full_name"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("dni_number"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("birthday_epoch"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("dni_number"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("full_name"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("photo_url"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("birthday_epoch"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("full_name"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("photo_url"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("dni_number"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("birthday_epoch"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("full_name"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("photo_url"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("dni_number"), names: None
    src/services/anoncreds/prover.rs:445 | name: Some("birthday_epoch"), names: None
Could not automatically construct presentation for presentation request Proof request:1.0 because predicate referent 0_birthday_epoch_GE_uuid did not produce any credentials.

And the log of this request by the FNMT agent does not show any error, only the following:

172.21.0.1 [09/May/2022:14:04:19 +0000] "POST /present-proof/send-request HTTP/1.1" 200 2678 "http://localhost:8046/api/doc" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.60 Safari/537.36"

Framework configuration

FNMT framework configuration (the configuration of the holder's framework is similar, but with ACAPY_WALLET_LOCAL_DID set to true):

AGENT_PORT: "8045"
ADMIN_PORT: "8046"
ACAPY_ENDPOINT: "http://313f-90-167-203-98.ngrok.io"
ACAPY_GENESIS_URL: "http://172.17.0.1:9000/genesis"
ACAPY_WALLET_SEED: ....
ACAPY_WALLET_TYPE: "indy
ACAPY_WALLET_NAME: ...
ACAPY_WALLET_KEY: ...
ACAPY_AUTO_PROVISION: "true"
ACAPY_LOG_FILE: "/logs/acapy-FNMT-20220509T154406.log"
ACAPY_LOG_LEVEL: info
ACAPY_DEBUG_CONNECTIONS: "true"
ACAPY_DEBUG_CREDENTIALS: "true"
ACAPY_DEBUG_PRESENTATIONS: "true"
ACAPY_AUTO_ACCEPT_INVITES: "true"
ACAPY_AUTO_PING_CONNECTION: "true"
ACAPY_AUTO_RESPOND_MESSAGES: "true"
ACAPY_AUTO_STORE_CREDENTIAL: "true"
ACAPY_AUTO_RESPOND_CREDENTIAL_REQUEST: "true"
ACAPY_AUTO_VERIFY_PRESENTATION: "true"
ACAPY_AUTO_RESPOND_PRESENTATION_REQUEST: "true"
ACAPY_WEBHOOK_URL: "http://controllerFNMT:5000/webhooks"

AND

aca-py start -it http '0.0.0.0' '8045' -ot http --admin '0.0.0.0' '8046'"

[ianco]

I think you want "LE" in your predicate (i.e. the birthdate is "LE" some date to prove that the age is "GE" some age).

[guillesanz21]

Oh I see, I knew the error I had was going to be a silly mistake...

However, a question arises for me... if the predicate condition is not met, doesn't the verifier have a way to be notified about it? Because in my case, the verifier wasn't getting any response.

[ianco]

If the holder doesn't have any credentials they can present (which is the case here, since there are no credentials that satisfy the predicate restriction) all the holder can do is send a problem report (which basically cancels the request)

I'n not sure any of the mobile wallets implement this right now, but since you're using a bunch of aca-py agents you can call the /present-proof/problem-report endpoint (I think that's it) on the holder agent

[guillesanz21]

Ok, I think I understand now.

Thank you! I am going to close the issue then.