Repository navigation
tracker: complete confidential-hardware conformance and release assurance decision #47
Description
Activity
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) intoPeerRequest, plus the reverse attach helper for clients. - Unit tests + fixtures; update
docs/spec/transport.mdwith 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 aPeerRequesttohandle_peer_request.Proposed A2A attachment
Per A2A v1.0 extensions: clients opt in via the
A2A-Extensionsheader; data rides inmetadataon the message/params.Item Proposed value Extension URI https://agentrust.io/extensions/ca2a/v0.1Delegation chain …/delegation_chain→ JSON array of credential objects (root→leaf)Requested capability …/requested_capability→ stringRecord id …/record_id→ stringParent record hash …/parent_record_hash→ string | nullSealed 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.
- A transport-side adapter that parses a real A2A-shaped
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
SendMessagemetadata in,PeerRequestout; 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_payloadas opaque bytes only. It is fine to base64url-decode and carry it intoPeerRequest, 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 throughattach_ca2a_metadatathenparse_peer_request. - Update
docs/spec/transport.mdto name the concrete keys and state that this only wires extraction intohandle_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_requestshape,docs/spec/transport.md,ROADMAP.md, andLIMITATIONS.md. No local tests were needed for this issue-scope review.- Keep the adapter outside the profile core: A2A
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_requestwired end to end on a live inbound call. #52 landedca2a startdrivingca2a_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_offerbeforeopen_sealedrather than only verifying its delegation chain. The wiring gap the box describes is closed. Whether a given deployment reachesassurance="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.attestproduces 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_DATAand 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.mdlists 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.
@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
main076639ac: #48, #52, #86, #89, #90, #95 and #99 all merged,docs/hardware-validation.mdis present, andsrc/ca2a_runtime/challenge.py,transport/server.py,transport/a2a_adapter.pyandtransport/a2a_sdk.pyall 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_DATAand 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.
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.mdandLIMITATIONS.mdon current main (post #141, merged3db81cd98, 2026-08-25).SevSnpProvider.atteston an SEV-SNP guest. Done 2026-08-24 on a GCPn2d-standard-4(AMD Milan). The report was produced by this codebase's own configfs-TSM collector,auxblobcarried 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,REPORTDATAmatched 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.mdstill 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.0shipped 2026-08-18 as a Developer Preview, andpyproject.tomlon main is already at0.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.
- changed the title
[-][tracker] Path to non-alpha 0.1.0: live A2A transport + hardware-backed attestation[/-][+]tracker: complete confidential-hardware conformance and release assurance decision[/+]on Sep 7, 2026
Tracks the evidence gates for describing cA2A as confidential/attested across trust domains. State as of 2026-09-23: live transport is complete, and #141 records successful SNP and TDX collector runs on real hardware. Hardware conformance and mutual simultaneous attestation remain open. TPM certificate-chain validation remains a separate limitation. See docs/hardware-validation.md, LIMITATIONS.md, and ROADMAP.md. Mapping contributed by @Susanpdl.
Definition of done
Complete the remaining hardware evidence gates, then make an explicit release assurance decision defining which platforms and trust-domain claims the evidence supports. A version number alone does not establish that assurance.
1. Live A2A transport (Tier 2)
PeerRequest(profile stays transport-agnostic; the adapter lives outside the profile). Done: feat(transport): A2A extension adapter for PeerRequest #48 landedca2a_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_requestwired 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 landedca2a startdrivingca2a_runtime.transport.server; fix: bound reference HTTP ingress #99 bounded that ingress with length limits, read timeouts and structured 400s.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'scaller_offerbeforeopen_sealedrather than only verifying its delegation chain. Whether a given deployment reachesassurance="hardware"through it is section 2's question, not this one.2. Hardware-backed attestation, at least one backend (Tier 3, critical path)
docs/hardware-validation.md.SevSnpProvider.attestproduces a real report on a non-paravisor SEV-SNP guest. Done 2026-08-24, recorded in docs: SEV-SNP and TDX collection validated on real silicon #141: the configfs-TSM collector ran on GCPn2d-standard-4(AMD Milan), supplied VCEK/ASK/ARK, appraised to the AMD root, and rejected a flipped bit.c3-standard-4, an 8000-byte DCAP v4 quote, matchingREPORTDATA, and appraisal to the Intel SGX Root CA.3. Conformance and mutual attestation 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).Validate mutual simultaneous attestation between two independently operated peers. The recorded cross-TEE run exercised one-directional appraisal using one operator's harness; it does not close this gate.
4. Release assurance decision
0.1.0/a1target is obsolete; choose release wording and version against the evidence available at that point.Out of scope (deferred to v1.0, not required to drop alpha)