DIF · date: see source
DIDComm Messaging v2
DIDComm Messaging Specification v2.0 (DIF)
If your 'p2p agent auth' conversation comes from digital-wallet people, they mean this. If it comes from OAuth/AAuth people, they probably do not.
At a glance
- Problem
- Agents (in the SSI sense) need transport-agnostic, end-to-end encrypted, optionally authenticated messaging based on DID keys.
- Identity / authn / authz
- Authenticated (authcrypt) or anonymous (anoncrypt) messaging. Authorization is application-level.
Actors
- Sender agent
- Recipient agent
When this matters for agents
When this matters for agents: if your 'p2p agent auth' conversation comes from digital-wallet people, they mean DIDComm (authcrypt/anoncrypt messaging). DIDComm 'agents' predate LLM agents. No interop with A2A or MCP is implied. Different stack, different problem.
Flow in plain language
Messages are packed to the recipient DID's keyAgreement keys. authcrypt requires the sender key to be authorized on the sender DID. Peer DIDs are recommended to reduce correlation.
Key tokens and claims
- from (DID)
- Required for authcrypt; must match an authorized sender key.
Implementer notes
DIDComm 'agents' predate LLM agents. Do not assume DIDComm interoperability with A2A or MCP. Different stack, different problem (messaging vs. HTTP API access vs. task protocol).
Relationship to others
Primary sources
- DIDComm v2.0https://identity.foundation/didcomm-messaging/spec/v2.0/