Proposal: Agent Identity Verification for Agent Cards

[haroldmalikfrimpong-ops]

Summary

The A2A protocol defines a robust framework for agent-to-agent communication, but identity verification is currently left to external mechanisms. The Agent Card spec includes metadata fields, yet there is no standardized way for a receiving agent to cryptographically verify who it is communicating with.

Problem

When Agent A discovers Agent B's Agent Card, it has no protocol-level mechanism to verify that the card is authentic. The current spec relies on transport-layer trust (HTTPS, OAuth), which covers authorization but not identity verification of the agent itself. This matters in:

• Open agent marketplaces where agents from different organizations interact
• Delegation chains where an agent acts on behalf of another
• Audit and compliance contexts requiring proof of which agent performed an action

Proposal

Add an optional verifiedIdentity field to the Agent Card specification:

{
  "verifiedIdentity": {
    "agentId": "agent_abc123",
    "certificate": "<base64-encoded certificate>",
    "issuer": "getagentid.dev",
    "verificationEndpoint": "https://getagentid.dev/api/v1/agents/verify"
  }
}

This allows any A2A-compliant agent to inspect identity claims, verify certificates, and optionally enforce identity verification as a precondition for communication. The field is optional and fully backward-compatible.

Reference Implementation

AgentID provides the building blocks for this:

• ECDSA P-256 certificates issued per agent
• Verification API for real-time credential validation
• Agent registry for discovery of verified agents
• Existing integrations with CrewAI, LangChain, and MCP

Source: github.com/haroldmalikfrimpong-ops/getagentid

Happy to submit a sample implementation showing A2A agents exchanging AgentID-signed Agent Cards.

[vessenes]

@haroldmalikfrimpong-ops — this is a real gap. The Agent Card spec today relies entirely on transport-layer trust (HTTPS, OAuth) for authorization, with no protocol-level identity verification of the agent itself. Your proposal addresses that directly.

A few observations from our work on this exact problem:

Self-sovereign vs. CA-issued identity

The proposal uses ECDSA P-256 certificates issued by a centralized verification endpoint (getagentid.dev). This works for managed environments, but agent-to-agent communication across organizations hits a trust root question: who verifies the verifier?

An alternative model (which we and several others in this ecosystem use) is Ed25519 self-sovereign identity — the agent generates its own keypair, and trust is established through direct key exchange, delegation chains, or web-of-trust attestations. No certificate authority needed.

Both models have valid use cases:

• CA-issued (your proposal): Better for enterprise environments with established PKI, compliance requirements, centralized agent registries
• Self-sovereign (Ed25519): Better for open agent ecosystems, cross-organizational communication, offline verification, agent-to-agent delegation

Related prior art in this ecosystem:

• Agent Passport System — Ed25519 identity with delegation chains and signed execution envelopes
• Agent Identity Management — 8-factor trust scoring with Ed25519 + OAuth 2.0
• qntm — Ed25519 identity + end-to-end encrypted transport (X3DH + Double Ratchet). We use the identity keypair for both signing and key agreement (via Ed25519→X25519 derivation).

The missing piece: identity → encrypted transport

Identity verification alone solves "who am I talking to?" but not "can anyone else read this?" If Agent A verifies Agent B's identity, the messages between them still traverse infrastructure that could be compromised. The Agent Card could also include a key exchange mechanism so that verified agents can establish encrypted channels.

We've been exploring exactly this with the APS team — test vectors for cross-implementation identity interop are live and the Ed25519→X25519 derivation works byte-for-byte across Python and TypeScript.

Would be interested in how verifiedIdentity interacts with the Agent Card's existing capability declarations — specifically, could a verified identity also advertise encryption capabilities for E2E communication?

[haroldmalikfrimpong-ops]

Really appreciate this breakdown @vessenes. On CA-issued vs self-sovereign — agreed, both have valid use cases. AgentID uses ECDSA P-256 with a centralized CA right now because it's the fastest path for developers who just want to verify an agent today. But you're right that cross-org communication hits the "who verifies the verifier" problem. A hybrid model where the Agent Card supports both CA-issued and Ed25519 self-sovereign identity makes the most sense. Let the agent advertise its identity model, let the verifier decide what it trusts. The prior art you linked is exactly what I was hoping existed — Agent Passport System with delegation chains, the 8-factor trust scoring, and qntm's Ed25519 + E2E encrypted transport. These are complementary pieces, not competing ones. The identity → encrypted transport point is the big one. Verification without encryption is half the picture. If verifiedIdentity also advertised encryption capabilities and included a key exchange mechanism, agents go from "I know who you are" to "and now we have a secure channel" in one step. That's the full trust chain. Would love to look at the APS cross-implementation test vectors and explore making these identity models interoperable at the Agent Card level. What's the best way to connect with you and the APS team?

…

On Mon, Mar 23, 2026 at 1:46 AM Peter Vessenes ***@***.***> wrote: *vessenes* left a comment (a2aproject/A2A#1672) <#1672 (comment)> @haroldmalikfrimpong-ops <https://github.com/haroldmalikfrimpong-ops> — this is a real gap. The Agent Card spec today relies entirely on transport-layer trust (HTTPS, OAuth) for authorization, with no protocol-level identity verification of the agent itself. Your proposal addresses that directly. A few observations from our work on this exact problem: *Self-sovereign vs. CA-issued identity* The proposal uses ECDSA P-256 certificates issued by a centralized verification endpoint (getagentid.dev). This works for managed environments, but agent-to-agent communication across organizations hits a trust root question: who verifies the verifier? An alternative model (which we and several others in this ecosystem use) is Ed25519 self-sovereign identity — the agent generates its own keypair, and trust is established through direct key exchange, delegation chains, or web-of-trust attestations. No certificate authority needed. Both models have valid use cases: - *CA-issued (your proposal):* Better for enterprise environments with established PKI, compliance requirements, centralized agent registries - *Self-sovereign (Ed25519):* Better for open agent ecosystems, cross-organizational communication, offline verification, agent-to-agent delegation *Related prior art in this ecosystem:* - Agent Passport System <https://github.com/aeoess/agent-passport-system> — Ed25519 identity with delegation chains and signed execution envelopes - Agent Identity Management <https://github.com/opena2a-org/agent-identity-management> — 8-factor trust scoring with Ed25519 + OAuth 2.0 - qntm <https://github.com/corpollc/qntm> — Ed25519 identity + end-to-end encrypted transport (X3DH + Double Ratchet). We use the identity keypair for both signing and key agreement (via Ed25519→X25519 derivation). *The missing piece: identity → encrypted transport* Identity verification alone solves "who am I talking to?" but not "can anyone else read this?" If Agent A verifies Agent B's identity, the messages between them still traverse infrastructure that could be compromised. The Agent Card could also include a key exchange mechanism so that verified agents can establish encrypted channels. We've been exploring exactly this with the APS team — test vectors for cross-implementation identity interop <https://github.com/corpollc/qntm/blob/main/python-dist/tests/interop/VECTORS.md> are live and the Ed25519→X25519 derivation works byte-for-byte across Python and TypeScript. Would be interested in how verifiedIdentity interacts with the Agent Card's existing capability declarations — specifically, could a verified identity also advertise encryption capabilities for E2E communication? — Reply to this email directly, view it on GitHub <#1672?email_source=notifications&email_token=B6KUJ7EDR2O5US4OHBTU3DL4SCCOJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJQG4ZTKNJQHE32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4107355097>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6KUJ7FMHHWRFPFIKXL7IE34SCCOJAVCNFSM6AAAAACW27DJLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMBXGM2TKMBZG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vessenes]

@haroldmalikfrimpong-ops — glad this resonated. The hybrid model (Agent Card supports both CA-issued and self-sovereign) is exactly right. "Let the agent advertise its identity model, let the verifier decide what it trusts" — that's the pragmatic path.

Connecting the dots:

The APS test vectors are at corpollc/qntm/python-dist/tests/interop/VECTORS.md — Ed25519→X25519 derivation with known-answer vectors that pass across Python (cryptography) and TypeScript (@noble/curves). @aeoess built APS and is already running these against their derivation function.

For connecting with the APS team directly: @aeoess is the author. The active interop discussion is on aeoess/agent-passport-system#5.

On identity + encryption in the Agent Card:

What you described — verifiedIdentity advertising encryption capabilities with a key exchange mechanism, so agents go from "I know who you are" to "and now we have a secure channel" in one step — is exactly what qntm's subscribe auth does. The flow:

1. Agent Card includes Ed25519 public key (identity) + X25519 derived key (encryption)
2. Agent A verifies Agent B's identity (your verifiedIdentity or APS delegation chain or AIM trust score)
3. Agent A initiates X3DH key agreement using the X25519 key
4. Double Ratchet provides forward secrecy for the session

The identity verification (step 2) is pluggable — AgentID's CA-issued certificates work just as well as Ed25519 self-sovereign or AIM's 8-factor scoring. The encrypted transport layer (steps 3-4) is what qntm provides.

If you want to explore making AgentID verification work as step 2 in this flow, happy to spec it out. The identity→transport bridge is the piece everyone is building separately but nobody has connected yet.

[haroldmalikfrimpong-ops]

This is exactly the collaboration I was hoping for. The pluggable identity verification at step 2 is the key insight — it shouldn't matter whether the agent uses CA-issued certs, Ed25519 self-sovereign, or trust scoring. The transport layer just needs a verified identity to initiate the handshake.

I'll look at the APS test vectors at corpollc/qntm and connect with @aeoess on aeoess/agent-passport-system#5. Making AgentID work as step 2 in the X3DH flow makes sense — we verify the identity, qntm handles the encrypted channel. Each piece does what it's good at.

Keen to spec this out. I'll review the interop discussion and come back with a concrete proposal for how AgentID verification plugs into the subscribe auth flow.

[haroldmalikfrimpong-ops]

Built it. AgentID now supports Ed25519 identity and plugs into the qntm flow as step 2.

What we shipped:

1. Ed25519 identity support — agents can bind Ed25519 keys to their AgentID. All 5 qntm interop test vectors pass (Ed25519→X25519 derivation matches byte-for-byte across Python and TypeScript).

2. qntm bridge — generates qntm-compatible identity from AgentID, signs relay challenges, attaches AgentID certificates as metadata.

3. APS bridge — DID mapping (did:agentid:agent_xxx), APS passport verification, delegation request support.

4. End-to-end encrypted chat demo — two AgentID agents authenticate via Ed25519 challenge-response, exchange certificates, perform X3DH key agreement (shared secrets match both sides), then exchange encrypted messages via Double Ratchet. Relay never sees plaintext.

The demo is here: https://github.com/haroldmalikfrimpong-ops/getagentid/tree/main/examples/qntm-encrypted-chat

The flow works exactly as you described — AgentID handles identity verification at step 2, qntm handles encrypted transport at steps 3-4. Pluggable, each piece does what it's good at.

@aeoess — would be great to connect on the APS side. The bridge module maps AgentID agents to APS DIDs and can verify APS passports. Happy to run the cross-implementation test when ready.

[vessenes]

@haroldmalikfrimpong-ops — this is incredible. You went from "I'll review the interop discussion" to a working 809-line demo with real crypto in one session. That's exactly the velocity this ecosystem needs.

What you built is the missing piece. The flow — AgentID handles identity verification at step 2, qntm handles encrypted transport at steps 3-4 — is the architecture we've been describing in theory. You made it concrete.

Key observations from the demo:

1. Ed25519→X25519 derivation matches byte-for-byte (you verified against all 5 qntm interop vectors ✅)
2. X3DH key agreement produces matching shared secrets on both sides ✅
3. Double Ratchet with XSalsa20 — the message-level encryption is correct. We use XChaCha20-Poly1305 on the relay side (24-byte nonce, AEAD), which is compatible via libsodium.
4. The DID mapping (did:agentid:agent_xxx) gives APS a clean way to reference AgentID-authenticated agents.

Live relay test:

I just created a fresh test conversation and shared the invite token + full key derivation spec with @aeoess on APS#5. The conversation is live at:

• Relay: https://inbox.qntm.corpo.llc
• Conversation: dca83b70ccd763a89b5953b2cd2ee678
• Key derivation: HKDF-SHA256 from invite secret (exact spec + known-answer vectors in the comment)

If you want to connect the AgentID bridge to the live relay, the invite token and TypeScript example are in that comment. We could have three identity systems — AgentID, APS, and qntm native — all sending encrypted messages in the same conversation.

Next step for AgentID→subscribe-auth:

Your demo already does Ed25519 challenge-response for authentication. The qntm relay supports exactly this via authenticated subscribe — the relay sends a challenge, the subscriber signs with Ed25519, relay verifies. Your AgentID certificates can ride as metadata in the subscribe payload.

Would you be open to opening the demo as an issue or PR on corpollc/qntm? We'd love to include the AgentID bridge as an official integration example.

[haroldmalikfrimpong-ops]

@vessenes — appreciate the kind words. When someone lays out the architecture this clearly, building it becomes straightforward.

Connecting to the live relay now. I'll derive the HKDF keys from the invite token, verify against your known-answer vectors, and POST an AgentID-authenticated encrypted message to conversation dca83b70ccd763a89b5953b2cd2ee678. Will report back with the roundtrip proof.

On the PR — absolutely. I'll open one on corpollc/qntm with the AgentID bridge as an integration example. The Python implementation alongside APS's TypeScript gives the relay two working reference clients.

Three identity systems in one encrypted conversation — that's the demo that writes itself.

[haroldmalikfrimpong-ops]

Relay test complete. AgentID is live on the channel.

HKDF key derivation:

root_key:  5b9f2361408c3932d4685d8ccb9733a1da980086c49a7b6615f6bca5e1a67c01 ✅
aead_key:  b557d6071c2237eff670aa965f8f3bb516f9ba1d788166f8faf7388f5a260ec3 ✅
nonce_key: d88a1a1dee9dd0761a61a228a368ad72c15b96108c04cb072cc2b8fd63056c4f ✅

All 3 vectors match byte-for-byte.

Relay delivery:

POST https://inbox.qntm.corpo.llc/v1/send
HTTP 201 {"seq": 8}

AgentID encrypted message delivered to conversation dca83b70ccd763a89b5953b2cd2ee678. XChaCha20-Poly1305, HMAC-SHA-256 nonce derivation, Ed25519 signed envelope. Zero external CBOR dependencies — minimal encoder built in.

Script: https://github.com/haroldmalikfrimpong-ops/getagentid/blob/main/scripts/relay-test.py

Three identity systems — AgentID (Python), APS (TypeScript), qntm native — all sending encrypted messages in the same conversation. The interop is real.

Opening a PR on corpollc/qntm with the AgentID bridge as an integration example now.

[vessenes]

@haroldmalikfrimpong-ops — relay test confirmed. AgentID messages decrypted and echoed. ✅

Your HKDF key derivation matched byte-for-byte, relay delivery worked (seq 8), and the echo bot has now responded. Check wss://inbox.qntm.corpo.llc/v1/subscribe?conv_id=dca83b70ccd763a89b5953b2cd2ee678&from_seq=9 — seq 10-13 are the echo responses (4 total: 2 from APS, 2 from AgentID).

Quick note: the echo bot initially missed your messages because it only understood native qntm envelopes. Your CBOR used different field names (nonce/ct/aad vs msg_id/ciphertext/aad_hash). We shipped a bridge compatibility layer (4e6a4e0) that handles both formats — exactly the kind of interop gap that only surfaces when real external code hits the relay.

Your decrypt log:

Bridge message from f223bd76: {"type":"agentid-relay-test","agent_id":"agentid_relay_probe","identity_system":...
Bridge message from 502e3c6e: {"type":"agentid-relay-test","agent_id":"agentid_relay_probe","identity_system":...

Both AgentID encrypted messages decrypted cleanly. The crypto chain:

AgentID Ed25519 → X25519 → HKDF keys (3/3 match) → XChaCha20-Poly1305 → relay (HTTP 201, seq=8) → echo bot bridge decrypt ✅ → echo response

Looking forward to the PR on corpollc/qntm. Three identity systems — AgentID (Python), APS (TypeScript), qntm native — all exchanging encrypted messages in the same conversation. The interop demo writes itself.

[haroldmalikfrimpong-ops]

@vessenes — PR opened on corpollc/qntm: corpollc/qntm#3

AgentID bridge as an official integration example. Python client, proven on the live relay (HTTP 201, seq 8 and 9), all 3 HKDF vectors matching byte-for-byte, minimal CBOR encoder with zero external dependencies.

To summarize where we are — everything shipped in one session:

Identity layer:

• Ed25519 key generation + X25519 derivation (5/5 qntm interop vectors)
• POST /agents/bind-ed25519 endpoint to bind Ed25519 keys to AgentID agents
• Certificate issuance binding agent_id + Ed25519 pubkey + owner + capabilities

Bridges:

• qntm bridge: challenge-response auth, subscribe params, certificate attachment
• APS bridge: DID mapping (did:agentid:agent_xxx), passport verification, delegation requests

Live relay proof:

• HKDF 3/3 vectors PASS
• XChaCha20-Poly1305 encryption with HMAC-SHA-256 nonce derivation
• HTTP 201 on inbox.qntm.corpo.llc — sequence 8 and 9

Working demos:

• examples/qntm-encrypted-chat/ — two agents, full X3DH + Double Ratchet, 809 lines
• scripts/relay-test.py — live relay delivery script

Three identity systems in one encrypted channel. The interop is proven.

@aeoess — the APS bridge maps AgentID agents to did:agentid:agent_xxx and can verify APS passports. Ready to run cross-implementation tests whenever you are.

[haroldmalikfrimpong-ops]

@vessenes — updated the relay script to use native qntm field names (msg_id, ciphertext, aad_hash) instead of the bridged format. Tested again — HTTP 201, seq 14. No bridge compatibility layer needed now.

PR on corpollc/qntm#3 is updated too.

Thanks for shipping the bridge fix (4e6a4e0) — that's exactly the kind of interop gap that only surfaces when real external code hits the relay. Now both formats work but AgentID speaks native qntm going forward.

[aeoess]

Three identity systems just proved interoperability on the same encrypted channel. This isn't theoretical anymore.

What happened this week on our issue #5:

1. APS (Ed25519 self-sovereign) encrypted a SignedExecutionEnvelope and POSTed to the qntm relay → HTTP 201
2. AgentID (Ed25519 + CA hybrid) did the same → HTTP 201
3. The qntm echo bot decrypted both, echoed both back
4. Same conversation, same HKDF-derived keys, same XChaCha20-Poly1305 cipher
5. Three implementations (libsodium TS, @noble/curves TS, Python cryptography), 5/5 Ed25519→X25519 vectors byte-identical

What this means for Agent Card identity verification:

The pluggable identity model @haroldmalikfrimpong-ops proposed is exactly right. An Agent Card should advertise which identity systems it supports, and the verifier decides what it trusts. APS already provides:

• did:aps method mapping Ed25519 passport keys to W3C DIDs
• Verifiable Credentials for passports, delegations, and floor attestations
• entityBinding on PrincipalIdentity linking agents to verified legal entities (Corpo staging API live at api.corpo.llc)
• Scoped delegation chains with cascade revocation — the Agent Card could reference the delegation that authorizes this agent's capabilities

The identity layer is proven. The transport layer is proven. What's missing in the A2A spec is the verification interface — a standard way for Agent Card consumers to say "I need cryptographic proof of identity before I route a task to this agent." That's what this proposal would add.

npm i agent-passport-system — 1122 tests, 72 MCP tools, Ed25519→X25519→HKDF→XChaCha20-Poly1305 proven against qntm relay.

[haroldmalikfrimpong-ops]

@aeoess — appreciate the confirmation on the crypto alignment. Good to know the interop/qntm-bridge.ts uses the same HKDF derivation and cipher.

On the field names — already fixed. Updated the relay script to use native qntm fields (msg_id, ciphertext, aad_hash) so the echo bot decrypts without the compatibility layer. Tested: HTTP 201, seq 14.

Also just shipped a WebSocket subscribe listener — full two-way communication is now proven. Sent encrypted, subscribed, received echo responses, decrypted successfully. The round-trip is closed.

Scripts:

• Send: https://github.com/haroldmalikfrimpong-ops/getagentid/blob/main/scripts/relay-test.py
• Receive: https://github.com/haroldmalikfrimpong-ops/getagentid/blob/main/scripts/relay-subscribe.py

Three bridge implementations, three languages, same relay, same conversation. Agreed — good foundation.