DIDComm connection failure with Credo (issuer) and ACA-Py 1.5.1 (holder) due to did:key parsing error

[Sshovon]

I’m testing interoperability between the Credo 0.6.x (as issuer) and ACA-Py 1.5.1 (as holder), and the DIDComm connection fails on the ACA-Py side during didexchange. The connection record in ACA-Py remains stuck in request state, and the invitation record ends up as deleted.

Invitation response after accepting the connection:

{
  "state": "deleted",
  "created_at": "2026-03-04T07:56:02.523858Z",
  "updated_at": "2026-03-04T07:56:02.523858Z",
  "trace": false,
  "oob_id": "c5a064af-6262-4d89-a2b4-ad13c9099b92",
  "invi_msg_id": "05de475c-06e0-4a93-9b96-5bd4517b66cb",
  "invitation": {
    "@type": "https://didcomm.org/out-of-band/1.1/invitation",
    "@id": "05de475c-06e0-4a93-9b96-5bd4517b66cb",
    "handshake_protocols": [
      "https://didcomm.org/didexchange/1.1",
      "https://didcomm.org/connections/1.0"
    ],
    "accept": [
      "didcomm/aip1",
      "didcomm/aip2;env=rfc19"
    ],
    "services": [
      {
        "id": "#inline-0",
        "type": "did-communication",
        "recipientKeys": [
          "did:key:z6Mkn2q9r8Yv1QjVhbqudsr3zH1Y2CT31mMV9vckKasfY98h"
        ],
        "serviceEndpoint": "https://60f5-27-147-191-147.ngrok-free.app"
      }
    ]
  },
  "connection_id": "385ea12a-5bae-4976-8e53-6e78039d3b35",
  "role": "receiver",
  "multi_use": false
}

When ACA-Py tries to complete the didexchange, it errors out. Relevant stack trace:

Alice      | Traceback (most recent call last):
Alice      |   File "/usr/local/lib/python3.13/asyncio/tasks.py", line 304, in __step_run_and_handle_result
Alice      |     result = coro.send(None)
Alice      |   File "/acapy_agent/core/dispatcher.py", line 255, in handle_v1_message
Alice      |     await handler(context, responder)
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/handlers/response_handler.py", line 26, in handle
Alice      |     conn_rec = await mgr.accept_response(context.message, context.message_receipt)
Alice      |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/manager.py", line 1000, in accept_response
Alice      |     signed_did = await self.verify_rotate(
Alice      |                  ^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |         wallet, response.did_rotate_attach, conn_rec.invitation_key
Alice      |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |     )
Alice      |     ^
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/manager.py", line 1208, in verify_rotate
Alice      |     if not await attached.data.verify(wallet, invi_key):
Alice      |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/messaging/decorators/attach_decorator.py", line 446, in verify
Alice      |     encoded_pk = DIDKey.from_did(protected["jwk"]["kid"]).public_key_b58
Alice      |                  ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/did/did_key.py", line 77, in from_did
Alice      |     _, fingerprint = did_parts[0].split("did:key:")
Alice      |     ^^^^^^^^^^^^^^
Alice      | ValueError: not enough values to unpack (expected 2, got 1)
Alice      | 2026-03-04 07:56:03,653 acapy_agent.core.dispatcher ERROR Handler error: Dispatcher.handle_v1_message
Alice      | Traceback (most recent call last):
Alice      |   File "/usr/local/lib/python3.13/asyncio/tasks.py", line 304, in __step_run_and_handle_result
Alice      |     result = coro.send(None)
Alice      |   File "/acapy_agent/core/dispatcher.py", line 255, in handle_v1_message
Alice      |     await handler(context, responder)
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/handlers/response_handler.py", line 26, in handle
Alice      |     conn_rec = await mgr.accept_response(context.message, context.message_receipt)
Alice      |                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/manager.py", line 1000, in accept_response
Alice      |     signed_did = await self.verify_rotate(
Alice      |                  ^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |         wallet, response.did_rotate_attach, conn_rec.invitation_key
Alice      |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |     )
Alice      |     ^
Alice      |   File "/acapy_agent/protocols/didexchange/v1_0/manager.py", line 1208, in verify_rotate
Alice      |     if not await attached.data.verify(wallet, invi_key):
Alice      |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/messaging/decorators/attach_decorator.py", line 446, in verify
Alice      |     encoded_pk = DIDKey.from_did(protected["jwk"]["kid"]).public_key_b58
Alice      |                  ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
Alice      |   File "/acapy_agent/did/did_key.py", line 77, in from_did
Alice      |     _, fingerprint = did_parts[0].split("did:key:")

In ACA-Py, GET /connections shows the connection stuck in request state. Can anyone please help me out on this? Happy to provide full logs, config, or test against a specific branch if that helps.

[swcurran]

@jamshale @PatStLouis @esune -- FYI about this. We need to make sure this is working.

[jamshale]

Patrick would probably be the best to look at it because of the py-dentity wallet.

There's been little work focusing on aca-py holder to upgraded credo issuers. I've been trying to make sure everything's working in the other direction.

[PatStLouis]

@Sshovon can you show me an invitation created from credo?

[PatStLouis]

the error seems to indicate that the verification method id used for the proof isn't using did:key

[Sshovon]

@PatStLouis following json is a multi-party oob invitation, that you can use for testing.

{
  "@type": "https://didcomm.org/out-of-band/1.1/invitation",
  "@id": "3d1ce01d-e53a-4a9c-8dc1-90aebcbd8e72",
  "label": "et",
  "accept": [
    "didcomm/aip1",
    "didcomm/aip2;env=rfc19"
  ],
  "handshake_protocols": [
    "https://didcomm.org/didexchange/1.1",
    "https://didcomm.org/connections/1.0"
  ],
  "services": [
    {
      "id": "#inline-0",
      "serviceEndpoint": "https://core-agent-dev.hovi.id/agent",
      "type": "did-communication",
      "recipientKeys": [
        "did:key:z6Mkg1gKXcqSvpLa8sWpi282VJG6X6F9snQ5Z8JYbdp5NT6q"
      ],
      "routingKeys": []
    }
  ],
  "imageUrl": "https://acme-corp.com/connection.png"
}

[PatStLouis]

@Sshovon here's the decoded protected header I'm receiving from credo:

{
  "alg": "EdDSA",
  "jwk": {
    "kty": "OKP",
    "crv": "Ed25519",
    "x": "Fym4bEYMqMDEfTn8ZUW7gXsCgqoNWOEe6Mgb93wdY-I",
    "kid": "649308fe-3c58-45e6-83f6-9c7ed292f261"
  }
}

The key id should be a did:key ex: did:key:z6Mkg1gKXcqSvpLa8sWpi282VJG6X6F9snQ5Z8JYbdp5NT6q#z6Mkg1gKXcqSvpLa8sWpi282VJG6X6F9snQ5Z8JYbdp5NT6q

It's using a uuid here which seems to be a value designed for internal reference.

You should bring this to the attention of the credo community and ask why is the kid a uuid value.

[swcurran]

Could be completely unrelated (and is if you are not using the very latest), but a kid related PR was just merged into Credo last week -- openwallet-foundation/credo-ts#2204

[TimoGlastra]

See my comment on the Credo issue: openwallet-foundation/credo-ts#2687

DID Exchange / DIDComm Signed attachments historically used the kid in the header, not the protected header. this is odd, usually the kid is in the protected header. However since we're talking about maintaining interop here, I'd expect ACA-Py to look at the kid in the unprotected header, which is still present (@Sshovon can you confirm the unprotected header still contains thekid when received from credo?)

So we did change the behvaiour in 0.6 to also include a kid in the jwk, but this shouldn't affect interop (as this is also not top-level kid, it's a kid nested in a jwk in the protected header).

Does ACA-Py have fallback some logic where it first tries to extract it from e.g. protectedHeader.kid, then protectedHeader.jwk.kid, then unprotectedHeader.kid, and so us adding a jwk in protectedHeader.jwk.kid now makes the parsing fail?

But I think ACA-Py should mainly look at the kid in the header, not the protected header (even though it doesn't make sense, this is how the interop was once established).

We will make an update in Credo to remove the kid, as it's not needed to include it here. But it's probably also good to look at why ACa-Py is failing

[swcurran]

Looks like this is being fixed in Credo -- see PR openwallet-foundation/credo-ts#2694. As of writing this note the PR has been approved but not yet merged. AFAIK, Credo 0.6.3 was released yesterday, so it will be in 0.6.4.

[swcurran]

And -- I just saw @TimoGlastra 's comment (thanks!!) above and see that there is work to do on the ACA-Py side. So we'll keep this one open and see what needs to be done in ACA-Py.

[PatStLouis]

@TimoGlastra is it possible to use the did:key verification method as the kid here? This has been how acapy processes attachments since its inception in 2019 by looking at the commit history.

[TimoGlastra]

is it possible to use the did:key verification method as the kid here? This has been how acapy processes attachments since its inception in 2019 by looking at the commit history.

But we do send the kid in the unprotected header. Do you expected it in the protected header? The examples in the aries rfcs use the unprotected header

[PatStLouis]

@TimoGlastra thanks for looking this up and providing information here, I'm just going off based on what the code is doing and what is causing the issue. Can you please link me to the RFC example you are referring to? As long as both aca-py/credo implement the best practice I can make some change in aca-py. Using the did:key as the kid value in the protected header seems like the quickest way to fix this, but if you say that is wrong or not the best practice we are happy to make some changes as long as this is documented somewhere.