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

59 lines
2.9 KiB
Markdown

# 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.