Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

tracker: complete confidential-hardware conformance and release assurance decision

Abierto
#47 7 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@imran-siddique ya está trabajando en esto.

Desde el 7/9/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

attestation enhancement tier-3

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)
  • A transport adapter parses real A2A wire messages into PeerRequest (profile stays transport-agnostic; the adapter lives outside the profile). Done: #48 landed ca2a_runtime.transport.a2a_adapter, #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: #52 landed ca2a start driving ca2a_runtime.transport.server; #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: #89 landed the mutual-attestation design and the stateless challenge primitive (src/ca2a_runtime/challenge.py), #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: #43 (example-readiness / live peer path), #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 a non-paravisor SEV-SNP guest. Done 2026-08-24, recorded in #141: the configfs-TSM collector ran on GCP n2d-standard-4 (AMD Milan), supplied VCEK/ASK/ARK, appraised to the AMD root, and rejected a flipped bit.
  • Stretch, TDX: collector and appraisal on real hardware. Done 2026-08-24, recorded in #141: GCP c3-standard-4, an 8000-byte DCAP v4 quote, matching REPORTDATA, and appraisal to the Intel SGX Root CA.
  • Stretch, TPM 2.0: complete certificate-chain validation. The collector ran on an Azure Trusted Launch vTPM on 2026-08-01, but the hardware-validation document still lists chain provenance as unvalidated. #77 is closed; that closure does not establish this hardware result.
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
  • After the remaining gates pass, update README.md and LIMITATIONS.md to state the supported assurance precisely, retaining caveats for unvalidated platforms or paths.
  • Make and record the release assurance decision after the remaining gates pass. The original 0.1.0 / a1 target 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)

  • 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 (#18).
Lenguaje dominante
Python
Estrellas
9
Forks
14
Merge medio
17 h 24 min
PR fusionados (30 d)
56

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de agentrust-io/ca2a

Todos los issues de agentrust-io/ca2a

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.