The Compliance-Receipt HTTP Response Header Field

IntroductionClients that receive machine-generated responses may want a durable, independently checkable record that a given response was issued. The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Header Field DefinitionCompliance-Receipt is a Dictionary Structured Field . Members:

v: Integer, version; this document defines 1.
rid: String, receipt identifier.
h: Byte Sequence, SHA-256 of the response content.
st: Token, one of sealed or pending.
kid: String, signing key identifier.
sig: Byte Sequence, Ed25519 signature.

All members except sig are REQUIRED. Unknown members MUST be ignored. A field that fails to parse, repeats a member, or lacks a required member MUST be treated as absent.:, st=sealed, kid="apex-psi-2026", sig=:: ]]>

Signature InputThe signature input is the serialization, per , of the Dictionary containing all members other than sig, in the order v, rid, h, st, kid. Signing only rid would allow status or digest substitution and is not permitted. The signature is Ed25519 ; keys are discovered from /.well-known/compliance-receipt on the issuer origin.

VerificationA client recomputes SHA-256 of the received content, compares it with h, reconstructs the signature input, and verifies sig. It MAY then resolve rid to the full receipt. Status pending MUST NOT be presented as anchored.

Security ConsiderationsThe header is set by the server; an intermediary able to rewrite responses can strip it. It binds content, not the identity of the requester. Content encodings change bytes; h is over the content as received after removing transfer codings but before content decoding.

IANA ConsiderationsThis document has no IANA actions in this revision. Registration in the Hypertext Transfer Protocol Field Name Registry will be requested only if this document advances.