adoption: cA2A is a profile on A2A and integrates with no A2A SDK

[imran-siddique]

The gap

cA2A describes itself as a trust profile layered on A2A. It depends on no A2A SDK, and nothing in src/ imports one:

$ grep -rn "import a2a\|from a2a\|a2a-sdk" src/ pyproject.toml
(nothing)

What exists instead is transport/a2a_adapter.py, which hand-parses A2A-shaped dicts out of metadata maps, and transport/server.py, a bespoke stdlib HTTP server. Both are honest about being a reference transport rather than the profile. But the practical consequence is that a team already running the official A2A SDK has no way to adopt cA2A short of rewriting their transport to ours, which nobody is going to do to try an alpha.

A2A reached v1.0 in April 2026 under the Linux Foundation, with official SDKs in Python, JavaScript, Java, C#/.NET, Go and Rust (pip install a2a-sdk), and is wired into Google ADK, Azure AI Foundry, Amazon Bedrock AgentCore and Copilot Studio. That is where A2A agents actually live. Our profile does not reach any of it.

This is the P0 adoption item for cA2A specifically. Every adapter we have is one we wrote for ourselves; ADOPTERS.md is empty.

Scope

A thin integration layer that lets an existing a2a-sdk server adopt the profile without replacing its transport:

• Server side. Something an SDK server can mount — a request hook or middleware — that pulls the namespaced cA2A metadata off the SDK's own inbound message type, builds a PeerRequest, calls handle_peer_request, and maps a CA2AError onto the SDK's error response at the code's own HTTP status. The enforcement core does not change; only the thing that feeds it does.
• Client side. The mirror: attach the cA2A metadata to an outbound SDK message, run the handshake, seal the payload, and optionally attest under the callee's challenge.
• The reference transport stays. It is the thing that runs with no dependencies and it is what the conformance suite drives. This is additive, and the SDK integration should be an optional extra (ca2a[a2a-sdk]) so the base install stays dependency-light.

What needs deciding first

• Which SDK surface to bind to. The SDK's server abstraction and its message/metadata types are the contract we would be coupling to, and A2A v1.0 is recent enough that pinning the wrong seam means rework. Worth reading the SDK before choosing.
• Whether the metadata parsing stays dict-shaped (parse the SDK's type into a plain map and reuse a2a_adapter unchanged) or gets typed against the SDK. The first keeps one parser and one set of tests; the second is nicer to use and doubles the surface.
• Python first, or Python and JS. cA2A's runtime is Python, so a JS client would be a separate implementation of the profile rather than an adapter, and that is a much larger commitment.

Acceptance

• An a2a-sdk server, otherwise unmodified, enforces a cA2A delegated call end to end and returns the provenance record.
• An a2a-sdk client sends one, including the sealed payload and the optional caller attestation.
• Both are exercised in CI against the released SDK, not a stub of it.
• The base install still has no A2A SDK dependency.

Not this issue

• Publishing the extension URI in the Agent Card, which is a separate normative gap.
• Anything about hardware attestation. This is transport reach only.

Related: #47 (its "live A2A transport" item is about parsing real A2A messages, which the reference transport now does; interop with the official SDK is a different thing and is not tracked there), #18 (profile stability with AAIF/Google).