Attested Inference Receipt (AIR): A COSE/CWT Profile for Confidential AI Inference

1.1. Goals

The goals of AIR v1 are:¶

1. Define a receipt wire format using existing IETF standards (COSE_Sign1, CWT, EAT).¶

2. Bind model identity (cryptographic hash), input/output hashes, attestation metadata, and operational telemetry in a single signed envelope.¶

3. Support AIR-local verification using standard COSE/CWT tooling, while allowing deployments to combine AIR with separate platform-specific attestation verification as needed.¶

4. Carry platform measurements in a portable receipt shape while preserving their platform-specific semantics via measurement_type.¶

5. Define an intentionally closed v1 profile with fail-closed parsing semantics.¶

1.2. Non-Goals

AIR v1 explicitly does not:¶

• Define a transport protocol or session management scheme.¶

• Specify attestation document verification procedures (these are platform-specific).¶

• Define an extension registry or compatibility mechanism for new claim or platform profiles.¶

• Prove data deletion or model correctness.¶

• Provide regulatory certification or compliance guarantees.¶

• Define pipeline chaining or multi-inference receipts.¶

• Support composite attesters with multiple distinct attestation documents per receipt (e.g., CPU TEE + GPU confidential compute). Workloads running on accelerator-equipped platforms such as NVIDIA H100 Confidential Compute can emit AIR v1 receipts, but those receipts cover only the CPU-side attestation; accelerator attestation is verified out of band and is not embedded in the receipt. A future composite-attester AIR profile would pair the CPU-side receipt with device-side Evidence such as the EAT Device Assignment profile ([I-D.poirier-rats-eat-da]); the RATS Conceptual Messages Wrapper ([I-D.ietf-rats-msg-wrap]) is a candidate standard conveyance for carrying platform Evidence and an AIR receipt together. An AIR v1 receipt emitted on such a platform MUST NOT be presented as evidence that the accelerator was in a confidential-computing mode; see Section 11.7.¶

• Define verifier-emitted Attestation Results. Where a deployment needs a Verifier-signed appraisal alongside an AIR receipt, an EAT Attestation Result (EAR, draft-ietf-rats-ear) is the natural complement.¶

4.1. COSE_Sign1 Envelope

An AIR v1 receipt is a tagged COSE_Sign1 structure (CBOR tag 18) as defined in [RFC9052] Section 4.2:¶

COSE_Sign1 = [
  protected   : bstr,          ; serialized protected header
  unprotected : map,            ; unprotected header map
  payload     : bstr,           ; serialized CWT claims map
  signature   : bstr .size 64   ; Ed25519 signature
]

The signature covers Sig_structure = ["Signature1", protected, external_aad, payload] where external_aad is empty (h'').¶

Verifiers MUST reject untagged COSE_Sign1 structures. The CBOR tag 18 is mandatory.¶

4.2. Protected Header

The protected header is a CBOR map containing exactly two entries:¶

Verifiers MUST reject receipts where alg is not -8 or where content type is not 61. Additional protected header parameters are not defined in v1 and MUST NOT be present.¶

The signing algorithm is Ed25519 ([RFC8032]). Receipts MUST be verified with the strict procedure specified in Section 8, Layer 2: a non-canonical scalar S (S outside [0, L), where L is the Ed25519 group order), a small-order R or A point, and any signature failing the cofactorless group equation are all rejected. This is stricter than the baseline verification of [RFC8032] Section 5.1.7.¶

4.3. Unprotected Header

The unprotected header MUST be empty for AIR v1 receipts. AIR v1 does not use kid or any other unprotected header parameter. Because unprotected header parameters are not covered by the COSE signature, verifiers MUST reject receipts with non-empty unprotected headers.¶

4.4. Payload: CWT Claims Map

The payload is a CBOR-encoded CWT claims map. The map uses deterministic encoding per [RFC8949] Section 4.2.1: map keys are sorted in the bytewise lexicographic order of their encoded form.¶

The claims map is closed: verifiers MUST reject maps containing unknown integer keys. Duplicate keys MUST be rejected.¶

4.5. CDDL Schema

The following CDDL [RFC8610] defines the complete wire shape:¶

air-receipt = #6.18([
  protected:   bstr .cbor air-protected-header,
  unprotected: air-unprotected-header,
  payload:     bstr .cbor air-claims,
  signature:   bstr .size 64
])

air-protected-header = {
  1 => -8,          ; alg: EdDSA (Ed25519)
  3 => 61,          ; content type: application/cwt
}

air-unprotected-header = {}

air-claims = {
  ; --- Standard CWT/EAT claims ---
  1   => tstr,                  ; iss: issuer
  6   => uint,                  ; iat: issued-at (Unix seconds)
  7   => bstr .size 16,         ; cti: CWT ID (UUID v4, 16 bytes)
  265 => "https://spec.cyntrisec.com/air/v1",  ; eat_profile
  ? 10 => bstr .size (8..64),   ; eat_nonce (optional)

  ; --- AIR private claims ---
  -65537 => tstr,               ; model_id
  -65538 => tstr,               ; model_version
  -65539 => sha256-hash,        ; model_hash
  -65540 => sha256-hash,        ; request_hash
  -65541 => sha256-hash,        ; response_hash
  -65542 => sha256-hash,        ; attestation_doc_hash
  -65543 => enclave-measurements, ; enclave_measurements
  -65544 => tstr,               ; policy_version
  -65545 => uint,               ; sequence_number
  -65546 => uint,               ; execution_time_ms
  -65547 => uint,               ; memory_peak_mb
  -65548 => tstr,               ; security_mode
  ? -65549 => tstr,             ; model_hash_scheme (optional)
}

sha256-hash = bstr .size 32
sha384-hash = bstr .size 48

enclave-measurements = nitro-measurements / tdx-measurements

nitro-measurements = {
  "pcr0"             => sha384-hash,   ; image
  "pcr1"             => sha384-hash,   ; kernel + ramdisk
  "pcr2"             => sha384-hash,   ; application
  ? "pcr3"           => sha384-hash,   ; IAM role (optional)
  ? "pcr4"           => sha384-hash,   ; instance identity (optional)
  ? "pcr8"           => sha384-hash,   ; signing cert (optional)
  "measurement_type" => "nitro-pcr",
}

tdx-measurements = {
  "pcr0"             => sha384-hash,   ; MRTD
  "pcr1"             => sha384-hash,   ; RTMR0
  "pcr2"             => sha384-hash,   ; RTMR1
  ? "pcr3"           => sha384-hash,   ; RTMR2 (optional)
  ? "pcr4"           => sha384-hash,   ; RTMR3 (optional)
  "measurement_type" => "tdx-mrtd-rtmr",
}

The full CDDL is also provided in Appendix A.¶

5.1. Standard CWT/EAT Claims

5.2. AIR Private Claims

AIR uses negative integer keys in the CWT private-use range to avoid collision with IANA-registered claims. Keys -65537 through -65548 are assigned and required. Key -65549 is assigned and optional. No other AIR private claim keys are defined in v1.¶

7.1. Single-Purpose Signing Key

The Ed25519 key bound to the platform attestation is a single-purpose AIR receipt signing key.¶

• The key MUST be used only to produce the signature of an AIR COSE_Sign1 receipt: the Ed25519 signature over the receipt's COSE Sig_structure ([RFC9052] Section 4.4) for the AIR profile named in the receipt's eat_profile claim.¶

• The key MUST NOT be reused for any other purpose. In particular it MUST NOT be used for transport-layer handshakes, attestation or key-exchange protocols, JWT or other token signing, transparency-log or audit-log signing, general-purpose Ed25519 signatures, or any other application protocol.¶

• An implementation that needs a signing key for any additional role MUST generate and separately attest a distinct key, or derive a distinct key under a separate, domain-separated key schedule. It MUST NOT repurpose the attested AIR signing key.¶

With this restriction, every signature the attested key can produce is an AIR receipt for the advertised profile, so an attested AIR signature is unambiguous.¶

7.2. Conformant Constructions

The following constructions satisfy the key binding requirement above when the associated attestation is verified by a RATS Verifier against the platform's trust chain:¶

1. AWS Nitro Enclaves: generate the Ed25519 receipt signing key inside the enclave and carry either its 32-byte public key, or an unambiguous encoded structure containing it, in the user_data field of the NSM attestation document. The Nitro Security Module signs the document, including user_data, so the receipt signing key is covered by the hardware-rooted signature. A verifier validates the document against the AWS Nitro root and checks that the receipt signing key carried in user_data matches the public key used to verify the AIR signature.¶

2. Intel TDX: generate the Ed25519 receipt signing key inside the Trusted Domain and bind it into the TDX quote's 64-byte REPORTDATA. Because REPORTDATA is fixed at 64 bytes, the binding is a SHA-512 digest -- placed as the full REPORTDATA -- over a domain-separated, length-prefixed encoding of: a domain label, the platform identifier, the protocol version, the transport handshake public key, the Ed25519 receipt signing key, the session nonce, and an optional platform-evidence hash.¶

   To make the binding independently reproducible, one interoperable construction pins the SHA-512 preimage exactly as the concatenation, in order, of: (1) the domain label, length-prefixed; (2) the platform identifier (a UTF-8 string, for example "gcp-cs-tdx"), length-prefixed; (3) the protocol version as a 4-octet unsigned big-endian integer (fixed width, not length-prefixed); (4) the 32-octet transport handshake public key, length-prefixed; (5) the 32-octet Ed25519 receipt signing key, length-prefixed; (6) the 32-octet session nonce, length-prefixed; and (7) a 1-octet platform-evidence flag -- 0x01 followed by the 32-octet platform-evidence hash when present, or 0x00 alone when absent. "Length-prefixed" means a 4-octet unsigned big-endian octet count immediately preceding the field it describes; the handshake key, receipt signing key, and nonce MUST each be exactly 32 octets. The REPORTDATA is the 64-octet SHA-512 digest of this preimage, and the domain label (for this construction, the ASCII string "cyntrisec-tdx-envelope-v2") distinguishes it from any other use of the same input shape. A verifier validates the quote via DCAP against the Intel SGX and TDX trust chains, recomputes the SHA-512 binding from the attestation envelope's stated inputs, and rejects the quote unless the result equals the quote's REPORTDATA.¶

These constructions describe the key-binding attestation itself. In AIR v1, whether a receipt's attestation_doc_hash references that same per-session attestation -- rather than a separate boot-time attestation -- is a profile-versioning question. For a receipt asserting end-to-end TEE provenance, Section 7.3 requires attestation_doc_hash to reference the same document that carries this key binding; a profile that separates the two (a boot-time attestation_doc_hash plus a per-session key-binding quote) is out of scope for AIR v1 and may be addressed by a future profile.¶

Other constructions MAY be used where the target attestation platform supports them. Implementers SHOULD consult [I-D.reddy-rats-key-binding] for a general treatment of key binding in RATS as that work matures. The Nitro and TDX constructions above instantiate the "combined" key-binding model of [I-D.reddy-rats-key-binding] -- the attestation Evidence and the key binding are produced together by the Attester -- and a future AIR profile could align this binding with that draft's confirmation (cnf) claim encoding once it stabilizes. AIR v1 binds the key through the platform quote (REPORTDATA / user_data) rather than a receipt-level cnf claim because the binding must be rooted in the hardware-signed attestation itself: the Attester generates the ephemeral signing key inside the TEE and commits it into the quote the vendor signs, which a cnf claim signed only by the workload cannot by itself provide.¶

7.3. Validator Behavior

For the end-to-end TEE assurance procedure below, the attestation document referenced by attestation_doc_hash MUST be the same document that carries the key binding (Section 7) and the measurement registers reconciled below. AIR v1 does not define a provenance procedure for a deployment whose key-binding attestation and attestation_doc_hash are different documents (for example, a per-session key-binding quote plus a separate boot-time attestation); such a split is left to a future profile.¶

An AIR Receipt Validator configured for end-to-end TEE assurance:¶

• MUST obtain the platform attestation document referenced by attestation_doc_hash and validate it via platform-specific procedures before accepting the receipt.¶

• MUST check the binding described in the construction above: the public key used to verify the AIR signature matches the public-key value embedded in the attestation document (or its hash, depending on the construction).¶

• MUST reject the receipt if the binding check fails.¶

• MUST reconcile the receipt's enclave_measurements claim against the measurement registers carried in the validated attestation document. Every measurement register present in enclave_measurements MUST equal, byte for byte, the corresponding register in the validated attestation document; a register that the attestation document does not expose cannot be reconciled. The validator MUST reject the receipt if any register in enclave_measurements is unequal to, or cannot be reconciled against, the validated attestation document (fail-closed). The enclave_measurements claim is signed only by the workload's own key; it is corroborated platform evidence only after this reconciliation succeeds (see Section 11.9).¶

• MUST require the presence of every measurement register its policy deems security-critical, and MUST reject a receipt that omits such a register (fail-closed). Byte-for-byte reconciliation quantifies only over the registers present in enclave_measurements, and the emitting workload chooses that set; a validator that does not enforce required-register presence can be handed a receipt that omits a workload- or runtime-identifying register. On Intel TDX in particular, the application and guest-runtime measurements are carried in the OPTIONAL RTMR2/RTMR3 slots, so a validator asserting that a specific workload executed MUST require the register(s) that identify that workload rather than only the mandatory MRTD/RTMR0/ RTMR1 platform registers.¶

• MUST NOT treat successful reconciliation as workload acceptability. Reconciliation establishes only that the receipt's measurement values match the validated attestation document (hardware-rootedness), not that those values, the platform TCB, or the debug state are acceptable. A validator asserting end-to-end TEE assurance MUST additionally appraise the reconciled measurements and the platform TCB/debug state against its reference-value policy -- or defer that appraisal to a RATS Verifier that performs it -- and MUST reject unacceptable values. In particular, a validator asserting a production security posture MUST reject a TEE that reports a debug or development mode (for example, Intel TDX TD_ATTRIBUTES.DEBUG set, or an SGX enclave in DEBUG mode), and MUST reject a platform whose TCB is out of date or revoked, unless the deployment explicitly accepts such a platform for a non-production purpose.¶

• MUST require the receipt to bind at least one freshness mechanism -- a verifier-supplied eat_nonce or cti deduplication -- before asserting end-to-end TEE provenance. [RFC9711] Section 9.3 requires an EAT to have a freshness mechanism to prevent replay and reuse; a provenance claim over a receipt carrying no freshness binding is vulnerable to replay of a pre-signed receipt (see Section 11.4).¶

• MUST, when the key-binding construction commits a session nonce into the platform quote (for example, TDX REPORTDATA) and the receipt also carries eat_nonce, check that the quote-bound nonce and eat_nonce are equal, so that the receipt and the underlying platform attestation share one freshness challenge.¶

An AIR Receipt Validator that does not require end-to-end TEE assurance (for example, in a deployment that uses AIR only as a signed log bound by application-layer trust decisions) MAY skip the checks in this section (key binding, measurement reconciliation, appraisal, and required-register presence). Such a validator MUST NOT claim TEE provenance from the receipt alone.¶

8.1. Layer 1: COSE Structure and Header Validation

1. Decode the input as CBOR. Confirm the outer structure is tagged with CBOR tag 18.¶

2. Decode the COSE_Sign1 array (4 elements).¶

3. Confirm the receipt size does not exceed 65,536 bytes. This bound is a verifier-side denial-of-service guard; typical AIR v1 receipts are under 1 KB. The bound applies to the serialized tagged COSE_Sign1 structure. Deployments requiring larger receipts (for example, with embedded certificate chains not defined in this version) MUST use a future AIR revision that specifies the additional payload.¶

4. Decode the protected header. Confirm it is a well-formed CBOR map.¶

5. Confirm alg (label 1) in the protected header is -8 (EdDSA). Reject receipts with any other algorithm.¶

6. Confirm content type (label 3) in the protected header is 61 (application/cwt).¶

7. Confirm the unprotected header is empty.¶

The payload is carried through this layer as an opaque byte string; it is not decoded until Layer 3, after signature verification.¶

8.2. Layer 2: Signature Verification

1. Construct Sig_structure = ["Signature1", protected, h'', payload] per [RFC9052] Section 4.4. The result is the message M over which the signature is verified.¶

2. Verify the Ed25519 signature -- the point R (first 32 octets) and the scalar S (last 32 octets) -- over M with the Ed25519 public key A. A conformant verifier MUST perform all of the following checks and MUST reject the receipt if any of them fails:¶

   a. Decode S as a 32-octet little-endian integer. Reject unless 0 <= S < L, where L is the order of the Ed25519 prime-order subgroup. A verifier MUST NOT reduce S modulo L; an S value outside [0, L) is a verification failure.¶

   b. Recover R and A as Edwards curve points from their 32-octet encodings. Reject the signature if either encoding does not decode to a point on the curve.¶

   c. Reject if A is a small-order point, or if R is a small-order point (a point of order 1, 2, 4, or 8).¶

   d. Compute k = SHA-512(R || A || M), interpreted as a little-endian integer (its reduction modulo L is implicit in the scalar multiplication [k]A). Verify the cofactorless group equation [S]B = R + [k]A, where B is the Ed25519 base point. Reject if it does not hold. The cofactored equation MUST NOT be used in place of the cofactorless equation.¶

Checks (c) and (d) make AIR signature verification stricter than the baseline of [RFC8032] Section 5.1.7, which permits the cofactored equation and does not require small-order rejection. The stricter procedure removes signature malleability the baseline would otherwise permit.¶

Step (b) requires only that R and A decode to points on the curve. AIR v1 does NOT require rejecting a non-canonical point encoding (an encoded y-coordinate not reduced modulo the field prime); the mandatory-to-implement Ed25519 verification routines accept such encodings. Rejecting them is not necessary for AIR security: a non-canonical re-encoding leaves the receipt's cti and claims unchanged, so it yields no new receipt identity, and the public key A is obtained out of band from the attestation in canonical form. The canonical-scalar check in step (a) is required and is distinct from point-encoding canonicalization.¶

8.3. Layer 3: Payload Decode and Claim Validation

Layer 3 is the first layer that decodes the payload CBOR, and it is entered only after the Layer 2 signature check has succeeded.¶

1. Decode the payload. Confirm it is a well-formed CBOR map. Confirm that every mandatory claim enumerated in the CDDL (Section 4.5) and the EAT Profile Declaration is present; reject the receipt if any mandatory claim is absent. The closed-claims-map check below rejects unknown keys but does not by itself guarantee that the mandatory claims are present.¶

2. Confirm eat_profile (key 265) equals "https://spec.cyntrisec.com/air/v1". Reject receipts with unknown profile values.¶

3. Confirm cti (key 7) is exactly 16 bytes.¶

4. Confirm iat (key 6) is a non-zero unsigned integer.¶

5. Confirm model_hash (key -65539) is exactly 32 bytes and not all zeros.¶

6. Confirm all required text string claims (iss, model_id, model_version, policy_version, security_mode) are non-empty and within reasonable bounds (implementation-defined, RECOMMENDED maximum 1024 bytes each).¶

7. Confirm enclave_measurements (key -65543) is a map.¶

8. Confirm measurement_type within enclave_measurements is one of the defined values ("nitro-pcr" or "tdx-mrtd-rtmr").¶

9. Confirm that every measurement value present in the map (whether required or optional) is exactly 48 bytes.¶

10. If measurement_type is "tdx-mrtd-rtmr", confirm pcr8 is absent. TDX measurement maps MUST NOT contain pcr8 (pcr8 is a Nitro-only field).¶

11. If model_hash_scheme (key -65549) is present, confirm it is one of the defined values ("sha256-single", "sha256-concat", "sha256-manifest"). Unknown values MUST be rejected.¶

12. Confirm security_mode (key -65548) is one of the defined values ("production", "evaluation"). Unknown values MUST be rejected (fail-closed).¶

13. Confirm request_hash (key -65540), response_hash (key -65541), and attestation_doc_hash (key -65542) are each exactly 32 bytes, and that sequence_number (key -65545), execution_time_ms (key -65546), and memory_peak_mb (key -65547) are each unsigned integers.¶

14. Confirm the claims map contains no unknown integer keys and no duplicate keys.¶

15. If eat_nonce (key 10) is present, confirm it is between 8 and 64 bytes inclusive; reject otherwise ([RFC9711] Section 4.1).¶

8.4. Layer 4: Policy Evaluation

Policy checks are configurable per verifier deployment. The following checks are defined:¶

FRESH (timestamp bounds):

If configured, verify now - max_age <= iat <= now + clock_skew.¶

NONCE (challenge binding):

If the verifier supplied a nonce, verify eat_nonce matches.¶

MODEL (expected model):

If configured, verify model_hash and/or model_id match expected values.¶

PLATFORM (expected platform):

If configured, verify measurement_type matches expected value.¶

REPLAY (deduplication):

If the verifier maintains a seen-cti store, reject duplicate cti values.¶

Verifiers SHOULD document which Layer 4 policies they enforce.¶

8.5. Interaction Model Compatibility

AIR is a receipt format; transport and session management are out of scope (see Section 1.2). AIR receipts are compatible with both the Challenge/Response and Uni-Directional interaction models of [I-D.ietf-rats-reference-interaction-models]:¶

• Challenge/Response: when the eat_nonce claim is present and was supplied by the verifier to the workload out of band (for example, as an inference-API parameter), the receipt provides challenge-response freshness per [RFC9711] Section 4.1.¶

• Uni-Directional: when eat_nonce is absent, freshness reduces to the iat timestamp plus verifier-side cti deduplication. This is acceptable for deployments that do not require challenge-binding, but MUST be understood as weaker than challenge-bound freshness: a compromised workload can pre-sign receipts, and verifiers relying only on iat gain no defense beyond clock skew. A validator operating in this mode MUST apply a bounded acceptance window (a max_age policy) and treat the result as recentness, not freshness: it conveys that a receipt is no older than the window, not that it was produced in response to a live challenge.¶

Attester-generated nonce values (nonce values not supplied by a verifier) provide no replay protection and SHOULD NOT be placed in eat_nonce. An implementation that needs a unique per-receipt identifier for internal purposes should use cti or an application-layer field, not eat_nonce.¶

Deployments that require platform-clock-independent freshness (for example, where the workload clock is not trusted by the verifier) may combine AIR with epoch-markers per [I-D.ietf-rats-epoch-markers]. AIR v1 does not itself define an epoch-marker claim; this integration is out of scope for v1 and may be considered in a future revision.¶

9.1. draft-messous-eat-ai

[I-D.messous-eat-ai] defines AI-related claims for EAT, including model identification, training metadata, and data-handling policy and SBOM references. AIR v1 is complementary: where draft-messous-eat-ai focuses on per-agent identity, provenance, and authorization metadata, AIR v1 focuses narrowly on per-inference execution evidence from a confidential workload. AIR intentionally binds a specific request/ response event to attestation-linked metadata; it is not a general AI agent identity profile. A future version of AIR could adopt registered claim keys from draft-messous-eat-ai once they stabilize, replacing the current private-use integer keys. The two drafts do not collide in the private-use key space -- draft-messous-eat-ai uses keys in the -75000 range while AIR uses -65537 through -65549 -- but a future coordinated registration SHOULD align them.¶

9.2. Concurrent AI-Attestation Work

Several concurrent efforts address adjacent parts of the AI-attestation problem. [I-D.sharif-ai-model-lifecycle-attestation] spans the whole model lifecycle -- from training-data attestation through per-inference output signing; AIR v1 is narrower, defining only the per-inference receipt wire format and its verification, and could serve as the receipt object such a lifecycle framework emits. In the research literature, AEX (arXiv:2603.14283) attests LLM API request/response provenance at the API boundary, and "Notarized Agents" (arXiv:2606.04193) defines receiver-attested receipts for AI agent actions. AIR's specific contribution is a closed, fail-closed COSE_Sign1 / CWT / EAT profile for a single confidential inference; it is not the only or first per-inference evidence scheme, and a future version could align its claim keys with these efforts.¶

9.3. SCITT

The Supply Chain Integrity, Transparency and Trust framework ([RFC9943]) uses "Receipt" to mean a Merkle-tree inclusion proof produced by a Transparency Service for a Signed Statement submitted to it. In AIR, "receipt" means a workload-signed per-inference evidence object. These are different artifacts despite the shared word; this document uses "AIR receipt" throughout to refer to the AIR v1 COSE_Sign1 artifact defined here, and "SCITT Receipt" when referring to a Transparency-Service inclusion proof.¶

AIR receipts are candidate payloads for SCITT Signed Statements, not Signed Statements themselves. A SCITT Signed Statement is a COSE_Sign1 structure carrying specific CWT claims (issuer, subject, etc.) that a Transparency Service uses for registration-policy evaluation. An AIR v1 COSE_Sign1 does not carry those outer registration-relevant claims. Deployments wishing to anchor AIR receipts in a SCITT Transparency Service should wrap an AIR COSE_Sign1 as the payload of an outer Signed Statement produced by the issuer, with the outer envelope supplying the claims required by the Transparency Service's registration policy.¶

TEE-backed Transparency Service profiles such as [I-D.ietf-scitt-receipts-ccf-profile] are natural complements to AIR's TEE-attested workload model. Complementary work by [I-D.kamimura-scitt-refusal-events] covers the refusal-event side of AI inference auditing, which pairs with AIR's successful-inference scope to give broader audit coverage.¶

A SCITT Transparency Service can provide an independent inclusion time and ordering record for AIR receipts that are submitted to it. It does not, by itself, prove when the underlying inference ran, and it does not detect a receipt that the issuer never submitted. Completeness requires a deployment policy on top of transparency logging, such as mandatory submission, monotonic counters, per-session manifests, or client-enforced inclusion proofs.¶

AIR v1 does not define the outer Signed Statement wrapping or a registration profile for a SCITT Transparency Service. Future revisions may define such a profile.¶

9.4. RATS Architecture

AIR receipts fit the RATS [RFC9334] architecture as follows:¶

• The confidential workload is the Attester. AIR receipts are Attester-generated claims; they are Evidence in the general sense of [RFC9334] Section 4.2, specialized to a per-inference application scope.¶

• The AIR Receipt Validator (see Section 3) performs AIR-local checks (signature, claim structure, local policy). The AIR Receipt Validator is not the RATS Verifier of [RFC9334] Section 4.1; it does not appraise platform Evidence against reference values or produce Attestation Results.¶

• A RATS Verifier appraises the platform attestation evidence referenced by attestation_doc_hash using platform-specific procedures and reference values. AIR v1 does not define those procedures.¶

• The end user, auditor, or compliance officer is the Relying Party. In a deployment that combines AIR with platform attestation, the Relying Party consumes both the AIR receipt and any platform Attestation Results.¶

• The TEE hardware vendor (AWS, Intel) is the Endorser; their attestation infrastructure anchors trust in the platform evidence.¶

AIR v1 is a workload-emitted artifact, not a Verifier-emitted Attestation Result. It is therefore distinct from IETF EAR ([I-D.ietf-rats-ear], EAT Attestation Results), which is produced by a Verifier after evaluating platform Evidence. In a complete deployment, a Verifier may evaluate platform Evidence and an AIR receipt together, and an EAR may reference an AIR receipt as part of the evidence it considered.¶

This version of AIR assumes a single Attester producing one attestation document per receipt. Patterns for composite attesters (multiple sub-attesters in one environment, e.g., CPU TEE + GPU confidential compute) and multi-verifier orchestration are the subject of active RATS WG work; see [I-D.richardson-rats-composite-attesters] and [I-D.ietf-rats-multi-verifier]. AIR v1 does not support these patterns; future versions may define how AIR receipts compose across such environments.¶

10.1. Decoding and Sampling Parameters

A future profile could carry the decoding configuration of the inference -- for example temperature, top_p, top_k, a random seed, and the stop-sequence set. Under the AIR trust model these are workload-asserted values (Trust Assumption TA-2, Section 11.1): a verifier can policy-pin them -- reject a receipt whose asserted decoding configuration is not the expected one -- but generally cannot recompute the response to confirm the configuration was actually applied, because production inference on hardware accelerators is not bit-reproducible across runs. Such claims therefore add policy-pinning value, not independent verifiability, and a profile defining them SHOULD state this explicitly so that a Relying Party does not read a pinned decoding claim as proof of the decoding that occurred.¶

10.2. Structured Context Commitments

AIR v1's request_hash commits to the request payload as a single opaque byte string. A future profile could decompose the context into separately committed parts -- for example distinct hashes for the user input, the system prompt, retrieved context (as in retrieval-augmented generation), and a tool-call / tool-result log -- and could add a prior-receipt hash to chain multi-step or multi-turn interactions. These share the decoding parameters' trust class: they are workload-asserted and corroborable only against artifacts a Relying Party independently holds. This design space overlaps with the agent identity and provenance claims of [I-D.messous-eat-ai] and with recent work on attestation and provenance for LLM API request/response outputs (for example, AEX, arXiv:2603.14283); a future AIR profile SHOULD reuse registered claim keys from that work where they exist rather than minting private-use keys.¶

11.1. Trust Assumptions

The security properties of AIR verification depend on the following Trust Assumptions. If any of these assumptions is broken, the corresponding AIR guarantees are void.¶

• TA-1 (TEE hardware correctness): the TEE hardware computes measurements faithfully, isolates enclave memory from the host and hypervisor as specified, and protects the attestation signing key. A hardware vulnerability, firmware bug, or supply chain compromise affecting the TEE voids all AIR TEE-provenance guarantees. AIR v1 does not define revocation mechanisms for compromised platforms.¶

• TA-2 (Workload honesty and evidence scope): the signing workload computes the hashes it signs over the data it actually processed, and populates claims consistently with the inference it actually performed. An AIR receipt only speaks for what the signing workload observed and emitted. A malicious or misconfigured workload can produce syntactically valid receipts that do not correspond to a genuine inference; AIR does not protect against such a signer. This assumption is meaningful only when combined with TA-3. Moreover, because attestation_doc_hash MAY reference a reused boot-time attestation rather than a per-inference one (see the attestation_doc_hash claim definition), a valid receipt does not establish that a specific inference occurred at a specific time, even when TA-1 through TA-4 all hold.¶

• TA-3 (Key binding enforced out of band): for deployments asserting end-to-end TEE provenance, the Ed25519 signing key is cryptographically bound to the attested workload per Section 7. Without this binding, key substitution attacks (see Section 11.10) defeat the TEE-provenance claim regardless of TA-1 and TA-2.¶

• TA-4 (Platform attestation verifiable via Endorser trust chain): the attestation document referenced by attestation_doc_hash can be obtained and validated by a RATS Verifier against the platform vendor's trust chain (for example, the AWS Nitro root CA, or the Intel DCAP / Provisioning Certification Service). AIR v1 does not define these procedures and relies on platform-specific verifiers.¶

AIR-local verification (Layers 1-4 of Section 8) proves only TA-independent properties: receipt well-formedness, signature validity under a provided public key, claim structural correctness, and policy match. Claims of TEE provenance require TA-1 through TA-4 to hold, with TA-3 enforced by the Validator and TA-4 enforced by a RATS Verifier.¶

11.2. Receipt Integrity

The Ed25519 signature over the COSE Sig_structure protects the protected header and all claims against tampering. The unprotected header is not covered by the signature; AIR v1 requires it to be empty (Section 4.3).¶

11.3. Algorithm Pinning

AIR v1 pins the signing algorithm to Ed25519 (alg = -8). The algorithm identifier is carried in the protected header and is therefore signed. This prevents algorithm confusion attacks where an attacker substitutes a weaker algorithm.¶

As of [RFC9864], the generic EdDSA algorithm identifier -8 is no longer marked "Recommended" in the IANA COSE Algorithms registry (its Recommended status is "Deprecated") in favor of algorithm-specific identifiers. AIR v1 pins -8 for interoperability with currently deployed COSE tooling; a future AIR profile MAY adopt the Ed25519-specific algorithm identifier. Algorithm agility in AIR is handled by profile versioning, not in-band negotiation: a future revision needing a different or post-quantum signature scheme defines a new profile identifier (the eat_profile value), so a verifier never has to accept an algorithm the profile did not pin.¶

11.4. Replay Protection

Replay protection in AIR v1 is a shared responsibility:¶

• The cti claim provides a unique receipt identifier. Verifiers maintaining state SHOULD track observed cti values and reject duplicates.¶

• The eat_nonce claim (optional) provides challenge-response freshness. When present, it binds the receipt to a specific verifier-supplied challenge, preventing replay to other verifiers.¶

• The sequence_number claim provides monotonicity within an observed session. Gaps indicate missing sequence numbers within that observed stream; absence of a gap does not prove that every receipt was submitted.¶

Verifiers not maintaining state and not using eat_nonce have limited replay protection (only iat-based freshness). Deployments requiring strong replay resistance MUST use at least one of cti deduplication or eat_nonce. A verifier configured with neither cti deduplication nor eat_nonce checking SHOULD surface a warning that the receipt has no replay protection beyond iat-based freshness.¶

11.5. Model Hash Limitations

The model_hash claim proves byte-level identity for the model artifact set as defined by model_hash_scheme, not model correctness, bias, or safety. Two distinct artifact sets with identical hashes are computationally infeasible, but a model with a correct hash may still produce harmful or incorrect outputs.¶

model_hash identifies the serialized model artifact set, not the in-memory computational form actually executed. Quantization, kernel fusion, speculative decoding, and other runtime optimizations can make the executing model differ numerically from the hashed artifacts; model_hash binds which artifacts were referenced, not the exact computation performed.¶

The model_hash_scheme claim (Section 5.2.13) declares how the hash was computed. Unknown scheme values MUST be rejected. This prevents a verifier from accepting a hash computed with an unrecognized method that might weaken integrity guarantees.¶

The model_hash claim is application-layer evidence. By itself it does not prove that the corresponding artifacts were loaded or executed inside a hardware-attested environment; that requires verification of the attested workload and its model-loading path.¶

11.6. Attestation Document Not Verified by Receipt

The attestation_doc_hash claim is a SHA-256 hash of the platform attestation document. AIR v1 does not embed or verify the attestation document. AIR-local verification alone is therefore insufficient to establish TEE assurance. Verifiers requiring such assurance MUST independently obtain and verify the attestation document using platform-specific procedures (e.g., Nitro COSE verification against the AWS root CA, Intel TDX DCAP verification against Intel PCS).¶

11.7. Accelerator Attestation Scope

An AIR v1 receipt attests the CPU-side TEE only. On a platform that also provides accelerator (for example, GPU) confidential computing, the accelerator's confidential-computing mode, device identity, and memory-protection state are NOT covered by the receipt, and are not implied by a successful enclave_measurements reconciliation. A Relying Party MUST NOT infer accelerator confidentiality from an AIR v1 receipt, and a party presenting such a receipt MUST NOT represent it as covering accelerator confidentiality. Where accelerator confidentiality is part of the trust decision, it MUST be established out of band from device-side Evidence (see the composite-attester note in Section 1.2) and MUST NOT be assumed from the presence of an AIR receipt. A future composite-attester AIR profile may bind CPU-side and accelerator-side Evidence into a single verifiable object.¶

11.8. Workload Honesty and Evidence Scope

An AIR receipt only speaks for what the signing workload observed and emitted. If the workload is malicious, misconfigured, or signs hashes for data that did not come from the claimed inference path, AIR can still produce a syntactically valid receipt. AIR therefore does not protect against an untrusted signer or against semantics outside the measured workload boundary.¶

Deployments that rely on AIR for end-to-end assurance MUST treat the receipt as meaningful only when the signing key is bound to an attested workload whose measurement set and execution policy are acceptable to the verifier.¶

11.9. Claim Trust Classes

Every claim in an AIR receipt is covered by the receipt signature, but that signature proves only that the workload asserted the claim. It does not, on its own, make the claim true. Claims differ in whether, and how, a verifier or Relying Party can corroborate them against evidence outside the receipt. This section classifies every AIR v1 claim so that implementers and Relying Parties do not mistake a workload self-assertion for independently established fact.¶

In RATS terms ([RFC9334]), a claim is corroborated hardware Evidence only when an Attesting Environment measured it and a Verifier appraises it against reference values; the remaining claims are workload assertions that the receipt signature authenticates but does not make true. Three trust classes are used:¶

• Self-asserted: backed only by the workload's signature. A malicious or misconfigured workload can place any syntactically valid value in the claim; the receipt signature does not elevate such a claim beyond "the workload stated this."¶

• Externally corroborable: a Relying Party that independently holds the corresponding artifact (a known-good reference value, the request or response bytes, or a verifier-supplied nonce) can confirm the claim by recomputation or comparison.¶

• Attestation-corroborable: the claim is meaningful only after a verifier obtains and validates the platform attestation document and reconciles the claim against it per Section 7.3. Before that reconciliation the claim is self-asserted.¶

The enclave_measurements claim warrants specific attention. It carries platform measurement registers (PCR or MRTD/RTMR values) and therefore resembles hardware-rooted evidence, but within the receipt it is a Self-asserted claim: the values are written and signed by the workload, not by the platform attestation service. It becomes corroborated platform evidence only after the Section 7.3 reconciliation against the validated attestation document. A verifier that presents enclave_measurements to a Relying Party as a verified measurement, without performing that reconciliation, misrepresents a workload self-assertion as hardware evidence.¶

11.10. Key Substitution Attack

If an implementation does not enforce key binding as described in Section 7, a workload compromise enables a key-substitution attack. An attacker with code execution in the workload may:¶

1. Extract the Ed25519 signing private key.¶

2. Obtain or generate a fresh platform attestation document with a different REPORTDATA (or equivalent field), which may correspond to a different measurement or a different workload image.¶

3. Sign AIR receipts with the extracted key and populate attestation_doc_hash with the hash of the new attestation document.¶

A verifier that checks only the AIR signature and the attestation_doc_hash field cannot distinguish such receipts from receipts produced by the attested workload. AIR-local verification remains valid in the narrow sense that the signature and claim structure are well-formed, but end-to-end TEE provenance is broken.¶

Deployments that claim end-to-end TEE provenance from AIR receipts MUST therefore enforce key binding per Section 7, and verifiers enforcing such claims MUST check that binding using platform-specific procedures.¶

11.11. Signing Key Reuse

Section 7 requires the attested AIR signing key to be single-purpose. Ed25519 unforgeability is analyzed for a key used in a single signing role; reusing the attested key across protocols falls outside that model and can enable cross-protocol signature confusion, in which a signature produced for another protocol is presented as an AIR receipt, or an AIR receipt signature is replayed into another protocol.¶

11.12. TEE Compromise

See TA-1 in Section 11.1. Operators of verifiers SHOULD consult platform-vendor advisories and maintain an allowlist or denylist of accepted platform measurements and TCB versions to respond to disclosed hardware or firmware vulnerabilities. AIR v1 does not itself define revocation or TCB-rollback signaling; this is typically performed by the platform-specific RATS Verifier against its reference-value store.¶

11.13. Clock Integrity

The iat claim depends on the workload's system clock. On AWS Nitro, the enclave uses the host clock (no independent time source). On Intel TDX, the CVM has a TSC but it is subject to frequency scaling. AIR v1 freshness checks are only as accurate as the platform clock.¶

11.14. Deterministic Encoding

AIR v1 requires deterministic CBOR encoding ([RFC8949] Section 4.2.1). This ensures that the same claims always produce the same payload bytes, preventing signature-valid variants of the same receipt. Implementations MUST sort map keys per the CBOR deterministic encoding rules.¶

11.15. Closed Claims Map

The claims map is closed: unknown integer keys MUST be rejected. This prevents downgrade attacks where an attacker adds unrecognized claims that a naive verifier might silently accept as benign. This closed-scope behavior is intentional in AIR v1; future extensions require a revised profile.¶

12.1. Input/Output Hashes

The request_hash and response_hash claims contain SHA-256 hashes, not plaintext inputs or outputs. However, for low-entropy inputs (e.g., binary classification queries, yes/no questions), an adversary with knowledge of the input space could brute-force the hash to recover the original input. Deployments handling sensitive low-entropy data SHOULD consider whether receipt exposure risks input recovery.¶

A deployment MAY mitigate this by folding a per-receipt secret salt (for example, the eat_nonce, or a random value retained by the issuer) into the hashed preimage, so that request_hash and response_hash are not dictionary-confirmable by an observer who does not hold the salt. This is a deliberate trade-off: a salted hash is no longer independently recomputable by a Relying Party that holds only the request or response bytes, so the claim's trust class shifts from externally-corroborable to corroborable-only-with-the-salt (see Section 11.9). A profile that defines salting MUST specify how the salt is conveyed to authorized verifiers.¶

12.2. Correlation Metadata

AIR receipts contain timestamps (iat), sequence numbers, and identifiers (cti, iss) that could be used to correlate activity across receipts. In privacy-sensitive deployments, operators SHOULD consider whether the combination of receipt metadata enables unwanted profiling.¶

12.3. Nonce Privacy

The eat_nonce claim, when present, may leak correlation data if the same nonce is reused across sessions or if the nonce encodes client-identifying information. Verifiers SHOULD use random nonces and avoid embedding client identifiers in nonce values.¶

12.4. Issuer Identity

The iss claim identifies the emitting entity. If the deployment assigns iss a human-readable value such as an organization name, the resulting receipts disclose the issuer's identity to anyone who can read them. For receipts that flow to auditors or relying parties outside the trust boundary of the issuer, this is usually intended and acceptable. For receipts that may be shared further (for example, aggregated in a transparency log, forwarded to external regulators, or included in public audit artifacts), the human-readable issuer identity may exceed the intended disclosure scope.¶

Deployments requiring issuer pseudonymity SHOULD use opaque iss values (for example, UUIDs or randomly-generated identifiers) and distribute issuer mappings out of band to the parties that need them.¶

12.5. Signing Key and Identifier Linkability

The Ed25519 receipt signing key is, in effect, a persistent pseudonym: every receipt a given attested workload emits is signed by the same key, so an observer can link all of that workload's inferences to one another and, via the key binding, to one attested environment. The model_id and enclave_measurements claims are likewise stable cross-receipt correlators. Where unlinkability across receipts or across relying parties matters, a deployment SHOULD use per-relying-party or rotating signing keys, each separately attested, accepting the additional attestation cost. AIR v1 does not use the EAT ueid, sueids, oemid, hwmodel, or hwversion claims -- the closed claims map prohibits them -- which avoids the permanent- hardware-identifier linkability discussed in [RFC9711] Section 8. The cti claim SHOULD be a random 128-bit value rather than a counter (see its claim definition); sequence_number is a deliberately session-linkable field, and because it is informational only a deployment concerned with linkability MAY emit a constant value for it.¶

14.1. Reference Implementation (Rust)

Organization:

Cyntrisec¶

Implementation:

EphemeralML (common/src/air_receipt.rs, common/src/air_verify.rs)¶

Description:

Full AIR v1 emitter and 4-layer verifier. Generates COSE_Sign1 receipts with deterministic CBOR encoding and Ed25519 signing. Verifier implements all four layers (parse, crypto, claims, policy) with structured error codes.¶

Maturity:

Demonstration. The implementation emits AIR v1 receipts and performs AIR-local verification on the Nitro, TDX, and GCP Confidential Space paths. Enforced single-document AIR TEE provenance per Section 7.3 is implemented for Nitro: the AIR signing key is extracted from the AWS-signed NSM attestation document referenced by attestation_doc_hash, and the client reconciles and appraises that document's measurement registers against caller-supplied reference values before asserting provenance. On TDX and GCP Confidential Space today, the receipt's attestation_doc_hash references a boot-time quote, while the receipt-signing-key binding and DCAP/platform verification are carried through a separate transport attestation and platform-evidence bundle. That is exactly the split model Section 7.3 places out of scope for AIR v1 TEE provenance, so those receipts are treated as AIR-local. Binding the receipt-signing key into the attestation_doc_hash quote and a TDX/GCP AIR chained verifier that validates that quote and appraises its MRTD/RTMR registers against reference values are future work.¶

Coverage:

The reference implementation passes its test suite, including the AIR v1 golden conformance vectors (Appendix B).¶

Contact:

borys@cyntrisec.com¶

14.2. Python Interop Verifier

Organization:

Cyntrisec (same team, independent implementation)¶

Implementation:

spec/v1/scripts/interop_test.py¶

Description:

Minimal Python verifier using pycose and cbor2 libraries. Validates COSE_Sign1 structure, Ed25519 signature, and claim presence.¶

Maturity:

Test/interop.¶

14.3. Client Nonce Conveyance

The reference gateway accepts an optional client-supplied challenge nonce on its OpenAI-compatible HTTP endpoints via a request header, X-Cyntrisec-Air-Nonce (a hex string). When the header is present and within the RFC 9711 length bounds, the gateway conveys the nonce to the workload, which binds it into the receipt's eat_nonce claim.¶

This header is an implementation convention of the reference gateway only. It is not part of the AIR receipt format, is not required for conformance, and a different deployment may convey the nonce by any means. AIR v1 defines the eat_nonce claim; it does not define how a nonce reaches the workload.¶

14.4. E2E Validation

The reference implementation has been exercised on three confidential computing platforms. "PASS" below means AIR receipt emission plus AIR-local verification plus measurement hardware-rootedness. Nitro additionally exercises the enforced single-document AIR TEE-provenance path of Section 7.3. On TDX and GCP Confidential Space the evidence is currently split between the boot-time attestation_doc_hash quote and the separate transport / platform-evidence verifier; full single-document Validator Behavior on those platforms is future work (see Maturity above):¶

15.1. Valid Receipt Walkthrough

The following describes a valid AIR v1 receipt in diagnostic notation. This corresponds to the v1-nitro-no-nonce golden vector.¶

The COSE_Sign1 envelope (tagged with CBOR tag 18):¶

18([
  h'A2012703183D',           / protected: {1: -8, 3: 61} /
  {},                         / unprotected: empty /
  h'B0...',                   / payload: CWT claims map /
  h'<64 bytes>'               / signature: Ed25519 /
])

The protected header decodes to:¶

{
  1: -8,    / alg: EdDSA /
  3: 61     / content type: application/cwt /
}

The payload (CWT claims map) includes 16 required claims, including the EAT profile:¶

{
  1: "cyntrisec.com",                          / iss /
  6: 1740000000,                               / iat /
  7: h'<16 bytes UUID v4>',                    / cti /
  265: "https://spec.cyntrisec.com/air/v1",    / eat_profile /
  -65537: "minilm-l6-v2",                      / model_id /
  -65538: "1.0.0",                             / model_version /
  -65539: h'<32 bytes SHA-256>',               / model_hash /
  -65540: h'<32 bytes SHA-256>',               / request_hash /
  -65541: h'<32 bytes SHA-256>',               / response_hash /
  -65542: h'<32 bytes SHA-256>',               / attestation_doc_hash /
  -65543: {                                    / enclave_measurements /
    "pcr0": h'<48 bytes SHA-384>',
    "pcr1": h'<48 bytes SHA-384>',
    "pcr2": h'<48 bytes SHA-384>',
    "measurement_type": "nitro-pcr"
  },
  -65544: "policy-2026.02",                    / policy_version /
  -65545: 1,                                   / sequence_number /
  -65546: 77,                                  / execution_time_ms /
  -65547: 0,                                   / memory_peak_mb /
  -65548: "production"                         / security_mode /
}

Verification with the corresponding Ed25519 public key succeeds through all four layers.¶

15.2. Invalid Receipt Categories

The specification includes invalid golden vectors covering failure modes across all verification layers. The structural and policy vectors are:¶

The signature-strictness vectors exercise the strict Ed25519 verification algorithm of Section 8 Layer 2. Each is a valid receipt body whose 64-octet signature violates one Layer 2 check (the letters reference the checks enumerated in that section):¶

Complete vector files (JSON with hex-encoded COSE bytes, expected failure codes, and policy overrides) are available in the reference implementation repository.¶

16.1. Normative References

[FIPS180-4]

National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8392]

Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

[RFC8610]

Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

16.2. Informative References

[I-D.ietf-rats-ear]

Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT Attestation Results", 2026.

[I-D.ietf-rats-eat-measured-component]

Frost, S., Fossati, T., Tschofenig, H., and H. Birkholz, "Entity Attestation Token (EAT) Measured Component", 2026.

[I-D.ietf-rats-epoch-markers]

Birkholz, H., Fossati, T., Pan, W., Mihalcea, I., and C. Bormann, "Epoch Markers", 2026.

[I-D.ietf-rats-msg-wrap]

Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", 2026.

[I-D.ietf-rats-multi-verifier]

Deshpande, Y., Zhang, J., Labiod, H., and H. Birkholz, "Remote Attestation with Multiple Verifiers", 2026.

[I-D.ietf-rats-reference-interaction-models]

Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference Interaction Models for Remote Attestation Procedures", 2026.

[I-D.ietf-scitt-receipts-ccf-profile]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., and A. Chamayou, "CCF Profile for COSE Receipts", 2026.

[I-D.kamimura-scitt-refusal-events]

Kamimura, T., "Verifiable AI Refusal Events using SCITT", 2026.

[I-D.messous-eat-ai]

Messous, A., Morand, L., and P. C. Liu, "Entity Attestation Token (EAT) Profile for Autonomous AI Agents", 2026.

[I-D.poirier-rats-eat-da]

Poirier, M., Birkholz, H., and T. Fossati, "An EAT Profile for Trustworthy Device Assignment", 2026.

[I-D.reddy-rats-key-binding]

Reddy, T., Tschofenig, H., Fossati, T., and I. Mihalcea, "Key Attestation for Entity Attestation Tokens (EAT)", 2026.

[I-D.richardson-rats-composite-attesters]

Richardson, M., Birkholz, H., Deshpande, Y., and T. Fossati, "Taxonomy of Composite Attesters", 2026.

[I-D.sharif-ai-model-lifecycle-attestation]

Sharif, R., "Cryptographic Attestation for AI Model Lifecycle: From Training Data to Inference Output", 2026.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9782]

Lundblade, L., Birkholz, H., and T. Fossati, "Entity Attestation Token (EAT) Media Types", RFC 9782, DOI 10.17487/RFC9782, May 2025, <https://www.rfc-editor.org/rfc/rfc9782>.

[RFC9864]

Jones, M.B. and O. Steele, "Fully-Specified Algorithms for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9864, DOI 10.17487/RFC9864, 2025, <https://www.rfc-editor.org/rfc/rfc9864>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

[SCITT]

"Supply Chain Integrity, Transparency and Trust (SCITT)", n.d., <https://datatracker.ietf.org/wg/scitt/about/>.