GET /v1/aci/attestation for the full field reference. This
page explains what each part proves.
What the report contains
The receipt-signing keys live in
attestation.workload_keyset.receipt_signing_keys, and the E2EE keys
in attestation.workload_keyset.e2ee_public_keys. (The legacy
/v1/attestation/report alias also adds top-level
signing_address / signing_algo / signing_public_key for older clients.)
Why the nonce matters
You pass?nonce=<random>. The gateway mixes your nonce into report_data inside the
hardware-signed quote. Because the quote is signed by the TEE, a report that commits to a nonce you
just generated cannot be a replay of an old capture. Generate a new nonce every time you verify, and
confirm the report’s report_data is derived from that nonce and the published keyset.
How verification uses the report
A verifier checks, in order:attestation.evidence.quoteverifies against Intel’s DCAP collateral, and the quote’s report data binds yournonceand theworkload_keyset.- The quote-bound statement commits to the JCS digest of
workload_keyset. workload_keyset_digestmatches what later receipts cite.- The keyset has not expired (
workload_keyset.not_afteris in the future). - The event log replays to the quote’s RTMR3 and its measured
compose-hashequalssha256(app_compose). - For reviewed-release enforcement, the measured compose hash is in an independently obtained allowlist.
source_provenance helps locate source for review, but the workload declares it. The compose hash is
the value bound into RTMR3 and accepted by verifier policy.
The gateway loads its identity and signing keys from dstack KMS inside the TEE. There is no
ephemeral-key or stub-quote mode: a report always carries a real hardware quote.
Related
Receipts
How a single response is bound to this attested identity.
Verify a response
Run the full check end to end.