We published an IETF Internet-Draft, draft-marques-asqav-compliance-receipts-07, that profiles the upstream draft-farley-acta-signed-receipts envelope with regulatory bindings. This post explains what the profile does, why each piece is there, and how the authoritative attestation and verification protocol fits in.
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, andpolicy_digest. - It sets a retention floor tied to the underlying regulation: 184 days (six months) for high-risk AI Act receipts, five years for DORA receipts under the sectoral instruments (MiFID II Art 16(7), AMLD Art 40).
- It mandates an anchor on every receipt. Every receipt carries an OpenTimestamps witness on all plans. Enterprise receipts also carry an RFC 3161 timestamp.
- It adds two extension fields,
risk_classandincident_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, sourced from the sectoral instruments (MiFID II Art 16(7), AMLD Art 40), 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 draft now maps the receipt format onto nine regulatory regimes across the EU and US: EU AI Act, DORA, NYDFS Part 500, NIST AI RMF, Colorado AI Act, Texas TRAIGA, CIRCIA, the HIPAA Security Rule, and SEC 17a-4. 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.
Authoritative attestation and verification
The draft registers code-authorship extensions and a verifier-behaviour protocol, and Asqav ships both. The authoritative attestation path, POST /code-authorship, re-fetches a commit from GitHub, re-derives the changed-files diff server-side, and signs the digest it computed. The signed subject is the server value, never a client-supplied one, so the producer cannot forge or backdate the record. The receipt carries the receipt type authoritative and the server-derived capture layer github_sha_pull.
The verification protocol is issuer-free. A third party resolves the signing key at /.well-known/jwks.json, recomputes the DSSE Pre-Authentication Encoding over the in-toto statement, and checks the ML-DSA-65 signature with no callback to Asqav. The same verifier walks the per-agent hash chain and checks the anchor. Because the authoritative digest is re-derived from a public commit, any third party that re-fetches the commit_sha reproduces it and confirms the subject independently.
Read the draft on the IETF Datatracker.