Skip to content

docs(roadmap): add upstream A2A interoperability workstream #113

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
imran-siddique merged 1 commit into from
Aug 17, 2026
Merged

docs(roadmap): add upstream A2A interoperability workstream #113

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions ROADMAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -43,4 +43,7 @@ Real hardware attestation verification (SEV-SNP VCEK chain, Intel TDX quote via
- Stable delegation credential and TRACE link schema with documented versioning guarantees
- Full RATS/EAT conformance for peer attestation evidence
- Conformance suite for "cA2A-compatible" claims: **landed** (`tests/conformance/`, normative README + runnable MUST-level checks, in CI). A production run on confidential-computing hardware is the remaining step for a hardware-attested claim.
- **Upstream A2A interoperability: not started.** Our own conformance suite says a peer implements cA2A. It says nothing about whether attaching the profile keeps us compatible with the wider A2A ecosystem, and that is a separate question worth answering with numbers. Plan: run the official [`a2aproject/a2a-tck`](https://github.com/a2aproject/a2a-tck) conformance suite first, then the A2A Interoperability Test Kit's multi-language launcher, which covers cross-SDK compatibility across Python, Go, TypeScript, Java and Rust. Publish the result as `docs/interop-report.md`, failures reported at the same volume as passes.
- The system under test is an official `a2a-sdk` server with the extension attached through `ca2a_runtime.transport.a2a_sdk`, **not** `ca2a start`. A normative A2A transport is explicitly out of scope for this profile (see [LIMITATIONS.md](LIMITATIONS.md)), so pointing a conformance suite at the reference standard-library transport would fail baseline MUSTs for reasons that say nothing about cA2A.
- The first thing to look for is whether the protobuf `Struct` integer-ness round trip documented in `ca2a_runtime.transport.a2a_sdk` lands in the same safe place on every SDK. `Struct` has no integer type, so a credential's `depth` of `0` returns as `0.0`, and the chain verifies only because `DelegationCredential.from_dict` coerces with `int()` before RFC 8785 canonicalisation, which refuses floats outright. That it is safe in Python is tested. That it is safe in Go and Rust is an assumption.
- OWASP liaison on the multi-agent threat mapping; ITI conversation on conformance