Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions 159
open-standards/sandbox/spec/eat.md
Transaction Science ba1212361f Add aac, map, sandbox standards; catalog the standards family 
Commit the previously-untracked standard directories and catalog them in the
root README alongside proof:

- aac/    — communication cargo class: portable boards + a ten-level
            offline-first cascade (Apache-2.0 code / CC-BY-4.0 spec).
- map/    — geospatial cargo class: range-requestable signed tilesets +
            an F0–F4 fidelity cascade (Apache-2.0 code / CC-BY-4.0 spec).
- sandbox/— isolated, metered, attested execution across the heterogeneous
            compute fabric (Apache-2.0 code / CC-BY-4.0 spec).
- jouleclaw-otel-authz, jouleclaw-trust — new jouleclaw reference crates.

Root README now lists aac, map, sandbox, and proof in the catalog, the tree,
and the contribution guide.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-06-07 17:04:36 -04:00

2.9 KiB
Raw Permalink Blame History

EAT interoperability (RATS)

The attestation (spec/attestation.md, SPEC §7) is the standard's own signed form: Ed25519 over the JCS-canonical core. To interoperate with the broader remote-attestation ecosystem, a host SHOULD also emit the attestation as an EAT — an Entity Attestation Token (RFC 9711), carried in a CWT (RFC 8392) and signed as a COSE_Sign1 token with EdDSA. This places a Sandbox attestation on the same footing as the tokens emitted by hardware roots that already speak EAT (NVIDIA NRAS device tokens, Arm CCA platform/realm tokens, Veraison attestation results), so a generic RATS (RFC 9334) verifier can consume it.

The EAT is a view of the attestation, not a replacement. It is signed by the same Supervisor key that signs the native attestation, and it references the canonical attestation by content address — so the two cannot disagree.

Claims

The CWT claims-set is a CBOR map with integer keys:

Key Claim Value
6 iat run-finish time, seconds
10 nonce the run binding, BLAKE3(unit_id ‖ receipt_id) (32 bytes)
256 ueid unique entity id, BLAKE3(host_id)[..16]
265 eat_profile https://transaction.science/sandbox/eat/v1
273 measurements [ { 1: tier, 2: tee-launch-measurement? } ]
-77001 (profile, private) { 1: attestation_id, 2: tier, 3: receipt_id }

The nonce binds the token to a specific run; the profile claim lets a verifier that understands this profile resolve and re-verify the canonical attestation (attestation_id is its content address). measurements carries the tier and, when the boundary was hardware-enforced (S6+), the TEE launch measurement.

Signing and verification

The claims-set is the COSE_Sign1 payload. The protected header is { 1: -8 } (alg = EdDSA); the unprotected header carries the steward kid (COSE label 4). This is the family's JCR-1 COSE_Sign1 primitive (spec/receipts.md), reused verbatim, so the same tooling verifies receipts and EATs.

A verifier MUST:

  1. verify the COSE_Sign1 signature against the Supervisor's public key and confirm alg = EdDSA;
  2. confirm eat_profile is the Sandbox profile;
  3. for this profile, resolve the referenced attestation_id and re-verify the native attestation if it requires the full §7 guarantees (the EAT alone conveys the standard claims, not the entire attestation core).

Reference

sandbox-attest::eat implements both directions: Attestation::seal_eat(kid, sk) produces the signed CWT, and verify_eat(cwt, vk, kid) checks the signature and profile and returns the recovered claims. Every sealed run (SealedRun::eat) carries the EAT alongside the native attestation, and the sandbox run-wasm reference run prints and verifies it. The encoding is a self-contained deterministic CBOR writer + reader (no external CBOR dependency), keeping the token reproducible.