IETF Internet-Draft for AI Compliance Receipts

Every receipt carries a top-level anchors[] array whose entries are {type, value} objects. The type field acts as the discriminator and selects the schema for value.

The type field MUST be either rfc3161 or opentimestamps. Any other value is a hard rejection at verification time.

Digest-covered fields MUST NOT contain IEEE-754 floats. Numeric values that need decimal precision are encoded as strings to keep the JCS canonicalisation byte-stable across language runtimes.

A receipt with decision = observation MUST NOT pair with type = protectmcp:decision. Observation is a non-enforcement vocabulary and pairing it with a decision-type receipt is a false-attestation hazard.

Receipts whose decision is deny or rate_limit MUST carry a reason string. A bare denial without a reason is rejected.

The issued_at timestamp MUST be within a 300-second forward-only window of the verifier's clock. Receipts dated in the future beyond that bound are rejected. Backward skew is tolerated to accommodate replay.

The issuer_id field on the receipt MUST be byte-equal to the kid field inside the signature envelope. A mismatch is a hard rejection.

The payload_digest field is an object with two members, algorithm and value. A bare digest string is not accepted on the wire.

The previousReceiptHash field commits to the JCS-canonical bytes of the prior receipt's signed payload, and only those bytes. Headers and the signature envelope are out of scope for the chain.

The first receipt emitted by an agent uses an all-zero 32-byte SHA-256 as its previousReceiptHash. Verifiers detect chain start by exact byte-match against the zero vector.

An anchor MUST be present on every signed receipt, with type set to either rfc3161 or opentimestamps. A receipt without an anchor is incomplete and is rejected.

When the chosen anchor is opentimestamps, the calendar-pending proof MUST be upgraded to a Bitcoin attestation within seven days. Beyond that window the proof is treated as incomplete.

The counterparty_binding object lands in the cloud signing relay, the Python SDK, the TypeScript SDK, and the conformance vectors as one atomic vocabulary. The same token shape applies on all four surfaces.

Legal Entity Identifiers carried on receipts are 20 characters and pass ISO 7064 mod 97-10 checksum validation. Malformed LEIs are rejected at envelope parse time.

Verifiers MUST accept both base64 and base64url encodings on the envelope_hash field. The signer is free to pick either. The verifier normalises before comparison.

When chain emission is intentionally suppressed (for example, during key rotation or maintenance windows), the receipt SHOULD carry the reason code chain_emission_blocked. This keeps the chain gap auditable.

The action_type string follows the namespace:verb shape, with no spaces. The advertised vocabulary lives at /.well-known/governance.json on the issuer.