The AI-Decision-Receipt HTTP Response Header Field

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 29 April 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

When an automated system decides something - to allow a payment, to refuse an application, to let an agent call a tool - the parties affected usually receive no durable evidence of that decision. Logs, where they exist, are held by the operator of the system and can be edited by that operator. A later dispute between a customer, a regulator, an insurer and the operator then depends on whose account is believed.¶

Several efforts address the identity of automated clients: HTTP Message Signatures [RFC9421] profiles that let a website verify which bot or agent sent a request, and OAuth-based delegation that records which person or organisation authorised an agent. Identity answers "who acted" and "were they allowed to". It does not answer "what exactly was decided, on exactly what input, and can that be shown later to someone who trusts none of the parties".¶

This document defines a small, transport-level receipt for that second question. A system that governs or records an automated decision (the issuer) returns the AI-Decision-Receipt header field with its HTTP response. The receipt binds:¶

• the decision outcome;¶
• a SHA-256 [FIPS180-4] fingerprint of the exact request body the decision was made on;¶
• the position and hash of the sealed record of that decision in the issuer's append-only, tamper-evident log; and¶
• a URI at which the record and its proofs can be checked without credentials.¶

The receipt is deliberately small and is not itself proof. It is a pointer that lets any party fetch the proof and check it with their own tools. The design follows the same principle as Certificate Transparency [RFC6962]: the issuer commits to a record in a log that anyone can audit, so a later change to that record cannot be hidden.¶

2. Terminology

Decision:

An outcome produced by an automated system about a request, for example to allow, hold for human review, or refuse an action.¶

Issuer:

The party that records the decision and emits the receipt. The issuer may be the system that made the decision, or a governance layer (for example a gateway) that sits in front of it.¶

Log:

The issuer's append-only sequence of sealed records, in which each record's hash commits to the hash of the record before it, so that altering, inserting or removing any record changes every later hash.¶

Seal:

The hash that identifies one record in the log.¶

Relying party:

Anyone who receives a receipt and wishes to check it: the client, the person affected by the decision, an auditor, a regulator, an insurer or a court.¶

3. The AI-Decision-Receipt Header Field

AI-Decision-Receipt is a Dictionary Structured Field (Section 3.2 of [RFC9651]). It is a response header field. It MUST NOT be sent as a trailer field, because a relying party needs it to be bound to the response it accompanies. Its members are defined below.¶

HTTP/1.1 200 OK
Content-Type: application/json
AI-Decision-Receipt: v=1, issuer="sebbi.pro", decision=ALLOW,
  score=0.12, block=1042,
  seal="9f2c4be0c6a1...f5a4b3c2d",
  req="5d41402abc4b...3c2b1a0f9e",
  call="GC-7Q2M9X4KDP",
  verify="https://sebbi.pro/forever?block=1042"
Access-Control-Expose-Headers: AI-Decision-Receipt

4. Issuer Requirements

An issuer that emits a receipt containing block, seal and verify:¶

1. MUST have appended the sealed record to its log before sending the response that carries the receipt.¶
2. MUST maintain the log so that each record's hash commits to the hash of the record before it, and MUST NOT alter or remove a record once sealed.¶
3. MUST make the record and its proofs available at the verify URI to any party, without authentication, for as long as it emits receipts that refer to it. Where the record contains personal or confidential data, the issuer MAY serve only the hashes needed for verification (see Section 9).¶
4. SHOULD regularly commit the latest hash of its log to at least one system it does not control, such that the commitment cannot later be changed by the issuer - for example a public timestamping service such as [OPENTIMESTAMPS], a public blockchain, or independent witnesses that countersign the log. This lets a relying party establish that a record existed no later than a given time.¶
5. SHOULD publish the method used to compute record hashes in enough detail that a relying party can recompute them independently.¶

5. Verifying a Receipt

A relying party verifies a receipt as follows:¶

1. Check that v is a version it understands and that the host of the verify URI matches issuer, or is otherwise recognised as acting for the issuer.¶
2. If req is present and the relying party holds the request body, compute its SHA-256 hash and check that it equals req.¶
3. Retrieve the record from the verify URI and check that the hash it carries for position block equals seal.¶
4. Recompute the record's hash from its published contents using the issuer's published method, and check that it equals seal; and check that the record commits to the hash of the record before it.¶
5. Where the issuer anchors its log externally, check that an anchor covers this record or a later one, using the anchoring system's own tools rather than the issuer's.¶

A receipt that passes these checks shows that the issuer recorded the stated decision about the stated request, at or before the anchored time, and has not since changed that record without detection. It does not show that the decision was correct, lawful or fair; it makes the decision available to be examined.¶

6. Relationship to Agent Identity

Agent identity mechanisms and this receipt are complementary. Identity establishes who sent a request and under whose authority; the receipt establishes what was decided about it and lets anyone check that record later. When an issuer has authenticated the client - for example by verifying an HTTP Message Signature [RFC9421] - it SHOULD place the verified key identifier in the agent member and include it in the sealed record, so that the identity of the agent and the decision about its request are bound in the same tamper-evident entry.¶

An issuer MUST NOT populate agent from unauthenticated information such as the User-Agent header field.¶

7. Implementation Status

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. It is to be removed before publication as an RFC.¶

sebbi.pro

Organisation: Monop Content, United Kingdom.¶

Description: emits AI-Decision-Receipt version 1 on every response from its AI gateway (which sits in front of OpenAI and Anthropic model APIs) and on every response from its decision API. Records are sealed in a SHA-256 hash chain that is anchored hourly in Bitcoin through OpenTimestamps and observed by independent witness chains. Records can be checked in a web browser or with a standalone script that makes no network calls to the issuer.¶

Specification and checker: https://sebbi.pro/standard/ai-decision-receipt¶

Level of maturity: in production.¶

Coverage: all members defined in this document except agent.¶

Contact: the author of this document.¶

8. Security Considerations

A receipt is an assertion by the issuer until it has been verified as described in Section 5. Relying parties MUST NOT treat the presence of the field as evidence that a decision was recorded.¶

The header field is not itself signed. An intermediary that can modify the response can alter or remove it. Integrity of the field in transit depends on the transport (for example TLS). Where a receipt must be attributable to the issuer independently of transport, the issuer MAY sign the response, including this field, with HTTP Message Signatures [RFC9421]. Regardless of signing, a forged receipt fails verification against the issuer's log.¶

An issuer controls its own log. Without external anchoring or witnessing, an issuer could rebuild its log from an earlier point. The anchoring requirement in Section 4 exists to make such rewriting detectable; relying parties that need strong assurance SHOULD check anchors themselves.¶

A receipt can be replayed alongside a different response. Relying parties SHOULD use req, and where present call and agent, to check that a receipt belongs to the exchange it accompanies.¶

Verify URIs are retrieved by relying parties. Relying parties SHOULD only follow verify URIs whose host matches the issuer or is otherwise trusted for that issuer, to avoid being directed to arbitrary hosts.¶

9. Privacy Considerations

The req member is a hash, not the request itself. A hash of a short or predictable request body can be reversed by guessing. Issuers SHOULD NOT publish request bodies at the verify URI, and SHOULD consider whether published hashes of low-entropy requests could reveal personal data; where they could, the issuer MAY include a secret random value, returned only to the client, in the hashed material.¶

The verify URI is public. Records published there MUST NOT contain personal data unless the issuer has a lawful basis to publish it; publishing only hashes is sufficient for verification.¶

The agent member can link requests made by the same agent. Issuers SHOULD include it only when the client has authenticated as that agent.¶

10. IANA Considerations

IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in Section 16.3.1 of [RFC9110]:¶

Field Name:

AI-Decision-Receipt¶

Status:

provisional¶

Structured Type:

Dictionary¶

Reference:

This document¶

Comments:

none¶

Acknowledgements

The design draws on the transparency-log approach of Certificate Transparency and on the Structured Field Values work of the HTTP Working Group.¶

Author's Address