tracker: complete confidential-hardware conformance and release assurance decision #47

Activity

1. imran-siddique

   added

   enhancementNew feature or requestNew feature or request

   tier-3Tier 3 — real hardware attestation (critical path)Tier 3 — real hardware attestation (critical path)

   attestationTEE / hardware attestationTEE / hardware attestation

   on Jul 10, 2026
2. Susanpdl commented on Jul 12, 2026

   

   Susanpdl

   on Jul 12, 2026

   Contributor

   More actions

   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.
3. carloshvp commented on Jul 12, 2026

   

   carloshvp

   on Jul 12, 2026

   Member

   More actions

   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.
4. Susanpdl commented on Aug 17, 2026

   

   Susanpdl

   on Aug 17, 2026

   Contributor

   More actions

   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.
5. imran-siddique commented on Aug 23, 2026

   

   imran-siddique

   on Aug 23, 2026

   MemberAuthor

   More actions

   @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.
6. Susanpdl commented on Aug 25, 2026

   

   Susanpdl

   on Aug 25, 2026

   Contributor

   More actions

   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.
7. imran-siddique commented on Sep 7, 2026

   

   imran-siddique

   on Sep 7, 2026

   MemberAuthor

   More actions

   PR #141 merged the SNP and TDX collector validation evidence. The remaining gate is conformance on confidential-computing hardware, followed by a decision on the attested-across-trust-domains claim. TPM chain provenance remains separate in #77; the original 0.1.0 release wording is stale.
8. imran-siddique

   self-assigned this

   on Sep 7, 2026
9. imran-siddique

   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
10. altrudev commented on Oct 16, 2026

    

    altrudev

    on Oct 16, 2026 – with ChatGPT Codex Connector

    Last edited by altrudev

    More actions

    Withdrawn by the author. This discussion is being maintained in the Frequency Federation project repository.