Unable to Verify INDY Credentials when public did is did:web

[adarshnb-19]

When public did is did:web , unable to verify INDY credenitials

• ACA-Py version: 1.3.0
• Holder: BC Wallet (Mobile)
• Issuer: ACA-Py agent (cloud) Askar Wallet

Scenario

• Verifier sends OOB invitation with presentation request attached with auto-verify true .
• Holder scans QR code.
• Holder sends credentials from BC Wallet (Mobile)
• Verification of credential throws an error
• "error_msg": "Ledger request error. Request failed: client request invalid: InvalidClientRequest('adarshnb-19.github.io:verifier', 1756973985079730427, "validation error [SafeRequest]: should not contain the following chars ['-', '.', ':'] (identifier=adarshnb-19.github.io:verifier)").

[ff137]

The error message is telling you that the name adarshnb-19.github.io:verifier is invalid because it contains 3 different characters that are disallowed: - . :

Why they are disallowed, and whether they can be allowed, is a different question that I cannot answer. But that's evidently what the error is.

[esune]

Related/duplicate to #3544

[jamshale]

I believe this is improper use of the public did configuration. Although it's not your fault. This configuration has become extremely confusing. I have created a ticket to try and address this https://github.com/openwallet-foundation/acapy/issues/3875.

[jamshale]

For indy verification and issuance you'll need to have the public did set to the correct indy did. I don't know why you need to have the public did set to the did:web? If it's for an oob connection you can have the use_public_did option as false (the default, and use the use_did option to specify your did:web.

This way you can use the indy did for public did which is is required for the ledger interactions and not set the did:web except for use in connections.

[adarshnb-19]

I was trying to issue an Indy credentials in two scenarios through out of band

1. Single tenant issuer to single tenant holder
2. Single tenant issuer to a Multi tenant holder .

Case 1
In first scenario OOB Issuance was succesfull without the use_did . When i set the use_did to a non public did:web , i get an 500 error in /oob/recieve_invitation of other agent .

Steps to reproduce the error:

1. Create credential offer for out-of-band.
2. Create out-of-band invitation. Add use_didwith a non public did:web
3. Receive the above out-of-band invitation on other agent
4. The error occurs.

Case 2
In second scenario OOB Issuance , I was able to recieve_invitation but , i did not get any records in credentials offer .

Steps to reproduce the error:

1. Create credential offer for out-of-band.
2. Create out-of-band invitation.
3. Receive the above out-of-band invitation on other multi-tenant agent.
4. Inspect the agent logs . Invitation will be recieved but there will no credential offers.

Here are the logs of multi-tenant agent

2025-09-20 04:16:08,099 aiohttp.access INFO 172.17.0.1 [20/Sep/2025:04:16:07 +0000] "POST /out-of-band/receive-invitation?auto_accept=true HTTP/1.1" 200 5460 "http://localhost:8002/api/doc" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36" 2025-09-20 04:16:08,104 acapy_agent.core.conductor ERROR Storage error occurred in message handler: StorageNotFoundError: Record not found: connection/9b289c6c-27e6-4e4a-9892-d95abcc6e3e1 Traceback (most recent call last): File "/usr/local/lib/python3.12/asyncio/tasks.py", line 314, in __step_run_and_handle_result result = coro.send(None) ^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/core/dispatcher.py", line 229, in handle_v1_message connection = await ConnRecord.retrieve_by_id( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/messaging/models/base_record.py", line 235, in retrieve_by_id result = await storage.get_record( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/storage/askar.py", line 91, in get_record raise StorageNotFoundError(f"Record not found: {record_type}/{record_id}") acapy_agent.storage.error.StorageNotFoundError: Record not found: connection/9b289c6c-27e6-4e4a-9892-d95abcc6e3e1 2025-09-20 04:16:08,110 acapy_agent.core.dispatcher ERROR Handler error: Dispatcher.handle_v1_message Traceback (most recent call last): File "/usr/local/lib/python3.12/asyncio/tasks.py", line 314, in __step_run_and_handle_result result = coro.send(None) ^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/core/dispatcher.py", line 229, in handle_v1_message connection = await ConnRecord.retrieve_by_id( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/messaging/models/base_record.py", line 235, in retrieve_by_id result = await storage.get_record( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/src/app/acapy_agent/storage/askar.py", line 91, in get_record raise StorageNotFoundError(f"Record not found: {record_type}/{record_id}") acapy_agent.storage.error.StorageNotFoundError: Record not found: connection/9b289c6c-27e6-4e4a-9892-d95abcc6e3e1 2025-09-20 04:16:08,219 acapy_agent.protocols.routing.v1_0.manager INFO >>> fetching routing record for verkey: FcbR3NAsjDeXmXaGhxNkXHG4Dd7XQjKFAzbJZAc6X7Je 2025-09-20 04:16:08,225 acapy_agent.protocols.routing.v1_0.manager INFO >>> FOUND routing record for verkey: FcbR3NAsjDeXmXaGhxNkXHG4Dd7XQjKFAzbJZAc6X7Je

[jamshale]

Maybe we can focus on Case#1 first, as it should be simpler. Is there any logs on the receiver side before the 500 error? Maybe there's an issue resolving the did, or the service block of the did:web isn't correct? Is it public where we can resolve it and have a look?

This should work in theory but there must be something wrong with the did or in the way acapy is handling it.

[adarshnb-19]

These are the logs on the recievers side .

`2025-09-25 11:43:44,280 acapy_agent.core.dispatcher ERROR Handler error: upgrade_middleware Traceback (most recent call last): File "/usr/src/app/acapy_agent/connections/base_manager.py", line 444, in resolve_didcomm_services doc_dict: dict = await resolver.resolve(self._profile, did, service_accept) File "/usr/src/app/acapy_agent/resolver/did_resolver.py", line 87, in resolve _, doc = await self._resolve(profile, did, service_accept, timeout=timeout) File "/usr/src/app/acapy_agent/resolver/did_resolver.py", line 60, in _resolve for resolver in await self._match_did_to_resolver(profile, did): File "/usr/src/app/acapy_agent/resolver/did_resolver.py", line 126, in _match_did_to_resolver raise DIDMethodNotSupported(f'No resolver supporting DID "{did}" loaded') acapy_agent.resolver.base.DIDMethodNotSupported: No resolver supporting DID "did:sov:verifier" loaded

The above exception was the direct cause of the following exception:

Traceback (most recent call last): File "/usr/src/app/acapy_agent/connections/base_manager.py", line 447, in resolve_didcomm_services raise BaseConnectionManagerError("Failed to resolve DID services") from error acapy_agent.connections.base_manager.BaseConnectionManagerError: Failed to resolve DID services`

The did is public . did:web:adarshnb-19.github.io:verifier .

[jamshale]

Thank you. It looks like there's a problem here. I'm not sure what it's doing to the did string, but it doesn't look right. @PatStLouis is currently looking at this feature for did:webvh and he might discover something. I might be able to find some time to look into it as well. Looks like it may be expecting the did to be an unqualified did:sov did, when it should accept any resolvable did with the appropriate services block.

[PatStLouis]

@adarshnb-19 Please post the output of /status/config

[adarshnb-19]

@PatStLouis Here the output of /status/config

{ "config": { "admin.admin_insecure_mode": true, "admin.enabled": true, "admin.host": "0.0.0.0", "admin.port": "8001", "admin.webhook_urls": [], "admin.admin_client_max_request_size": 1, "debug.auto_accept_requests": true, "default_endpoint": "http://192.168.1.10:9001", "additional_endpoints": [], "tails_server_base_url": "http://dev-indy.nborbit.net", "tails_server_upload_url": "http://dev-indy.nborbit.net", "revocation.anoncreds_legacy_support": "accept", "ledger.genesis_url": "http://192.168.1.10:9000/genesis", "ledger.keepalive": 5, "log.level": "info", "auto_ping_connection": true, "public_invites": true, "requests_through_public_did": true, "trace.target": "log", "trace.tag": "", "trace.label": "Issuer", "emit_new_didcomm_prefix": true, "emit_new_didcomm_mime_type": true, "auto_provision": true, "transport.inbound_configs": [ [ "http", "0.0.0.0", "9001" ] ], "transport.outbound_configs": [ "http" ], "transport.enable_undelivered_queue": false, "transport.max_message_size": 2097152, "transport.max_outbound_retry": 4, "transport.ws.heartbeat_interval": 3, "transport.ws.timeout_interval": 15, "default_label": "Issuer", "wallet.name": "issuerwallet", "wallet.storage_type": "default", "wallet.type": "askar", "endorser.author": false, "endorser.endorser": false, "endorser.auto_endorse": false, "endorser.auto_write": false, "endorser.auto_create_rev_reg": false, "endorser.auto_promote_author_did": false, "ledger.read_only": false, "ledger.genesis_transactions": "{\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node1\",\"blskey\":\"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba\",\"blskey_pop\":\"RahHYiCvoNCtPTrVtP7nMC5eTYrsUA8WjXbdhNc8debh1agE9bGiJxWBXYNFbnJXoXhWFMvyqhqhRoq737YQemH5ik9oL7R4NTTCz2LEZhkgLJzB3QRQqJyBNyv7acbdHrAT8nQ9UkLbaVL9NBpnWXBTw4LEMePaSHEw66RzPNdAX1\",\"client_ip\":\"172.17.0.1\",\"client_port\":9702,\"node_ip\":\"172.17.0.1\",\"node_port\":9701,\"services\":[\"VALIDATOR\"]},\"dest\":\"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv\"},\"metadata\":{\"from\":\"Th7MpTaRZVRYnPiabds81Y\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":1,\"txnId\":\"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62\"},\"ver\":\"1\"}\n{\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node2\",\"blskey\":\"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk\",\"blskey_pop\":\"Qr658mWZ2YC8JXGXwMDQTzuZCWF7NK9EwxphGmcBvCh6ybUuLxbG65nsX4JvD4SPNtkJ2w9ug1yLTj6fgmuDg41TgECXjLCij3RMsV8CwewBVgVN67wsA45DFWvqvLtu4rjNnE9JbdFTc1Z4WCPA3Xan44K1HoHAq9EVeaRYs8zoF5\",\"client_ip\":\"172.17.0.1\",\"client_port\":9704,\"node_ip\":\"172.17.0.1\",\"node_port\":9703,\"services\":[\"VALIDATOR\"]},\"dest\":\"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb\"},\"metadata\":{\"from\":\"EbP4aYNeTHL6q385GuVpRV\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":2,\"txnId\":\"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc\"},\"ver\":\"1\"}\n{\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node3\",\"blskey\":\"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5\",\"blskey_pop\":\"QwDeb2CkNSx6r8QC8vGQK3GRv7Yndn84TGNijX8YXHPiagXajyfTjoR87rXUu4G4QLk2cF8NNyqWiYMus1623dELWwx57rLCFqGh7N4ZRbGDRP4fnVcaKg1BcUxQ866Ven4gw8y4N56S5HzxXNBZtLYmhGHvDtk6PFkFwCvxYrNYjh\",\"client_ip\":\"172.17.0.1\",\"client_port\":9706,\"node_ip\":\"172.17.0.1\",\"node_port\":9705,\"services\":[\"VALIDATOR\"]},\"dest\":\"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya\"},\"metadata\":{\"from\":\"4cU41vWW82ArfxJxHkzXPG\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":3,\"txnId\":\"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4\"},\"ver\":\"1\"}\n{\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node4\",\"blskey\":\"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw\",\"blskey_pop\":\"RPLagxaR5xdimFzwmzYnz4ZhWtYQEj8iR5ZU53T2gitPCyCHQneUn2Huc4oeLd2B2HzkGnjAff4hWTJT6C7qHYB1Mv2wU5iHHGFWkhnTX9WsEAbunJCV2qcaXScKj4tTfvdDKfLiVuU2av6hbsMztirRze7LvYBkRHV3tGwyCptsrP\",\"client_ip\":\"172.17.0.1\",\"client_port\":9708,\"node_ip\":\"172.17.0.1\",\"node_port\":9707,\"services\":[\"VALIDATOR\"]},\"dest\":\"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA\"},\"metadata\":{\"from\":\"TWwCRQRZ2ZHMJFn9TzLp7W\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":4,\"txnId\":\"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008\"},\"ver\":\"1\"}", "upgrade.from_version": "v0.7.5" } }

[PatStLouis]

@adarshnb-19 could you try setting your agent as readonly and see if this helps? I can see you have the option "ledger.read_only": false, try setting this to true.

[PatStLouis]

its not clear what your agent setup is like, your wallet name is issuerWallet but you said in your issue this is a verifier? Do you have a single agent playing both roles? If this agent needs to write to the ledger, you will need an indy public did. its not clear why you are setting up a did:web as the public did for this agent. You can just keep your indy did as the public did, and instead tell the oob invitation to use the web did of your choice with the use_did property.

the public did functionality in acapy should really only be used with indy currently, I don't think its been designed for other use cases.

Try these two options and let us know if it changes anything:

• setting up the agent in read only mode
• setting the public did to indy and using the use_did oob property with your web did

[adarshnb-19]

@PatStLouis I tried both options, and the outcome were the same.

Here’s my agent setup for context:

• Single-tenant Indy issuer
• Multi-tenant Indy and JSON-LD credential holder
• Read-only-ledger Indy verifier (which can issue and verify JSON-LD credentials)

I was attempting to issue a JSON-LD credential from the single-tenant verifier to the multi-tenant holder using an out-of-band flow.

For the multi-tenant holder, the out-of-band issuance didn’t work at all — both with and without the use_did parameter (as described in case 2).

For the single-tenant setup, using the use_did parameter with a non-public DID during out-of-band issuance or verification with read-only-ledger also failed, as shown in the logs of case 1 .

[PatStLouis]

It's difficult to follow what you are trying to do, in the initial issue, you mention you are trying to verify credentials from the BC Wallet, now you are saying you are trying to issue a json-ld credential to an acapy multitenant holder. We need to focus on 1 scenario to help you.

What I understand from the original issue is that you have a verifier agent, which has a did:web registered and published to github, and you have set this did as the public_did in your wallet using the /wallet/did/public endpoint. You are then trying to send a presentation request to the BC wallet to verify an anoncreds credential issued with an indy ledger.

The initial error message you listed is:

Ledger request error. Request failed: client request invalid: InvalidClientRequest('adarshnb-19.github.io:verifier', 1756973985079730427, "validation error [SafeRequest]: should not contain the following chars ['-', '.', ':'] (identifier=adarshnb-19.github.io:verifier)")

This seems to indicate the agent is trying to send a client request to the indy ledger, thus not being in read_only mode (as demonstrated by the /status/config output you shared later).

I also notice you are running on a local network, this will not work with the BC Wallet. Same goes for your did web didcomm service. The did document is public, but your didcomm service endpoint is private. This will not work with any other agent outside of your local network.

It seems you need to figure out your networking between your agents to allow them to communicate.

The last log you shared:

Traceback (most recent call last):
File "/usr/src/app/acapy_agent/connections/base_manager.py", line 447, in resolve_didcomm_services
raise BaseConnectionManagerError("Failed to resolve DID services") from error
acapy_agent.connections.base_manager.BaseConnectionManagerError: Failed to resolve DID services`

The did is public . did:web:adarshnb-19.github.io:verifier .

Reads that the agent is unable to reach the didcomm endpoint.

[adarshnb-19]

@PatStLouis Thanks for the clarification — let me restate the error I'm encountering more clearly.

• Verify Indy credentials, and
• Issue JSON-LD credentials (using a did:web) through an out-of-band (OOB) flow.

Initially, I had configured the agent with a public did:web, but that caused Indy verification to fail. Following the earlier suggestions, I reverted to using an Indy DID as the public DID and specified the did:web through the use_did parameter in the OOB invitation.

However, when I tested this configuration in a single-tenant to single-tenant OOB flow, the process failed with a 500 error during /out-of-band/receive-invitation on the receiver agent.

The receiver logs showed:

No resolver supporting DID "did:sov:verifier" loaded
Failed to resolve DID services

even though the did:web document is publicly resolvable.

[PatStLouis]

The did document is public, but your didcomm service is not, its set on a private IP: http://192.168.1.10:9003

My suggestion, setup your agent with Indy configuration first, only using an indy did as public did and ensure you can verify indy credentials. To issue json-ld credentials, you need to establish a connection with the recipient and send the json ld credential. You do not need a public did to do so. You only need the did:web to be the issuer of the credential which is taken care of at the credential issuance layer, not the OOB layer.

If you really want to use the did:web as the didcomm connection did, you can use the use_did oob parameter, this should resolve the "did:sov:verifier" issue, which seems like it's parsing the did:web:adarshnb-19.github.io:verifier to did:sov:verifier for some reason. Do not use public_did as anything else than indy.

[PatStLouis]

if you give me an oob invitation url you are using I can have a quick look to see if I find anything else

[adarshnb-19]

@PatStLouis
Here is the invitation url https://organization-didwebproblem.eapiagents.develop.nborbit.ca?oob=eyJAdHlwZSI6ICJodHRwczovL2RpZGNvbW0ub3JnL291dC1vZi1iYW5kLzEuMS9pbnZpdGF0aW9uIiwgIkBpZCI6ICJjODk1ZWY4Zi01YjliLTRmNzUtYjYzNi00YzIzNTlkYzg4NDgiLCAibGFiZWwiOiAib3JnYW5pemF0aW9uLWRpZHdlYnByb2JsZW0gQWdlbnQiLCAiaGFuZHNoYWtlX3Byb3RvY29scyI6IFsiaHR0cHM6Ly9kaWRjb21tLm9yZy9kaWRleGNoYW5nZS8xLjAiXSwgImFjY2VwdCI6IFsiZGlkY29tbS9haXAxIiwgImRpZGNvbW0vYWlwMjtlbnY9cmZjMTkiXSwgInJlcXVlc3RzfmF0dGFjaCI6IFt7IkBpZCI6ICJyZXF1ZXN0LTAiLCAibWltZS10eXBlIjogImFwcGxpY2F0aW9uL2pzb24iLCAiZGF0YSI6IHsianNvbiI6IHsiQHR5cGUiOiAiaHR0cHM6Ly9kaWRjb21tLm9yZy9wcmVzZW50LXByb29mLzIuMC9yZXF1ZXN0LXByZXNlbnRhdGlvbiIsICJAaWQiOiAiYTcwYjQ0MzctYmU4MS00Mzg4LWIzNmQtMDg5MDQxMmY2NDZhIiwgIn50aHJlYWQiOiB7InB0aGlkIjogImM4OTVlZjhmLTViOWItNGY3NS1iNjM2LTRjMjM1OWRjODg0OCJ9LCAiY29tbWVudCI6ICJzdHJpbmciLCAid2lsbF9jb25maXJtIjogdHJ1ZSwgImZvcm1hdHMiOiBbeyJhdHRhY2hfaWQiOiAiaW5keSIsICJmb3JtYXQiOiAiaGxpbmR5L3Byb29mLXJlcUB2Mi4wIn1dLCAicmVxdWVzdF9wcmVzZW50YXRpb25zfmF0dGFjaCI6IFt7IkBpZCI6ICJpbmR5IiwgIm1pbWUtdHlwZSI6ICJhcHBsaWNhdGlvbi9qc29uIiwgImRhdGEiOiB7ImJhc2U2NCI6ICJleUp1WVcxbElqb2dJbEJ5YjI5bUlISmxjWFZsYzNRaUxDQWljbVZ4ZFdWemRHVmtYMkYwZEhKcFluVjBaWE1pT2lCN0ltRmtaR2wwYVc5dVlXeFFjbTl3TVNJNklIc2libUZ0WlhNaU9pQmJJbk5qYjNKbElsMHNJQ0p5WlhOMGNtbGpkR2x2Ym5NaU9pQmJleUpqY21Wa1gyUmxabDlwWkNJNklDSTBTRmd4V1hOQmFEbHljMkZaTVhsb1RqWnFibWhHT2pNNlEwdzZNamt6T0RrNU1UcGthV1IzWldJaWZWMTlmU3dnSW5KbGNYVmxjM1JsWkY5d2NtVmthV05oZEdWeklqb2dlMzBzSUNKMlpYSnphVzl1SWpvZ0lqRXVNQ0lzSUNKdWIyNWpaU0k2SUNJMU56UTVOVGMxT0RVd016VTNNakUxTnpjeU56UTJPRFlpZlE9PSJ9fV19fX1dLCAic2VydmljZXMiOiBbImRpZDp3ZWI6b3JnYW5pemF0aW9uZGlkd2VicHJvYmxlbS5uYm9yYml0LmlvIl19

these are the wallet-DIDs { "results": [ { "did": "4HX1YsAh9rsaY1yhN6jnhF", "verkey": "2nqdaq6Ef29u7eXSWwrmf6FSCu5uJiBSZdnGsVxAg58J", "posture": "posted", "key_type": "ed25519", "method": "sov", "metadata": { "posted": true, "endpoint": "https://organization-didwebproblem.eapiagents.develop.nborbit.ca" } }, { "did": "did:web:organizationdidwebproblem.nborbit.io", "verkey": "DLbn6WpVG5RcZEtfkaU13wosuwf4VmdGEaAMHFQhpWib", "posture": "wallet_only", "key_type": "ed25519", "method": "web", "metadata": {} } ] }

and these are the logs on the recievers side

Traceback (most recent call last): File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/connections/base_manager.py", line 444, in resolve_didcomm_services doc_dict: dict = await resolver.resolve(self._profile, did, service_accept) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/did_resolver.py", line 87, in resolve _, doc = await self._resolve(profile, did, service_accept, timeout=timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/did_resolver.py", line 60, in _resolve for resolver in await self._match_did_to_resolver(profile, did): ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/home/aries/.local/lib/python3.12/site-packages/acapy_agent/resolver/did_resolver.py", line 126, in _match_did_to_resolver raise DIDMethodNotSupported(f'No resolver supporting DID "{did}" loaded') acapy_agent.resolver.base.DIDMethodNotSupported: No resolver supporting DID "did:sov:organizationdidwebproblem.nborbit.io" loaded

[Jsyro]

I ran into another issue i believe is related to this.

Setup:

• publishing a did:sov (and schema and cred_def)-
• then did:webvh (and schema and cred_def),
• then did:cheqd (And schema a cred_def),

Action: calling 'issue-credential-2.0/send-offer' with the cred_def if for the did:sov based cred def.

Result: 400 with Could not determine schema attributes. If you did not create the schema, then you need to provide the schema_id..

Cause?: The public did of the wallet was set the did:cheqd

Resolution: Suggested by @esune. calling POST /wallet/did/public with the published did:sov:, and re-calling the issuer-credential-2.0/send-offer was successful