[tracker] Path to non-alpha 0.1.0: live A2A transport + hardware-backed attestation

[imran-siddique]

Tracks the gate for dropping the a1 qualifier and legitimately describing cA2A as confidential/attested across trust domains. Today (0.1.0a1) everything is verifiable offline or in software; all attestation validation is synthetic-vector, and there is no live transport. Per the discipline in LIMITATIONS.md (proof, not promises), the claim flips only when the items below land. See ROADMAP.md (Tier 2 / Tier 3).

Definition of done

cA2A can honestly claim "attested across trust domains," and we cut 0.1.0 (no alpha qualifier).

1. Live A2A transport (Tier 2)

• A transport adapter parses real A2A wire messages into PeerRequest (profile stays transport-agnostic; the adapter lives outside the profile).
• ca2a_runtime.peer.handle_peer_request wired end to end on a live inbound call: verify chain → intersect delegated scope with local policy → open the sealed payload with the enclave key → emit a linked provenance record, fail-closed.
• The sealed channel is bound to a verified attestation report on the live call (closes the current gap where the seal is not tied to a verified measurement in the live path).
• Related: Example-readiness: bridge cA2A to a runnable example (offline now, live peer path next) #43 (example-readiness / live peer path), Wire the real Cedar engine into the cross-operator-delegation example #45 (Cedar in the example).

2. Hardware-backed attestation, at least one backend (Tier 3, critical path)

• Verify a real SEV-SNP report + VCEK pair end to end against a golden measurement on a confidential VM (not synthetic vectors). SEV-SNP is furthest along: the VCEK chain is already validated against the real AMD Milan root; the report-signature path needs a real report.
• SevSnpProvider.attest produces a real report on an SEV-SNP guest.
• Stretch: the same end-to-end validation for TDX and TPM 2.0 (each needs its own hardware).
• Related: feat(tee): OPAQUE managed runtime provider (explicit opt-in) #5 (OPAQUE managed runtime provider as one attestation backend).

3. Conformance on hardware

• Run tests/conformance/ on confidential-computing hardware (a production run), so a "cA2A-compatible / attested" claim is backed by a real run rather than synthetic vectors (ROADMAP v1.0 note).

4. Flip the claims and release

• Update README.md and LIMITATIONS.md to remove the "do not assume attested across trust domains" caveats for whatever landed.
• Cut 0.1.0 (drop the a1 alpha qualifier).

Out of scope (deferred to v1.0, not required to drop alpha)

• Full RATS/EAT conformance for peer attestation evidence.
• Stable, versioned delegation-credential and TRACE-link schemas.
• A2A v1.x profile-stability sign-off with AAIF/Google (spec: confirm A2A v1.x profile stability with AAIF/Google #18).

[Susanpdl]

Proposal: first slice toward Tier 2 — A2A extension adapter (parse only)

I'd like to take the first checkbox under Live A2A transport (Tier 2) as a standalone PR before wiring HTTP / ca2a start.

Scope (PR1)

• A transport-side adapter that parses a real A2A-shaped SendMessage (extension metadata) into PeerRequest, plus the reverse attach helper for clients.
• Unit tests + fixtures; update docs/spec/transport.md with the concrete URI/schema.
• Out of scope for this PR: HTTP/JSON-RPC server, ca2a start, attestation handshake, seal↔verified-measurement binding.

This matches the existing design in peer.py / docs/spec/transport.md: the profile stays transport-agnostic; the adapter lives outside it and hands a PeerRequest to handle_peer_request.

Proposed A2A attachment

Per A2A v1.0 extensions: clients opt in via the A2A-Extensions header; data rides in metadata on the message/params.

Item	Proposed value
Extension URI	https://agentrust.io/extensions/ca2a/v0.1
Delegation chain	…/delegation_chain → JSON array of credential objects (root→leaf)
Requested capability	…/requested_capability → string
Record id	…/record_id → string
Parent record hash	…/parent_record_hash → string | null
Sealed payload	…/sealed_payload → base64url ciphertext (optional)

API sketch

def parse_peer_request(message: dict, *, metadata: dict | None = None) -> PeerRequest: ...
def attach_ca2a_metadata(message: dict, request: PeerRequest) -> dict: ...

Happy to adjust the URI, key naming, or where metadata attaches (message vs params) before coding — please say if you'd prefer a short design issue first, or a PR against this proposal.

[carloshvp]

This PR1 split makes sense as a transport-adapter slice. I would take it directly as a PR rather than open a second design issue, with one boundary condition: it should stay explicitly parse/attach only and not close any of the attestation or seal-to-measurement gates in this tracker.

Acceptance bar I would use for that PR:

• Keep the adapter outside the profile core: A2A SendMessage metadata in, PeerRequest out; reverse helper attaches the same namespaced fields without changing A2A routing or payload semantics.
• Use one stable extension namespace and fail closed on malformed cA2A metadata for a cA2A-aware peer, but leave a message with no cA2A extension as ordinary A2A input rather than inventing a partial trust state.
• Treat sealed_payload as opaque bytes only. It is fine to base64url-decode and carry it into PeerRequest, but the PR should not imply the payload is bound to a verified measurement or that hardware attestation has happened.
• Add fixtures for at least: valid root-to-leaf delegation metadata, missing/invalid delegation chain, malformed base64 sealed payload, parent_record_hash: null, unknown non-cA2A metadata preserved/ignored, and a round trip through attach_ca2a_metadata then parse_peer_request.
• Update docs/spec/transport.md to name the concrete keys and state that this only wires extraction into handle_peer_request; HTTP/JSON-RPC serving, live attestation handshake, ca2a start, and seal-to-verified-report binding remain separate checkboxes before the non-alpha claim flips.

The important part is preserving the claim boundary in LIMITATIONS.md: parsing real A2A extension metadata is progress on Tier 2 transport wiring, not evidence yet that cA2A is attested across trust domains.

Validation: checked the current PeerRequest / handle_peer_request shape, docs/spec/transport.md, ROADMAP.md, and LIMITATIONS.md. No local tests were needed for this issue-scope review.