Error Message when running register-dids.sh script

[msingh1304]

Discussed in https://github.com/hyperledger-labs/business-partner-agent/discussions/856

^{Originally posted by **msingh1304** February 7, 2023} Hello Team, We have completed the pre-requisite required for the installation but now facing an issue when trying to run the script. Pre-requisite completed:  VM has been configured on Cloud.  Pre-requisite of installing the below mentioned tools on VM have already been completed. o docker o docker-compose o git Current Impediment/Blocker:  When trying to run the script “register-dids.sh” as per the docs, we are getting the below mentioned message, could you please confirm what is this gp used for and which package is required to run gp?, we could not find this in the pre-requisite list document. Error Message: /usr/bin/which: no gp in (/home/linux/.local/bin:/home/linux/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)

[etschelp]

https://github.com/hyperledger-labs/business-partner-agent/tree/main/scripts#accessing-the-frontend

[msingh1304]

@etschelp

When I am using the below mentioned proof template, I get success response in postman but the attribute values are coming as blank in the wallet when trying to verify it.

{ "name": "My-Basis-ID-Proof", "attributeGroups": [ { "schemaUUID": "d512daa9-87df-4964-9caf-c7088cd401a9", "nonRevoked": true, "attributes": [ { "name": "firstName", "conditions": [] }, { "name": "familyName", "conditions": [] } ], "schemaLevelRestrictions": { "schemaName": "My-Basis-ID-Proof", "schemaVersion": "0.1", "schemaIssuerDid": "xxxxxxx9A6s", "credentialDefinitionId": "xxxxxx9A6s:3:CL:40987:My-Basis-ID-Proof", "issuerDid": "xxxxx9A6s" } } ] }

---

When I am using this template, it doesn't work, I get error message Error message: { "message": "Bad Request", "_embedded": { "errors": [ { "message": "template.attributeGroups: must not be empty", "_embedded": {}, "_links": {} } ] }, "_links": { "self": { "href": "/api/proof-templates", "templated": false } } }

Template

{
    "nonce": "1119659676972173955782496",
    "name": "Test-ID",
    "version": "1.0",
    "requested_attributes": {
        "xxxxxxxx9A6s:2:Test-ID:0.1": {
            "names": [
                "firstName",
                "familyName"
            ],
            "non_revoked": {
                "to": 1678451649,
                "from": 1678451649
            },
            "attributes": [
                {
                    "name": "firstName",
                    "conditions": []
                },
                {
                    "name": "familyName",
                    "conditions": []
                }
            ],
            "restrictions": [
                {
                    "schema_id": "xxxxxxxx9A6s:2:Test-ID:0.1",
                    "schema_name": "Test-ID",
                    "schema_version": "0.1",
                    "schema_issuer_did": "xxxxxxxx9A6s",
                    "cred_def_id": "xxxxxxxxxx9A6s:3:CL:41055:Test-ID",
                    "issuer_did": "xxxxxxxxx9A6s"
                }
            ]
        }
    },
    "requested_predicates": {}
}

Also unable to access the front end.

[etschelp]

1. create a proof template. a proof template is not a proof request in the scope of the bpa. see swagger-ui or browser on how this works. what you have above looks ok i guess
2. send a proof request based on the template to a connection. again swagger-ui or browser

[msingh1304]

@etschelp

Yes, I did the same thing that you are mentioning here, after creating the proof template, I sent the proof request

Step 1: Created a Schema Step 2: Created Credential Definition Step 3: Created Proof Template Step 4: Created Connection Invitation Request Step 5: Issued a credential Step 6: Verifying the credential.

Following all the process but still unable to figure it out why the blank values are showing up when verifying the credential and all the previous steps are working fine.

[etschelp]

Also unable to access the front end.

did you map the port?

but the attribute values are coming as blank in the wallet when trying to verify it.

what do you mean by that and where? the app the bpa? be aware that here is a difference between a proof request and the presentation.

[msingh1304]

Also unable to access the front end.

did you map the port?

but the attribute values are coming as blank in the wallet when trying to verify it.

what do you mean by that and where? the app the bpa? be aware that here is a difference between a proof request and the presentation.

When I say values are coming as blank, it is coming as blank in the wallet. I know proof request and template are different.

Proof Request Sample:

---

{
    "credDefUUID": "xxx-0388-4sds84-xxx-99f8038ba215",
    "partnerId": "xxxx-9eac-xxxx-xxxx-4b7e34ad18c9",
    "document": {
        "familyName": "Singh",
        "firstName": "M"
    }
}

And the above one I am using it to create proof template.

---

[etschelp]

it totally depends on the wallet app how it displays the proof request, with value restrictions or not. the important part is what the wallet app responds. so if you have two credentials one with name=test and one with name=other and you send a proof request with a value restriction name=test and the wallet app selects the one with name=test, and the bpa receives name=test then everything works as expected.

[msingh1304]

it totally depends on the wallet app how it displays the proof request, with value restrictions or not. the important part is what the wallet app responds. so if you have two credentials one with name=test and one with name=other and you send a proof request with a value restriction name=test and the wallet app selects the one with name=test, and the bpa receives name=test then everything works as expected.

Exactly, that is how it should work, whenever I am verifying the credential, it is verifying the same credentials present in the wallet for the respective schema id and credential id. Anything else that I need to look into this issue?

[msingh1304]

@etschelp

Issue is resolved now, I found that the DB PostgreSQL port was not open, credentials were appearing in the wallet but it was not persisting the data, hence the values were coming as blank in the wallet at the time of verifying the credentials. I think this could be the only issue, after opening the port, container restart, everything started working fine.

Thanks to you also for helping me every time to dig further into the issue and find the root cause. There is one more question, I find lissi wallet slower than estatus wallet, which wallet works well lissi or estatus?

[etschelp]

If you look at the app store entries you see that the Lissi wallet is being more actively maintained. In the end it pretty much depends on your use case and with whom you want to interact with in your ecosystem. As of now there is no app that does it all. So far the esatus wallet was a basic but reliable app for everything anoncreds and Indy ledger related. The Lissi app does a bit more.

[msingh1304]

@etschelp

I am facing intermittent issues, it works sometimes and sometimes it doesn't work. I have also noticed that after doing restart of the containers it works, and now we are getting this issue:

---

Error Message:

06:50:13.991 [default-nioEventLoopGroup-1-2] ERROR AcaPyAuthFetcher - aca-py webhook authentication failed. Configured bpa.webhook.key: @_:xxxxxxxx33On, received x-api-key header: null

---

[etschelp]

This means you are running something very old, is this intentional? This has been removed quite a while ago. This means you have configured the bpa for webhook security, but did not do it for the acapy. You need to check if --webhook-url '${BPA_WEBHOOK_URL}#${BPA_WEBHOOK_KEY}' is set on the acapy. But there was a version that had issues with the webhook, if you are running this one there want be an fix except for using a later one.

[msingh1304]

@etschelp

Yes, it is set, here is docker compose yml section for aries agent

---

 mylab-aries-agent:
    image: bcgovimages/aries-cloudagent:py36-1.16-1_0.7.0
    container_name: ${AGENT_CONTAINER_NAME}
    ports:
      - ${ACAPY_ADMIN_PORT}
      - ${ACAPY_HTTP_PORT}:${ACAPY_HTTP_PORT}
    depends_on:
      - ${WALLET_CONTAINER_NAME}
    entrypoint: /bin/bash
    command: [
        "-c",
        "sleep 15;
        aca-py start \
        --auto-provision \
        --arg-file acapy-static-args.yml \
        --inbound-transport http '0.0.0.0' ${ACAPY_HTTP_PORT} \
        **--webhook-url '${BPA_WEBHOOK_URL}#${BPA_WEBHOOK_KEY}' \**
        --genesis-file '${ACAPY_GENESIS_FILE}' \
        --endpoint ${ACAPY_ENDPOINT} \
        --wallet-name '${ACAPY_WALLET_DATABASE}' \
        --wallet-key '${ACAPY_WALLET_ENCRYPTION_KEY}' \
        --wallet-storage-type '${ACAPY_WALLET_TYPE}' \
        --wallet-storage-config '{\"url\":\"${POSTGRESQL_HOST}:5432\",\"max_connections\":5}' \
        --wallet-storage-creds '{\"account\":\"${POSTGRESQL_USER}\",\"password\":\"${POSTGRESQL_PASSWORD}\",\"admin_account\":\"${POSTGRESQL_USER}\",\"admin_password\":\"${POSTGRESQL_PASSWORD}\"}' \
        --seed '${ACAPY_SEED}' \
        --admin '0.0.0.0' ${ACAPY_ADMIN_PORT} \
        --label '${AGENT_NAME}' \
        --debug-presentations \
        ${ACAPY_ADMIN_CONFIG} \
        ${ACAPY_READ_ONLY_MODE} \
        ${ACAPY_TAILS_BASE_URL} \
        ${ACAPY_TAILS_UPLOAD_URL} \
        "
    ]
    volumes:
      - "./acapy-static-args.yml:/home/indy/acapy-static-args.yml"
      - "./idunion-genesis.txt:/home/indy/idunion-genesis.txt"
    networks:
      - digilab-bpa
    restart: always
#--genesis-url '${ACAPY_GENESIS_URL}' \

---

[etschelp]

Like I said, this is all very old stuff, and has already been fixed a while back. I believe there was a issue with acapy where the api key got lost after some time, or after a exception (don't remember exactly) and after a restart it was set again. You either have to upgrade, or turn of webhook authentication. As long as you do not expose BPA's webhook URL to the internet this should be ok. Otherwise upgrade, because no one will support the stack you are running.

[msingh1304]

@etschelp

Okay, got it. If I understand you currently, you are saying that aries cloud agent version present in the git hub repository is "image: bcgovimages/aries-cloudagent:py36-1.16-1_0.7.5" and my code has " image: bcgovimages/aries-cloudagent:py36-1.16-1_0.7.0

Possible Solutions to fix this issue:

1. Upgrade the aries cloud agent version to latest that is "image: bcgovimages/aries-cloudagent:py36-1.16-1_0.7.5"
2. Comment this line in the existing docker-compose yaml file

Is that correct?

[etschelp]

Like always I'm having no clue what you are doing, and like I said it looks like you are running something very old, so just bumping up one version without considering the rest will cause other issues. So you have two options:

1. leave everything as it is and just set BPA_WEBHOOK_KEY= in your .env file
2. or, use the compose file like it is defined in the main branch of the BPA repository, but this means you have to migrate things

[msingh1304]

@etschelp

leave everything as it is and just set BPA_WEBHOOK_KEY= in your .env file : This is already set.

[etschelp]

what version of the bpa are you running? or commit version?

[msingh1304]

@etschelp PFB the requested info what version of the bpa are you running? or commit version? : ghcr.io/hyperledger-labs/business-partner-agent:edge

[etschelp]

Then you are all set, because this version does not use webhooks any more and the exception above can physically not happen because the code that logs the exception above is gone. If you are still seeing this exception my guess is that you have build your own bpa images locally and tagged it as edge. To be sure you can use the latest tagged stable version: ghcr.io/hyperledger-labs/business-partner-agent-new:0.12.0, but from what I have seen above your docker compose file and your config will then not match anymore, and you have to migrate.

[msingh1304]

Yeah, I know the wierd thing is I get only error at the time of receiving proof presentation api, Unable to receive proof data and in the logs I get api key error message because of that entire flow is not running. Strange part is after restart of fhe containers everything works fine for 1 days and then the next day same issue.

On Mon, 3 Apr 2023, 17:57 Philipp Etschel, @.***> wrote:

Then you are all set, because this version does not use webhooks any more and the exception above can physically not happen because the code that logs the exception above is gone. If you are still seeing this exception my guess is that you have build your own bpa images locally and tagged it as edge. To be sure you can use the latest tagged stable version: ghcr.io/hyperledger-labs/business-partner-agent-new:0.12.0, but from what I have seen above your docker compose file and your config will then not match anymore, and you have to migrate.

— Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/business-partner-agent/issues/857#issuecomment-1494232523, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3AXSCUIGPKG7XMYNPRR2YDW7K62PANCNFSM6AAAAAAUT4KWYU . You are receiving this because you authored the thread.Message ID: @.***>

[etschelp]

Ok from the top, yes acapy had a bug that did reset the api key after a time, if you restart it will work for a while and then it will be gone again. To fix that you will have to upgrade acapy.

BUT, the webhook api key should not be needed at all, because it is removed from the latest BPA version so you should not see this at all. This means you are not only running an old acapy version but also an old BPA version. I already wrote tons of hints on how to debug and fix this with docker, you just have to scroll up in this very long dialog.

[msingh1304]

Okay, let me scroll up and find any solution if you have mentioned it in our thread

On Mon, 3 Apr 2023, 19:51 Philipp Etschel, @.***> wrote:

Ok from the top, yes acapy had a bug that did reset the api key after a time, if you restart it will work for a while and then it will be gone again. To fix that you will have to upgrade acapy.

BUT, the webhook api key should not be needed at all, because it is removed from the latest BPA version so you should not see this at all. This means you are not only running an old acapy version but also an old BPA version. I already wrote tons of hints on how to debug and fix this with docker, you just have to scroll up in this very long dialog.

— Reply to this email directly, view it on GitHub https://github.com/hyperledger-labs/business-partner-agent/issues/857#issuecomment-1494420693, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3AXSCQQMNYW7TIYOFNURILW7LMHDANCNFSM6AAAAAAUT4KWYU . You are receiving this because you authored the thread.Message ID: @.***>

[msingh1304]

@etschelp

Are you saying that temporary fix would be to restart the containers for now and permanent fix is to upgrade acapy version and BPA version, is that correct?

[msingh1304]

@etschelp

Awaiting your reply

[etschelp]

thats what I said