[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. State as of 2026-08-23: the live transport is done and one hardware run remains on the critical path. Section 1 is complete, and section 2 has real SEV-SNP report and VCEK verification against a confidential VM. What is left is generating an SNP report on a non-paravisor guest, plus a conformance run on CC hardware. Both need hardware access rather than more code. Mapping contributed by @Susanpdl. 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). Done: feat(transport): A2A extension adapter for PeerRequest #48 landed ca2a_runtime.transport.a2a_adapter, feat(transport): bridge to the official a2a-sdk (#91) #95 replaced the hand-rolled path with a bridge to the official a2a-sdk.
• 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. Done: feat(cli): ca2a start, run the reference transport from a config file #52 landed ca2a start driving ca2a_runtime.transport.server; fix: bound reference HTTP ingress #99 bounded that ingress with length limits, read timeouts and structured 400s.
• The sealed channel is bound to a verified attestation report on the live call. Done: feat(ca2a): mutual attestation design, and the challenge primitive #89 landed the mutual-attestation design and the stateless challenge primitive (src/ca2a_runtime/challenge.py), feat(ca2a): appraise the caller before opening its payload #90 threaded it through the transport so the callee appraises the caller's caller_offer before open_sealed rather than only verifying its delegation chain. Whether a given deployment reaches assurance="hardware" through it is section 2's question, not this one.
• 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). Done 2026-07-27 against a 2026-07-20 Azure capture, recorded in docs/hardware-validation.md.
• SevSnpProvider.attest produces a real report on an SEV-SNP guest. The one open item on the critical path. The collector exists (feat(tee): implement SEV-SNP and TDX collectors over configfs-TSM #86, via configfs-TSM) and has never run on silicon. Note the wrinkle: every piece of real SNP evidence this project holds came from an Azure CVM, and Azure runs SNP behind a Hyper-V paravisor, so the guest cannot set REPORT_DATA and roots its channel key through the vTPM instead. This collector does not apply there. Closing this needs a non-paravisor guest: GCP N2D or bare metal.
• Stretch: the same end-to-end validation for TDX and TPM 2.0 (each needs its own hardware). Further along than this line suggested. The TPM collector produced a genuine platform-AK quote on a real Azure vTPM on 2026-08-01, with only the certificate chain outstanding (tee: TPM key provenance is host-dependent on Azure, and the local TPMT_SIGNATURE parser is a duplicate #77). The TDX verifier was validated against a real GCP C3 quote. Neither the TDX nor the TPM collector path is finished: TDX has not run on hardware, and GCP C3 is the natural host since that is where the appraised quote came from.
• 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.

[Susanpdl]

This tracker has not been updated since 12 July and every box is still unticked, while section 1 has actually finished and section 2 is one run short. Anyone reading it today would conclude the opposite of what shipped. I do not have write access to tick them, so here is the mapping with evidence.

Section 1, live A2A transport: complete

Adapter parses real A2A wire messages. #48 landed ca2a_runtime.transport.a2a_adapter, and #95 replaced the hand-rolled path with a bridge to the official a2a-sdk.

handle_peer_request wired end to end on a live inbound call. #52 landed ca2a start driving ca2a_runtime.transport.server, and #99 later bounded that ingress with length limits, read timeouts and structured 400s.

Sealed channel bound to a verified attestation report on the live call. This is the box I would have expected to still be open, and it is not. #89 landed the design and the stateless challenge primitive, and #90 threaded it through the transport, so the callee now appraises the caller's caller_offer before open_sealed rather than only verifying its delegation chain. The wiring gap the box describes is closed. Whether a given deployment reaches assurance="hardware" through it is section 2's question, not this one.

Section 2, hardware-backed attestation: one item left, with a wrinkle

Real SEV-SNP report plus VCEK end to end on a confidential VM. Done 2026-07-27 against a 2026-07-20 Azure capture, recorded in docs/hardware-validation.md.

SevSnpProvider.attest produces a real report on an SEV-SNP guest. This is the one genuinely open item, and it is worth being precise about what would close it. The collector now exists (#86), going through configfs-TSM, but has never run on silicon.

The wrinkle: every piece of real SNP evidence this project has came from an Azure CVM, and Azure is precisely where this collector does not apply. Azure runs SNP behind a Hyper-V paravisor, so the guest cannot set REPORT_DATA and roots its channel key through the vTPM instead. Ticking this box needs a non-paravisor guest, GCP N2D or bare metal, which is a different machine than the one the earlier runs used. docs/hardware-validation.md lists what the run should confirm.

Stretch, TDX and TPM. Further along than the box suggests. The TPM collector produced a genuine platform-AK quote on a real Azure vTPM on 2026-08-01, with only the certificate chain outstanding (#77). The TDX verifier was validated against a real GCP C3 quote. The TDX collector has not run on hardware, and GCP C3 is the natural host since that is where the appraised quote came from.

Sections 3 and 4: untouched

Conformance on hardware has not been attempted, and the claim flip and release have not started.

What is actually left to cut 0.1.0

One SNP report generated on a non-paravisor guest, one conformance run on confidential-computing hardware, then the caveat removal and the release. Both remaining runs need hardware access rather than more code, which is a different kind of blocker than this tracker currently implies.

[imran-siddique]

@Susanpdl thank you, and sorry it took six days. Every claim in your mapping checks out and I have ticked the boxes against it.

I verified rather than took it, against main 076639ac: #48, #52, #86, #89, #90, #95 and #99 all merged, docs/hardware-validation.md is present, and src/ca2a_runtime/challenge.py, transport/server.py, transport/a2a_adapter.py and transport/a2a_sdk.py all exist.

The thing you caught is worse than a stale checkbox and worth naming. This repository's whole discipline is proof, not promises, and the tracker was failing that in the direction nobody watches for. We are careful not to claim more than shipped. This claimed less, for six weeks, on the page a reader goes to for the project's status. A tracker that understates is the same integrity failure as one that overstates, and it is harder to catch because it never trips anyone's scepticism.

Your read on what is left is the one I am adopting. One SNP report on a non-paravisor guest, one conformance run on CC hardware, then the caveat removal and the release. And you are right about the wrinkle, which is the part most people would have missed: every piece of real SNP evidence here came from an Azure CVM, Azure runs SNP behind a Hyper-V paravisor so the guest cannot set REPORT_DATA and roots through the vTPM instead, and the configfs-TSM collector from #86 therefore cannot be exercised on the machine that produced all our other evidence. GCP N2D or bare metal, a different host.

That reframes the remaining blocker correctly: hardware access, not code. The tracker previously implied the opposite.

I have also written the TPM and TDX detail into the stretch line rather than leaving it as one unticked box, since "not started" and "verifier validated against a real GCP C3 quote, collector not yet run" are very different states.

On write access: noted, and it is a fair thing to raise. Nobody should have to file a comment because they cannot tick a box they have the evidence for.

[Susanpdl]

Follow-up to the Aug 23 tick-up. Two of the boxes left open there are closed on main now, and one more line in this tracker is stale for a different reason.

Section 2 collector boxes: closed by #141

Verified against docs/hardware-validation.md and LIMITATIONS.md on current main (post #141, merge d3db81cd98, 2026-08-25).

SevSnpProvider.attest on an SEV-SNP guest. Done 2026-08-24 on a GCP n2d-standard-4 (AMD Milan). The report was produced by this codebase's own configfs-TSM collector, auxblob carried VCEK/ASK/ARK, appraisal reached the ARK, and a flipped bit failed closed. That is the non-paravisor path this box asked for, and the wrinkle from the earlier comment held: Azure was the wrong machine for this collector, GCP N2D was the right one.

Stretch, TDX half. Also done 2026-08-24 on a GCP c3-standard-4: 8000-byte DCAP v4 quote, REPORTDATA matched the derived binding, appraised to the Intel SGX Root CA. Same loop as SNP: this codebase produced the evidence and this codebase appraised it.

Stretch, TPM half. Unchanged. Collector ran on Azure Trusted Launch (2026-08-01); certificate-chain provenance is still host-dependent and tracked in #77. hardware-validation.md still lists that under Not yet validated.

Section 3: still open

Conformance on confidential-computing hardware has not been attempted, as far as I can see. That is now the clearest remaining gate this tracker names for a non-alpha "attested across trust domains" claim. The collector silicon gap is no longer that gate.

Section 4: partly overtaken by events

The "cut 0.1.0" line is stale. v0.2.0 shipped 2026-08-18 as a Developer Preview, and pyproject.toml on main is already at 0.2.1. What is still open is the claim flip itself: removing the "do not assume attested across trust domains" caveats for whatever this release is willing to stand behind. That is a maintainer judgment call more than a missing feature, and it should wait on section 3 (and whatever of mutual-on-silicon / TPM-chain you treat as in-scope for that claim).

Same constraint as last time: I do not have write access to tick the boxes. Happy to leave the mapping here if that is still the least bad path.