AI-Decision-Receipt: an HTTP response header for verifiable AI decisions
Version 1
Editor: Justin Dobson, sebbi.pro (Monop Content, United Kingdom)
Canonical: https://sebbi.pro/standard/ai-decision-receipt.txt
Internet-Draft: https://datatracker.ietf.org/doc/draft-dobson-ai-decision-receipt/
Licence: text CC BY 4.0; reference code Apache-2.0. Free to implement, no permission needed.

Abstract

   This document defines AI-Decision-Receipt, an HTTP response header that
   carries a checkable receipt for a decision made by, or about, an
   artificial intelligence system: what was decided, where the decision is
   sealed, a fingerprint of the exact request, and where anyone can verify
   it without trusting the issuer.

1. Conventions

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" are
   to be interpreted as described in BCP 14 (RFC 2119, RFC 8174).

2. The header

   AI-Decision-Receipt is a Dictionary Structured Field (RFC 8941).

   Example:
     AI-Decision-Receipt: v=1, issuer="sebbi.pro", decision=ALLOW,
       score=0.12, block=1042, seal="<64 hex>", req="<64 hex>",
       verify="https://sebbi.pro/forever?block=1042"

3. Members

   v         Integer. MUST be 1.
   issuer    String. MUST be the host name of the party that sealed the
             decision.
   decision  Token. MUST be upper case. ALLOW, CHALLENGE and BLOCK are
             defined; issuers MAY define others (e.g. HOLD_FOR_HUMAN).
   score     Decimal from 0 to 1. SHOULD be sent when the issuer scores risk.
   block     Integer >= 0. MUST give the decision's position in the issuer's
             append-only record.
   seal      String. MUST be the lower-case hex SHA-256 of that record entry.
   req       String. SHOULD be the lower-case hex SHA-256 of the exact
             request body the decision was made on. When present it MUST be
             64 lower-case hex characters.
   call      String. MAY identify the call within a gateway.
   verify    String. MUST be an https URL where the decision can be checked.

   Recipients MUST ignore members they do not understand. Keys MUST NOT
   repeat.

4. Verification

   A recipient verifies a receipt by:
   1. hashing the request body it sent and comparing the result with req;
   2. fetching verify and confirming that the record at block has seal;
   3. where the issuer anchors its record in a public timestamp (for
      example Bitcoin), checking that anchor, which proves the decision
      existed before the anchoring block.

5. Conformance levels

   L1 EMITS       every header sent passes the MUST rules of section 3.
   L2 VERIFIABLE  L1, and verify resolves on the issuer's own domain.
   L3 ANCHORED    L2, and the verify response proves the record against a
                  public timestamp that does not depend on the issuer.

   Implementations test themselves against the published test vectors at
   https://sebbi.pro/standard/ai-decision-receipt/test-vectors.json and with the free checker at
   https://sebbi.pro/standard/ai-decision-receipt/conformance.

6. Discovery

   An issuer SHOULD publish /.well-known/ai-decision-receipt.json describing
   where it emits the header, how to verify it and the level it claims.
   Issuers that do so may be listed in the public implementers register.

7. Browsers

   Issuers SHOULD send Access-Control-Expose-Headers: AI-Decision-Receipt.

8. Security considerations

   A receipt proves what the issuer recorded, and when; it does not by
   itself prove the decision was correct. The req fingerprint binds the
   receipt to one request; recipients SHOULD always compare it. Issuers
   MUST NOT place personal data in the header; only fingerprints travel.

9. Privacy considerations

   Only SHA-256 fingerprints of requests appear. Verification pages SHOULD
   NOT reveal request content.