Enforcement Attestation Receipts for AI Inference Decisions

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

AI systems that take or influence consequential actions are increasingly deployed in regulated settings. When such a decision is later questioned, the party being questioned is frequently also the party that produced the record of the decision. A log an operator controls does not, on its own, let an independent reviewer confirm what was asked and what was decided.¶

This document defines a compact receipt that an issuer signs for an LLM inference decision. The receipt is verifiable offline by any holder of the issuer's public key. The verifier need not contact the issuer at verification time.¶

2. Receipt Structure

A receipt is a single JSON object [RFC8259]. Version 1 defines the required fields in Section 2.1 and the optional fields in Section 2.2.¶

Unless a field is listed in this document for version 1, it MUST NOT appear at the top level. Verifiers MUST reject receipts that contain unknown top-level fields. This closed set keeps independent verifiers simple and prevents silent semantic drift.¶

3. Outcome Values

The outcome field MUST be one of:¶

ALLOWED:

The request was permitted to proceed to the model provider.¶

BLOCKED:

The request was not sent to the model provider.¶

SUPPRESSED:

The request was not sent because the issuer detected a runaway or loop condition.¶

PASSED:

A synonym of ALLOWED retained for backward compatibility. New issuers SHOULD emit ALLOWED.¶

4. What a Verified Receipt Proves

A receipt that verifies under a trusted public key proves that the holder of the corresponding private key attested the included fields, including outcome and request_hash, at the stated timestamp. It does not prove that the underlying model output was correct, that the policy identifiers were appropriate, or that the issuer's process was fair.¶

5. Canonical Payload and Signing

The canonical payload is produced by:¶

1. Removing the signature field, if present.¶

2. Serialising the remaining fields to JSON with all object keys sorted lexicographically and no whitespace between tokens.¶

3. Encoding the result as UTF-8, with non-ASCII characters emitted literally as UTF-8 and never as \uXXXX escapes (see Section 5.3).¶

4. Serialising every integer-valued number, including a float such as 1.0, as an integer with no decimal point or trailing zero, and every other number as the shortest decimal representation that round-trips to the same value.¶

A number whose shortest representation requires exponential notation, meaning a magnitude below 1e-4 or at or above 1e21, is outside the range that common implementations serialise identically. An issuer MUST NOT sign such a value directly; where one would arise it MUST first be rounded into the safe range (for cost_prevented_eur, to two decimal places). This canonicalisation aligns in intent with the JSON Canonicalization Scheme [RFC8785] but does not adopt its number serialisation. A later version of this format MAY adopt RFC 8785 fully; such a change requires a new v value.¶

6. Verification

A verifier that holds a trusted public key for the issuer:¶

1. Confirms all required fields are present and well-typed for Section 2.1, including: request_hash is 64 lowercase hex characters; public_key and signature decode as unpadded base64url to 32 and 64 bytes respectively; cost_prevented_eur is a non-negative number; timestamp is an RFC 3339 datetime with an explicit timezone offset; and policy_applied is an array of strings in lexicographic order.¶

2. Confirms no unknown top-level fields exist.¶

3. Confirms optional fields, if present, satisfy Section 2.2.¶

4. Confirms outcome is one of the values in Section 3.¶

5. Confirms the embedded public_key equals the trusted public key.¶

6. Reconstructs the canonical payload per Section 5.¶

7. Verifies the signature over the canonical bytes using the suite named by v and the trusted public key.¶

Verifying only against the embedded public_key, without an out-of-band trust decision, proves integrity of the object but not issuer identity.¶

7. Conformance

An implementation claiming conformance to this document MUST:¶

• Produce or accept receipts matching Section 2.¶

• Implement canonicalisation and verification as specified in Section 5 and Section 6.¶

• Reject the invalid cases described by the published conformance vectors referenced in Appendix B.¶

Informative interoperability artefacts, including valid and invalid receipts and a fixed test public key, are published with the ATTESTATION-v1 specification repository. Those vectors are not normative text of this document; if a vector and this document disagree, this document prevails, and the vector set SHOULD be corrected.¶

8. Security Considerations

9. IANA Considerations

This document has no IANA actions. A future revision may request registration of a media type for the receipt object.¶

10. References

Appendix A. Example Receipt

The following informative example is vector valid/001-allowed.json from the conformance set in Appendix B. A verifier that pins the test public key in Appendix B MUST accept it. The author regenerated and re-checked this object against that key before publishing this revision; if verification fails, the vector set or this figure is wrong and MUST be corrected before relying on either.¶

Field order in this figure is for readability; canonical signing order is defined in Section 5. The signature value is shown on two lines for document formatting only; in the vector file it is a single base64url string with no whitespace.¶

{
  "v": 1,
  "attestation_id": "00000000-0000-0000-0000-000000000001",
  "trace_id": "trace-tv-001",
  "org_id": "org-test-vectors",
  "request_hash":
    "8f3a7e2b9c4d5f6a1b0c9d8e7f6a5b4c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a",
  "model": "gpt-4o",
  "outcome": "ALLOWED",
  "policy_applied": ["budget_guard"],
  "cost_prevented_eur": 0,
  "timestamp": "2026-04-23T10:15:30.000000+00:00",
  "public_key": "alWzEnrA_z9McN9z_MFfQCnH9mVgOwRZ26wrI7oix4E",
  "signature":
    "gXA2GNEvACSGDtOk9KMEeHDUQMPUhHJHeLFMbbrwKlEI"
    "XY9UkvI5gWQ201Lm3Tkh7K3luXwQtqcua6vv4HmAAg"
}

Pinned test public key for this example and the vector set:¶

alWzEnrA_z9McN9z_MFfQCnH9mVgOwRZ26wrI7oix4E

Appendix B. Conformance Vectors

Informative conformance vectors (valid receipts, invalid receipts, and the fixed test public key) are published at:¶

https://github.com/Aqta-ai/attestation-spec/tree/main/test-vectors¶

A conformant verifier that pins that test public key MUST accept every receipt in the valid set and MUST reject every receipt in the invalid set. Those vectors are generated from a fixed seed documented in that repository so third parties can reproduce the signatures.¶

Appendix C. Reference Implementations

Open-source reference verifiers implementing this format are published as aqta-verify-receipt on the Python Package Index and on the npm package registry. Those packages are informative aids. Conformance is defined by this document and the vector set in Appendix B, not by any single implementation.¶

Appendix D. Changes From draft-chueayen-attestation-receipts-00

• Added explicit non-goals and a "what a verified receipt proves" section.¶

• Clarified relationship to related Internet-Drafts without requiring them.¶

• Documented optional chain fields and spec_version for wire clarity.¶

• Clarified that cost_prevented_eur is non-security and SHOULD be 0 for new issuers.¶

• Added conformance language, an example receipt, and a pointer to published test vectors.¶

• Normative reference to SHA-256 via RFC 6234.¶

• Tightened verification steps for issuer identity pinning.¶

• Softened attestation_id to UUID string with version-4 SHOULD, matching the published conformance vectors.¶

• Clarified policy_applied as UTF-8 strings (matches the non-ASCII valid vector) and tightened verification type checks.¶

Author's Address