An IETF profile for AI agent compliance receipts

We published an IETF Internet-Draft, draft-marques-asqav-compliance-receipts, that profiles the upstream draft-farley-acta-signed-receipts envelope for EU AI Act and DORA bindings. This post explains what the profile does and why each piece is there.

What the profile does

The upstream draft specifies a generic signed receipt envelope for AI agent actions: a wire format, a canonicalization rule, a signature suite, and an optional hash chain. It is intentionally regulation-agnostic. The Asqav profile takes that envelope as-is and adds four things on top of it.

• It tightens fields that the upstream draft marks OPTIONAL into REQUIRED for any receipt that claims the profile, including payload_digest, action_ref, and policy_digest.
• It sets a retention floor tied to the underlying regulation: six months for high-risk AI Act receipts, five years for DORA receipts.
• It mandates dual-anchoring. Every receipt carries an RFC 3161 timestamp and an OpenTimestamps witness.
• It adds two extension fields, risk_class and incident_class, drawn from controlled vocabularies that match the regulatory text.

A receipt that conforms to the Asqav profile is, by construction, a conformant upstream receipt. The signature validates with stock libraries. The chain validates with stock verifiers. A verifier that does not know about EU AI Act can still walk the receipt and confirm cryptographic facts; it just cannot attest the compliance bindings. Cryptographic validity and compliance attestation are different claims, and they fail independently.

A concrete binding

Article 12(2)(c) of the EU AI Act requires operators of high-risk systems to monitor the operation of the system and detect substantial modifications. The profile binds Article 12(2)(c) to the policy_digest field. A change in policy_digest between two otherwise-comparable Actions, same issuer_id, same action_ref family, same risk_class, is treated as a candidate substantial-modification event. The verifier surfaces those candidates. A human decides whether the change was substantial in the regulatory sense. The receipt log is the evidence trail. The binding lives in the field-level conformance rule, not in a separate PDF.

DORA Article 17 works the same way. The upstream draft says retention is out of scope. The profile sets a five-year floor for any receipt whose issuer_id is bound to a Financial Entity scope, and ties that floor to the OpenTimestamps anchor so deletion before the floor expires is detectable from the chain alone. If a receipt's anchor proves it existed five years ago and the producer cannot show it now, that is a finding. The supervisor does not have to take anyone's word for it.

The current draft has eleven such bindings, six against the AI Act and five against DORA. The pattern is the same in every case: pick the regulatory obligation, identify the receipt field that already carries the relevant fact, write a conformance rule that a verifier can mechanically check.

Read the draft on the IETF Datatracker.