0.9.0 error VERIFY_ERROR::Missing referent

[monar24]

Hi,

I have validated my use case against the latest release of 0.9.0. One issue that arose in this release that was not present previously, is a proof verification failure due to VERIFY_ERROR::Missing referent (omitted some details to shorten the snippet, please see below).

Past proofs simply verified with status true. In this case I have a very simple proof of a credential schema with only 3 attributes, all of which are revealed. The schema supports revocation and was created appropriately. Credentials were issued with no errors and in the proof request details I can see they are correct.

            "thread_id": "038fd547-6a8b-49e9-8306-1552253c7765",
            "updated_at": "2023-07-27T22:32:26.026171Z",
            "connection_id": "0c1e1cb4-afd7-473d-9a8b-2a0385850bbf",
            "verified": "false",
            "trace": false,
            "auto_present": false,
            "pres": {
                "@type": "https://didcomm.org/present-proof/2.0/presentation",
                "@id": "8c9b3fb7-3b48-4adb-b3c4-57b511a2e818",
                "~thread": {
                    "thid": "038fd547-6a8b-49e9-8306-1552253c7765"
                },
                "formats": [
                    {
                        "attach_id": "indy",
                        "format": "[hlindy/proof@v2.0](mailto:hlindy/proof@v2.0)"
                    }
                ],
                "presentations~attach": [
                    {
                        "@id": "indy",
                        "mime-type": "application/json",
                        "data": {
                            "base64": ....."
                        }
                    }
                ]
            },
            "verified_msgs": [
                "VERIFY_ERROR::Missing referent"
            ],```

[swcurran]

@andrewwhitehead — could you please look at this. If this is an 0.9.0 issue, we need to address immediately.

[swcurran]

Does this presentation involve revocation? Could you share — redacted as necessary to not share any secrets — the startup parameters you are using?

[monar24]

Yes it involves revocation, I verified that I am able to revoke the credential and that on a new request it correctly detects the credential is revoked. Redacted Params as follows (currently reworking docker-compose into k8, but here are the same settings; also please note I pasted fake port values here just for our conversation) :

      ACAPY_WALLET_KEY: ${VERIFIER_WALLET_KEY}
      ACAPY_ADMIN_INSECURE_MODE: "false"
      ACAPY_DEBUG_CONNECTIONS: "true"
      ACAPY_PUBLIC_INVITES: "true"
      ACAPY_ADMIN_API_KEY: ${VERIFIER_API_KEY}
      ACAPY_ENDPOINT: "http://verifier:456"
      ACAPY_GENESIS_URL: "${GENESIS_URL}"
      ACAPY_LABEL: "Verifier"
      ACAPY_LOG_LEVEL: "debug"
      ACAPY_WALLET_TYPE: "askar"
      ACAPY_AUTO_PROVISION: "true"
      ACAPY_TAILS_SERVER_BASE_URL: ${TAILS_SERVER_BASE_URL}
      ADMIN_PORT: "${ADMIN_PORT}"
      AGENT_PORT: "${AGENT_PORT}"
      ACAPY_STORAGE_CONFIG: "{\"url\":\"${POSTGRESQL_WALLET_HOST}:${POSTGRESQL_WALLET_PORT}\",\"max_connections\":5,\"wallet_scheme\":MultiWalletSingleTable}"
      ACAPY_STORAGE_CREDS: "{\"account\":\"${POSTGRESQL_WALLET_USER}\",\"password\":\"${POSTGRESQL_WALLET_PASSWORD}\",\"admin_account\":\"${POSTGRESQL_ADMIN_USER}\",\"admin_password\":\"${POSTGRESQL_WALLET_ADMIN_PASSWORD}\"}"
      ACAPY_CREDENTIAL_STORE_NAME: "${ACAPY_CREDENTIAL_STORE_NAME}"
      ACAPY_STORAGE_TYPE: "postgres_storage"
      TAG_NAME: "prod"`
    command: ["-c",
        "aca-py start \
        --admin '0.0.0.0' 123 \
        --inbound-transport http '0.0.0.0' 456 \
        --webhook-url http://host.docker.internal:8000/api/v1/verifier \
        --outbound-transport http \
        --wallet-type askar \
        --trace-target log \
        --trace-tag acapy.events \
        --wallet-name sampleWalletName \
        --public-invites \
        --auto-provision \
        --notify-revocation \
        --emit-new-didcomm-prefix \
        --monitor-revocation-notification \
        --log-level DEBUG  "
    ]
    ports:
      - "123:123" ```

[swcurran]

I've not heard from Andrew yet, but on a hunch, can you please add this option -- --anoncreds-legacy-revocation accept and retry?

[swcurran]

Also, what is the holder app in this case?

[monar24]

Thank you, let me give that flag a try. I will add it my three agents. Holder app is multi-tenant and running with following redacted params:

      ACAPY_ADMIN_INSECURE_MODE: "false"
      ACAPY_AUTO_PROVISION: "true"
      ACAPY_DEBUG_CONNECTIONS: "true"
      ACAPY_ADMIN_API_KEY: ${HOLDER_API_KEY}
      ACAPY_WALLET_TYPE: "askar"
      ACAPY_GENESIS_URL: "${GENESIS_URL}"
      ACAPY_ENDPOINT: "http://holder:8001"
      ACAPY_LABEL: "Holder"
      ACAPY_LOG_LEVEL: "debug"
      ADMIN_PORT: "456"
      AGENT_PORT: "123"
      ACA_PY_WALLET_NAME: "${ ACA_PY_WALLET_NAME}"
      ACAPY_WALLET_KEY: ${HOLDER_WALLET_KEY}
      ACAPY_STORAGE_CONFIG: "{\"url\":\"${POSTGRESQL_WALLET_HOST}:${POSTGRESQL_WALLET_PORT}\",\"max_connections\":5,\"wallet_scheme\":MultiWalletSingleTable}"
      ACAPY_STORAGE_CREDS: "{\"account\":\"${POSTGRESQL_WALLET_USER}\",\"password\":\"${POSTGRESQL_WALLET_PASSWORD}\",\"admin_account\":\"${POSTGRESQL_ADMIN_USER}\",\"admin_password\":\"${POSTGRESQL_WALLET_ADMIN_PASSWORD}\"}"
      ACAPY_CREDENTIAL_STORE_NAME: "${ACAPY_CREDENTIAL_STORE_NAME}"
      ACAPY_STORAGE_TYPE: "postgres_storage"
      MONITOR_REVOCATION_NOTIFICATION: "true"
      TAG_NAME: "prod"
    entrypoint: /bin/bash
    command: ["-c",
        "aca-py start \
        --admin '0.0.0.0' 8002 \
        --inbound-transport http '0.0.0.0' 8001 \
        --webhook-url http://host.docker.internal:8000/api/v1/holder \
        --outbound-transport http \
        --multitenant \
        --multitenant-admin \
        --wallet-type askar \
        --trace-target log \
        --jwt-secret abc123fakesecret \
        --trace-tag acapy.events \
        --public-invites "
      ]
    ports:
      - "456:456"

[monar24]

same behavior with using --anoncreds-legacy-revocation accept, although it definitely made sense to attempt it

[andrewwhitehead]

So that error does appear to be raised by indy-credx, and it can indicate that either a requested attribute was not supplied, or that the timestamp used in the presentation is not supported for the presentation request. Does the presentation contain all of the requested attributes, and if so, what are the values for 'non_revoked' in the presentation and the presentation request?

[swcurran]

Just to confirm — the only change you made in the scenario was a change from a previous ACA-Py to this one?

Are you using BCovrin Test for this test? It’s been having some problems because it was altered. I hope that is not the issue.

I hate to ask, but could you revert to the older version (which one?) retry, and then back to 0.9.0?

[monar24]

Ah this may have been an oversight, non_revoked : {} was sending in empty in the request. Not certain if the combination of removing the field and adding the flag sorted it (will definitely be keeping this startup option for legacy support though). Regardless, thank you both so much for your time in assisting our team :)

(Also to properly answer above, this is our pre-prod (staging) indy network, no worries on BCovrin to our knowledge)

[swcurran]

There will be more detail about that flag coming. Eventually, you will want to turn it off, but at this point it should likely remain on. Just as a matter of interest, what holder software is being used?

[monar24]

Ok 2 questions on that actually, 1) To preview later details, is it a risk later to leave it on? 2) To my knowledge, changing agent settings is a bit of a challenge in production, I would be hesitant to risk state changes

The holder, issuer, and agent are all using ghcr.io/hyperledger/aries-cloudagent-python:py3.9-0.9.0, with askar for the wallets

[swcurran]

The setting should be left on as long as you are expecting to receive presentations from holders using software that contains the Indy SDK or versions of CredX prior to 1.0.0 — the version in 0.9.0. Basically, as of CredX 1.0.0, there is a change to the format of the presentation. The flag set to accept causes the verifier to process and accept presentations using the old and new formats. Changing the flag to reject means that old format presentations are not accepted.

If you are using ACA-Py 0.9.0 with Askar for the holders and the verifiers, then it is safe to change it to “reject”. It will also be safe to change that setting in the future, as that is all it is — a feature flag that controls if an old format presentation will be verified, or just outright rejected.

Hope that helps.