\n
Network Working Group J. A. Gomes Marques\nInternet-Draft Asqav\nIntended status: Informational 20 July 2026\nExpires: 21 January 2027\n\n Compliance Profile of Signed Action Receipts for AI Agents\n draft-marques-asqav-compliance-receipts-07\n\nAbstract\n\n This document defines a multi-jurisdiction compliance profile of the\n signed action receipt format used by AI agents to record machine-\n readable evidence of access-control decisions. The profile binds\n receipt fields to two regulatory surfaces: on the European Union\n side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689)\n and Article 17 of DORA (Regulation (EU) 2022/2554); on the United\n States side, the NIST AI Risk Management Framework, the Colorado AI\n Act, the Texas Responsible AI Governance Act, the New York Department\n of Financial Services Cybersecurity Regulation (23 NYCRR Part 500),\n the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident\n Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working\n entirely within the existing wire format, canonicalization\n transformation, and signing algorithms of the underlying receipt\n format, the profile tightens a subset of the OPTIONAL fields to\n REQUIRED, imposes a retention floor, and requires at least one\n timestamping anchor (RFC 3161 or OpenTimestamps). It registers\n OPTIONAL extension fields for risk and incident classification,\n cross-agent envelope binding, per-action freshness and integrity,\n build provenance, threat-framework taxonomy, server-built enforcement\n attestation, producer-asserted risk acceptance, and producer-asserted\n code authorship, each subject to false-attestation guards where\n applicable, and registers receipt type namespaces for passive-\n telemetry, result-bound observation, risk-acceptance, and code-\n authorship receipts. The full field set and its normative\n requirements are defined in the body of this document.\n\nStatus of This Memo\n\n This Internet-Draft is submitted in full conformance with the\n provisions of BCP 78 and BCP 79.\n\n Internet-Drafts are working documents of the Internet Engineering\n Task Force (IETF). Note that other groups may also distribute\n working documents as Internet-Drafts. The list of current Internet-\n Drafts is at https://datatracker.ietf.org/drafts/current/.\n\nGomes Marques Expires 21 January 2027 [Page 1]\nInternet-Draft Compliance Receipts Profile July 2026\n\n Internet-Drafts are draft documents valid for a maximum of six months\n and may be updated, replaced, or obsoleted by other documents at any\n time. It is inappropriate to use Internet-Drafts as reference\n material or to cite them other than as "work in progress."\n\n This Internet-Draft will expire on 21 January 2027.\n\nCopyright Notice\n\n Copyright (c) 2026 IETF Trust and the persons identified as the\n document authors. All rights reserved.\n\n This document is subject to BCP 78 and the IETF Trust's Legal\n Provisions Relating to IETF Documents (https://trustee.ietf.org/\n license-info) in effect on the date of publication of this document.\n Please review these documents carefully, as they describe your rights\n and restrictions with respect to this document.\n\nTable of Contents\n\n 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5\n 1.1. Profile, Not Fork . . . . . . . . . . . . . . . . . . . . 5\n 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6\n 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6\n 3. Relationship to ACTA-RECEIPTS . . . . . . . . . . . . . . . . 7\n 4. Canonicalization Scope . . . . . . . . . . . . . . . . . . . 8\n 5. Receipt Field Profile . . . . . . . . . . . . . . . . . . . . 10\n 5.1. Common Payload Fields . . . . . . . . . . . . . . . . . . 10\n 5.1.1. type . . . . . . . . . . . . . . . . . . . . . . . . 10\n 5.1.2. issued_at . . . . . . . . . . . . . . . . . . . . . . 10\n 5.1.3. issuer_id . . . . . . . . . . . . . . . . . . . . . . 11\n 5.1.4. payload_digest (OPTIONAL upstream, REQUIRED in this\n profile) . . . . . . . . . . . . . . . . . . . . . . 12\n 5.1.5. action_ref (OPTIONAL upstream, REQUIRED in this\n profile) . . . . . . . . . . . . . . . . . . . . . . 12\n 5.1.6. sandbox_state (OPTIONAL upstream, REQUIRED for\n High-Risk in this profile) . . . . . . . . . . . . . 12\n 5.1.7. iteration_id (OPTIONAL upstream, REQUIRED for\n multi-step in this profile) . . . . . . . . . . . . . 12\n 5.2. Decision Receipt Fields (type protectmcp:decision) . . . 13\n 5.2.1. reason (OPTIONAL upstream, REQUIRED for deny/rate_limit\n in this profile) . . . . . . . . . . . . . . . . . . 13\n 5.2.2. policy_digest (OPTIONAL upstream, REQUIRED in this\n profile) . . . . . . . . . . . . . . . . . . . . . . 13\n 5.3. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this\n profile) . . . . . . . . . . . . . . . . . . . . . . . . 14\n 5.4. Anchoring (No Upstream Equivalent) . . . . . . . . . . . 15\n 5.5. Extension Fields . . . . . . . . . . . . . . . . . . . . 18\n\nGomes Marques Expires 21 January 2027 [Page 2]\nInternet-Draft Compliance Receipts Profile July 2026\n\n 5.6. Counterparty Binding . . . . . . . . . . . . . . . . . . 19\n 5.6.1. Wire Shape . . . . . . . . . . . . . . . . . . . . . 19\n 5.6.2. Emitter Behaviour . . . . . . . . . . . . . . . . . . 22\n 5.6.3. Verifier Behaviour . . . . . . . . . . . . . . . . . 22\n 5.7. Result-Bound and Freshness Extensions . . . . . . . . . . 23\n 5.8. Build-Provenance Extensions . . . . . . . . . . . . . . . 25\n 5.9. Enforcement-Attestation Extensions . . . . . . . . . . . 27\n 5.10. Risk-Acceptance Extensions . . . . . . . . . . . . . . . 28\n 5.11. Code-Authorship Extensions . . . . . . . . . . . . . . . 31\n 5.12. Threat-Framework Taxonomy Extensions . . . . . . . . . . 34\n 6. European Union Bindings . . . . . . . . . . . . . . . . . . . 35\n 6.1. EU AI Act Article 12 Binding . . . . . . . . . . . . . . 35\n 6.1.1. Article 12(1), automatic recording of events . . . . 35\n 6.1.2. Article 12(2)(a), identifying situations that may\n result in the high-risk AI system presenting a risk\n within the meaning of Article 79(1) or in a substantial\n modification . . . . . . . . . . . . . . . . . . . . 36\n 6.1.3. Article 12(2)(b), facilitating the post-market\n monitoring referred to in Article 72 . . . . . . . . 36\n 6.1.4. Article 12(2)(c), monitoring the operation of high-risk\n AI systems referred to in Article 26(5) . . . . . . . 36\n 6.1.5. Retention . . . . . . . . . . . . . . . . . . . . . . 36\n 6.2. EU AI Act Article 26 Binding . . . . . . . . . . . . . . 37\n 6.2.1. Article 26(1), in accordance with the instructions for\n use . . . . . . . . . . . . . . . . . . . . . . . . . 37\n 6.2.2. Article 26(2), assign human oversight . . . . . . . . 37\n 6.2.3. Article 26(5), monitor the operation . . . . . . . . 38\n 6.2.4. Article 26(6), keep the logs for at least six\n months . . . . . . . . . . . . . . . . . . . . . . . 38\n 6.3. DORA Article 17 Binding . . . . . . . . . . . . . . . . . 38\n 6.3.1. Article 17(1), ICT-related incident management\n process . . . . . . . . . . . . . . . . . . . . . . . 38\n 6.3.2. Article 17(2), record all ICT-related incidents and\n significant cyber threats . . . . . . . . . . . . . . 38\n 6.3.3. Article 17(3)(b), establish procedures to identify,\n track, log, categorise and classify ICT-related\n incidents . . . . . . . . . . . . . . . . . . . . . . 38\n 6.3.4. Retention . . . . . . . . . . . . . . . . . . . . . . 39\n 7. United States Bindings . . . . . . . . . . . . . . . . . . . 39\n 7.1. NIST AI RMF Binding . . . . . . . . . . . . . . . . . . . 39\n 7.1.1. GOVERN function . . . . . . . . . . . . . . . . . . . 40\n 7.1.2. MAP function . . . . . . . . . . . . . . . . . . . . 40\n 7.1.3. MEASURE function . . . . . . . . . . . . . . . . . . 40\n 7.1.4. MANAGE function . . . . . . . . . . . . . . . . . . . 40\n 7.2. Colorado AI Act (SB 24-205) Binding . . . . . . . . . . . 40\n 7.2.1. Section 6-1-1703(2), risk management policy and\n program . . . . . . . . . . . . . . . . . . . . . . . 41\n 7.2.2. Section 6-1-1703(3), impact assessment . . . . . . . 41\n\nGomes Marques Expires 21 January 2027 [Page 3]\nInternet-Draft Compliance Receipts Profile July 2026\n\n 7.2.3. Section 6-1-1703(7), notice of algorithmic\n discrimination . . . . . . . . . . . . . . . . . . . 41\n 7.3. Texas Responsible AI Governance Act (HB 149) Binding . . 41\n 7.3.1. Safe-harbor evidentiary support . . . . . . . . . . . 41\n 7.3.2. Prohibited-use detection . . . . . . . . . . . . . . 42\n 7.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart\n C) . . . . . . . . . . . . . . . . . . . . . . . . . . . 42\n 7.4.1. 45 CFR 164.312(b), audit controls . . . . . . . . . . 42\n 7.4.2. 45 CFR 164.316(b)(2), six-year retention . . . . . . 42\n 7.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part\n 500) . . . . . . . . . . . . . . . . . . . . . . . . . . 43\n 7.5.1. 23 NYCRR 500.6, audit trail . . . . . . . . . . . . . 43\n 7.5.2. 23 NYCRR 500.17, notices to superintendent . . . . . 43\n 7.5.3. 23 NYCRR 500.6 retention . . . . . . . . . . . . . . 44\n 7.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR\n 240.17a-4) . . . . . . . . . . . . . . . . . . . . . . . 44\n 7.6.1. 17 CFR 240.17a-4(f), electronic recordkeeping\n system . . . . . . . . . . . . . . . . . . . . . . . 44\n 7.6.2. 17 CFR 240.17a-4(a) and (b) retention . . . . . . . . 44\n 7.7. CIRCIA Binding (Cyber Incident Reporting for Critical\n Infrastructure Act of 2022) . . . . . . . . . . . . . . . 45\n 7.7.1. Covered Cyber Incident reporting support . . . . . . 45\n 7.7.2. Records related to a Covered Cyber Incident report . 45\n 8. Audit Pack Composition . . . . . . . . . . . . . . . . . . . 46\n 9. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . . 47\n 9.1. Mandatory Checks . . . . . . . . . . . . . . . . . . . . 47\n 9.2. Optional Checks . . . . . . . . . . . . . . . . . . . . . 48\n 9.3. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 48\n 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49\n 10.1. Tamper Resistance . . . . . . . . . . . . . . . . . . . 50\n 10.2. Chain Availability Under Single-Linear Per-Agent\n Serialization . . . . . . . . . . . . . . . . . . . . . 50\n 10.3. Key Compromise . . . . . . . . . . . . . . . . . . . . . 51\n 10.4. Retention and Long-Term Verifiability . . . . . . . . . 51\n 10.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 52\n 10.6. Anchor Trust . . . . . . . . . . . . . . . . . . . . . . 52\n 10.7. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 52\n 10.8. Cross-Regime Conflict . . . . . . . . . . . . . . . . . 53\n 10.9. Algorithm Agility . . . . . . . . . . . . . . . . . . . 53\n 10.10. Issuer-Misrepresentation Residual . . . . . . . . . . . 53\n 10.11. Cross-Agent Integrity Trust Boundary . . . . . . . . . . 54\n 10.12. Compromised Intermediary Between Two Honest Endpoints . 55\n 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58\n 11.1. Compliance Receipt Extension Fields Registry . . . . . . 58\n 11.2. Compliance Receipt Type Namespaces Registry . . . . . . 66\n 12. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 68\n 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 73\n 14. Normative References . . . . . . . . . . . . . . . . . . . . 73\n\nGomes Marques Expires 21 January 2027 [Page 4]\nInternet-Draft Compliance Receipts Profile July 2026\n\n 15. Informative References . . . . . . . . . . . . . . . . . . . 75\n Worked Example (Informative) . . . . . . . . . . . . . . . . . . 82\n Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 85\n Changes in draft -07 . . . . . . . . . . . . . . . . . . . . . 85\n Changes in draft -06 . . . . . . . . . . . . . . . . . . . . . 86\n Changes in draft -05 . . . . . . . . . . . . . . . . . . . . . 90\n Changes in draft -04 . . . . . . . . . . . . . . . . . . . . . 94\n Changes in draft -03 . . . . . . . . . . . . . . . . . . . . . 100\n Changes in draft -02 . . . . . . . . . . . . . . . . . . . . . 101\n Changes in draft -01 . . . . . . . . . . . . . . . . . . . . . 101\n Changes in draft -00 . . . . . . . . . . . . . . . . . . . . . 101\n Appendix - Capture Topologies for Compliance Receipt Emission . . 101\n In-Process SDK . . . . . . . . . . . . . . . . . . . . . . . . 102\n Network-Layer Egress Proxy . . . . . . . . . . . . . . . . . . 102\n Browser Extension . . . . . . . . . . . . . . . . . . . . . . . 103\n eBPF SNI Observer . . . . . . . . . . . . . . . . . . . . . . . 103\n MCP Transparent Proxy . . . . . . . . . . . . . . . . . . . . . 104\n Passive Telemetry Ingestion . . . . . . . . . . . . . . . . . . 104\n capture_topology Vocabulary and Considerations for a Future IANA\n Registry . . . . . . . . . . . . . . . . . . . . . . . 105\n Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 106\n\n1. Introduction\n\n1.1. Profile, Not Fork\n\n [ACTA-RECEIPTS] specifies a generic, signed receipt envelope for\n recording machine-to-machine access control decisions made by AI\n agents. Section 2.2 of [ACTA-RECEIPTS] defines a common payload\n field set in which all fields except type, issued_at, and issuer_id\n are OPTIONAL. Section 5.7 of [ACTA-RECEIPTS] introduces hash\n chaining (previousReceiptHash) inside an optional Commitment Mode\n extension. [ACTA-RECEIPTS] does not define receipt retention, does\n not require timestamping anchors, and does not bind to any regulatory\n regime.\n\n This document is an additive overlay on [ACTA-RECEIPTS]: it\n constrains fields the upstream draft leaves OPTIONAL, fixes their\n values where regulation requires, and registers a set of extension\n fields with reserved names spanning regulatory classification, cross-\n agent envelope binding, per-action freshness and integrity, build\n provenance, threat-framework taxonomy, and server-built enforcement\n attestation. The full extension-field set is defined in Section 5.5\n and the sections that follow it. A Compliance Receipt remains a\n conformant [ACTA-RECEIPTS] receipt. Field references use upstream\n field names rather than section numbers, to reduce maintenance hazard\n if upstream re-numbers in a future revision.\n\nGomes Marques Expires 21 January 2027 [Page 5]\nInternet-Draft Compliance Receipts Profile July 2026\n\n1.2. Scope\n\n This document fills the regulatory binding gap on two surfaces.\n Section 5 binds the receipt to European Union obligations: Article 12\n (record-keeping) and Article 26 (deployer obligations) of the EU AI\n Act, and Article 17 (ICT-related incident management) of DORA.\n Section 6 binds the receipt to United States obligations: the\n voluntary functions of the NIST AI Risk Management Framework, the\n deployer obligations of the Colorado AI Act and the Texas Responsible\n AI Governance Act, the audit-trail and incident-reporting obligations\n of NYDFS Part 500, the audit controls and documentation retention of\n the HIPAA Security Rule, the broker-dealer recordkeeping requirements\n of SEC Rule 17a-4, and the covered-incident reporting requirements of\n CIRCIA.\n\n The bindings are written from the Deployer's perspective, where\n Deployer is used in the regime-specific sense (Article 3(4) of\n [EU-AI-ACT] for EU bindings; Section 6-1-1701(6) of the Colorado\n Revised Statutes for Colorado bindings). Where another statute uses\n a different term (Provider, Financial Entity, Covered Entity for\n HIPAA, Covered Entity for NYDFS, Broker-Dealer for SEC, Covered\n Entity for CIRCIA), the binding section names the term as the source\n statute uses it.\n\n A verifier that implements only [ACTA-RECEIPTS] can cryptographically\n validate a profile receipt but cannot attest the additional\n compliance bindings of this document.\n\n2. Conventions and Definitions\n\n The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\n "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and\n "OPTIONAL" in this document are to be interpreted as described in BCP\n 14 [RFC2119] [RFC8174] when, and only when, they appear in all\n capitals, as shown here.\n\n The following terms are used in this document.\n\n Action: An operation performed by an AI agent that is subject to a\n policy evaluation. Examples include a tool invocation, an\n external API call, a write to durable storage, and the issuance of\n an irreversible instruction to another system.\n\n Action Receipt: A signed envelope conforming to [ACTA-RECEIPTS] that\n records the policy evaluation result for a single Action.\n\n Compliance Receipt: An Action Receipt that additionally satisfies\n the requirements of this profile.\n\nGomes Marques Expires 21 January 2027 [Page 6]\nInternet-Draft Compliance Receipts Profile July 2026\n\n Deployer (EU AI Act): As defined in Article 3(4) of [EU-AI-ACT].\n\n Deployer (Colorado AI Act): As defined in Section 6-1-1701(6) of the\n Colorado Revised Statutes, as enacted by [COLORADO-AI-ACT].\n\n High-Risk AI System (EU AI Act): As defined in Article 6 of\n [EU-AI-ACT].\n\n High-Risk AI System (Colorado AI Act): As defined in\n Section 6-1-1701(9) of the Colorado Revised Statutes, as enacted\n by [COLORADO-AI-ACT].\n\n Financial Entity: As defined in Article 2(2) of [DORA], for entities\n listed in Article 2(1).\n\n Covered Entity (HIPAA): As defined in 45 CFR 160.103, namely a\n health plan, a health care clearinghouse, or a health care\n provider that transmits health information in electronic form in\n connection with a covered transaction.\n\n Covered Entity (NYDFS): As defined in 23 NYCRR 500.1(e), namely any\n person operating under or required to operate under a license,\n registration, charter, certificate, permit, accreditation or\n similar authorization under the Banking Law, the Insurance Law or\n the Financial Services Law, regardless of whether the covered\n entity is also regulated by other government agencies.\n\n Broker-Dealer: As defined in section 3(a)(4) and 3(a)(5) of the\n Securities Exchange Act of 1934, subject to recordkeeping under\n [SEC-17A-4].\n\n Covered Entity (CIRCIA): As to be defined in the final rule\n promulgated under the Cyber Incident Reporting for Critical\n Infrastructure Act of 2022. Pending publication of the final\n rule, the term is interpreted in accordance with the statutory\n definition at 6 U.S.C. 681 and CISA's notice of proposed\n rulemaking.\n\n Audit Pack: A bundle of Compliance Receipts, the chain commitments\n that link them, the public verification keys, the trust anchor\n metadata, and the regime mapping required by Sections 5 and 6 of\n this document, packaged for delivery to a regulator or auditor.\n\n3. Relationship to ACTA-RECEIPTS\n\n This profile is an additive overlay on [ACTA-RECEIPTS]. It does not\n modify the envelope, the canonicalization rule, the signature object,\n or the algorithm registry of [ACTA-RECEIPTS].\n\nGomes Marques Expires 21 January 2027 [Page 7]\nInternet-Draft Compliance Receipts Profile July 2026\n\n The following normative statements apply.\n\n * Implementations of this profile MUST produce receipts that are\n cryptographically verifiable by a conformant [ACTA-RECEIPTS]\n verifier under the canonicalization rules (JCS, [RFC8785]) and the\n signature scope of [ACTA-RECEIPTS] Section 5.6.\n\n * Implementations of this profile MUST NOT introduce new top-level\n fields in the signed payload that conflict with names reserved by\n [ACTA-RECEIPTS].\n\n * Implementations of this profile MAY use any signature algorithm\n permitted by [ACTA-RECEIPTS]: EdDSA (Ed25519, mandatory-to-\n implement, [RFC8032]), ES256 (ECDSA using P-256 and SHA-256,\n [RFC7518]), and ML-DSA-65 ([FIPS204]).\n\n * Where [ACTA-RECEIPTS] marks a field OPTIONAL and this profile\n marks the same field REQUIRED, the stricter requirement applies to\n Compliance Receipts.\n\n A receipt that fails any MUST clause of this profile is not a\n Compliance Receipt. It MAY still be a valid [ACTA-RECEIPTS] receipt.\n\n This profile differentiates from [ACTA-RECEIPTS] on three axes:\n mandatory hash-chain linkage (upstream Commitment Mode is OPTIONAL),\n mandatory anchoring with RFC 3161 or OpenTimestamps (both\n RECOMMENDED; upstream lists Sigstore Rekor in its Implementation\n Status appendix as an OPTIONAL temporal anchor), and a retention\n floor tied to specific regulatory articles (upstream is silent on\n retention).\n\n4. Canonicalization Scope\n\n This section is normative. The canonicalization rule itself (JCS,\n [RFC8785]) is inherited unchanged from [ACTA-RECEIPTS]; this section\n bounds the inputs the rule is applied to, so that the cross-\n implementation byte equality on which the hash chain of Section 5.3,\n the anchor scope of Section 5.4, and the cross-agent binding of\n Section 5.6 all depend is achievable in practice.\n\n IEEE-754 floating-point numbers MUST NOT appear in the canonical form\n covered by a SHA-256 digest under this profile. Callers MUST\n serialize numeric values that are not exact integers in the IEEE-754\n safe integer range (the closed interval from minus (2 to the 53 minus\n 1) to plus (2 to the 53 minus 1) inclusive) either as JSON strings or\n as integer-rational pairs (numerator and denominator as JSON numbers\n within that safe integer range) before the canonicalization step.\n\nGomes Marques Expires 21 January 2027 [Page 8]\nInternet-Draft Compliance Receipts Profile July 2026\n\n Rationale: Section 3.2.2.3 of [RFC8785] specifies, by reference to\n Section 7.1.12.1 of ECMA-262, a byte-stable serialization that in\n principle covers all IEEE-754 double-precision values, integer or\n fractional. In practice, several widely deployed JSON serializers do\n not implement the ECMA-262 Number-to-String algorithm with byte\n fidelity: Python json.dumps, Go encoding/json, and Java Jackson\n (without explicit configuration) all produce different byte sequences\n from the same IEEE-754 double in documented cases (round-to-even\n ties, subnormal values, large-magnitude values requiring scientific\n notation). Compliance and regulatory contexts (monetary amounts,\n retention thresholds, anchoring intervals) additionally prefer exact\n integer or string-encoded decimal representations because float\n rounding loses the exact bytes that auditors quote. This profile\n therefore shifts the canonicalization burden off implementers (who\n would otherwise have to verify ECMA-262 conformance of an underlying\n JSON library) and onto callers, who are in a better position to\n choose a portable representation for the use case at hand. A receipt\n that carries a floating-point number in a digest-covered field is not\n guaranteed to verify across implementations even when each\n implementation independently conforms to [RFC8785], because the\n conformance burden has not been met by every mainstream JSON library.\n\n Tool-version-specific semantic equivalence is OUT OF SCOPE for the\n chain layer of this profile. The chain layer guarantees byte\n equality only. Examples of semantic equivalence that this profile\n does not assert and does not require a verifier to assert: SQL\n keyword case folding (SELECT vs select), filesystem path\n normalization (trailing slash, redundant separators, symlink\n resolution), Unicode normalization in any form (NFC, NFD, NFKC,\n NFKD); Section 3.1 of [RFC8785] requires that all components\n depending on JCS preserve Unicode string data as-is, and\n Section 3.2.2.2 of [RFC8785] serializes each code point without\n normalization, so callers MUST NOT rely on a verifier normalizing\n strings before comparison, locale-aware string collation (Turkish\n dotted-i, German sharp-s case folding, ICU collation tables), numeric\n tolerance (1.0 vs 1, 1e3 vs 1000), or URL percent-encoding choices\n below the RFC 3986 unreserved set. Higher-level semantic equivalence\n is a per-tool concern and, where required by a regulator, MUST be\n expressed in the policy artefact resolved through policy_digest\n (Section 5.2.2) rather than in the chain.\n\n The chain layer of this profile answers a single question for a\n verifier or a regulator: did the same canonicalized bytes pass\n through agent X at wall-clock time T, as fixed by the anchor evidence\n of Section 5.4. Anything beyond that question, including whether two\n byte sequences are semantically equivalent under a downstream tool,\n whether a policy update materially changed the meaning of a\n previously accepted Action, or whether a counterparty's\n\nGomes Marques Expires 21 January 2027 [Page 9]\nInternet-Draft Compliance Receipts Profile July 2026\n\n interpretation of the same bytes matched the originator's, is the\n verifier's concern and is supported by the Audit Pack manifest\n (Section 8) and the verifier reporting fields of Section 9.3, not by\n the chain itself.\n\n5. Receipt Field Profile\n\n This section enumerates fields defined by [ACTA-RECEIPTS] and states\n the additional requirements that this profile places on them. Field\n names follow [ACTA-RECEIPTS] exactly.\n\n Compliance Receipts MUST use the upstream wire field name signature\n for the signature object, exactly as defined in Sections 2.1 and\n 2.1.1 of [ACTA-RECEIPTS]. The keys inside that object are alg, kid,\n sig. Implementations whose internal storage uses a different field\n name MUST translate to signature on emission and on canonicalization\n for verification; receipts that appear on the wire under any other\n top-level field name are non-conformant to [ACTA-RECEIPTS] and to\n this profile. Anchors MUST be projected into a top-level anchors\n array with a type discriminator and a value field carrying the anchor\n bytes (base64-encoded for binary payloads). Flat-column\n implementations MUST project on emission and Audit Pack export.\n\n5.1. Common Payload Fields\n\n5.1.1. type\n\n Compliance Receipts MUST set type to a value drawn from the namespace\n protectmcp:decision, protectmcp:restraint, or protectmcp:lifecycle,\n or to an extension namespace registered for use with this profile.\n\n5.1.2. issued_at\n\n REQUIRED upstream and in this profile. The value MUST be an ISO 8601\n timestamp with an explicit timezone. The producing system MUST\n source the value from a clock synchronized to a recognized time\n authority and MUST NOT backdate the value. Verifiers MUST reject\n receipts whose issued_at is more than 300 seconds ahead of the\n verifier's own clock. Verifiers MUST NOT reject a receipt solely\n because issued_at lies in the past; past skew is bounded by the\n applicable retention floor in Sections 5 and 6, not by freshness.\n Historical receipts within retention MUST verify on the same path as\n fresh ones.\n\nGomes Marques Expires 21 January 2027 [Page 10]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.1.3. issuer_id\n\n REQUIRED upstream and in this profile. The value MUST identify a\n legal entity, not a natural person. Where the producing system is\n operated by a Deployer, the issuer_id MUST resolve, through the trust\n anchor metadata in the Audit Pack, to a record naming the Deployer.\n To preserve the upstream Section 2.2 invariant that issuer_id MUST\n match the kid field of the signature object, Compliance Receipts MUST\n place the same value in both issuer_id and kid; the verifier resolves\n that value to a public key through the Audit Pack trust-anchor\n metadata rather than through the well-known JWK Set endpoint or the\n RECOMMENDED sb:issuer:<base58-fingerprint> form of [ACTA-RECEIPTS]\n Section 2.1.1. This profile thereby supersedes the upstream\n RECOMMENDED kid format for Compliance Receipts; the upstream\n RECOMMENDED format remains valid for non-Compliance receipts.\n\n Implementations SHOULD use a Legal Entity Identifier (LEI) as defined\n by [ISO17442] where one is allocated to the Deployer. Examples and\n test fixtures MUST use a placeholder whose four-character LOU prefix\n (positions 1-4) is not allocated in the GLEIF Local Operating Unit\n code list, whose positions 5-6 are the ISO 17442 reserved value 00,\n and whose two trailing characters (positions 19-20) are the ISO 7064\n mod 97-10 check digits computed over positions 1-18 (for example\n 00000000000000000098, where the all-zero 18-character base produces\n the check digits 98 per the ISO 17442-1:2020 Annex A check-digit\n algorithm, which converts any letters in positions 1-18 to digits\n A=10 ... Z=35 before the mod 97-10 computation; for an all-zero base\n the conversion is a no-op); implementations MUST NOT use a real\n third-party LEI in documentation or test data. Where no LEI is\n allocated and the Deployer is a US entity, an Employer Identification\n Number (EIN) issued by the United States Internal Revenue Service or\n a Central Index Key (CIK) issued by the United States Securities and\n Exchange Commission MAY be used, expressed as the bare numeric\n string. Decentralized Identifiers ([W3C-DID]) MAY be used otherwise.\n Implementations MUST treat the value as opaque on verification;\n identifier resolution is out of scope for this profile.\n\n issuer_id values MUST be bare identifiers without a scheme prefix\n where the scheme is unambiguous from the value's syntactic form. An\n LEI is the 20-character alphanumeric string defined by [ISO17442] and\n is self-identifying through its length and check-digit structure;\n implementations MUST emit the bare 20-character LEI without a lei: or\n other scheme prefix. EINs and CIKs are likewise emitted as the bare\n numeric string. Decentralized Identifiers ([W3C-DID]) carry their\n own scheme prefix (did:) as defined by the DID specification and that\n prefix is intrinsic to the identifier syntax rather than an added\n scheme tag. The same kid-equals-issuer_id invariant requires\n signature.kid to be the bare identifier in the same form. The worked\n\nGomes Marques Expires 21 January 2027 [Page 11]\nInternet-Draft Compliance Receipts Profile July 2026\n\n example in Appendix "Worked Example (Informative)" uses the bare\n 20-character placeholder LEI 00000000000000000098; conformant cloud\n emitters and SDK clients MUST match this form on the wire.\n\n5.1.4. payload_digest (OPTIONAL upstream, REQUIRED in this profile)\n\n REQUIRED for Compliance Receipts. The value MUST follow the upstream\n object form (hash, size, optional preview) defined in Section 2.2 of\n [ACTA-RECEIPTS]; this profile does not redefine the wire shape. The\n associated payload that this digest covers MUST be retained for the\n period mandated by the most restrictive applicable regime in Sections\n 5 and 6 of this document. Implementations MUST NOT discard the\n underlying payload while a receipt that references it is still within\n its retention window.\n\n5.1.5. action_ref (OPTIONAL upstream, REQUIRED in this profile)\n\n REQUIRED for Compliance Receipts. The value is a SHA-256 hash of the\n canonical Action representation as defined in [ACTA-RECEIPTS]. This\n profile uses action_ref as the primary join key for cross-engine\n reconstruction during an audit.\n\n5.1.6. sandbox_state (OPTIONAL upstream, REQUIRED for High-Risk in this\n profile)\n\n REQUIRED for receipts produced by High-Risk AI Systems under either\n [EU-AI-ACT] or [COLORADO-AI-ACT]. Upstream defines sandbox_state as\n an OS-level containment status and restricts the value to one of\n enabled, disabled, or unavailable; this profile inherits that\n enumeration unchanged. A Deployer that operates a High-Risk AI\n System and produces a stream of receipts in which sandbox_state is\n consistently disabled SHOULD treat that stream as a finding under the\n applicable risk-management documentation requirement (Article 9 of\n [EU-AI-ACT] for the Provider's risk management system, with which a\n Deployer operating per Article 26(1) is required to be consistent;\n Section 6-1-1703(2) of the Colorado Revised Statutes) and document\n the rationale in the Audit Pack metadata.\n\n5.1.7. iteration_id (OPTIONAL upstream, REQUIRED for multi-step in this\n profile)\n\n REQUIRED for multi-step agent workflows. The value MUST be stable\n across all receipts emitted within the same logical task or session\n so that a regulator can reconstruct the full chain of Actions.\n iteration_id is distinct from the upstream session_id field defined\n in [ACTA-RECEIPTS] Section 3.1.1, which is an opaque MCP session\n identifier. A Compliance Receipt MAY carry both: session_id for MCP-\n session correlation and iteration_id for logical-task correlation.\n\nGomes Marques Expires 21 January 2027 [Page 12]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.2. Decision Receipt Fields (type protectmcp:decision)\n\n The decision field value MUST be allow, deny, rate_limit, or\n observation. Implementations using a different internal vocabulary\n (e.g. permit for allow) MUST normalise on emission and on Audit Pack\n export. The observation value records that an Action was observed\n and the receipt was signed without any policy evaluation having taken\n place; it is the regulator-honest alternative to emitting allow when\n no policy matched, and MUST NOT appear in a receipt of type\n protectmcp:decision. A producing system that has not evaluated a\n policy for an Action MUST either refuse to issue a Compliance Receipt\n for that Action or MUST emit the receipt with type\n protectmcp:lifecycle and decision observation; in the latter case the\n upstream policy_decision internal field, if present in the producing\n system's internal vocabulary, takes the literal value none, which the\n emitter MUST map to observation on the wire. Verifiers MUST reject a\n Compliance Receipt that carries decision observation together with\n type protectmcp:decision; conversely, a Compliance Receipt of type\n protectmcp:lifecycle MAY carry decision observation in addition to\n the other three vocabulary values. The policy_digest requirement of\n Section 5.2.2 applies to observation receipts in the form of a digest\n of the producing system's "no policy matched" sentinel policy\n artefact, which the Deployer MUST retain alongside its other policy\n artefacts for the applicable retention window.\n\n The upstream tool_name field (REQUIRED in [ACTA-RECEIPTS]\n Section 3.1.1) is REQUIRED for Compliance Receipts of type\n protectmcp:decision.\n\n5.2.1. reason (OPTIONAL upstream, REQUIRED for deny/rate_limit in this\n profile)\n\n REQUIRED for Compliance Receipts where decision is deny or\n rate_limit. The value MUST be a machine-readable reason code drawn\n from a vocabulary documented in the Deployer's Audit Pack metadata.\n\n5.2.2. policy_digest (OPTIONAL upstream, REQUIRED in this profile)\n\n REQUIRED for Compliance Receipts. The value MUST be of the form\n sha256:<hex> and MUST reference a policy artefact that the Deployer\n retains for the applicable retention window. Verifiers MUST reject\n Compliance Receipts whose policy_digest does not resolve in the Audit\n Pack.\n\nGomes Marques Expires 21 January 2027 [Page 13]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.3. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile)\n\n Upstream Commitment Mode introduces previousReceiptHash as part of an\n optional extension. This profile makes the linkage REQUIRED.\n Implementations MUST emit a previousReceiptHash field, populated per\n the digest-scope rule of Section 5.7 of [ACTA-RECEIPTS]: the\n lowercase hex encoding of SHA-256 over the canonical signing-input\n bytes of the immediately prior receipt emitted by the same issuer_id,\n where the canonical signing-input bytes are the JCS-canonical\n serialization ([RFC8785]) of the predecessor's signed payload object\n (the same bytes the predecessor's cryptographic signature covers),\n NOT the envelope object that additionally includes the signature or\n anchors top-level keys. The first receipt in a chain MUST set this\n field to the all-zero SHA-256 value (this profile's stipulation;\n [ACTA-RECEIPTS] Section 5.7 specifies only the digest scope of\n subsequent links). JSON key is the literal previousReceiptHash\n (camelCase, case-sensitive); snake_case aliases MUST NOT appear on\n the wire.\n\n Rationale for the payload-bytes (signing-input) digest scope rather\n than the envelope-including-signature digest scope: the chain layer's\n purpose is to make after-the-fact alteration of the predecessor's\n signed content detectable, and the predecessor's signed content is\n exactly the bytes its signature covers (the canonical payload\n object). Digesting those bytes binds the chain to what A actually\n attested to, is recomputable offline from the predecessor's payload\n alone, and matches Section 5.7 of [ACTA-RECEIPTS]. The chain does\n not need to bind the predecessor's signature value directly because\n the predecessor's signature is verified independently under\n Section 9.1, and cross-agent envelope integrity (where binding the\n peer's signature value matters) is the role of counterparty_binding\n per Section 5.6, which digests at the envelope-including-signature\n scope precisely because the peer signature is the load-bearing\n artefact in the cross-agent case. Implementations that previously\n digested the envelope-including-signature object MUST migrate to the\n signing-input scope before emitting chained receipts under this\n profile; verifiers MUST recompute under the signing-input scope when\n checking previousReceiptHash.\n\n Each issuer MUST maintain a single linear per-agent chain. When one\n agent identity emits receipts from multiple concurrent execution\n paths (for example parallel tool calls dispatched within a single\n agent loop, or fan-out work performed by a thread pool inside one\n issuer), the issuer MUST serialize emission through a single\n predecessor pointer at a time: each newly emitted receipt's\n previousReceiptHash MUST resolve to the SHA-256(JCS(receipt)) of the\n immediately prior receipt emitted by that same issuer_id, taken in\n emission order, regardless of which concurrent execution path\n\nGomes Marques Expires 21 January 2027 [Page 14]\nInternet-Draft Compliance Receipts Profile July 2026\n\n produced it. Parallel sub-chains within one agent identity (for\n example, a per-receipt chain_id discriminator that would partition\n one issuer's stream into multiple independently advancing chains) are\n NOT defined by this profile. An issuer that requires parallel sub-\n chains MUST express each parallel path as a distinct agent identity,\n with its own issuer_id value, its own signing key, and its own per-\n agent chain rooted at the all-zero SHA-256 genesis value. Rationale:\n deterministic verification of the chain segment covering an audit\n window, as required by the regime bindings of Sections 5 and 6 (in\n particular Section 6.3.2, Section 7.5.1, and Section 7.6.1), depends\n on a single linear total order over the receipts emitted under each\n agent identity; a verifier reconstructing the chain from a regulator-\n supplied issuer_id needs that ordering to be well-defined without\n out-of-band metadata.\n\n5.4. Anchoring (No Upstream Equivalent)\n\n [ACTA-RECEIPTS] lists Sigstore Rekor in its Implementation Status\n appendix as an OPTIONAL temporal anchor. This profile imposes a\n normative anchoring requirement.\n\n Compliance Receipts MUST be anchored. An anchor is an [RFC3161]\n timestamp token covering the signed envelope, an [OPENTIMESTAMPS]\n commitment covering the envelope, or both; implementations SHOULD\n emit both forms. For both anchor types, the bytes committed are SHA-\n 256(JCS(envelope_minus_anchors)), where envelope_minus_anchors is the\n wire envelope object with the anchors top-level key removed prior to\n canonicalization, leaving the two-key object {payload, signature}.\n The anchors key MUST be removed from the object, not set to null or\n to an empty array; these produce different JCS output and break\n interoperability (mirroring the upstream Section 5.6 stripping rule).\n The anchor thereby binds payload and signature without being self-\n referential. The anchor evidence MUST be retained alongside the\n receipt for the applicable retention window. Verifiers MUST reject\n Compliance Receipts that lack at least one valid anchor.\n\n An anchor MAY be attached after issuance if the receipt is persisted\n with an unambiguous pending marker and the anchor lands within a\n documented bound. For [OPENTIMESTAMPS], this profile imposes a 7-day\n deadline; this is a profile-imposed bound, not a property of the\n OpenTimestamps protocol, whose calendar-to-block upgrade time depends\n on the calendar operator's publication interval. [RFC3161] tokens\n MUST be obtained synchronously. A verifier MUST treat a pending\n receipt as non-conformant once the bound elapses.\n\nGomes Marques Expires 21 January 2027 [Page 15]\nInternet-Draft Compliance Receipts Profile July 2026\n\n The anchor MAY cover an aggregate of receipts (for example, a Merkle\n root over a batch) rather than each receipt individually, provided\n that the inclusion proof linking the receipt to the aggregate is\n retained alongside the receipt and the aggregate anchor.\n\n Where the anchor type is [RFC3161], the full TimeStampResp DER bytes\n MUST be retained, sufficient for offline verification by a holder\n with access to the TSA's published public key. Time-stamp tokens\n carrying ESSCertIDv2 per [RFC5816] MUST be accepted by Compliance\n Verifiers. An rfc3161 anchor MAY be obtained from a Time-Stamping\n Authority operated independently of the issuer (for example a public\n RFC 3161 TSA under a distinct trust root) in addition to, or instead\n of, an issuer-operated TSA; the independently operated TSA is the\n genuinely independent witness referenced in Section 10.6, and is one\n of the N witnesses of witness_policy rather than ever the sole\n anchor. Where the anchor type is [OPENTIMESTAMPS], the upgrade from\n the initial calendar attestation to the Bitcoin block attestation\n MUST be completed within the 7-day profile-imposed bound, and the\n upgraded proof MUST be retained for the applicable retention window\n per the second paragraph of this section.\n\n Each entry in the top-level anchors array is an object with the\n following members.\n\n type: REQUIRED string discriminator. MUST be one of rfc3161 or\n opentimestamps.\n\n value: REQUIRED on every anchor entry. The anchor token bytes,\n base64-encoded. For rfc3161 the value is the base64 encoding of\n the full TimeStampResp DER bytes (sufficient for offline\n cryptographic re-verification by a holder with access to the TSA's\n published public key). For opentimestamps the value is the base64\n encoding of the OpenTimestamps proof blob (the .ots\n serialization). A verifier MUST cryptographically re-verify the\n anchor against the signed envelope using these bytes per\n Section 9.1; anchor entries served without value MUST NOT be\n reported as anchor_valid_*=true.\n\n status: OPTIONAL informational string. When present, MUST be one of\n anchored (the anchor has reached its final attestation state: an\n [RFC3161] token has been obtained, or an [OPENTIMESTAMPS]\n commitment has upgraded to its Bitcoin block attestation), pending\n (the anchor has been requested but the final attestation state has\n not yet been reached, e.g. an OpenTimestamps commitment that has\n been submitted to a calendar but has not yet upgraded to a Bitcoin\n block within the 7-day bound of this section), or failed (the\n anchor submission was attempted and did not produce a usable\n attestation, e.g. a TSA returned an error response or an\n\nGomes Marques Expires 21 January 2027 [Page 16]\nInternet-Draft Compliance Receipts Profile July 2026\n\n OpenTimestamps calendar refused the commitment). status is\n operational metadata; a verifier MUST NOT derive cryptographic\n validity from status alone, and MUST always re-verify the value\n bytes per Section 9.1.\n\n anchor_block_hash: OPTIONAL informational string. The Bitcoin block\n hash at which an [OPENTIMESTAMPS] commitment was anchored.\n Present only on entries with type=opentimestamps and\n status=anchored; absent on rfc3161 entries and on pending or\n failed OpenTimestamps entries. anchor_block_hash is operational\n metadata; a verifier MUST NOT derive cryptographic validity from\n anchor_block_hash alone, and MUST always re-verify the value bytes\n against the OpenTimestamps proof per Section 9.1.\n\n An OPTIONAL envelope-level witness_policy member, a sibling of\n payload, signature, and anchors, declares an N-of-M durable-anchoring\n quorum over the anchors array. witness_policy is an object with two\n members: required, a REQUIRED integer in the closed range [1, length\n of witnesses]; and witnesses, a REQUIRED non-empty JSON array whose\n values are a subset of the anchor type vocabulary {rfc3161,\n opentimestamps}. The witnesses array MUST NOT contain duplicate\n values and MUST NOT contain any value outside that vocabulary; in\n particular a transparency-log pointer such as Rekor is NOT a witness\n type and MUST be rejected if it appears in witnesses. The policy\n declares that the receipt's durable anchoring is satisfied only when\n at least required distinct witness types named in witnesses each hold\n a verifiable inclusion proof, that is, an anchor entry of that type\n whose value bytes re-verify against SHA-\n 256(JCS(envelope_minus_anchors)) per Section 9.1 and, for\n opentimestamps, has upgraded to its Bitcoin block attestation within\n the 7-day bound of this section.\n\n A receipt reaches the quorum-met state (the reference implementation\n reports this as witness_quorum_met) only when the count of distinct\n witness types satisfying the preceding paragraph is greater than or\n equal to required. A Compliance Receipt MUST NOT assert that durable\n anchoring has been achieved, and a producer MUST NOT set or report\n witness_quorum_met, unless required witnesses each hold a real,\n verifiable inclusion proof; an anchors entry with status=pending or\n status=failed, or with absent or non-verifying value bytes, does NOT\n count toward the quorum. This is the same false-attestation\n principle that governs the rest of this profile: a receipt MUST NOT\n claim a cryptographic property it cannot prove from retained bytes,\n and a verifier MUST recompute the quorum from the re-verified anchors\n entries rather than trust any producer-asserted quorum flag. The\n reference cloud implementation enforces the quorum honesty rule at\n signing time and publishes it as the\n witness_policy_required_exceeds_confirmed guard in its /.well-known/\n\nGomes Marques Expires 21 January 2027 [Page 17]\nInternet-Draft Compliance Receipts Profile July 2026\n\n governance.json wire-vocabulary surface. witness_policy places no\n constraint on a receipt that carries no such member; the baseline\n single-anchor requirement of this section continues to apply to every\n Compliance Receipt regardless of whether witness_policy is present.\n\n5.5. Extension Fields\n\n This profile registers extension fields across five groupings that\n MAY appear in the signed payload object alongside the fields defined\n by [ACTA-RECEIPTS]: (a) regulatory classification fields (risk_class,\n incident_class) defined in this section; (b) the cross-agent\n envelope-binding field counterparty_binding defined in Section 5.6;\n (c) per-action freshness and integrity fields (result_digest,\n expires_at, nonce, tool_fingerprint, config_manifest_digest,\n cve_inventory_digest) and build-provenance fields (executable_hash,\n sbom_digest, slsa_provenance_pointer, supply_chain_pointer) defined\n in Section 5.7 and Section 5.8; (d) server-built enforcement-\n attestation fields (authorized_under_mandate, controls_evaluated)\n defined in Section 5.9; (e) self-declared threat-framework taxonomy\n fields (mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf,\n iso_42001, eu_ai_act_articles), the opaque caller-supplied\n rfc3161_timestamp token, and the platform-set guard\n framework_mappings_self_declared defined in Section 5.12; (f)\n producer-asserted risk-acceptance fields (approver_id, initiator_id,\n acceptance_reason, accepted_at, supersedes, sarif_digest,\n finding_ref, approval_ref, risk_snapshot) defined in Section 5.10;\n and (g) producer-asserted code-authorship fields (repo_ref,\n commit_sha, base_sha, change_digest, change_ref, change_approval_ref,\n change_class, authored_by) defined in Section 5.11. All extension\n fields appear inside the signed payload object and are therefore\n covered by the upstream Section 5.6 signature scope.\n\n risk_class: A vocabulary term identifying the risk classification of\n the Action under the Deployer's risk management documentation.\n The vocabulary MUST be referenced in the Audit Pack metadata.\n Where the Deployer operates under [EU-AI-ACT], the documentation\n is the Provider's Article 9 risk management system as referenced\n via the instructions for use under Article 26(1); where the\n Deployer operates under [COLORADO-AI-ACT], the documentation is\n the Section 6-1-1703(2) risk management policy and program.\n\n incident_class: A vocabulary term identifying the incident\n classification of the Action under the applicable regime: an ICT-\n related incident under [DORA], with classification criteria in\n [REG-2024-1772] and the canonical reporting enumeration of Annex\n II data glossary, field 3.23 (Type of the incident) of\n [REG-2025-302] (verifiers MUST resolve the canonical values from\n the regulation directly); a Cybersecurity Event under 23 NYCRR\n\nGomes Marques Expires 21 January 2027 [Page 18]\nInternet-Draft Compliance Receipts Profile July 2026\n\n 500.1(f) (or, where the Section 500.17(a) reporting threshold is\n met, a Cybersecurity Incident under 23 NYCRR 500.1(g)) for Covered\n Entities of [NYDFS-500]; a Covered Cyber Incident under [CIRCIA]\n once the final rule takes effect; or a security incident under 45\n CFR 164.304 for Covered Entities of [HIPAA-SECURITY].\n Implementations MAY refine the set, provided the flattened mapping\n in the Audit Pack manifest (Section 8) projects each refinement to\n the applicable canonical category for each in-scope regime.\n\n risk_class MUST be encoded as a JSON string. incident_class MUST be\n encoded as a JSON string drawn from the canonical vocabulary\n referenced in the Audit Pack, OR as a JSON array of such strings to\n preserve cross-regime classification (for example, a single Action\n that is both a DORA ICT-related incident and a CIRCIA Covered Cyber\n Incident, or both a NYDFS Cybersecurity Incident and a CIRCIA Covered\n Cyber Incident). Both fields are OPTIONAL at the syntactic level but\n MAY be REQUIRED by the regime bindings in Sections 5 and 6 of this\n document.\n\n Implementations MAY define additional extension fields. Such fields\n MUST NOT collide with names defined by [ACTA-RECEIPTS] or by this\n document. Implementations defining extension fields SHOULD register\n them in the registry described in Section 11.\n\n5.6. Counterparty Binding\n\n This section is normative. counterparty_binding is an in-payload\n object an acknowledging agent ("B") emits to carry a cryptographic\n digest of the full signed envelope of an originating agent ("A"). It\n provides cross-agent byte-equality evidence when a shared\n intermediary sits between two honest agents and the per-agent hash\n chains of Section 5.3 validate independently regardless of whether\n B's observed bytes equal A's signed bytes. action_ref is a\n correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS]\n Section 2.2); counterparty_binding moves the evidence onto B's own\n COSE or JWS signature, which the verifier already trusts.\n\n5.6.1. Wire Shape\n\n The field MUST appear inside the signed payload object. It MUST NOT\n appear in unprotected COSE or JWS header parameters, or in\n external_aad per [RFC9052] Section 4.3 when the receipt is used for\n audit (external_aad is permissible only in transport-optimized modes\n out of scope for Compliance Receipts). For COSE-framed receipts the\n field sits inside the COSE_Sign1 or COSE_Sign payload per [RFC9052]\n Section 4.1; for JWS-framed receipts it is a top-level claim per\n [RFC7515].\n\nGomes Marques Expires 21 January 2027 [Page 19]\nInternet-Draft Compliance Receipts Profile July 2026\n\n The field is an object with the following members.\n\n envelope_hash: REQUIRED string. Base64-encoded SHA-256 digest\n computed over A's entire serialized signed envelope, including A's\n signature bytes. The digest input is framing-specific:\n\n * JSON-framed (this profile's default for receipts not\n transported under COSE or JWS, and mandatory-to-implement for\n any conformant Compliance Receipt implementation): the JCS-\n canonical UTF-8 byte sequence of A's signed envelope JSON\n object per [RFC8785], where the envelope is the three-key\n object {"payload": <signed payload object>, "signature":\n <signature object with alg, kid, sig members>, "anchors":\n <array of anchor objects, OPTIONAL>}. The payload object\n carries the signed fields A emitted (including type, issuer_id,\n issued_at, action_ref, payload_digest, previousReceiptHash,\n decision, and any extension fields under Section 5.5); the\n signature object carries the algorithm identifier, key\n identifier, and base64- or base64url-encoded signature bytes\n exactly as A emitted them. B MUST NOT re-canonicalize A's\n payload or strip the anchors array before computing the digest.\n\n * COSE-framed: the full COSE_Sign1 or COSE_Sign byte string per\n [RFC8949] Section 4.2 (deterministic encoding).\n\n * JWS-framed: the full JWS Compact Serialization\n (header.payload.signature) after payload canonicalization per\n [RFC8785].\n\n The digest algorithm is SHA-256 (mandatory-to-implement). The\n encoding MUST be standard base64 per [RFC4648] Section 4 on\n emission, OR base64url per Section 5 where the surrounding\n transport requires URL-safe encoding; verifiers MUST accept both\n alphabets and MUST normalise to a single alphabet (typically\n standard base64) before byte-comparing to a recomputed value.\n Including A's signature in the digest scope binds the signed-over\n content of A's receipt at the envelope level and prevents an\n intermediary that re-signs A's claims with a different key from\n escaping detection.\n\n The framing in which A's envelope was emitted MUST be preserved\n through B's binding. The value of envelope_hash is framing-\n specific because JCS-canonical JSON (UTF-16 code-unit\n lexicographic key ordering per [RFC8785]), COSE deterministic\n encoding (length-then-byte map-key ordering per [RFC8949]\n Section 4.2), and JWS Compact Serialization with JCS-canonical\n payload (UTF-16 code-unit lexicographic ordering per [RFC8785])\n produce different byte sequences from the same semantic payload-\n\nGomes Marques Expires 21 January 2027 [Page 20]\nInternet-Draft Compliance Receipts Profile July 2026\n\n and-signature, and the three framings therefore yield different\n envelope_hash values for the same underlying receipt. A\n transcoding intermediary that re-frames A's envelope (JSON to\n COSE, COSE to JWS, or any other pairing) changes the digest input\n and MUST be treated as a tampering event by the verifier;\n verifiers MUST NOT reframe an envelope before recomputing\n envelope_hash.\n\n Future revisions MAY extend to additional digest algorithms drawn\n from the [ACTA-RECEIPTS] digest algorithm registry;\n implementations that require algorithm negotiation SHOULD carry\n the algorithm identifier out of band in the Audit Pack manifest\n rather than in the wire field.\n\n receipt_ref: REQUIRED opaque content-addressed locator the verifier\n resolves through the Audit Pack or a Deployer-published index to\n A's full signed envelope. The value is an opaque string from the\n verifier's perspective; producers MAY use any stable identifier\n scheme (URI, content-addressed digest, opaque database id) so long\n as the Audit Pack resolution layer returns the correct envelope\n bytes. Future profiles (for example, a SCITT-style inclusion-\n proof profile under [ACTA-RECEIPTS] Section 4.2 extension\n semantics) MAY layer on this field.\n\n expect_ack_from: OPTIONAL string. The expected acknowledging-party\n identifier, expressed as a kid or issuer_id value matching the\n same bare-identifier form required by Section 5.1.3. When\n present, the field declares which acknowledging party A or the\n producer expects to sign over this receipt's bytes; a verifier\n cross-checks the acknowledging receipt's kid against the expected\n identifier per Section 5.6.3. Verifiers MUST NOT reject solely on\n absence of an acknowledging receipt; absence is a liveness-loss\n signal observable through Audit Pack metadata rather than a non-\n conformance condition on the current receipt.\n\n transport_label: OPTIONAL string (mcp, bus, orchestrator, http).\n Operational only; verifiers MUST NOT derive trust from this label.\n\n "counterparty_binding": {\n "envelope_hash": "bDqg...5PE=",\n "receipt_ref": "asqav-receipt://org/123/agent_A/seq/4811",\n "expect_ack_from": "00000000000000000098",\n "transport_label": "mcp"\n }\n\n The COSE form follows the same member set under deterministic CBOR\n map ordering per [RFC8949] Section 4.2.\n\nGomes Marques Expires 21 January 2027 [Page 21]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.6.2. Emitter Behaviour\n\n B SHOULD emit counterparty_binding when any of the following hold:\n A's signing request flagged the action as requiring acknowledgment\n (for example, by populating an expect_ack_from list); the Deployer's\n risk management documentation requires bilateral byte-binding; or B\n is operating under the guidance of Section 10.11. B MUST compute\n envelope_hash over the exact byte stream it received and accepted,\n not over a re-canonicalization at B; re-canonicalizing at B masks\n intermediary tampering whenever the tampered bytes canonicalize to\n the same payload object, which is the threat case this section\n addresses. Where one acknowledgment receipt confirms envelopes from\n N originators, the field MAY be an array of objects; pairwise\n bindings cannot prove all N originators emitted identical bytes (see\n Section 10.10).\n\n5.6.3. Verifier Behaviour\n\n A Compliance Verifier processing a receipt carrying\n counterparty_binding MUST, in addition to Section 9.1, resolve\n receipt_ref through the Audit Pack or a Deployer-published index to\n A's full signed envelope, recompute the SHA-256 digest of that\n envelope under the scope rule of Section 5.6.1, base64-encode the\n result, and compare to envelope_hash. A non-resolving receipt_ref or\n a digest mismatch MUST cause the acknowledging receipt to be reported\n non-conformant; liveness loss at A MUST NOT be silently treated as\n success. Where expect_ack_from is present, the verifier MUST\n additionally check that the acknowledging receipt's signature.kid\n matches the declared identifier (under the bare-identifier form\n required by Section 5.1.3); a mismatch MUST cause the acknowledging\n receipt to be reported non-conformant, exactly as a digest mismatch\n is. The field is OPTIONAL to emit, but a declared expectation that\n the acknowledger's identity fails to satisfy is a failed binding, not\n an informational flag.\n\n The Deployer or Audit Pack producer MUST retain A's signed envelope\n for at least as long as any acknowledging receipt binding it remains\n within retention under Sections 5 and 6. For chains of three or more\n agents, this profile defaults to pairwise bindings; multi-signer co-\n presence under [RFC9052] Section 4.1 is OPTIONAL, and verifiers MUST\n NOT treat a co-signed envelope as a substitute for a pairwise binding\n chain.\n\nGomes Marques Expires 21 January 2027 [Page 22]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.7. Result-Bound and Freshness Extensions\n\n This section is normative. It defines six OPTIONAL extension fields\n that may appear inside the signed payload object to bind the receipt\n to the byte-equality of a downstream result, to bound the freshness\n of a decision, to declare the tool and configuration that produced\n the action, and to record the supply-chain Common Vulnerabilities and\n Exposures (CVE) inventory in effect at signing time. The fields are\n independently OPTIONAL; an implementation MAY emit any subset. All\n six are covered by the upstream Section 5.6 signature scope under\n [ACTA-RECEIPTS].\n\n result_digest: OPTIONAL object of the same shape as payload_digest\n defined in Section 2.2 of [ACTA-RECEIPTS]: REQUIRED string hash\n formatted sha256:<64 lowercase hex chars>, REQUIRED integer size\n in bytes, OPTIONAL string preview. The digest covers the\n canonicalized bytes of the downstream Action's result body\n (response payload, tool output, model completion). The field is\n emitted on a follow-up protectmcp:observation:result_bound receipt\n that references the originating protectmcp:decision via\n action_ref; a verifier processing a result-bound observation MUST\n treat a digest mismatch between result_digest and the verifier's\n local recomputation over retained result bytes as a non-\n conformance condition. Result bytes covered by result_digest are\n subject to the same retention floor as the originating decision\n receipt under Sections 5 and 6.\n\n expires_at: OPTIONAL ISO 8601 timestamp with explicit timezone,\n encoded as a JSON string. Declares the wall-clock time after\n which the producing system considers the decision result stale and\n not safe to replay. The field provides an upper freshness bound\n that is additive to the 300-second forward-skew bound on issued_at\n of Section 5.1.2; expires_at bounds replay safety from above, the\n forward-skew rule bounds emission honesty from above. A verifier\n MUST reject a downstream action that replays a decision whose\n expires_at lies in the past relative to the replay's wall clock;\n verifiers MUST NOT reject the originating receipt itself solely\n because expires_at has elapsed (the receipt remains valid as a\n record of the decision at issued_at).\n\n nonce: OPTIONAL JSON string carrying a producer-generated value that\n\nGomes Marques Expires 21 January 2027 [Page 23]\nInternet-Draft Compliance Receipts Profile July 2026\n\n is unique across the producer's emission stream for the lifetime\n of the cryptographic key identified by kid. The field SHOULD be\n the lowercase hexadecimal encoding of 12 random bytes (24\n hexadecimal characters). Verifiers SHOULD reject a second receipt\n that carries the same nonce under the same issuer_id as a replay\n candidate; the rejection is informational where the bound action\n is idempotent and load-bearing where the bound action is not. The\n field is OPTIONAL at the syntactic level but is a SHOULD-emit for\n any producer whose downstream actions are not idempotent.\n\n tool_fingerprint: OPTIONAL JSON string of 32 lowercase hexadecimal\n characters carrying the first 32 hexadecimal characters (128 bits)\n of the SHA-256 digest over the JCS canonicalization ([RFC8785]) of\n the JSON object {"tool_name": <tool name>, "schema": <declared\n input schema>}, where schema is the JSON object form of the tool's\n declared input schema (an empty object when the tool declares\n none). The field binds a receipt to a specific tool identity; a\n verifier or auditor reproducing the Action can detect tool drift\n (the same tool name with a different declared schema) by comparing\n fingerprints across receipts in the same chain, and a fingerprint\n change under an unchanged tool name surfaces naming collisions and\n registry shadowing. The field is OPTIONAL and complementary to\n action_ref: action_ref identifies the call, tool_fingerprint\n identifies the callee.\n\n config_manifest_digest: OPTIONAL JSON string formatted sha256:<64\n lowercase hex chars> over the canonical bytes of the producer's\n configuration manifest in effect at the time the Action was\n signed. The manifest content is operator-defined and SHOULD\n include the producer's policy bundle reference, model identifiers\n and versions, prompt template digests, retrieval index\n identifiers, and any other inputs whose change would constitute a\n substantial modification of the producing system under Article 43\n of [EU-AI-ACT] or under Section 6-1-1701 of [COLORADO-AI-ACT].\n The field is OPTIONAL but, when emitted, SHOULD resolve through\n the Audit Pack to retained manifest bytes for the duration of the\n longest applicable retention floor in Sections 5 and 6.\n\n cve_inventory_digest: OPTIONAL JSON string formatted sha256:<64\n lowercase hex chars> over the canonical bytes of the producer's\n CVE inventory at the time the Action was signed. The inventory\n content SHOULD list the CVE identifiers known to apply to the\n producer's executing image and its declared runtime dependencies,\n plus the producer's accepted-residual rationale per [EU-AI-ACT]\n Article 15 robustness obligations or the equivalent obligations\n under Sections 5 and 6. The field binds a snapshot of the\n producer's known-vulnerability surface to the receipt; a regulator\n examining the receipt can resolve the digest through the Audit\n\nGomes Marques Expires 21 January 2027 [Page 24]\nInternet-Draft Compliance Receipts Profile July 2026\n\n Pack to the canonical inventory bytes that were in effect when the\n Action was signed, rather than relying on a later-time inventory\n that may have been updated after the Action was performed.\n\n Implementations emitting result_digest SHOULD use the dedicated\n protectmcp:observation:result_bound type registered in Section 11.2\n for the follow-up receipt that carries the bound digest.\n Implementations MAY emit expires_at, nonce, tool_fingerprint,\n config_manifest_digest, and cve_inventory_digest on any receipt type\n defined by this profile; the fields are type-agnostic.\n\n5.8. Build-Provenance Extensions\n\n This section is normative. It defines four OPTIONAL extension fields\n that bind the receipt to the supply-chain provenance of the\n executable that produced the Action. The four fields form a layered\n subsumption set: executable_hash binds the running binary,\n sbom_digest binds the dependency manifest the binary was built from,\n slsa_provenance_pointer resolves to the SLSA attestation envelope for\n that build, and supply_chain_pointer resolves to a transparency-log\n entry (in-toto, Sigstore, or Rekor) covering the build. An\n implementation MAY emit any subset. All four are covered by the\n upstream Section 5.6 signature scope under [ACTA-RECEIPTS].\n\n executable_hash: OPTIONAL JSON string formatted sha256:<64 lowercase\n hex chars> over the canonical bytes of the executable that invoked\n the Action. For container-based producers the canonical bytes are\n the immutable image manifest digest of the running image (the\n value an OCI registry returns under the same name plus tag,\n computed under the OCI Image Manifest Specification). For non-\n container executables the canonical bytes are the SHA-256 of the\n on-disk binary file at the path the producer's runtime resolved.\n The field binds build-side provenance into the signed receipt: a\n regulator examining the receipt can recover the exact executable\n identity that produced the Action without trusting any side-\n channel attestation. A verifier MAY cross-check executable_hash\n against the executable identity declared in the SLSA attestation\n resolved through slsa_provenance_pointer; mismatch SHOULD be\n reported as an axis flag rather than as non-conformance because\n the two fields may identify the same artefact under different\n addressing schemes.\n\n sbom_digest: OPTIONAL JSON string formatted sha256:<64 lowercase hex\n chars> over the canonical bytes of the Software Bill of Materials\n (SBOM) document covering the executing image. The canonical form\n MUST be either CycloneDX (any 1.x specification version, JSON\n form, with the canonicalization rule defined by CycloneDX itself)\n or SPDX (version 2.x or later, JSON form, with the\n\nGomes Marques Expires 21 January 2027 [Page 25]\nInternet-Draft Compliance Receipts Profile July 2026\n\n canonicalization rule defined by SPDX itself); the producer SHOULD\n record the chosen format and version in the Audit Pack manifest\n entry for the receipt so a verifier can recompute the digest. The\n field complements executable_hash: executable_hash identifies the\n artefact, sbom_digest identifies the dependency closure of that\n artefact.\n\n slsa_provenance_pointer: OPTIONAL JSON string carrying an https URL\n that resolves to the Supply-chain Levels for Software Artifacts\n (SLSA) provenance attestation envelope for the build that produced\n the executable identified by executable_hash. The pointer target\n SHOULD be the SLSA Provenance v1.0 in-toto statement form;\n producers MAY emit earlier SLSA versions where toolchain support\n is incomplete, and verifiers SHOULD accept any SLSA version they\n implement. The field shifts the trust root for build-side\n provenance off the producer's self-attestation and onto the build\n platform's attestation; the verifier's confidence in the resolved\n attestation is bounded by the verifier's trust in the build\n platform's signing root.\n\n supply_chain_pointer: OPTIONAL JSON string carrying an https URL\n that resolves to a transparency-log entry covering the build that\n produced the executable identified by executable_hash. The\n pointer target SHOULD be an in-toto attestation, a Sigstore entry,\n or a Rekor entry, in that preference order where the producer can\n choose; verifiers SHOULD accept any of the three. The field\n provides a transparency-log-backed audit path for the build,\n independent of the SLSA attestation envelope referenced by\n slsa_provenance_pointer; the two fields are complementary because\n a transparency-log entry attests inclusion under a public log,\n while a SLSA attestation attests build-platform output bytes.\n\n The four fields are type-agnostic and MAY appear on any receipt type\n defined by this profile. Where a Deployer operates under a\n regulatory regime that requires build-side traceability (Article 12\n of [EU-AI-ACT] read together with Article 17 of [DORA]; the audit-\n controls obligation of 45 CFR 164.312(b) of [HIPAA-SECURITY]; the\n recordkeeping rule of [SEC-17A-4] read with [NYDFS-500] 23 NYCRR\n 500.6), the Deployer SHOULD emit at least executable_hash on every\n protectmcp:decision receipt and SHOULD retain the SBOM, the SLSA\n attestation, and the transparency-log entry through the longest\n applicable retention floor in Sections 5 and 6.\n\nGomes Marques Expires 21 January 2027 [Page 26]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.9. Enforcement-Attestation Extensions\n\n This section is normative. It defines two OPTIONAL extension fields\n that record, inside the signed payload object, which authorization\n and enforcement controls the issuing platform genuinely evaluated\n when it signed the receipt. Both fields are server-built: they are\n populated by the issuing platform at signing time, never carried in\n the producer's signing request, and a caller-supplied value for\n either field MUST be dropped by the issuing platform before signing.\n Both fields are covered by the upstream Section 5.6 signature scope\n under [ACTA-RECEIPTS]. The design rule for both fields is omission-\n over-false attestation: a control that did not run is represented by\n the absence of its key, never by a present key asserting a result the\n control did not produce. The two fields each carry a false-\n attestation guard that rejects a present-but-malformed attestation,\n in the same spirit as the framework_mappings_self_declared guard of\n Section 5.5 and the witness_policy quorum guard of Section 5.4.\n\n authorized_under_mandate: OPTIONAL object recording that the Action\n was signed under a self-declared authorizing mandate. The object\n carries four members: mandate_id (REQUIRED string, the issuer-\n scoped identifier of the mandate the Action was authorized under),\n issuer_id (REQUIRED string, the identifier of the party that\n issued the mandate, in the bare-identifier form required by\n Section 5.1.3), scope_digest (REQUIRED string formatted sha256:<64\n lowercase hex chars> over the canonical bytes of the mandate's\n authorized-action-types scope), and verified (REQUIRED boolean).\n The trust semantics are deliberately narrow: verified=true asserts\n self-declared issuer authority, the same trust level as\n framework_mappings_self_declared of Section 5.5, and is NEVER an\n issuing-platform attestation of verified third-party\n authorization. The mandate binding is self-declared by the\n issuer, is evaluated against the issuing platform's own clock at\n signing time, and scopes the Action to a set of authorized action\n types; this profile does NOT define a value cap, a counterparty\n restriction, or any other constraint on the mandate, and a\n verifier MUST NOT infer one from the presence of this field. A\n verifier resolves scope_digest by retrieving the mandate\n identified by mandate_id through the Audit Pack or a Deployer-\n published mandate index and recomputing the digest over the\n canonical scope bytes; a mismatch MUST be reported as a non-\n conformance condition. The false-attestation guard for this\n field, published as false_mandate_attestation_guard in the issuing\n platform's wire vocabulary, rejects an authorized_under_mandate\n object that is present but does not carry all of mandate_id,\n issuer_id, verified=true, and a well-formed scope_digest: a\n present-but-malformed attestation is rejected at signing time\n rather than signed and surfaced as truth.\n\nGomes Marques Expires 21 January 2027 [Page 27]\nInternet-Draft Compliance Receipts Profile July 2026\n\n controls_evaluated: OPTIONAL object enumerating the enforcement\n controls that genuinely fired when the issuing platform signed the\n Action, plus the allow result. The member keys are drawn from a\n closed set: emergency_halt, delegation_scope, quorum, mandate,\n policy, content_scan, and result; an unknown key MUST be rejected.\n Each control key is present ONLY when its control actually ran on\n this sign; an absent key means the control never ran on this sign,\n and a verifier MUST NOT infer from an absent key that the control\n ran and passed silently. The quorum member, when present, MUST\n carry fired=true together with a 64-lowercase-hex attestation_hash\n proving the quorum evaluation; the policy member, when present and\n asserting a policy was evaluated, MUST carry matched_count greater\n than or equal to 1. The false-attestation guard for this field,\n published as false_control_attestation_guard in the issuing\n platform's wire vocabulary, rejects a present-but-malformed\n controls_evaluated object: an unknown control key, a quorum member\n lacking fired=true plus a 64-hex attestation_hash, or a policy\n member asserting evaluation without matched_count greater than or\n equal to 1, is rejected at signing time. Because the field is\n server-built and a caller-supplied controls_evaluated is dropped\n before signing, a verifier MAY treat the enumerated keys as the\n issuing platform's own record of which controls it ran.\n\n Both fields are type-agnostic and MAY appear on any receipt type\n defined by this profile, though they are most commonly emitted on\n protectmcp:decision receipts where an authorization or enforcement\n evaluation produced the recorded decision. Neither field replaces\n the policy-evaluation honesty rule that an issuing platform MUST NOT\n assert a control ran when it did not (the design note carried under\n Section 10): controls_evaluated records which controls ran, not that\n any control blocked, and an absent control key is the conformant\n representation of a control that did not run.\n\n5.10. Risk-Acceptance Extensions\n\n This section is normative. It defines OPTIONAL extension fields that\n appear inside the signed payload object of a receipt of type\n protectmcp:lifecycle:risk_acceptance (registered in Section 11.2),\n which records a producer's decision to accept a known risk, security\n finding, or policy exception. A risk-acceptance receipt is a\n lifecycle record, not a policy-evaluation outcome: it is emitted\n through the no-policy lifecycle path of Section 5.2, carries decision\n observation, and asserts that no policy was evaluated for the\n acceptance. The fields are covered by the upstream Section 5.6\n signature scope under [ACTA-RECEIPTS], by the previousReceiptHash\n chain link of Section 5.3, and by the anchors timestamp of\n Section 5.4; taken together these prove only that the producer\n asserted these values, key-authored them, and chained them at the\n\nGomes Marques Expires 21 January 2027 [Page 28]\nInternet-Draft Compliance Receipts Profile July 2026\n\n receipt's issued_at. The receipt does NOT make any accepted risk\n safe, any snapshot value true, reproducible, or verified, or any\n declared expiry enforced. The scope-honesty labels in the field\n definitions below are normative and mirror the labels published in\n the issuing platform's /.well-known/governance.json wire-vocabulary\n surface.\n\n approver_id: REQUIRED JSON string carrying the producer-asserted\n identity that authored the risk acceptance, in the bare-identifier\n form of Section 5.1.3 (a bare kid or issuer_id). The field is\n bound into the signed bytes only: the issuing platform performs NO\n authority check, NO authentication of the named identity, and NO\n identity resolution; the only comparison it makes is the\n compliance_mode string-equality refusal against initiator_id (the\n risk_acceptance_self_approval_guard of the initiator_id entry\n below). A risk-acceptance receipt that omits approver_id MUST be\n rejected at signing time by the false-attestation guard named in\n Section 11.1.\n\n initiator_id: OPTIONAL JSON string carrying the producer-asserted\n identity that requested the acceptance, in the same bare-\n identifier form. The field is bound into the signed bytes only.\n The reference cloud implementation refuses at signing time, as the\n risk_acceptance_self_approval_guard, a risk-acceptance receipt\n signed under compliance_mode whose initiator_id string-equals\n approver_id, because a receipt asserting an approval flow approved\n by its own initiator is incoherent on its face. The guard is a\n string-incoherence check (case-sensitive exact match), NOT\n identity resolution: it fires only when both fields are present,\n an absent field never fires it, and any real segregation-of-duties\n decision belongs to the Deployer's enforcement layer, not to this\n record format.\n\n acceptance_reason: REQUIRED JSON string carrying the free-text\n producer rationale for accepting the risk. The field proves that\n the rationale existed and was key-authored at issued_at; it is\n never parsed, scored, or validated by the issuing platform. A\n risk-acceptance receipt that omits acceptance_reason MUST be\n rejected at signing time by the same false-attestation guard as\n approver_id.\n\n accepted_at: OPTIONAL ISO 8601 timestamp with explicit timezone,\n encoded as a JSON string, carrying the producer-asserted wall-\n clock time at which the acceptance was authored. This value is\n self-declared by the producer; the only times the issuing platform\n attests are issued_at (Section 5.1.2) and the anchors evidence\n (Section 5.4). The field is distinct from issued_at so that an\n acceptance back-dated relative to emission is auditable.\n\nGomes Marques Expires 21 January 2027 [Page 29]\nInternet-Draft Compliance Receipts Profile July 2026\n\n supersedes: OPTIONAL JSON string carrying a producer-asserted\n pointer to the prior risk-acceptance receipt this one replaces,\n encoded either as an opaque receipt locator or as a sha256:<64\n lowercase hex chars> digest. The field proves that the\n supersession claim existed at issued_at; resolution is the\n verifier's job, and the issuing platform NEVER invalidates the\n prior receipt: the hash chain of Section 5.3 is immutable and\n supersedes is a forward pointer only.\n\n sarif_digest: OPTIONAL JSON string formatted sha256:<64 lowercase\n hex chars> over the producer-declared canonical bytes of the\n static-analysis (SARIF) scan artifact the acceptance rested on.\n The digest is a shape-only existence proof: it proves THAT the\n named SARIF artifact existed unaltered at issued_at and nothing\n more. The issuing platform NEVER parses, fetches, re-runs, or\n validates the scan; a verifier recomputes SHA-256 over the SARIF\n bytes retained in the Audit Pack and treats a mismatch as a tamper\n signal, in the same manner as config_manifest_digest of\n Section 5.7.\n\n finding_ref: OPTIONAL JSON string carrying a producer-asserted\n opaque pointer to the specific finding or rule identifier inside\n the SARIF artifact (for example a ruleId plus a location). The\n field is free-text; it proves the reference existed at issued_at\n and is never resolved or validated by the issuing platform.\n\n approval_ref: OPTIONAL JSON string carrying a producer-asserted\n opaque correlation pointer to a human-in-the-loop approval\n identifier or an external ticket. The field is free-text; it\n proves the correlation pointer existed at issued_at and is never\n resolved or validated by the issuing platform.\n\n risk_snapshot: OPTIONAL object carrying a point-in-time snapshot of\n THIRD-PARTY risk signals as the producer read them, with members:\n snapshot_at (REQUIRED ISO 8601 timestamp with explicit timezone,\n the producer-asserted read-time the snapshot is pinned to),\n snapshot_source (REQUIRED free-text string naming where the\n signals came from, for example a named EPSS feed, the CISA KEV\n catalog, or an NVD CVSS record), epss (OPTIONAL string), cvss\n (OPTIONAL string), cvss_vector (OPTIONAL string), kev_listed\n (OPTIONAL boolean), and cve_ids (OPTIONAL JSON array of CVE-\n identifier strings). The object is a producer-asserted snapshot,\n NOT a value the issuing platform computed, fetched, verified,\n queried, or vouched for; it proves only that the producer asserted\n these signals at snapshot_at, and is explicitly NOT reproducible\n from any input the issuing platform holds. A verifier MUST NOT\n read any member as an issuing-platform-derived or verified score.\n All numeric risk signals (epss, cvss) MUST be encoded as JSON\n\nGomes Marques Expires 21 January 2027 [Page 30]\nInternet-Draft Compliance Receipts Profile July 2026\n\n strings, not as JSON numbers, consistent with the IEEE-754 float\n prohibition of Section 4; this string encoding is load-bearing for\n the snapshot-not-score semantics. Whenever any of epss, cvss,\n cvss_vector, or kev_listed is populated, snapshot_source MUST be\n present; a populated numeric or KEV signal without snapshot_source\n MUST be rejected at signing time by the false-attestation guard\n named in Section 11.1, so that a value can never be read as an\n issuing-platform-derived score.\n\n A risk-acceptance receipt MAY additionally carry the type-agnostic\n expires_at field of Section 5.7 to declare the wall-clock time after\n which the Deployer considers the acceptance stale, and the server-\n built authorized_under_mandate field of Section 5.9. Consistent with\n Section 5.7, expires_at on a risk-acceptance receipt is declared, not\n enforced: the issuing platform records the declared expiry but NEVER\n auto-revokes an expired acceptance, and a verifier MUST NOT reject\n the originating risk-acceptance receipt itself solely because\n expires_at has elapsed. The named identities (approver_id,\n initiator_id) are bound fields; beyond the string-incoherence refusal\n of the risk_acceptance_self_approval_guard, NO separation-of-duties\n check is performed by this profile.\n\n5.11. Code-Authorship Extensions\n\n This section is normative. It defines extension fields, two of them\n REQUIRED on the type and the rest OPTIONAL, that appear inside the\n signed payload object of a receipt of type\n protectmcp:lifecycle:code_authorship (registered in Section 11.2),\n which records a producer's assertion that an agent-authored change to\n a code repository existed at a point in time. A code-authorship\n receipt is a lifecycle record, not a policy-evaluation outcome: it is\n emitted through the no-policy lifecycle path of Section 5.2, carries\n decision observation, and asserts that no policy was evaluated for\n the change. The reference cloud implementation enforces the no-\n policy rule at signing time as the\n code_authorship_requires_no_policy_decision guard, signs the type\n only on its compliance signing path (the\n code_authorship_requires_compliance_mode guard), and rejects, as the\n code_authorship_fields_require_code_authorship_receipt guard, a\n receipt of any other type that carries the fields of this section.\n The fields are covered by the upstream Section 5.6 signature scope\n under [ACTA-RECEIPTS], by the previousReceiptHash chain link of\n Section 5.3, and by the anchors timestamp of Section 5.4; taken\n together these prove only that the producer asserted these values,\n key-authored them, and chained them at the receipt's issued_at. The\n receipt proves only that the change existed, was key-authored, and\n was chained at time T. It does NOT make the change correct, safe,\n reviewed, or building: the issuing platform NEVER clones the\n\nGomes Marques Expires 21 January 2027 [Page 31]\nInternet-Draft Compliance Receipts Profile July 2026\n\n repository, never re-runs or re-diffs the change, never verifies that\n the named code exists or compiles, and never verifies the producing\n model. The scope-honesty labels in the field definitions below are\n normative and mirror the labels published in the issuing platform's\n /.well-known/governance.json wire-vocabulary surface.\n\n repo_ref: REQUIRED JSON string carrying a producer-asserted opaque\n pointer to the repository the change was authored against (for\n example a clone URL or an internal repository identifier). The\n field is free-text; it proves the reference existed at issued_at\n and is never resolved, cloned, or validated by the issuing\n platform. A code-authorship receipt that omits repo_ref MUST be\n rejected at signing time by the\n code_authorship_missing_required_field guard named in\n Section 11.1.\n\n commit_sha: REQUIRED JSON string carrying the producer-asserted\n commit identifier of the authored change (for example a Git object\n name). The field is bound into the signed bytes only: the issuing\n platform NEVER fetches the named commit, never verifies that it\n exists, and never verifies its contents. It proves only that the\n producer asserted this commit identifier at issued_at. A code-\n authorship receipt that omits commit_sha MUST be rejected at\n signing time by the same guard as repo_ref.\n\n base_sha: OPTIONAL JSON string carrying the producer-asserted base\n commit identifier the change was authored on top of. Like\n commit_sha, the field is bound into the signed bytes only and is\n NEVER fetched or verified by the issuing platform; it proves only\n that the producer asserted this base at issued_at.\n\n change_digest: OPTIONAL JSON string formatted sha256:<64 lowercase\n hex chars> over the producer-declared canonical bytes of the\n change (for example a unified diff). The digest is a shape-only\n existence proof: it proves THAT the named change existed unaltered\n at issued_at and nothing more. The issuing platform NEVER\n fetches, re-diffs, or re-computes the change; a verifier\n recomputes SHA-256 over the change bytes retained in the Audit\n Pack and treats a mismatch as a tamper signal, in the same manner\n as sarif_digest of Section 5.10 and config_manifest_digest of\n Section 5.7. A change_digest value outside the sha256:<64\n lowercase hex chars> wire form MUST be rejected at signing time by\n the change_digest_not_sha256_wire_form guard.\n\n change_ref: OPTIONAL JSON string carrying a producer-asserted opaque\n\nGomes Marques Expires 21 January 2027 [Page 32]\nInternet-Draft Compliance Receipts Profile July 2026\n\n pointer to the change as a unit (for example a pull-request or\n merge-request identifier). The field is free-text; it proves the\n reference existed at issued_at and is never resolved or validated\n by the issuing platform.\n\n change_approval_ref: OPTIONAL JSON string carrying a producer-\n asserted opaque correlation pointer to a human-in-the-loop\n approval identifier or an external review ticket for the change.\n The field is free-text; it proves the correlation pointer existed\n at issued_at and is never resolved or validated by the issuing\n platform, in the same manner as approval_ref of Section 5.10.\n\n change_class: OPTIONAL JSON string drawn from the closed vocabulary\n read, write, delete, execute, or deploy, declaring the producer-\n asserted class of the change. The value is self-declared; the\n issuing platform records it but does NOT verify that the change\n matches the declared class. A value outside the closed vocabulary\n MUST be rejected at signing time, the field being constrained to\n the closed vocabulary.\n\n authored_by: OPTIONAL object carrying a producer-asserted\n description of the authoring agent, with members: agent_id\n (OPTIONAL string identifying the authoring agent), model_id\n (OPTIONAL string naming the model), model_version (OPTIONAL string\n naming the model version), tool (OPTIONAL string naming the\n authoring tool), and attestation_source (OPTIONAL string naming\n where the authorship description came from). The object is\n producer-asserted, NOT a value the issuing platform computed,\n verified, queried, or vouched for; it proves only that the\n producer asserted these values at issued_at. The issuing platform\n NEVER verifies the named model. Whenever any of model_id or\n model_version is populated, attestation_source MUST be present; a\n populated model field without attestation_source MUST be rejected\n at signing time by the false-attestation guard named in\n Section 11.1, so that a model claim can never be read as an\n issuing-platform-verified attestation.\n\n A code-authorship receipt MAY additionally carry the server-built\n authorized_under_mandate field of Section 5.9 to record the self-\n declared authorizing mandate the change was signed under; this\n profile reuses that field for code-authorship authorization and does\n not define a separate authorization field. Consistent with\n Section 5.9, authorized_under_mandate asserts self-declared issuer\n authority only and is NEVER an issuing-platform attestation of\n verified third-party authorization.\n\nGomes Marques Expires 21 January 2027 [Page 33]\nInternet-Draft Compliance Receipts Profile July 2026\n\n5.12. Threat-Framework Taxonomy Extensions\n\n This section is normative. It defines six OPTIONAL caller-supplied\n taxonomy fields, one OPTIONAL caller-supplied opaque timestamp token,\n and one platform-set false-attestation guard boolean, all of which\n MAY appear inside the signed payload object. The six taxonomy fields\n record producer-asserted mappings of the Action into established\n threat-and-control catalogues; they are self-declared and are NOT\n verified by the issuing platform. The guard boolean exists so that a\n verifier can tell a self-declared classification apart from a\n platform-verified one. All eight fields are covered by the upstream\n Section 5.6 signature scope under [ACTA-RECEIPTS], and an\n implementation MAY emit any subset.\n\n mitre_techniques: OPTIONAL JSON array of MITRE ATT&CK technique\n identifiers (for example T1059, T1078) self-declared by the\n producer. The values are referenced by identifier from the MITRE\n ATT&CK enterprise matrix. The field is not verifier-checked by\n the issuing platform; when the array is populated the issuing\n platform MUST set framework_mappings_self_declared to true.\n\n mitre_atlas: OPTIONAL JSON array of MITRE ATLAS identifiers (for\n example AML.T0051) covering AI-system-specific adversary\n techniques, self-declared by the producer and referenced by\n identifier from the MITRE ATLAS catalogue. When populated the\n issuing platform MUST set framework_mappings_self_declared to\n true.\n\n owasp_llm_top10: OPTIONAL JSON array of OWASP Top 10 for LLM\n Applications identifiers (for example LLM01, LLM02), self-declared\n by the producer and referenced by identifier from the OWASP Top 10\n for LLM Applications publication. When populated the issuing\n platform MUST set framework_mappings_self_declared to true.\n\n nist_ai_rmf: OPTIONAL JSON array of NIST AI Risk Management\n Framework function identifiers and subcategories (for example\n GOVERN-1.1, MEASURE-2.7), self-declared by the producer and\n referenced from [NIST-AI-RMF]. When populated the issuing\n platform MUST set framework_mappings_self_declared to true.\n\n iso_42001: OPTIONAL JSON array of ISO/IEC 42001:2023 control\n identifiers (for example A.6.2.6), self-declared by the producer\n and referenced from ISO/IEC 42001:2023. When populated the\n issuing platform MUST set framework_mappings_self_declared to\n true.\n\n eu_ai_act_articles: OPTIONAL JSON array of EU AI Act article\n\nGomes Marques Expires 21 January 2027 [Page 34]\nInternet-Draft Compliance Receipts Profile July 2026\n\n identifiers (for example Article-12, Article-15), self-declared by\n the producer and referenced from [EU-AI-ACT]. When populated the\n issuing platform MUST set framework_mappings_self_declared to\n true.\n\n rfc3161_timestamp: OPTIONAL JSON string carrying a base64-encoded\n [RFC3161] TimeStampResp (DER) supplied by the producer at signing\n time and preserved verbatim on the receipt for offline TSA chain\n verification independent of any platform-issued anchors. The\n payload entry is an opaque caller-supplied token, NOT the per-\n receipt anchor produced by the platform under Section 5.4; the\n base64 encoding is per [RFC4648]. This field does not flip\n framework_mappings_self_declared.\n\n framework_mappings_self_declared: OPTIONAL JSON boolean false-\n attestation guard set by the issuing platform. The platform MUST\n set it to true whenever any of mitre_techniques, mitre_atlas,\n owasp_llm_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is\n populated. A producer-supplied value of false alongside a\n populated taxonomy field MUST be overridden by the issuing\n platform, in the same spirit as the false-attestation guards of\n Section 5.9 and the witness_policy quorum guard of Section 5.4.\n The guard does not assert that the self-declared mappings are\n correct; it asserts only that they are self-declared rather than\n platform-verified, and a verifier MUST NOT treat a populated\n taxonomy field as platform-verified.\n\n The eight fields are type-agnostic and MAY appear on any receipt type\n defined by this profile.\n\n6. European Union Bindings\n\n6.1. EU AI Act Article 12 Binding\n\n Each subsection cites the operative phrase of Article 12 and binds it\n to the receipt field that satisfies it.\n\n6.1.1. Article 12(1), automatic recording of events\n\n Article 12(1) requires High-Risk AI Systems to technically allow for\n the automatic recording of events (logs) over the lifetime of the\n system. The signed-receipt format provides one mechanism that\n satisfies that logging capability; alternative mechanisms remain\n valid. Where this profile is chosen, a Compliance Receipt SHOULD be\n produced for every Action against an external resource, and a\n configuration change that disables receipt generation SHOULD be\n recorded as a protectmcp:lifecycle Compliance Receipt.\n Implementations MAY emit at finer or coarser granularity so long as\n\nGomes Marques Expires 21 January 2027 [Page 35]\nInternet-Draft Compliance Receipts Profile July 2026\n\n the log set, taken together, satisfies Article 12(2)(a) through (c).\n\n6.1.2. Article 12(2)(a), identifying situations that may result in the\n high-risk AI system presenting a risk within the meaning of\n Article 79(1) or in a substantial modification\n\n The combination of type, decision, reason, and policy_digest MUST be\n sufficient for an auditor to identify, by query alone, receipts that\n correspond to risk situations enumerated in the Deployer's risk\n management documentation. Where the Deployer classifies an Action as\n risk-bearing, the receipt MUST carry a risk_class extension field.\n\n6.1.3. Article 12(2)(b), facilitating the post-market monitoring\n referred to in Article 72\n\n The hash-chain linkage required by Section 5.3 satisfies post-market\n monitoring traceability. The chain head MUST be made available to\n the Provider and to the competent authority on request.\n\n6.1.4. Article 12(2)(c), monitoring the operation of high-risk AI\n systems referred to in Article 26(5)\n\n Any change to the policy artefact referenced by policy_digest MUST\n produce a new digest. A change in policy_digest between two\n otherwise-comparable Actions may be examined by the Deployer or by a\n regulator as a candidate substantial-modification event under Article\n 43, and MUST be retained at least as long as the longest receipt in\n the chain that references either digest.\n\n6.1.5. Retention\n\n Article 12 itself sets no retention period; the operative deployer\n floor is Article 26(6) ("at least six months"). The parallel\n provider floor in Article 19(1) sets the same six-month minimum on\n Providers; this profile's retention bindings are written from the\n Deployer perspective, and a Provider that wishes to use Compliance\n Receipts as its Article 19(1) record SHOULD adopt the Deployer floor\n explicitly through a separate Provider-role binding (deferred to a\n future revision).\n\nGomes Marques Expires 21 January 2027 [Page 36]\nInternet-Draft Compliance Receipts Profile July 2026\n\n EU AI Act Article 26(6) requires six months of logs (interpreted as\n 184 days when expressed as a day-count floor for hash-chain anchoring\n intervals). The normative requirement on Compliance Receipts is:\n implementations MUST retain receipts until the later of (a) the day\n six calendar months after the date of the Action, computed calendar-\n arithmetically per [ISO8601-2] duration arithmetic, and (b) any\n longer Union or national law floor. The six-month period is read\n calendar-month-wise (the receipt expiry day is the same day-of-month\n six months later, with end-of-month rollover where the target month\n is shorter), not as a fixed day count.\n\n The 184-day figure (the maximum number of days in any rolling six-\n calendar-month window, worst case Aug-Jan, 31+30+31+30+31+31) is\n informative only; it expresses a safe day-count floor for hash-chain\n anchoring intervals and Audit Pack export windows where calendar-\n arithmetic is impractical at the producer layer. A Deployer that\n retains receipts strictly under the calendar-month rule above\n satisfies Article 26(6); a Deployer that uses 184 days as an internal\n day-count overestimate also satisfies it. A 183-day day-count floor\n is not endorsed by this profile: under a rolling six-calendar-month\n window 1 August to 31 January spans 184 days and 183 days is one day\n short. Where the Deployer is also a Financial Entity, the sectoral\n floor in Section 6.3.4 applies.\n\n6.2. EU AI Act Article 26 Binding\n\n6.2.1. Article 26(1), in accordance with the instructions for use\n\n policy_digest MUST resolve through Section 8 to a retained artefact\n (machine check). The Deployer SHOULD demonstrate consistency with\n the Provider's instructions for use (process check). Inability to\n perform the machine check is presumed non-compliance.\n\n6.2.2. Article 26(2), assign human oversight\n\n For any Action whose decision is allow and which the Deployer's risk\n management documentation marks as requiring human oversight, the\n Deployer MUST ensure that the receipt is either reviewed by a\n designated natural person within the period required by national law,\n or that a follow-on protectmcp:lifecycle Compliance Receipt records\n the absence of such review with a reason code. Both records MUST\n themselves be Compliance Receipts. This profile addresses the\n trigger and record of oversight; the competence, training, authority,\n and necessary support of the reviewer required by Article 26(2)\n remain the Deployer's separate responsibility.\n\nGomes Marques Expires 21 January 2027 [Page 37]\nInternet-Draft Compliance Receipts Profile July 2026\n\n6.2.3. Article 26(5), monitor the operation\n\n A Deployer MUST be able to produce an Audit Pack covering any\n contiguous time window since the High-Risk AI System became\n operational.\n\n6.2.4. Article 26(6), keep the logs for at least six months\n\n Compliance Receipts under this binding MUST be retained for at least\n the period stated in Section 6.1.5. Where the Deployer is also a\n Financial Entity, the longer sectoral floor in Section 6.3.4 applies.\n\n6.3. DORA Article 17 Binding\n\n6.3.1. Article 17(1), ICT-related incident management process\n\n A Compliance Receipt produced inside a Financial Entity's ICT\n environment may serve as the canonical record of an Action that\n triggered an ICT-related incident. action_ref MUST be carried into\n the Financial Entity's incident workflow as the primary correlation\n key.\n\n6.3.2. Article 17(2), record all ICT-related incidents and significant\n cyber threats\n\n The hash chain required by Section 5.3 supports the recording\n obligation of Article 17(2) by making after-the-fact alteration of\n recorded incidents detectable. The Financial Entity MUST be able to\n produce, on request, the chain segment covering the period of an\n incident, together with the anchor evidence that fixes the chain to\n wall-clock time.\n\n6.3.3. Article 17(3)(b), establish procedures to identify, track, log,\n categorise and classify ICT-related incidents\n\n For Actions identified as part of an ICT-related incident, the\n producing system MUST emit incident_class. The classification\n criteria are those set out in Article 18(1) of [DORA], with further\n specification in [REG-2024-1772]. The canonical reporting\n enumeration to which incident_class flattens is bound by Annex II\n field 3.23 of [REG-2025-302] (see Section 5.5). Implementations MUST\n publish a flattened mapping in the Audit Pack manifest as required by\n Section 5.5.\n\nGomes Marques Expires 21 January 2027 [Page 38]\nInternet-Draft Compliance Receipts Profile July 2026\n\n6.3.4. Retention\n\n Article 17 of [DORA] does not itself set a uniform numeric retention\n floor. The five-year (1827-day) figure used by this profile derives\n from sectoral instruments that overlap DORA-scoped Financial\n Entities. Investment firms keep records of all services, activities\n and transactions under Article 16(6) of [MIFID2], with Article 72 and\n Annex I of [REG-2017-565] fixing the form and content of those\n records. The explicit five-year retention period in [MIFID2] is set\n by Article 16(7) for records of telephone conversations and\n electronic communications, kept for a period of five years and, where\n requested by the competent authority, for a period of up to seven\n years.\n\n Records of customer due diligence and of transactions under Article\n 40 of [AMLD] are kept for five years after the end of the business\n relationship. The AMLD record-keeping regime is superseded, in\n respect of record retention, by Article 77 of [AMLR] from 10 July\n 2027, which preserves the five-year floor and adds a case-by-case\n extension up to a further five years where the competent authority so\n requires. Implementations operating across the AMLD-to-AMLR\n transition MUST satisfy whichever instrument is in force on the date\n of the Action.\n\n Compliance Receipts MUST be retained for the period required by\n applicable Union or national law; where a sectoral floor applies,\n retention MUST equal or exceed the longest applicable floor. Absent\n a more specific rule, this profile RECOMMENDS 1827 days from the date\n of the Action (the worst-case rolling five-calendar-year window\n contains two leap days, so 1827 days satisfies "five years"\n regardless of the calendar years over which the window falls).\n Anchor evidence MUST be retained for the same period. Verification\n keys whose lifetime expires within the retention window MUST have\n their public components retained so that historical signatures remain\n verifiable.\n\n7. United States Bindings\n\n7.1. NIST AI RMF Binding\n\n [NIST-AI-RMF] is a voluntary framework. Adoption of this profile, on\n its own, does not establish conformity with the AI RMF; it provides a\n tamper-evident receipt substrate that an AI RMF program can use as\n evidence under the MEASURE function and as a structured input to the\n GOVERN, MAP, and MANAGE functions. [NIST-GENAI-PROFILE] applies the\n AI RMF functions to generative AI; the profile bindings below apply\n to generative and non-generative AI agent deployments alike unless\n explicitly noted.\n\nGomes Marques Expires 21 January 2027 [Page 39]\nInternet-Draft Compliance Receipts Profile July 2026\n\n7.1.1. GOVERN function\n\n The GOVERN function requires that organizations document AI policies\n and procedures. The combination of policy_digest and the Audit Pack\n manifest provides a machine-readable binding between every Action and\n the policy artefact in force at the time of the Action. A change to\n the policy artefact MUST produce a new policy_digest value (per\n Section 5.2.2); the Audit Pack therefore records every policy change\n in a tamper-evident manner.\n\n7.1.2. MAP function\n\n The MAP function requires that the context, capabilities, and risks\n of an AI system be characterised. The combination of type,\n tool_name, action_ref, and iteration_id SHOULD be sufficient for an\n auditor to reconstruct the operational context of any Action without\n dereferencing the underlying payload.\n\n7.1.3. MEASURE function\n\n The MEASURE function requires that AI risks and impacts be analysed\n and tracked over time. The hash-chain linkage required by\n Section 5.3 provides tamper-evident continuity of the receipt stream\n over the AI system's operational lifetime, satisfying the\n traceability prerequisite of MEASURE.\n\n7.1.4. MANAGE function\n\n The MANAGE function requires that AI risks be prioritised and acted\n upon based on projected impact. The risk_class extension field\n carries the Deployer's risk classification of the Action; together\n with decision, reason, and policy_digest, it supports prioritisation\n and incident response without requiring the verifier to re-derive\n risk from the underlying payload.\n\n7.2. Colorado AI Act (SB 24-205) Binding\n\n [COLORADO-AI-ACT] imposes deployer obligations effective June 30,\n 2026 (per Senate Bill 25B-004, which postponed the original February\n 1, 2026 effective date). The Act regulates the deployment of High-\n Risk AI Systems and the prevention of algorithmic discrimination.\n\nGomes Marques Expires 21 January 2027 [Page 40]\nInternet-Draft Compliance Receipts Profile July 2026\n\n7.2.1. Section 6-1-1703(2), risk management policy and program\n\n Section 6-1-1703(2) requires deployers to implement a risk management\n policy and program for the High-Risk AI System. policy_digest MUST\n resolve through Section 8 to the deployer's risk management policy\n artefact in force at the time of the Action. Where the Deployer\n classifies an Action as risk-bearing under that policy, the receipt\n MUST carry a risk_class extension field.\n\n7.2.2. Section 6-1-1703(3), impact assessment\n\n Section 6-1-1703(3) requires deployers to complete an impact\n assessment annually and within 90 days after any intentional and\n substantial modification of the High-Risk AI System. The combination\n of type, policy_digest, and previousReceiptHash MUST be sufficient\n for an auditor to identify, by query alone, the receipts that span\n the period covered by an impact assessment, including any policy\n changes within that period.\n\n7.2.3. Section 6-1-1703(7), notice of algorithmic discrimination\n\n Where a Deployer determines that a High-Risk AI System has caused or\n is reasonably likely to have caused algorithmic discrimination, the\n producing system SHOULD record that determination as a\n protectmcp:lifecycle Compliance Receipt naming the determination, the\n affected receipts by action_ref, and the policy or risk-management\n response with a reason code.\n\n7.3. Texas Responsible AI Governance Act (HB 149) Binding\n\n [TEXAS-TRAIGA] takes effect January 1, 2026. The Act adopts an\n intent-based liability framework for the development and deployment\n of AI systems and provides a safe harbor at Section 552.105(e)(2)(D)\n of the Texas Business and Commerce Code for organisations that\n substantially comply with the most recent version of\n [NIST-GENAI-PROFILE], or another nationally or internationally\n recognized risk management framework for AI systems, and operate an\n internal review process.\n\n7.3.1. Safe-harbor evidentiary support\n\n Where a Deployer relies on the safe-harbor provision of HB 149 by\n substantially complying with [NIST-GENAI-PROFILE], the Audit Pack MAY\n be presented as evidence of that compliance. The bindings of\n Section 7.1 apply, with the additional Generative AI Profile bindings\n of [NIST-GENAI-PROFILE].\n\nGomes Marques Expires 21 January 2027 [Page 41]\nInternet-Draft Compliance Receipts Profile July 2026\n\n7.3.2. Prohibited-use detection\n\n Receipts whose decision is deny with a reason code drawn from a\n vocabulary documenting the Act's prohibited-use categories under\n Section 552.052 of the Texas Business and Commerce Code added by HB\n 149 (incitement or encouragement of physical self-harm including\n suicide, harm to another person, or engagement in criminal activity)\n MUST be retained for the period stated in Section 7.4.2 or the longer\n period required by Texas law, whichever is greater.\n\n7.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart C)\n\n [HIPAA-SECURITY] applies to Covered Entities (HIPAA) that handle\n electronic protected health information. The bindings below apply\n only to receipts whose underlying Actions reference electronic\n protected health information.\n\n7.4.1. 45 CFR 164.312(b), audit controls\n\n 45 CFR 164.312(b) requires implementation of "hardware, software,\n and/or procedural mechanisms that record and examine activity in\n information systems that contain or use electronic protected health\n information". The combination of type, action_ref, tool_name, and\n the hash-chain linkage required by Section 5.3 satisfies the\n recording requirement; the verification rules of Section 9.1 satisfy\n the examination requirement.\n\n7.4.2. 45 CFR 164.316(b)(2), six-year retention\n\n 45 CFR 164.316(b)(2) (and in particular the subparagraph\n 164.316(b)(2)(i)) requires that the documentation required by 45 CFR\n 164.316(b)(1) be retained "for 6 years from the date of its creation\n or the date when it last was in effect, whichever is later". The\n audit-log content produced under 45 CFR 164.312(b) is not itself\n documentation required by 164.316(b)(1); the Security Rule does not\n set an explicit retention floor for individual audit-log records. By\n analogy with the six-year floor that 164.316(b)(2) places on the\n policies and procedures that govern audit-log generation, this\n profile applies the same six-year floor to Compliance Receipts whose\n underlying Actions reference electronic protected health information.\n\n Records covered by the HIPAA Security Rule audit-trail retention MUST\n be retained for six years from the date of creation or the date when\n last in effect, whichever is later, per 45 CFR 164.316(b)(2). This\n profile expresses that floor as 2192 days from the later of (a) the\n date of the Action and (b) the date the policy artefact referenced by\n policy_digest ceased to be in effect: 2192 is the maximum number of\n days in any rolling six-calendar-year window (worst case spans two\n\nGomes Marques Expires 21 January 2027 [Page 42]\nInternet-Draft Compliance Receipts Profile July 2026\n\n leap days, e.g. 2024-2030 contains February 29 of 2024 and 2028,\n yielding 6*365+2 = 2192 days). The six-year analogy floor is\n grounded in 164.316(b)(2); a Covered Entity that retains receipts\n strictly under 164.316(b)(2)(i) bound only to the policy artefact's\n creation-or-cessation date MAY do so when no longer audit-log floor\n is established by separate Union, state, or sectoral law.\n Verification keys whose lifetime expires within the retention window\n MUST have their public components retained so that historical\n signatures remain verifiable.\n\n7.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500)\n\n [NYDFS-500] applies to Covered Entities (NYDFS) operating under New\n York Banking, Insurance, or Financial Services Law. The bindings\n below apply only to receipts produced by such Covered Entities.\n\n7.5.1. 23 NYCRR 500.6, audit trail\n\n 23 NYCRR 500.6(a) requires Covered Entities to securely maintain\n systems that, to the extent applicable and based on its risk\n assessment, (1) are designed to reconstruct material financial\n transactions, and (2) include audit trails designed to detect and\n respond to cybersecurity events that have a reasonable likelihood of\n materially harming any material part of the normal operations of the\n Covered Entity. The hash chain required by Section 5.3 together with\n the anchor evidence required by Section 5.4 satisfies the tamper-\n evidence prerequisite of the audit-trail obligation.\n\n7.5.2. 23 NYCRR 500.17, notices to superintendent\n\n 23 NYCRR 500.17(a)(1) requires that "Each covered entity shall notify\n the superintendent electronically in the form set forth on the\n department's website as promptly as possible but in no event later\n than 72 hours after determining that a cybersecurity incident has\n occurred at the covered entity, its affiliates, or a third-party\n service provider." The reporting trigger is a Cybersecurity Incident\n under 23 NYCRR 500.1(g), not any Cybersecurity Event under 500.1(f).\n For Actions identified as part of such an Incident, the producing\n system MUST emit incident_class with a value indicating Cybersecurity\n Incident under 23 NYCRR 500.1(g), and the Covered Entity MUST be able\n to produce, on request, the chain segment covering the period of the\n Incident together with the anchor evidence that fixes the chain to\n wall-clock time.\n\nGomes Marques Expires 21 January 2027 [Page 43]\nInternet-Draft Compliance Receipts Profile July 2026\n\n7.5.3. 23 NYCRR 500.6 retention\n\n 23 NYCRR 500.6(b) requires that "Each Covered Entity shall maintain\n records required by this section for not fewer than five years." The\n five-year floor applies uniformly to records required by paragraph\n (a)(1) (designed to reconstruct material financial transactions) and\n to records required by paragraph (a)(2) (audit trails designed to\n detect and respond to cybersecurity events that have a reasonable\n likelihood of materially harming any material part of the normal\n operations of the Covered Entity). Compliance Receipts produced\n under this binding MUST be retained for at least 1827 days from the\n date of the Action (the worst-case rolling five-calendar-year window\n contains two leap days).\n\n7.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4)\n\n [SEC-17A-4] applies to Broker-Dealers, Security-Based Swap Dealers,\n and Major Security-Based Swap Participants. The bindings below apply\n only to receipts produced inside such entities.\n\n7.6.1. 17 CFR 240.17a-4(f), electronic recordkeeping system\n\n The November 3, 2022 amendments to 17 CFR 240.17a-4 (compliance date\n May 3, 2023) added an audit-trail alternative to the prior write-\n once-read-many (WORM) electronic recordkeeping requirement. The\n audit-trail alternative requires that the electronic recordkeeping\n system permit the recreation of an original record if it is modified\n or deleted. The hash-chain linkage required by Section 5.3 together\n with the retention rule in Section 7.6.2 and the anchor evidence\n required by Section 5.4 satisfies the audit-trail alternative when\n the Compliance Receipt is the system-of-record for a regulated\n record.\n\n7.6.2. 17 CFR 240.17a-4(a) and (b) retention\n\n 17 CFR 240.17a-4(a) requires preservation of certain records for not\n less than 6 years, the first two years in an easily accessible place.\n 17 CFR 240.17a-4(b) requires preservation of a different list of\n records for not less than three years, the first two years in an\n easily accessible place. Compliance Receipts that constitute or\n support a record listed in 17 CFR 240.17a-4(a) MUST be retained for\n at least 2192 days from the date of the Action, applying the same\n six-year worst-case methodology as Section 7.4.2; receipts that\n constitute or support a record listed only in 17 CFR 240.17a-4(b)\n MUST be retained for at least 1096 days from the date of the Action\n (the worst-case rolling three-calendar-year window contains one leap\n day). Where both apply, the longer period applies.\n\nGomes Marques Expires 21 January 2027 [Page 44]\nInternet-Draft Compliance Receipts Profile July 2026\n\n7.7. CIRCIA Binding (Cyber Incident Reporting for Critical\n Infrastructure Act of 2022)\n\n [CIRCIA] requires Covered Entities (CIRCIA) to report Covered Cyber\n Incidents to the Cybersecurity and Infrastructure Security Agency\n within 72 hours of reasonable belief that the incident has occurred,\n and to report ransom payments within 24 hours. The reporting\n obligations take effect upon publication of the final rule. Pending\n publication, the bindings below apply on a voluntary basis.\n\n7.7.1. Covered Cyber Incident reporting support\n\n For Actions identified as part of a Covered Cyber Incident, the\n producing system MUST emit incident_class with a value indicating\n Covered Cyber Incident under [CIRCIA]. The Covered Entity MUST be\n able to produce, on request, the chain segment covering the period of\n the incident together with the anchor evidence that fixes the chain\n to wall-clock time.\n\n7.7.2. Records related to a Covered Cyber Incident report\n\n Section 2242(a)(4) of the Homeland Security Act of 2002, as enacted\n by [CIRCIA] and codified at 6 U.S.C. 681b(a)(4), requires Covered\n Entities to preserve data relevant to a Covered Cyber Incident or\n ransom payment in accordance with procedures established in the final\n rule. CISA's notice of proposed rulemaking at 89 FR 23644 (April 4,\n 2024), proposed Section 226.13(c), proposes a preservation period of\n not less than two years measured from the submission of the most\n recently required CIRCIA report (or the date that submission would\n have been required absent a preservation exception under proposed\n Section 226.4(a)); this profile uses that proposed floor pending\n publication of the final rule.\n\n Records covered by CIRCIA preservation MUST be retained for two years\n from the submission of the most recently required CIRCIA report under\n 6 U.S.C. 681b(c)(2). Compliance Receipts that are referenced in a\n CIRCIA report or that the Covered Entity reasonably anticipates will\n be so referenced MUST be retained for the longer of (a) the period\n established by the final rule and (b) two years from the submission\n of the most recently required CIRCIA report (or the date that\n submission would have been required absent a preservation exception),\n per proposed Section 226.13(c) of the CIRCIA NPRM at 89 FR 23644\n (April 4, 2024). Covered Entities MUST NOT measure the retention\n floor from the date of the underlying Action; an Action detected and\n reported months later carries a preservation window that runs forward\n from the report submission date.\n\nGomes Marques Expires 21 January 2027 [Page 45]\nInternet-Draft Compliance Receipts Profile July 2026\n\n8. Audit Pack Composition\n\n This section is informative. It describes the contents of an Audit\n Pack as introduced in Section 2.\n\n An Audit Pack contains the following items.\n\n * The set of Compliance Receipts covered by the requested time\n window, in the canonical envelope form defined by [ACTA-RECEIPTS].\n\n * The chain commitments that link the receipts: for each receipt,\n the value of previousReceiptHash and the recomputed digest of the\n predecessor envelope.\n\n * The anchor evidence: [RFC3161] tokens, OpenTimestamps proofs, or\n both. Each anchor item MUST be associated, by hash, with the\n receipt or aggregate it covers.\n\n * The trust anchor metadata that identifies the Deployer or other\n regulated entity associated with each issuer_id value.\n\n * The verification key material for every kid value present, in a\n form that does not require online retrieval.\n\n * Vocabularies referenced by reason, risk_class, incident_class, and\n extension fields, embedded as JSON arrays with a stable\n identifier. The Audit Pack MUST expose a digest-resolution\n facility that, given a policy_digest, returns the retained\n artefact.\n\n * A regime mapping document that names which receipts the producer\n asserts as evidence under any of the regimes addressed by Sections\n 5 and 6 of this document (EU AI Act Article 12, EU AI Act Article\n 26, DORA Article 17, NIST AI RMF, Colorado AI Act, Texas\n Responsible AI Governance Act, NYDFS Part 500, HIPAA Security\n Rule, SEC Rule 17a-4, CIRCIA).\n\n * The chain heads valid at the start and end of the time window,\n signed by the Deployer or other regulated entity.\n\n An Audit Pack MUST itself be signed per the [ACTA-RECEIPTS] algorithm\n registry. The manifest MUST include bundle_digest, bundle_signature,\n bundle_public_key, and algorithm_registry_version.\n\n The following manifest-level fields SHOULD appear on an Audit Pack\n bundle when the underlying receipt stream exposes the corresponding\n semantics. Each is informative and does not alter the wire shape of\n individual receipts.\n\nGomes Marques Expires 21 January 2027 [Page 46]\nInternet-Draft Compliance Receipts Profile July 2026\n\n regime_mapping_disclaimer: String emitted on bundles whose per-\n receipt regime predicates derive from mapping logic the original\n producing system did not sign. The value identifies the producer\n of the mapping, the document version under which it was computed,\n and a disclaimer that the regime-satisfaction flags are advisory\n and remain subject to the verifier's own check against Sections 5\n and 6.\n\n stale_pending: Boolean flag set per bundle entry whose anchor\n evidence is still pending after the bound of Section 5.4 (7 days\n for OpenTimestamps; synchronous for RFC 3161). When true, the\n bundled receipt is non-conformant per Section 5.4, and a\n Compliance Verifier consumes the flag to drive anchor_valid_*\n false in its per-axis report (see Section 9.3). A verify endpoint\n over the same bundle SHOULD surface stale_pending in its response.\n\n9. Verifier Behaviour\n\n A verifier conformant to this profile is referred to as a Compliance\n Verifier.\n\n9.1. Mandatory Checks\n\n A Compliance Verifier MUST perform all of the following checks before\n treating a receipt as a Compliance Receipt.\n\n * Verify the signature using the algorithm declared in\n signature.alg, in accordance with [ACTA-RECEIPTS].\n\n * Resolve the verification key through one of the key-distribution\n mechanisms described in Section 4.3 of [ACTA-RECEIPTS] (well-known\n JWK Set or out-of-band distribution), or through Audit Pack trust-\n anchor metadata. The verifier MUST NOT trust a verification key\n embedded in the receipt envelope.\n\n * Verify that all fields marked REQUIRED by Section 5 are present\n and well-formed.\n\n * Verify the hash-chain linkage by recomputing SHA-256 over the\n canonical signing-input bytes of the immediately preceding receipt\n (the JCS-canonical serialization of the predecessor's signed\n payload object, per Section 5.3) and comparing the lowercase hex\n encoding to previousReceiptHash.\n\nGomes Marques Expires 21 January 2027 [Page 47]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * Verify at least one anchor: an [RFC3161] token, an\n [OPENTIMESTAMPS] commitment, or both. The anchor MUST cover the\n signed envelope as it appears in the receipt. The verifier MUST\n cryptographically re-verify the anchor against the signed\n envelope; presence of anchor metadata without a successful\n cryptographic check MUST NOT yield "valid".\n\n * Verify the future-skew bound on issued_at per Section 5.1.2. Past\n skew MUST NOT cause non-conformance when the receipt is within\n retention.\n\n * Verify that policy_digest resolves through Section 8. A digest\n computed over a nonced or otherwise mixed-input form (for example,\n SHA-256(nonce || JCS(artefact))) MUST NOT be treated as\n policy_digest; the digest scope is the canonical form of the\n artefact alone. The verifier MUST recompute SHA-256 over the\n canonical form of the resolved artefact as documented in the Audit\n Pack manifest, and compare; for JSON artefacts the canonical form\n is JCS per [RFC8785].\n\n A receipt that fails any of these checks MUST be reported as non-\n conformant.\n\n9.2. Optional Checks\n\n A Compliance Verifier MAY additionally perform any of the following.\n\n * Cross-check the issuer_id against an external registry (LEI, EIN,\n CIK, NPI, GLEIF, or a Deployer-published list).\n\n * Resolve the policy artefact referenced by policy_digest and\n compare it to a Provider-supplied or Deployer-supplied reference\n policy.\n\n * Recompute the chain head and compare it to a Deployer-published\n value.\n\n * Validate incident_class (each element if encoded as an array) and\n risk_class extension values against the vocabularies referenced in\n the Audit Pack.\n\n9.3. Reporting\n\n A Compliance Verifier SHOULD produce a structured per-receipt report\n that names the regime bindings the receipt satisfies and the outcome\n of the per-axis checks the verifier performed. The following fields\n SHOULD be emitted; the axes are independent and consumers MUST NOT\n collapse them into a single boolean before display.\n\nGomes Marques Expires 21 January 2027 [Page 48]\nInternet-Draft Compliance Receipts Profile July 2026\n\n regimes_satisfied: Array of short stable regime identifiers drawn\n from the regimes listed in Section 8 (for example eu_ai_act, dora,\n nist_ai_rmf, colorado_ai, texas_traiga, hipaa_security, nydfs_500,\n sec_17a4a, sec_17a4b, circia). The set is open-ended; consumers\n MUST treat unknown identifiers as informational. Where this field\n is inherited from a producer-side mapping in the bundle, the\n bundle-level regime_mapping_disclaimer of Section 8 applies.\n\n anchor_valid_ots: Boolean. true when an [OPENTIMESTAMPS] anchor is\n present, has upgraded to the Bitcoin block attestation within the\n 7-day bound of Section 5.4, and re-verifies cryptographically\n against the signed envelope; otherwise false (including the case\n where the only present anchor is RFC 3161).\n\n anchor_valid_rfc3161: Boolean. true when an [RFC3161] token is\n present, carries an ESSCertIDv2 per [RFC5816] where required, and\n re-verifies cryptographically against the signed envelope;\n otherwise false.\n\n policy_digest_resolved: Boolean. true when policy_digest resolved to\n a retained artefact whose JCS-canonical SHA-256 matches the\n receipt value, per Section 9.1; false on absence, resolution\n failure, or digest mismatch.\n\n duplicate_emission_candidate: Boolean. true when at least one other\n receipt sharing action_ref and issuer_id has been observed in the\n same Audit Pack or in a verifier-maintained index; otherwise\n false. The axis is informational; this profile does not require\n verifiers to maintain a cross-receipt index. An absent index MUST\n report false rather than omit the axis, so consumers learn "no\n duplicate" from the value and learn "axis unknown" only from the\n verifier's documented capability set.\n\n A receipt may carry anchor_valid_ots=true and\n anchor_valid_rfc3161=false (or vice versa) and still satisfy the\n mandatory anchor check of Section 5.4, which requires only one valid\n anchor. Where a receipt carries counterparty_binding per\n Section 5.6, the verifier SHOULD additionally emit the outcome of the\n check of Section 5.6.3; this profile reserves a stable field\n identifier for that axis pending implementation experience.\n\n10. Security Considerations\n\n This profile inherits all of the security considerations of\n [ACTA-RECEIPTS]. The following considerations are specific to the\n compliance binding.\n\nGomes Marques Expires 21 January 2027 [Page 49]\nInternet-Draft Compliance Receipts Profile July 2026\n\n10.1. Tamper Resistance\n\n The hash-chain linkage required by Section 5.3 provides tamper-\n evidence at the chain level. An adversary who removes a receipt from\n the middle of the chain MUST recompute and re-sign every subsequent\n envelope. The anchor evidence required by Section 5.4 binds segments\n of the chain to wall-clock time, raising the cost of a re-signing\n attack.\n\n Implementations SHOULD anchor at intervals no longer than 24 hours.\n Implementations operating under DORA Article 17, 23 NYCRR 500.17, or\n [CIRCIA] SHOULD anchor at intervals no longer than one hour, given\n the four-hour initial-notice deadline (with 72-hour intermediate-\n report and one-month final-report bounds) per DORA Article 17 and the\n RTS in [REG-2025-301], the 72-hour notification clock under 23 NYCRR\n 500.17, and the 72-hour CIRCIA covered-cyber-incident reporting\n deadline that will apply once the CIRCIA final rule takes effect.\n\n A deployment that uses only the signature, without chain linkage and\n anchoring, can be rolled back by an insider with control of the\n signing key for the period between the deletion and the next anchor.\n The MUST clauses of Section 5.3 and Section 5.4 close that window.\n\n10.2. Chain Availability Under Single-Linear Per-Agent Serialization\n\n This section is informative. The single-linear per-agent chain\n requirement of Section 5.3 serializes receipt emission for a given\n issuer_id through a single predecessor pointer. A denial-of-service\n against the predecessor pointer (database row lock contention,\n network partition between the emitter and the predecessor store, slow\n IO, or an adversary deliberately holding the chain-tail lock)\n therefore bounds the per-agent emission throughput, because every new\n receipt MUST resolve the digest of the immediately prior receipt\n before it can be linked. A partial-write failure between\n predecessor-pointer commit and signature commit can additionally\n produce chain-head ambiguity if not handled defensively.\n\n Issuers SHOULD use a bounded predecessor-lookup timeout (operator-\n tuned, typically on the order of seconds rather than tens of seconds)\n and SHOULD emit a structured audit event with type\n protectmcp:lifecycle and a stable reason code (RECOMMENDED:\n chain_emission_blocked) when the timeout fires, rather than silently\n dropping the receipt or stalling caller threads. Issuers SHOULD\n additionally document a chain-head recovery procedure for crashed\n emitters: on restart, the issuer re-reads the predecessor row,\n verifies that no orphan signature exists for the next sequence\n position, and resumes emission. Operators that require parallel per-\n issuer throughput beyond what a single linear chain sustains MUST use\n\nGomes Marques Expires 21 January 2027 [Page 50]\nInternet-Draft Compliance Receipts Profile July 2026\n\n distinct issuer_id values per parallel path, with separate signing\n keys and chains rooted at the all-zero genesis value, per the rule in\n Section 5.3.\n\n The threat profile here is availability, not confidentiality or\n integrity: a successful chain-availability attack delays or drops\n emission, but it cannot tamper with already-emitted receipts (those\n are protected by Section 10.1) and it cannot forge receipts (those\n are protected by Section 10.3). The chain_emission_blocked lifecycle\n receipt is itself a Compliance Receipt and therefore links into the\n chain once emission resumes, so the gap is detectable rather than\n silent.\n\n10.3. Key Compromise\n\n A Compliance Receipt is only as trustworthy as the key that signed\n it. On suspected compromise of an issuer key, the Deployer MUST\n publish a revocation notice that names the key, the time of suspected\n compromise, and the chain head at that time. Receipts signed by the\n compromised key after the named time MUST NOT be treated as\n Compliance Receipts.\n\n Verifiers MUST consult revocation metadata supplied with the Audit\n Pack and MUST reject Compliance Receipts whose signing key was\n revoked at or before issued_at. Where the Deployer publishes its\n verification keys through a well-known JWK Set endpoint, a revoked\n key remains published and its entry carries a revoked_at timestamp,\n so that a verifier can pass a receipt issued before that instant and\n fail one issued at or after it.\n\n10.4. Retention and Long-Term Verifiability\n\n The longest retention floor in this profile is 2192 days (six\n calendar years), set by Section 7.4 and Section 7.6; the EU side has\n a parallel five-year (1827-day) floor under Section 6.3. Both exceed\n the typical operational crypto-period of a signing key under\n recommended key-management practice. Implementations SHOULD use ML-\n DSA-65 from the [ACTA-RECEIPTS] algorithm registry ([FIPS204]) for\n receipts expected to be verified after the cryptographic lifetime of\n classical signature schemes ends. Implementations MUST retain public\n key material for the entire retention window.\n\nGomes Marques Expires 21 January 2027 [Page 51]\nInternet-Draft Compliance Receipts Profile July 2026\n\n10.5. Privacy\n\n [ACTA-RECEIPTS] prohibits the inclusion of raw prompts, tool\n arguments, and credentials in the signed payload. This profile\n extends that prohibition to the extension fields defined in this\n document. The risk_class and incident_class values MUST be drawn\n from controlled vocabularies and MUST NOT carry free-text personal\n data.\n\n Where the underlying Action references a data subject, the\n payload_digest field MUST cover the data; the data itself MUST be\n held in a separate store that respects the data subject's rights\n under applicable law (including but not limited to the General Data\n Protection Regulation for EU data subjects, the California Consumer\n Privacy Act and Virginia Consumer Data Protection Act for the\n corresponding US states, and the HIPAA Privacy Rule where electronic\n protected health information is involved). A request for erasure\n that is granted under applicable data protection law MUST be\n reflected by deletion of the referenced payload, not by deletion of\n the receipt; the receipt remains as evidence that an Action occurred\n and was governed by a named policy at a named time.\n\n10.6. Anchor Trust\n\n The trust assumptions of an anchor depend on the anchor type.\n [RFC3161] timestamp tokens depend on the trust placed in the named\n Time Stamping Authority. OpenTimestamps commitments depend on the\n inclusion of the commitment in a public Bitcoin block. A Compliance\n Verifier SHOULD treat the simultaneous presence of both anchor types\n as stronger evidence than the presence of only one.\n\n10.7. Replay\n\n A Compliance Receipt is bound to a single Action via action_ref.\n Replay of a Compliance Receipt against a different Action is\n detectable by action_ref mismatch. The 300-second issued_at skew\n bound stated in Section 5.1.2 limits the window in which a freshly-\n replayed receipt can be presented as recent.\n\n Where the verifier supports it, two receipts sharing action_ref and\n issuer_id SHOULD be flagged as a candidate duplicate-emission event\n for human review. This profile does not require verifiers to\n maintain a cross-receipt index; deployers needing duplicate-emission\n detection should arrange it at the Audit Pack production layer.\n\nGomes Marques Expires 21 January 2027 [Page 52]\nInternet-Draft Compliance Receipts Profile July 2026\n\n10.8. Cross-Regime Conflict\n\n Where the same Action is in scope of more than one regime addressed\n by this document, the producing system MUST satisfy the union of the\n applicable requirements. Where a SHOULD clause in one regime\n conflicts with a MUST clause in another, the MUST clause prevails.\n Where two MUST clauses conflict, the producing system MUST refuse to\n issue the receipt and MUST log the refusal as a protectmcp:lifecycle\n Compliance Receipt.\n\n10.9. Algorithm Agility\n\n This profile inherits its algorithm registry from [ACTA-RECEIPTS].\n Implementations MUST treat the verification of a historical receipt\n according to the algorithm registry that was in force at issued_at,\n not the registry in force at the time of verification, provided that\n the signing key was not revoked.\n\n10.10. Issuer-Misrepresentation Residual\n\n Per-agent hash chains under Section 5.3 detect tampering inside a\n single issuer's stream but not the cross-agent attack in which a\n compromised intermediary silently swaps payload bytes between two\n honest agents. Both per-agent chains validate; action_ref is a\n correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS]\n Section 2.2). Without a cross-agent binding primitive, a regulator\n obtains no cryptographic answer to "did the acknowledging agent\n acknowledge the bytes the originating agent actually sent". This\n profile defines counterparty_binding (Section 5.6) as the partial\n mitigation; the following residuals remain.\n\n * Endpoint collusion. If both signing keys are compromised by the\n same attacker, the attacker produces a coordinated forgery; no\n signature scheme defends against this case.\n\n * Intermediary holds the originating agent's key. In hosted-agent\n deployments where the intermediary possesses the originating\n agent's private key, it can sign anything as either party. Remote\n attestation of key origin is the appropriate countermeasure and is\n out of scope here.\n\n * Originator offline at verification time. Section 5.6.3 requires\n the originating envelope to be retrievable; if unpublished,\n offline, or rate-limited, the binding becomes unverifiable\n (liveness loss, observable as failure).\n\nGomes Marques Expires 21 January 2027 [Page 53]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * Fan-out witness gap. When an originator broadcasts to N\n acknowledgers, each emits an independent pairwise binding; none\n witnesses any other. Append-only log profiles (future SCITT-style\n transparency) are deferred to a later revision.\n\n * Key rotation orphan. If the originating agent rotates keys after\n emission but before an acknowledger binds it, the storage\n obligation of Section 5.6.3 still requires the old envelope to\n remain retrievable; if retention discipline fails, the binding\n orphans.\n\n * Privacy of envelope hashes. envelope_hash is computed over the\n full signed bytes including A's signature; an observer of B's\n receipt learns a stable identifier for A's exact action and\n therefore can correlate B's behaviour across receipts even when\n A's payload is otherwise confidential. Where this correlation is\n unacceptable, a commitment scheme (for example, HMAC over the\n envelope with a per-counterparty key disclosed only to the\n verifier) is appropriate; this profile does not specify one.\n\n * Real-time prevention. counterparty_binding is detective, not\n preventive: B has already accepted the bytes by the time the\n binding is signed. Verifiers detect tampering only at audit time;\n the in-flight bytes were not blocked. Where prevention is\n required, transport-level integrity per Section 10.11 is the\n appropriate primitive in addition to (not instead of) this\n profile.\n\n * Payload-content semantics. The binding proves byte equality, not\n semantic equality. An intermediary that re-encodes A's bytes into\n a different but JCS-equivalent canonical form is detected (the\n SHA-256 differs); an intermediary that swaps A's bytes for\n entirely different bytes that B's policy happens to interpret as\n semantically equivalent is detected too. But an intermediary that\n swaps A's bytes for an A-signed REPLAY of a prior valid envelope\n from A is not detected by this binding alone; replay protection\n requires that the verifier also check action_ref and\n previousReceiptHash uniqueness within the chain segment.\n\n10.11. Cross-Agent Integrity Trust Boundary\n\n This section is informative. It records operator guidance for cases\n where channel-level protection is the only available defence and\n counterparty_binding per Section 5.6 has not yet been adopted by both\n endpoints. For channels between named principals, implementers\n SHOULD secure the channel using mutually authenticated TLS 1.3 per\n [RFC8446]; MAY use the tls-exporter channel binding per [RFC9266]\n derived via [RFC5705] where higher channel uniqueness is required;\n\nGomes Marques Expires 21 January 2027 [Page 54]\nInternet-Draft Compliance Receipts Profile July 2026\n\n and MAY layer HTTP Message Signatures per [RFC9421] where\n intermediaries perform legitimate transformations.\n\n Operators MUST NOT interpret transport-layer security alone as\n evidence of cross-agent byte equality. Only counterparty_binding\n produces application-layer, signed, replay-after-the-fact evidence\n answering that question. Topologies where the intermediary\n terminates TLS (CDN edges, MCP servers, message buses, orchestrators)\n defeat transport-layer integrity against the threat case of\n Section 10.10; in those topologies counterparty_binding is the only\n defence this profile offers, and the absence of channel-binding\n evidence in the Audit Pack SHOULD be documented as a known residual.\n\n10.12. Compromised Intermediary Between Two Honest Endpoints\n\n This section is informative. Where an Action travels from a sending\n agent A to a receiving agent B through one or more intermediary\n processes M, and where M is compromised in such a way that M presents\n byte sequence X to A and a different byte sequence X' to B, neither\n A's nor B's cryptographic signature detects the divergence in\n isolation: each endpoint signs the bytes it observed, and each\n endpoint's per-agent hash chain per Section 5.3 remains internally\n valid. Absent the counterparty_binding primitive this profile\n introduces, the only available cross-agent primitive is action_ref as\n a SHA-256 join key per Section 5.1.5; both A's chain and B's chain\n remain valid in isolation, and divergence is only recoverable through\n a regulator-driven post-hoc comparison of the two chains.\n\n counterparty_binding introduced in Section 5.6 closes the case where\n M silently swaps bytes between two honest endpoints A and B. An\n acknowledging receipt under this binding is REQUIRED to carry an\n envelope_hash computed over the exact byte stream B received (SHA-\n 256(A's envelope) under the digest-scope rule of Section 5.6.1). A\n verifier resolves receipt_ref to A's stored envelope, recomputes the\n digest, and compares; a mismatch indicates that the bytes B signed\n are not the bytes A signed, and the acknowledging receipt MUST be\n reported non-conformant per Section 5.6.3. The binding is detective\n rather than preventive: it does not stop M from performing the swap\n in flight, but it produces signed, replay-after-the-fact evidence\n that the swap occurred.\n\n The following residuals remain and are not closed by\n counterparty_binding alone. The list is intentionally honest about\n the audit-time, not sign-time, nature of the detective evidence: a\n verifier resolves receipt_ref to A's retained envelope and recomputes\n the digest at audit time, so any residual reasoning that depends on\n "A is not in the loop at sign time" is rhetorical, not load-bearing.\n\nGomes Marques Expires 21 January 2027 [Page 55]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * Collusion of M and B. If M and B are jointly compromised, M swaps\n the bytes in flight and B issues an acknowledging receipt carrying\n an envelope_hash computed over the altered bytes that B signs as\n if they were A's. Under counterparty_binding the audit-time\n verifier resolves receipt_ref to A's retained envelope and\n recomputes the digest, so the binding is reported non-conformant\n when A's storage is honest and reachable; M+B collusion alone does\n NOT silently succeed. M+B collusion silently succeeds only when\n the collusion ALSO extends to corrupting A's retained envelope,\n suppressing A's chain segment, or making A's storage unreachable\n to the auditor; that is, the true residual is M+B+(A's-storage\n compromise or unavailability). Operator mitigation: anchor A's\n chain on independent witnesses (combined [RFC3161] +\n [OPENTIMESTAMPS] anchors per Section 5.4, and OPTIONAL deployer-\n operated transparency logs) so that A's anchored chain-segment\n digests are independently recoverable from public evidence;\n regulator-side comparison of A's anchored chain against B's stored\n chain detects the divergence even when A's local storage is\n impeached.\n\n * Collusion of M and A. If M and A are jointly compromised, A signs\n a fabricated envelope at M's direction and M relays it to B; B\n verifies M's relay normally, B's counterparty_binding correctly\n digests the bytes A signed, A's per-agent chain validates, and B's\n per-agent chain validates. Every cryptographic invariant in this\n profile holds because the binding correctly attests that the bytes\n B received were the bytes A signed; the fraud is in A's intent,\n not in any byte mismatch. This residual is fundamentally outside\n the receipt model's threat surface: no application-layer\n cryptographic primitive in this profile distinguishes a fraudulent\n A-signed envelope from an honest A-signed envelope when M is also\n colluding to corroborate plausibility (relay logs, timestamping,\n message ordering). Operator mitigation: separation of duties\n between issuer (A) and intermediary (M) so that the same operator\n cannot control both signing keys and relay logs; anchor evidence\n on independent witnesses under different trust roots so that an\n attacker controlling A and M still cannot retroactively coordinate\n anchor inclusion across uncolluding timestamping authorities; out-\n of-band attestation by the regulator or auditor of A's operational\n context (provenance, code signing, runtime attestation) where the\n policy regime authorises it.\n\n * Compromise of B itself. A B that has been compromised (private\n key extraction, supply-chain compromise, or insider operation) can\n sign any envelope_hash the attacker chooses; counterparty_binding\n proves only that the signing key acknowledged some bytes, not that\n those bytes match what an honest B would have observed.\n\nGomes Marques Expires 21 January 2027 [Page 56]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * Loss of A's stored envelope. counterparty_binding requires the\n verifier to resolve receipt_ref to A's full signed envelope; if\n A's chain segment is unavailable (retention discipline failure,\n key rotation orphan, deliberate withholding), the binding becomes\n unverifiable and the receipt is reported non-conformant on\n liveness grounds rather than on byte-equality grounds. An\n adversary who can arrange A-envelope unavailability and then re-\n emit colluding bytes can degrade the binding from a byte-equality\n check to a liveness-loss flag.\n\n Operators concerned about these residuals in the absence of single-\n point cryptographic defence SHOULD:\n\n * Anchor receipts to multiple independent witnesses. Where both\n [RFC3161] and [OPENTIMESTAMPS] anchors are present per\n Section 5.4, a coordinated M-B collusion attack must also induce\n both timestamping authorities to anchor the colluding bytes within\n the operator's anchor interval, raising the conjunction-cost of\n the attack. Operators MAY add further anchors (e.g. a Deployer-\n operated transparency log or a witness service) without changing\n the wire format defined here.\n\n * Use side-by-side chain comparison under regulator subpoena. The\n audit-trail alternative semantics established for SEC 17a-4\n recordkeeping (see Section 7.6.1) and the post-market surveillance\n regime of EU AI Act Articles 12 and 26 (see Section 6.1 and\n Section 6.2) authorise the regulator to compel both A's and B's\n Audit Packs and to reconstruct the relay by joining on action_ref\n per Section 5.1.5. counterparty_binding reduces the regulator's\n workload from "compare both chains and detect divergence" to\n "verify B's bound digest against A's stored envelope"; the\n underlying subpoena-and-compare workflow remains the regulator's\n ultimate authority and remains operative when the binding is\n unverifiable.\n\n * Document M's relay logs out-of-band. Where the intermediary M is\n identifiable (a named MCP server, message bus, orchestrator, or\n relay), the operator SHOULD require M to produce signed relay logs\n covering the time window of the Action and SHOULD submit those\n logs to the same Audit Pack production layer as A's and B's\n chains. Out-of-band relay logs do not require a wire-format\n change in this profile; they are operational evidence that\n complements counterparty_binding rather than replacing it.\n\n The worst-case latency to detection for an M-only compromise (not M-B\n collusion) is bounded by the anchor interval recommended in\n Section 10.1: 24 hours by default, one hour for Deployers operating\n under [DORA] Article 17, 23 NYCRR 500.17, or [CIRCIA]. After the\n\nGomes Marques Expires 21 January 2027 [Page 57]\nInternet-Draft Compliance Receipts Profile July 2026\n\n next anchor commits, the divergence between A's anchored chain\n segment and the digest carried in B's counterparty_binding is\n permanently recoverable from the anchored evidence alone, without\n trust in M.\n\n11. IANA Considerations\n\n This document requests two new IANA registries to support stable,\n machine-checkable extensions to the Compliance Receipt format.\n\n11.1. Compliance Receipt Extension Fields Registry\n\n IANA is requested to create a new registry titled "Compliance Receipt\n Extension Fields" under a new "Compliance Receipts" registry group.\n\n This registry covers both signed-payload fields and envelope-level\n fields (siblings of payload and signature); each entry's Description\n identifies which.\n\n Each entry contains:\n\n * Field Name: a JSON object key, lowercase ASCII letters, digits,\n and underscore.\n\n * Description: a one-line summary of the field's purpose.\n\n * Reference: the document that defines the field's semantics.\n\n * Vocabulary: a URL or registry pointer for the controlled\n vocabulary that field values are drawn from, or "free-form" if\n none.\n\n The registration policy is Specification Required, per [RFC8126].\n The Designated Expert(s) SHOULD verify that the field name does not\n collide with any field defined by [ACTA-RECEIPTS], that the Reference\n is a stable, dereferenceable specification, and that the Vocabulary\n is documented sufficiently for an independent verifier to validate\n values.\n\n Initial registry contents (each entry labelled with Scope to\n disambiguate signed-payload fields from envelope-level fields per the\n registry description above):\n\n * risk_class - Scope: signed-payload - Risk classification term\n under the Deployer's risk management documentation - This document\n - Vocabulary referenced in Audit Pack metadata.\n\nGomes Marques Expires 21 January 2027 [Page 58]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * incident_class - Scope: signed-payload - Incident classification\n term spanning DORA Article 18(1) (with further specification in\n [REG-2024-1772] and the canonical reporting enumeration of Annex\n II field 3.23 of [REG-2025-302]), 23 NYCRR 500.1 Cybersecurity\n Event/Incident, [CIRCIA] Covered Cyber Incident, and HIPAA\n security incident under 45 CFR 164.304 - This document - Audit\n Pack metadata.\n\n * counterparty_binding - Scope: signed-payload - Signed-payload\n object carrying a base64-encoded SHA-256 digest (envelope_hash) of\n a peer agent's full signed envelope including signature bytes, a\n resolvable opaque locator (receipt_ref), an OPTIONAL expected-\n acknowledger identifier (expect_ack_from), and an OPTIONAL\n operational transport_label; see Section 5.6 for the full member\n set and the digest-scope rule - This document - Member vocabulary\n defined in Section 5.6.1; digest algorithm is SHA-256 per\n [ACTA-RECEIPTS] with base64 encoding per [RFC4648].\n\n * result_digest - Scope: signed-payload - Object of the upstream\n payload_digest shape (hash, size, OPTIONAL preview) carrying a\n SHA-256 digest of the downstream Action's result body; defined in\n Section 5.7 - This document - Digest algorithm is SHA-256 with hex\n encoding under the sha256:<64 hex> form.\n\n * expires_at - Scope: signed-payload - ISO 8601 timestamp with\n explicit timezone declaring the wall-clock time after which the\n decision result is stale and not safe to replay; defined in\n Section 5.7 - This document - Free-form ISO 8601 string.\n\n * nonce - Scope: signed-payload - Producer-generated string unique\n across the producer's emission stream for the lifetime of kid;\n defined in Section 5.7 - This document - Lowercase hexadecimal\n encoding of 12 random bytes (24 hexadecimal characters).\n\n * tool_fingerprint - Scope: signed-payload - JSON string of 32\n lowercase hex characters carrying the truncated (first 128 bits)\n SHA-256 digest of the JCS-canonical ([RFC8785]) serialization of\n the JSON object {"tool_name": <tool name>, "schema": <declared\n input schema>}; defined in Section 5.7 - This document - Digest\n algorithm is SHA-256 over [RFC8785] canonical bytes, truncated to\n its first 32 hexadecimal characters.\n\n * config_manifest_digest - Scope: signed-payload - JSON string\n formatted sha256:<64 hex> over the canonical bytes of the\n producer's configuration manifest in effect at signing time;\n defined in Section 5.7 - This document - Manifest content is\n operator-defined; canonicalization rule is operator-declared in\n the Audit Pack manifest entry.\n\nGomes Marques Expires 21 January 2027 [Page 59]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * cve_inventory_digest - Scope: signed-payload - JSON string\n formatted sha256:<64 hex> over the canonical bytes of the\n producer's CVE inventory at signing time; defined in Section 5.7 -\n This document - Inventory content lists CVE identifiers per the\n producer's accepted-residual rationale.\n\n * executable_hash - Scope: signed-payload - JSON string formatted\n sha256:<64 hex> over the canonical bytes of the executable that\n invoked the Action (OCI image manifest digest for container\n producers, on-disk SHA-256 for non-container executables); defined\n in Section 5.8 - This document - Digest algorithm is SHA-256.\n\n * sbom_digest - Scope: signed-payload - JSON string formatted\n sha256:<64 hex> over the canonical bytes of the CycloneDX or SPDX\n SBOM document covering the executing image; defined in Section 5.8\n - This document - SBOM format and version declared in the Audit\n Pack manifest entry.\n\n * slsa_provenance_pointer - Scope: signed-payload - JSON string\n carrying an https URL resolving to the SLSA provenance attestation\n envelope for the build of the executable identified by\n executable_hash; defined in Section 5.8 - This document - Target\n SHOULD be SLSA Provenance v1.0 in-toto statement form.\n\n * supply_chain_pointer - Scope: signed-payload - JSON string\n carrying an https URL resolving to a transparency-log entry (in-\n toto, Sigstore, or Rekor) covering the build of the executable\n identified by executable_hash; defined in Section 5.8 - This\n document - Verifier acceptance is SHOULD across the three log\n formats.\n\n * anchors - Scope: envelope-level - Envelope-level array of\n timestamp / transparency-log anchors covering the signed envelope;\n entries carry a REQUIRED type discriminator (rfc3161 or\n opentimestamps) and a REQUIRED value field, plus OPTIONAL\n informational members status (anchored / pending / failed) and\n anchor_block_hash (string Bitcoin block hash for upgraded\n OpenTimestamps entries); full schema is defined in Section 5.4 -\n This document - Anchor type vocabulary: rfc3161 per [RFC3161],\n opentimestamps per [OPENTIMESTAMPS].\n\n * witness_policy - Scope: envelope-level - Envelope-level object\n declaring an N-of-M durable-anchoring quorum over the anchors\n array; carries a REQUIRED integer required in the closed range [1,\n length of witnesses] and a REQUIRED non-empty array witnesses\n whose distinct values are a subset of {rfc3161, opentimestamps}\n (Rekor and other transparency-log pointers are NOT witness types\n and MUST be rejected). The receipt reaches the quorum-met state\n\nGomes Marques Expires 21 January 2027 [Page 60]\nInternet-Draft Compliance Receipts Profile July 2026\n\n only when at least required distinct witness types each hold a\n verifiable inclusion proof; a producer MUST NOT assert durable\n anchoring unless that holds, per the false-attestation rule of\n Section 5.4 - This document - Witness type vocabulary: rfc3161 per\n [RFC3161], opentimestamps per [OPENTIMESTAMPS]; inclusion-proof\n prior art per [RFC9943] and [RFC6962].\n\n * mitre_techniques - Scope: signed-payload - JSON array of MITRE\n ATT&CK technique identifiers (for example T1059, T1078) self-\n declared by the producer; not verifier-checked by the issuing\n platform; flips framework_mappings_self_declared to true when\n populated; defined in Section 5.12 - This document - Vocabulary\n referenced by id from the MITRE ATT&CK enterprise matrix.\n\n * mitre_atlas - Scope: signed-payload - JSON array of MITRE ATLAS\n identifiers (for example AML.T0051) covering AI-system-specific\n adversary techniques; self-declared; flips\n framework_mappings_self_declared to true when populated; defined\n in Section 5.12 - This document - Vocabulary referenced by id from\n the MITRE ATLAS catalogue.\n\n * owasp_llm_top10 - Scope: signed-payload - JSON array of OWASP Top\n 10 for LLM Applications identifiers (for example LLM01, LLM02);\n self-declared; flips framework_mappings_self_declared to true when\n populated; defined in Section 5.12 - This document - Vocabulary\n referenced by id from the OWASP Top 10 for LLM Applications\n publication.\n\n * nist_ai_rmf - Scope: signed-payload - JSON array of NIST AI Risk\n Management Framework function identifiers and subcategories (for\n example GOVERN-1.1, MEASURE-2.7); self-declared; flips\n framework_mappings_self_declared to true when populated; defined\n in Section 5.12 - This document - Vocabulary referenced from NIST\n AI RMF 1.0.\n\n * iso_42001 - Scope: signed-payload - JSON array of ISO/IEC\n 42001:2023 control identifiers (for example A.6.2.6); self-\n declared; flips framework_mappings_self_declared to true when\n populated; defined in Section 5.12 - This document - Vocabulary\n referenced from ISO/IEC 42001:2023.\n\n * eu_ai_act_articles - Scope: signed-payload - JSON array of EU AI\n Act article identifiers (for example Article-12, Article-15);\n self-declared; flips framework_mappings_self_declared to true when\n populated; defined in Section 5.12 - This document - Vocabulary\n referenced from [EU-AI-ACT].\n\nGomes Marques Expires 21 January 2027 [Page 61]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * rfc3161_timestamp - Scope: signed-payload - JSON string carrying a\n base64-encoded RFC 3161 TimeStampResp (DER) supplied by the\n producer at signing time and preserved verbatim on the receipt for\n offline TSA chain verification independent of any platform-issued\n anchors; payload entry is an opaque caller-supplied token, not the\n per-receipt anchor produced by the platform; defined in\n Section 5.12 - This document - Bytes are an RFC 3161 TimeStampResp\n per [RFC3161]; base64 encoding per [RFC4648].\n\n * framework_mappings_self_declared - Scope: signed-payload - JSON\n boolean false-attestation guard set by the issuing platform to\n true whenever any of mitre_techniques, mitre_atlas,\n owasp_llm_top10, nist_ai_rmf, iso_42001, or eu_ai_act_articles is\n populated; a producer-supplied value of false alongside a\n populated taxonomy field MUST be overridden by the issuing\n platform; defined in Section 5.12 - This document - Boolean.\n\n * authorized_under_mandate - Scope: signed-payload - Server-built\n object recording a self-declared authorizing mandate the Action\n was signed under; carries REQUIRED mandate_id, REQUIRED issuer_id,\n a REQUIRED scope_digest formatted sha256:<64 hex> over the\n mandate's authorized-action-types scope, and a REQUIRED verified\n boolean whose true value asserts self-declared issuer authority\n (the same trust level as framework_mappings_self_declared, never\n issuing-platform-verified third-party authorization); a present-\n but-malformed object is rejected at signing time by the\n false_mandate_attestation_guard; defined in Section 5.9 - This\n document - Member vocabulary defined in Section 5.9; scope_digest\n digest algorithm is SHA-256.\n\n * controls_evaluated - Scope: signed-payload - Server-built object\n enumerating the enforcement controls that genuinely fired on this\n sign plus the allow result; member keys are a closed set\n (emergency_halt, delegation_scope, quorum, mandate, policy,\n content_scan, result) and an unknown key is rejected; a key is\n present only when its control ran (omission-over-false\n attestation), quorum requires fired=true plus a 64-hex\n attestation_hash, and a policy member asserting evaluation\n requires matched_count at least 1; a caller-supplied value is\n dropped before signing (the false_control_attestation_guard);\n defined in Section 5.9 - This document - Control-key vocabulary\n defined in Section 5.9.\n\n * approver_id - Scope: signed-payload - Producer-asserted identity\n (bare kid or issuer_id) that authored a risk acceptance on a\n protectmcp:lifecycle:risk_acceptance receipt; a FIELD bound into\n the signed bytes with NO authority check, NO authentication, and\n NO identity resolution performed by the issuing platform, only the\n\nGomes Marques Expires 21 January 2027 [Page 62]\nInternet-Draft Compliance Receipts Profile July 2026\n\n compliance_mode string-equality refusal against initiator_id (the\n risk_acceptance_self_approval_guard); REQUIRED on the receipt type\n and enforced by the risk_acceptance_missing_required_field false-\n attestation guard; defined in Section 5.10 - This document - Bare-\n identifier form per Section 5.1.3.\n\n * initiator_id - Scope: signed-payload - Producer-asserted identity\n (bare kid or issuer_id) that requested the acceptance; a FIELD\n bound into the signed bytes; under compliance_mode a value that\n string-equals approver_id is refused at signing time by the\n risk_acceptance_self_approval_guard (a string-incoherence check,\n not identity resolution; an absent field never fires it); defined\n in Section 5.10 - This document - Bare-identifier form per\n Section 5.1.3.\n\n * acceptance_reason - Scope: signed-payload - Free-text producer\n rationale for accepting a risk; proves the rationale existed and\n was key-authored at issued_at, never parsed or scored; REQUIRED on\n the risk-acceptance receipt type and enforced by the\n risk_acceptance_missing_required_field guard; defined in\n Section 5.10 - This document - Free-form string.\n\n * accepted_at - Scope: signed-payload - Producer-asserted ISO 8601\n authoring time of the acceptance; self-declared, distinct from the\n platform-attested issued_at and anchors times; defined in\n Section 5.10 - This document - Free-form ISO 8601 string.\n\n * supersedes - Scope: signed-payload - Producer-asserted pointer\n (opaque receipt locator OR sha256:<64 hex>) to the prior risk-\n acceptance receipt this one replaces; proves the supersession\n claim existed at issued_at; the issuing platform NEVER invalidates\n the prior receipt (the chain of Section 5.3 is immutable, this is\n a forward pointer only); defined in Section 5.10 - This document -\n Opaque locator or sha256:<64 hex> digest.\n\n * sarif_digest - Scope: signed-payload - JSON string formatted\n sha256:<64 hex> over the producer-declared canonical bytes of the\n SARIF scan artifact the acceptance rested on; a SHAPE-ONLY\n existence proof that THAT artifact existed unaltered at issued_at\n and nothing more; the issuing platform NEVER parses, fetches, re-\n runs, or validates the scan; defined in Section 5.10 - This\n document - Digest algorithm is SHA-256; canonicalization rule\n declared in the Audit Pack manifest entry.\n\nGomes Marques Expires 21 January 2027 [Page 63]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * finding_ref - Scope: signed-payload - Producer-asserted opaque\n free-text pointer to a finding or rule id inside the SARIF\n artifact; proves the reference existed at issued_at, never\n resolved or validated; defined in Section 5.10 - This document -\n Free-form string.\n\n * approval_ref - Scope: signed-payload - Producer-asserted opaque\n free-text correlation pointer to a human-in-the-loop approval id\n or external ticket; proves the pointer existed at issued_at, never\n resolved or validated; defined in Section 5.10 - This document -\n Free-form string.\n\n * risk_snapshot - Scope: signed-payload - Object carrying a\n producer-asserted point-in-time snapshot of THIRD-PARTY risk\n signals (snapshot_at, snapshot_source, OPTIONAL epss, cvss,\n cvss_vector, kev_listed, cve_ids); the issuing platform does NOT\n fetch, compute, verify, query, or vouch for these values, and the\n snapshot is explicitly NOT reproducible from any input the\n platform holds; numerics are strings (floats prohibited per\n Section 4) and snapshot_source is REQUIRED whenever any numeric or\n KEV signal is present (a populated signal without it is rejected\n by the risk_snapshot_numeric_requires_snapshot_source guard) so a\n value can never be read as a platform-derived or verified score;\n defined in Section 5.10 - This document - Third-party feed\n vocabulary named per-receipt in snapshot_source; the platform\n defines no controlled vocabulary for the signal values.\n\n * repo_ref - Scope: signed-payload - Producer-asserted opaque\n pointer to the repository a change was authored against, carried\n on a protectmcp:lifecycle:code_authorship receipt; REQUIRED on the\n receipt type and enforced by the\n code_authorship_missing_required_field false-attestation guard;\n free-text, proves the reference existed at issued_at, never\n resolved, cloned, or validated by the issuing platform; defined in\n Section 5.11 - This document - Free-form string.\n\n * commit_sha - Scope: signed-payload - Producer-asserted commit\n identifier of the authored change; REQUIRED on the receipt type\n and enforced by the code_authorship_missing_required_field false-\n attestation guard; bound into the signed bytes only, NEVER fetched\n or verified by the issuing platform, proves only that the producer\n asserted it at issued_at; defined in Section 5.11 - This document\n - Free-form string.\n\nGomes Marques Expires 21 January 2027 [Page 64]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * base_sha - Scope: signed-payload - Producer-asserted base commit\n identifier the change was authored on top of; bound into the\n signed bytes only, NEVER fetched or verified by the issuing\n platform; defined in Section 5.11 - This document - Free-form\n string.\n\n * change_digest - Scope: signed-payload - JSON string formatted\n sha256:<64 hex> over the producer-declared canonical bytes of the\n change; a SHAPE-ONLY existence proof that THAT change existed\n unaltered at issued_at and nothing more; the issuing platform\n NEVER fetches, re-diffs, or re-computes the change; a value\n outside the sha256:<64 hex> wire form is rejected at signing time\n by the change_digest_not_sha256_wire_form guard; defined in\n Section 5.11 - This document - Digest algorithm is SHA-256;\n canonicalization rule declared in the Audit Pack manifest entry.\n\n * change_ref - Scope: signed-payload - Producer-asserted opaque\n free-text pointer to the change as a unit (for example a pull-\n request id); proves the reference existed at issued_at, never\n resolved or validated; defined in Section 5.11 - This document -\n Free-form string.\n\n * change_approval_ref - Scope: signed-payload - Producer-asserted\n opaque free-text correlation pointer to a human-in-the-loop\n approval id or external review ticket for the change; proves the\n pointer existed at issued_at, never resolved or validated; defined\n in Section 5.11 - This document - Free-form string.\n\n * change_class - Scope: signed-payload - Producer-asserted class of\n the change drawn from the closed vocabulary read, write, delete,\n execute, deploy; self-declared, the issuing platform records but\n does NOT verify the change matches the class; a value outside the\n closed vocabulary is rejected at signing time as an out-of-\n vocabulary value; defined in Section 5.11 - This document - Closed\n vocabulary {read, write, delete, execute, deploy}.\n\n * authored_by - Scope: signed-payload - Object carrying a producer-\n asserted description of the authoring agent (agent_id, model_id,\n model_version, tool, attestation_source); the issuing platform\n does NOT verify the named model; attestation_source is REQUIRED\n whenever model_id or model_version is populated (a populated model\n field without it is rejected by the\n authored_by_model_requires_attestation_source guard) so a model\n claim can never be read as a platform-verified attestation;\n defined in Section 5.11 - This document - Member vocabulary\n defined in Section 5.11; the platform defines no controlled\n vocabulary for the member values.\n\nGomes Marques Expires 21 January 2027 [Page 65]\nInternet-Draft Compliance Receipts Profile July 2026\n\n This document additionally requests that IANA register\n counterparty_binding as a new claim in the CBOR Web Token (CWT)\n Claims registry established by [RFC8392], with this document as the\n reference and the semantics defined in Section 5.6. The requested\n CWT claim key is TBD by IANA; this document proposes allocation from\n the IANA First Come First Served range (claim keys greater than or\n equal to -65536 and less than -256, or greater than or equal to\n 65536, per [RFC8392] Section 9.1) so as not to consume Expert Review\n or Standards Action space. The JSON-form claim name is the literal\n string counterparty_binding as registered above in the Compliance\n Receipt Extension Fields Registry.\n\n11.2. Compliance Receipt Type Namespaces Registry\n\n IANA is requested to create a new registry titled "Compliance Receipt\n Type Namespaces" under the same "Compliance Receipts" registry group.\n\n Each entry contains:\n\n * Namespace: a colon-separated identifier prefix used as a value of\n the type field, lowercase ASCII letters, digits, hyphen,\n underscore, and colon.\n\n * Description: a one-line summary of the receipt category.\n\n * Reference: the document that defines the namespace.\n\n The registration policy is Specification Required, per [RFC8126].\n The Designated Expert(s) SHOULD verify that the namespace does not\n collide with any namespace already registered or any namespace\n reserved by [ACTA-RECEIPTS], and that the Reference is a stable\n specification.\n\n Initial registry contents:\n\n * protectmcp:acknowledgment - A receipt emitted by the B-party in a\n counterparty_binding pair, confirming receipt of the A-party\n action and carrying a digest of the bound envelope per Section 5.6\n - This document.\n\n * protectmcp:decision - A receipt recording a policy evaluation\n outcome (allow, deny, rate_limit) for an MCP-mediated tool call\n where a policy was actually evaluated; observation is reserved to\n protectmcp:lifecycle and protectmcp:observation per Section 5.2 -\n This document.\n\nGomes Marques Expires 21 January 2027 [Page 66]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * protectmcp:restraint - A receipt recording the application or\n release of a restraint on an agent (e.g., quota, rate limit,\n sandbox tightening) - This document.\n\n * protectmcp:lifecycle - A receipt recording an agent or system\n lifecycle event (e.g., configuration change, key rotation,\n oversight review, or a decision=observation record indicating an\n Action was signed without policy evaluation per Section 5.2) -\n This document.\n\n * protectmcp:lifecycle:configuration_change - A receipt recording a\n configuration change to an agent or producing system, including\n changes that disable or re-enable receipt generation (see\n Section 6.1.1); a registered sub-namespace under\n protectmcp:lifecycle that the reference cloud implementation emits\n today; the implementation rejects at signing time, as the\n configuration_change_missing_config_manifest_digest guard, a\n receipt of this type that lacks a well-formed\n config_manifest_digest (Section 5.7) - This document.\n\n * protectmcp:lifecycle:risk_acceptance - A receipt recording a\n producer's acceptance of a known risk, security finding, or policy\n exception; a registered sub-namespace under protectmcp:lifecycle\n that signs through the no-policy lifecycle path\n (decision=observation, no policy evaluated) and carries the risk-\n acceptance extension fields of Section 5.10 - This document.\n\n * protectmcp:lifecycle:code_authorship - A receipt recording a\n producer's assertion that an agent-authored change to a code\n repository existed at a point in time; a registered sub-namespace\n under protectmcp:lifecycle that signs through the no-policy\n lifecycle path (decision=observation, no policy evaluated) and\n carries the code-authorship extension fields of Section 5.11; the\n receipt proves only that the change existed, was key-authored, and\n was chained at the receipt time, and the issuing platform never\n clones the repository, re-diffs the change, verifies the code, or\n verifies the model - This document.\n\nGomes Marques Expires 21 January 2027 [Page 67]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * protectmcp:observation - A receipt recording passive telemetry\n about an Action that was signed without a policy evaluation,\n emitted under one of the capture topologies catalogued in\n Appendix "Appendix - Capture Topologies for Compliance Receipt\n Emission" (typically network_proxy, browser_extension,\n ebpf_observer, or mcp_proxy) where the originating application\n could not call the receipt-emitting SDK directly; the reference\n cloud implementation rejects at signing time, as the\n false_attestation_guard, a receipt that declares the\n passive_telemetry capture topology but carries a type outside\n protectmcp:observation and its sub-namespaces - This document.\n\n * protectmcp:observation:result_bound - A sub-namespace under\n protectmcp:observation for a follow-up observation receipt that\n carries a result_digest (Section 5.7) binding the byte-equality of\n a downstream Action's result to the originating\n protectmcp:decision receipt identified by action_ref; the\n reference cloud implementation emits this type for tool calls\n whose downstream result is regulator-relevant (LLM completions\n under EU AI Act Article 12, audit-log entries under HIPAA\n 164.312(b), broker-dealer communications under SEC 17a-4); the\n implementation rejects at signing time, as the\n result_bound_missing_result_digest guard, a receipt of this type\n that lacks a well-formed result_digest - This document.\n\n12. Related Work\n\n This section catalogues parallel proposals that overlap the problem\n space of signed records for AI-agent actions. The intent is to\n position this profile within the broader Independent Submissions and\n individual drafts landscape so that an implementer can choose the\n surface that matches the trust model and the regulator that the\n implementer is bound by. The citations follow the RFC 7322 form and\n are informative; this section places no normative constraint on a\n Compliance Receipt implementation.\n\n * [DRAFT-SHARIF-APKI] defines a certificate-based Public Key\n Infrastructure for autonomous AI agents, with X.509 certificate\n profiles, naming conventions, and revocation considerations. Its\n scope is identity issuance and trust-root anchoring for agent\n principals; it does not define a per-action receipt format. This\n profile is complementary to [DRAFT-SHARIF-APKI]: an implementer\n that anchors agent identity through APKI can express the resulting\n kid and issuer_id values in Compliance Receipts under\n Section 5.1.3, with the trust-anchor metadata of the Audit Pack\n resolving through the APKI certificate chain.\n\nGomes Marques Expires 21 January 2027 [Page 68]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * [DRAFT-SHARIF-AML] defines cryptographic attestation across the AI\n model lifecycle, from training-data provenance to inference-time\n output binding. Its scope is the model-build and model-evaluation\n surface, addressing what evidence a model producer or model\n consumer SHOULD retain about the model's lineage and behaviour.\n This profile is complementary at the per-action layer: a Deployer\n that consumes a model whose lifecycle attestations are produced\n under [DRAFT-SHARIF-AML] can reference those attestation digests\n in Compliance Receipts via config_manifest_digest (Section 5.7) or\n via the build-provenance four-tuple of Section 5.8 where the model\n is delivered as a containerized executable.\n\n * [PIPELOCK-ER2] proposes an alternative receipt format for AI agent\n actions under the EvidenceReceipt v2 schema. The Pipelock format\n is published as a public reference outside the IETF process and\n addresses overlapping evidence-class requirements with a different\n envelope, a different canonicalization choice, and a different\n anchoring posture. This profile and the Pipelock format are\n bidding for the same regulator audience under different design\n tradeoffs; an implementer that already deploys EvidenceReceipt v2\n receipts can map the field set across the two surfaces, though\n byte-equality across the formats is not preserved (the\n canonicalization rules differ) and a cross-format verifier would\n have to recompute digests under each format's rule.\n\n * [LYRIE-ATP] defines the Agent Trust Protocol, an open\n cryptographic trust framework for AI agent identity published\n outside the IETF process, built from five primitives: an Agent\n Identity Certificate binding an agent name, version, and model to\n a signed key; a Scoped Authorization Token declaring time-bounded\n permissions; a Tamper-Evident Action Log of hash-chained signed\n action records; a Delegation Receipt recording authority transfer\n between agents; and a Runtime Attestation Bundle tying runtime\n state to the declared identity. Its Tamper-Evident Action Log\n overlaps this profile's per-action receipt surface, while its\n identity, authorization, and delegation primitives sit on the\n identity-anchoring and delegation layer that this profile composes\n on top of rather than redefines. This profile is complementary:\n an implementer that anchors agent identity and delegation through\n the Agent Trust Protocol can express the resulting identity as the\n issuer_id of Compliance Receipts under Section 5.1.3, while this\n profile's receipts are signed server-side by an operator\n unaffiliated with the agent's operator and carry the regulator-\n facing field bindings of Sections 5 and 6 that a self-produced\n action log does not.\n\nGomes Marques Expires 21 January 2027 [Page 69]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * [RFC9943] defines the Supply Chain Integrity, Transparency, and\n Trust architecture: an append-only Transparency Service that\n admits signed statements about an artefact and returns a receipt\n proving inclusion in the log, with verification reducing to a\n Merkle inclusion proof in the tradition of [RFC6962] Certificate\n Transparency. SCITT and RFC 6962 are the canonical inclusion-\n proof prior art that this profile's witness_policy (Section 5.4)\n generalizes from a single log to an N-of-M quorum over\n heterogeneous durable-anchoring witnesses. This profile is\n complementary to SCITT rather than competitive with it: a SCITT\n Transparent Statement MAY carry a Compliance Receipt as its signed\n payload, so that a Deployer operating a SCITT Transparency Service\n obtains a SCITT receipt whose inclusion proof can be named as one\n witness in a Compliance Receipt's witness_policy, while the\n Compliance Receipt continues to carry the regulator-facing field\n bindings that SCITT's artefact-neutral envelope does not define.\n This closes the append-only-log gap deferred under Section 10.12.\n\n * [A2A] defines the Agent2Agent protocol, a vendor-neutral\n horizontal protocol for communication between independent agents,\n hosted as a Linux Foundation project. A2A defines an Agent Card,\n an extension mechanism (data-only, profile, method, and state-\n machine extension classes declared inside the Agent Card\n capabilities and activated by clients through a request header),\n and an Agent Card signature that carries a detached JSON Web\n Signature over the Agent Card document itself. A2A is\n complementary to this profile rather than competitive with it:\n A2A's Agent Card signature attests the integrity of the card, not\n the execution of a per-action authorization decision, and A2A is\n explicitly method-agnostic on identity verification. A Deployer\n can reference a Compliance Receipt from an A2A Agent Card through\n a verifier-issued attestation pointer (a resolvable URL, a content\n hash over the referenced receipt, and the verifier identity\n expressed as a decentralized identifier), so that the Compliance\n Receipt's issuer_id (Section 5.1.3) is the receipt subject and the\n per-action regulator-facing bindings of Sections 5 and 6 compose\n on top of A2A's identity layer without either layer redefining the\n other.\n\n * [A2A-IDF] is the Agent Identity Verification and Trust Framework\n proposal under the A2A protocol's contribution process, defining\n tiered identity verification levels (self-asserted, domain-\n verified, organization-verified), Agent Card signing for\n production agents, revocation endpoints, delegation-chain\n verification, and per-message signing. Its scope is the identity\n and trust-anchoring layer beneath per-action receipts; it does not\n define a regulator-facing per-action receipt format, and its post-\n quantum cryptography work is scheduled for a later cycle. This\n\nGomes Marques Expires 21 January 2027 [Page 70]\nInternet-Draft Compliance Receipts Profile July 2026\n\n profile is complementary to [A2A-IDF] at the per-action layer: an\n implementer that anchors agent identity through an A2A-IDF\n verification level can express the resulting identity as the\n issuer_id and kid of Compliance Receipts under Section 5.1.3,\n while this profile already signs receipts with the ML-DSA-65 post-\n quantum signature algorithm of [FIPS204] that the surrounding\n agent-identity ecosystem largely defers.\n\n * [DRAFT-HOPLEY-X402] is the closest parallel receipt format: it\n defines a Compliance Receipt minted at admission time under a\n payment-gate remote procedure call, carrying an ALLOW, REFER, or\n DENY verdict bound to a payment mandate. The format canonicalizes\n under [RFC8785] JCS, digests under SHA-256, and links receipts in\n a monotonic hash chain (position plus content hash plus previous-\n hash), in the same family of design primitives as this profile\n (JCS canonicalization, SHA-256 digests, hash-chain linkage under\n Section 5.3, and a categorical decision under Section 5.2 bound to\n an authorizing mandate under Section 5.9). The two drafts differ\n in scope and trust model. [DRAFT-HOPLEY-X402] is narrowed to\n payment anti-money-laundering and sanctions-screening admission\n decisions, is bound to a payment-settlement substrate, and its\n REFER verdict carries a jurisdiction-specific suspicious-activity-\n reporting meaning. This profile is the broader superset: it\n covers general agent-action receipts across regulatory regimes\n rather than payment screening alone (Sections 5 and 6), it is\n signed by a neutral third party rather than by the screening party\n itself (the unaffiliated-custodian posture the recordkeeping\n bindings of Sections 5 and 6 anchor), it carries the organization-\n wide enforcement controls enumerated in controls_evaluated\n (Section 5.9) rather than a single admission verdict, and it signs\n with the ML-DSA-65 post-quantum algorithm of [FIPS204]. An\n implementer deploying both can map the verdict and mandate-binding\n fields across the two surfaces, though byte-equality is not\n preserved because the envelope shapes differ.\n\n * [IN-TOTO-ATTESTATION] defines the in-toto Attestation Framework, a\n specification for authenticated metadata about software supply-\n chain artifacts: a signed statement binds a subject (an artifact\n identified by a digest) to a predicate carrying claims about how\n that artifact was produced. Its scope is the build-and-provenance\n surface for software artifacts; it does not define a regulator-\n facing per-action receipt format. This profile is complementary\n to [IN-TOTO-ATTESTATION] at the code-authorship layer of\n Section 5.11: a producer that authors a change whose build\n provenance is attested under in-toto can bind the in-toto subject\n digest into a code-authorship receipt via change_digest\n (Section 5.11) or reference the in-toto attestation through the\n build-provenance pointers of Section 5.8, while the code-\n\nGomes Marques Expires 21 January 2027 [Page 71]\nInternet-Draft Compliance Receipts Profile July 2026\n\n authorship receipt carries the time-of-authorship existence proof\n and the chained per-action evidence that the in-toto statement\n does not by itself provide.\n\n * [DRAFT-NELSON-DELEGATION] proposes a delegation-receipt format for\n AI agents, recording that one agent delegated a scoped authority\n to another and the resulting authorization chain. Its scope is\n the delegation-and-authorization surface between agent principals;\n it does not define a code-authorship or change-existence receipt.\n This profile is complementary at the per-action layer: a code-\n authorship receipt under Section 5.11 can reference the\n authorizing mandate the change was signed under through the reused\n authorized_under_mandate field of Section 5.9, while a delegation\n receipt under [DRAFT-NELSON-DELEGATION] can supply the upstream\n delegation chain that the mandate's authority rests on, without\n either layer redefining the other.\n\n * [DRAFT-SHARIF-AAT] defines a JSON-based structured logging format\n for autonomous AI systems, covering event capture, retention, and\n compliance-mapping to the EU AI Act, SOC 2, ISO/IEC 42001, and PCI\n DSS v4.0.1. Its scope is the per-system audit log surface; it\n does not define a cryptographically signed, hash-chained per-\n action receipt or a regulator-facing field binding. This profile\n is complementary: a Deployer that produces audit-log entries under\n [DRAFT-SHARIF-AAT] can reference a Compliance Receipt's action_ref\n (Section 5.1.5) as the stable per-action anchor correlating an\n audit-log entry with the cryptographic evidence of the access-\n control decision, while this profile's signing is performed\n server-side by an operator unaffiliated with the agent's operator,\n providing a tamper-evidence guarantee that a self-produced audit\n log does not carry.\n\n * [DRAFT-NARAJALA-ANSv2] defines a domain-anchored trust layer for\n autonomous AI agent identity through a dual-certificate model and\n a cryptographic Transparency Log, supplying verifiable identity\n resolution for agent principals at discovery time. Its scope is\n the naming and identity-anchoring surface; it does not define a\n per-action receipt format or regulator-facing retention bindings.\n This profile is complementary: an implementer that resolves agent\n identity through ANS v2 can express the resulting well-known\n domain anchor as the issuer_id of Compliance Receipts under\n Section 5.1.3, while this profile's receipts are signed server-\n side by an operator unaffiliated with the agent's operator, so the\n trust guarantee at the per-action layer is independent of whether\n the agent's operator controls the ANS v2 identity anchor.\n\nGomes Marques Expires 21 January 2027 [Page 72]\nInternet-Draft Compliance Receipts Profile July 2026\n\n This section is non-exhaustive. The Independent Submissions stream\n and the individual-draft search surface of the IETF Datatracker host\n additional proposals whose scope intersects the Compliance Receipt\n problem space; an implementer evaluating the field is encouraged to\n re-query the Datatracker against the keywords "agent", "receipt",\n "attestation", and "audit trail" at the time of implementation. The\n author welcomes pull requests against the source repository of this\n draft naming additional active parallel work.\n\n13. Acknowledgements\n\n The author thanks Tom Farley for [ACTA-RECEIPTS], on which this\n profile is built. This profile would not exist without the field\n catalogue and envelope structure that the upstream draft defines.\n The author also thanks the Asqav community for review of early\n drafts.\n\n14. Normative References\n\n [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\n Requirement Levels", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n <https://www.rfc-editor.org/info/rfc2119>.\n\n [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, <https://www.rfc-editor.org/info/rfc8174>.\n\n [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital\n Signature Algorithm (EdDSA)", RFC 8032,\n DOI 10.17487/RFC8032, January 2017,\n <https://www.rfc-editor.org/info/rfc8032>.\n\n [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,\n DOI 10.17487/RFC7518, May 2015,\n <https://www.rfc-editor.org/info/rfc7518>.\n\n [FIPS204] National Institute of Standards and Technology, "Module-\n Lattice-Based Digital Signature Standard", FIPS 204,\n DOI 10.6028/NIST.FIPS.204, 13 August 2024,\n <https://csrc.nist.gov/pubs/fips/204/final>.\n\n [RFC5816] Santesson, S. and N. Pope, "ESSCertIDv2 Update for RFC\n 3161", RFC 5816, DOI 10.17487/RFC5816, April 2010,\n <https://www.rfc-editor.org/info/rfc5816>.\n\nGomes Marques Expires 21 January 2027 [Page 73]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,\n "Internet X.509 Public Key Infrastructure Time-Stamp\n Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August\n 2001, <https://www.rfc-editor.org/info/rfc3161>.\n\n [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for\n Writing an IANA Considerations Section in RFCs", BCP 26,\n RFC 8126, DOI 10.17487/RFC8126, June 2017,\n <https://www.rfc-editor.org/info/rfc8126>.\n\n [OPENTIMESTAMPS]\n OpenTimestamps, "OpenTimestamps Server", September 2016,\n <https://github.com/opentimestamps/opentimestamps-server>.\n\n [ACTA-RECEIPTS]\n Farley, T., "Signed Decision Receipts for Machine-to-\n Machine Access Control", Work in Progress, Internet-Draft,\n draft-farley-acta-signed-receipts-02, 28 June 2026,\n <https://datatracker.ietf.org/doc/html/draft-farley-acta-\n signed-receipts-02>.\n\n [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON\n Canonicalization Scheme (JCS)", RFC 8785,\n DOI 10.17487/RFC8785, June 2020,\n <https://www.rfc-editor.org/info/rfc8785>.\n\n [ISO17442] ISO, "Financial services - Legal entity identifier (LEI) -\n Part 1: Assignment", ISO 17442-1:2020, August 2020,\n <https://www.iso.org/standard/78829.html>.\n\n [W3C-DID] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July\n 2022, <https://www.w3.org/TR/did-1.0/>.\n\n [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):\n Structures and Process", STD 96, RFC 9052,\n DOI 10.17487/RFC9052, August 2022,\n <https://www.rfc-editor.org/info/rfc9052>.\n\n [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object\n Representation (CBOR)", STD 94, RFC 8949,\n DOI 10.17487/RFC8949, December 2020,\n <https://www.rfc-editor.org/info/rfc8949>.\n\n [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web\n Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May\n 2015, <https://www.rfc-editor.org/info/rfc7515>.\n\nGomes Marques Expires 21 January 2027 [Page 74]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,\n "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,\n May 2018, <https://www.rfc-editor.org/info/rfc8392>.\n\n [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data\n Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,\n <https://www.rfc-editor.org/info/rfc4648>.\n\n [NIST-GENAI-PROFILE]\n National Institute of Standards and Technology,\n "Artificial Intelligence Risk Management Framework:\n Generative Artificial Intelligence Profile", NIST AI\n 600-1, DOI 10.6028/NIST.AI.600-1, 26 July 2024,\n <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>.\n\n15. Informative References\n\n [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol\n Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,\n <https://www.rfc-editor.org/info/rfc8446>.\n\n [RFC5705] Rescorla, E., "Keying Material Exporters for Transport\n Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,\n March 2010, <https://www.rfc-editor.org/info/rfc5705>.\n\n [RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,\n DOI 10.17487/RFC9266, July 2022,\n <https://www.rfc-editor.org/info/rfc9266>.\n\n [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP\n Message Signatures", RFC 9421, DOI 10.17487/RFC9421,\n February 2024, <https://www.rfc-editor.org/info/rfc9421>.\n\n [ISO8601-2]\n ISO, "Date and time - Representations for information\n interchange - Part 2: Extensions", ISO 8601-2:2019,\n February 2019, <https://www.iso.org/standard/70908.html>.\n\n [EU-AI-ACT]\n European Parliament and Council, "Regulation (EU)\n 2024/1689 of the European Parliament and of the Council of\n 13 June 2024 laying down harmonised rules on artificial\n intelligence and amending Regulations (EC) No 300/2008,\n (EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU)\n 2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU,\n (EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence\n Act) (Text with EEA relevance)", 12 July 2024,\n <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.\n\nGomes Marques Expires 21 January 2027 [Page 75]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [DORA] European Parliament and Council, "Regulation (EU)\n 2022/2554 of the European Parliament and of the Council of\n 14 December 2022 on digital operational resilience for the\n financial sector and amending Regulations (EC) No\n 1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No\n 909/2014 and (EU) 2016/1011 (Text with EEA relevance)", 27\n December 2022,\n <https://eur-lex.europa.eu/eli/reg/2022/2554/oj>.\n\n [REG-2025-301]\n European Commission, "Commission Delegated Regulation (EU)\n 2025/301 of 23 October 2024 supplementing Regulation (EU)\n 2022/2554 of the European Parliament and of the Council\n with regard to regulatory technical standards specifying\n the content, timelines and templates on the reporting of\n major ICT-related incidents and significant cyber threats\n (Text with EEA relevance)", 20 February 2025,\n <https://eur-lex.europa.eu/eli/reg_del/2025/301/oj>.\n\n [REG-2025-302]\n European Commission, "Commission Implementing Regulation\n (EU) 2025/302 of 23 October 2024 laying down implementing\n technical standards for the application of Regulation (EU)\n 2022/2554 of the European Parliament and of the Council\n with regard to the standard forms, templates, and\n procedures for financial entities to report a major ICT-\n related incident and to notify a significant cyber threat\n (Text with EEA relevance)", 20 February 2025,\n <https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj>.\n\n [REG-2024-1772]\n European Commission, "Commission Delegated Regulation (EU)\n 2024/1772 of 13 March 2024 supplementing Regulation (EU)\n 2022/2554 of the European Parliament and of the Council\n with regard to regulatory technical standards specifying\n the criteria for the classification of ICT-related\n incidents and cyber threats, setting out materiality\n thresholds and specifying the details of reports of major\n incidents (Text with EEA relevance)", 25 June 2024,\n <https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj>.\n\n [MIFID2] European Parliament and Council, "Directive 2014/65/EU of\n the European Parliament and of the Council of 15 May 2014\n on markets in financial instruments and amending Directive\n 2002/92/EC and Directive 2011/61/EU (recast) (Text with\n EEA relevance)", 12 June 2014,\n <https://eur-lex.europa.eu/eli/dir/2014/65/oj>.\n\nGomes Marques Expires 21 January 2027 [Page 76]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [REG-2017-565]\n European Commission, "Commission Delegated Regulation (EU)\n 2017/565 of 25 April 2016 supplementing Directive 2014/65/\n EU of the European Parliament and of the Council as\n regards organisational requirements and operating\n conditions for investment firms and defined terms for the\n purposes of that Directive (Text with EEA relevance)", 31\n March 2017,\n <https://eur-lex.europa.eu/eli/reg_del/2017/565/oj>.\n\n [AMLD] European Parliament and Council, "Directive (EU) 2015/849\n of the European Parliament and of the Council of 20 May\n 2015 on the prevention of the use of the financial system\n for the purposes of money laundering or terrorist\n financing, amending Regulation (EU) No 648/2012 of the\n European Parliament and of the Council, and repealing\n Directive 2005/60/EC of the European Parliament and of the\n Council and Commission Directive 2006/70/EC (Text with EEA\n relevance)", 5 June 2015,\n <https://eur-lex.europa.eu/eli/dir/2015/849/oj>.\n\n [AMLR] European Parliament and Council, "Regulation (EU)\n 2024/1624 of the European Parliament and of the Council of\n 31 May 2024 on the prevention of the use of the financial\n system for the purposes of money laundering or terrorist\n financing (Text with EEA relevance)", 19 June 2024,\n <https://eur-lex.europa.eu/eli/reg/2024/1624/oj>.\n\n [NIST-AI-RMF]\n National Institute of Standards and Technology,\n "Artificial Intelligence Risk Management Framework (AI RMF\n 1.0)", NIST AI 100-1, DOI 10.6028/NIST.AI.100-1, 26\n January 2023,\n <https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>.\n\n [COLORADO-AI-ACT]\n State of Colorado, Seventy-Fourth General Assembly,\n "Senate Bill 24-205, Consumer Protections for Artificial\n Intelligence", 17 May 2024,\n <https://leg.colorado.gov/bills/sb24-205>.\n\n [TEXAS-TRAIGA]\n State of Texas, 89th Legislature, Regular Session, "House\n Bill 149, Texas Responsible Artificial Intelligence\n Governance Act", 22 June 2025,\n <https://capitol.texas.gov/BillLookup/\n History.aspx?LegSess=89R&Bill=HB149>.\n\nGomes Marques Expires 21 January 2027 [Page 77]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [HIPAA-SECURITY]\n United States Department of Health and Human Services,\n "HIPAA Security Rule, 45 CFR Part 164, Subpart C, Security\n Standards for the Protection of Electronic Protected\n Health Information", 20 February 2003,\n <https://www.ecfr.gov/current/title-45/subtitle-A/\n subchapter-C/part-164>.\n\n [NYDFS-500]\n New York State Department of Financial Services, "23 NYCRR\n Part 500, Cybersecurity Requirements for Financial\n Services Companies", 1 March 2017,\n <https://www.dfs.ny.gov/industry-guidance/cybersecurity>.\n\n [SEC-17A-4]\n United States Securities and Exchange Commission,\n "Electronic Recordkeeping Requirements for Broker-Dealers,\n Security-Based Swap Dealers, and Major Security-Based Swap\n Participants (Rule 17a-4 Amendments)", 3 November 2022,\n <https://www.federalregister.gov/\n documents/2022/11/03/2022-22670/electronic-recordkeeping-\n requirements-for-broker-dealers-security-based-swap-\n dealers-and-major>. Effective date January 3, 2023;\n compliance date for amendments to 17 CFR 240.17a-4 May 3,\n 2023.\n\n [CIRCIA] United States Congress, "Cyber Incident Reporting for\n Critical Infrastructure Act of 2022, enacted as Division Y\n of the Consolidated Appropriations Act, 2022 (Public Law\n 117-103); statutory authority codified at 6 U.S.C. 681 et\n seq.", 15 March 2022,\n <https://www.congress.gov/117/plaws/publ103/PLAW-\n 117publ103.pdf>. Public Law 117-103 was enacted on March\n 15, 2022. Implementing regulations are proceeding under a\n CISA notice of proposed rulemaking at 89 FR 23644 (April\n 4, 2024); the final rule is pending publication.\n\n [DRAFT-SHARIF-APKI]\n Independent, "Agent Public Key Infrastructure (APKI):\n Certificate-Based Identity and Trust for Autonomous AI\n Agents", Work in Progress, Internet-Draft, draft-sharif-\n apki-agent-pki-00, 2025,\n <https://datatracker.ietf.org/doc/draft-sharif-apki-agent-\n pki/>. Active Independent Submission on the IETF\n Datatracker; defines a certificate-based PKI for\n autonomous AI agents. Cited under Section 12 as parallel\n work on the identity-anchoring surface complementary to\n this profile's per-action receipt format.\n\nGomes Marques Expires 21 January 2027 [Page 78]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [DRAFT-SHARIF-AML]\n Independent, "Cryptographic Attestation for AI Model\n Lifecycle: From Training Data to Inference Output", Work\n in Progress, Internet-Draft, draft-sharif-ai-model-\n lifecycle-attestation-00, 2025,\n <https://datatracker.ietf.org/doc/draft-sharif-ai-model-\n lifecycle-attestation/>. Active Independent Submission on\n the IETF Datatracker; defines cryptographic attestation\n across the AI model lifecycle from training- data\n provenance to inference-time output binding. Cited under\n Section 12 as parallel work on the model-build and model-\n evaluation surface complementary to this profile's per-\n action receipt format.\n\n [PIPELOCK-ER2]\n Pipelock, "EvidenceReceipt v2: An Alternative Receipt\n Format for AI Agent Actions", 2025,\n <https://github.com/luckyPipewrench/pipelock>. Public\n reference published outside the IETF process, documented\n in the project's open-source repository. Cited under\n Section 12 as an alternative receipt-format proposal under\n different envelope, canonicalization, and anchoring\n choices; byte-equality across the two formats is not\n preserved.\n\n [LYRIE-ATP]\n OTT Cybersecurity, "Agent Trust Protocol (ATP)", 2026,\n <https://atp.lyrie.ai>. Open cryptographic trust\n framework for AI agent identity published outside the IETF\n process, defining an Agent Identity Certificate, a Scoped\n Authorization Token, a Tamper-Evident Action Log of hash-\n chained signed action records, a Delegation Receipt, and a\n Runtime Attestation Bundle. Cited under Section 12 as\n parallel work whose Tamper-Evident Action Log overlaps\n this profile's per-action receipt surface and whose\n identity and delegation primitives sit on the identity-\n anchoring layer beneath it.\n\nGomes Marques Expires 21 January 2027 [Page 79]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [A2A] A2A Project, a Linux Foundation project, "Agent2Agent\n (A2A) Protocol", 2025,\n <https://github.com/a2aproject/A2A>. Vendor-neutral\n horizontal protocol for communication between independent\n agents, hosted as a Linux Foundation project. Defines an\n Agent Card, an extension mechanism, and a JSON Web\n Signature over the Agent Card document. Cited under\n Section 12 as parallel work on the agent- interoperation\n surface complementary to this profile's per-action receipt\n format; A2A is method-agnostic on identity verification\n and does not define a regulator-facing per-action receipt\n format.\n\n [A2A-IDF] A2A Project contributors, "Agent Identity Verification and\n Trust Framework (A2A-IDF)", 2026,\n <https://github.com/a2aproject/A2A/issues/1497>. Identity\n and trust-framework proposal under the A2A protocol\n contribution process, defining tiered verification levels,\n Agent Card signing, revocation, and delegation-chain\n verification. Cited under Section 12 as parallel work on\n the identity-anchoring layer beneath this profile's per-\n action receipts; post-quantum cryptography is scheduled\n for a later cycle.\n\n [DRAFT-HOPLEY-X402]\n Hopley, C., "x402 Compliance Receipt", Work in Progress,\n Internet-Draft, draft-hopley-x402-compliance-receipt-02,\n 25 May 2026, <https://datatracker.ietf.org/doc/draft-\n hopley-x402-compliance-receipt/>. Independent Submission,\n Informational. Defines a JCS-canonicalized, SHA-256 hash-\n chained Compliance Receipt carrying an ALLOW, REFER, or\n DENY admission verdict bound to a payment mandate under\n the x402 payment substrate. Cited under Section 12 as the\n closest parallel receipt format; this profile is the\n broader superset (general agent-action receipts, neutral\n third-party signing, organization-wide control\n attestation, ML-DSA-65) and that draft is narrowed to\n payment anti- money-laundering and sanctions-screening\n admission decisions.\n\n [RFC9943] IETF SCITT Working Group, "An Architecture for Trustworthy\n and Transparent Digital Supply Chains", RFC 9943, June\n 2026, <https://www.rfc-editor.org/info/rfc9943>.\n Published as RFC 9943 (Proposed Standard), the Supply\n Chain Integrity, Transparency, and Trust (SCITT)\n architecture defining an append-only Transparency Service\n that issues inclusion-proof receipts over signed\n statements; formerly the Internet-Draft draft-ietf-scitt-\n\nGomes Marques Expires 21 January 2027 [Page 80]\nInternet-Draft Compliance Receipts Profile July 2026\n\n architecture. Cited under Section 12 as canonical\n inclusion-proof prior art complementary to this profile's\n witness_policy; a SCITT Transparent Statement can carry a\n Compliance Receipt as its payload.\n\n [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate\n Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,\n <https://www.rfc-editor.org/info/rfc6962>. Defines the\n Merkle-tree inclusion-proof model for an append-only\n public log. Cited under Section 12 as the foundational\n inclusion-proof prior art that this profile's\n witness_policy generalizes to an N-of-M quorum over\n heterogeneous durable-anchoring witnesses.\n\n [IN-TOTO-ATTESTATION]\n in-toto project, a Cloud Native Computing Foundation\n project, "in-toto Attestation Framework", 2024,\n <https://github.com/in-toto/attestation>. Specification\n for authenticated metadata about software supply-chain\n artifacts, binding a subject artifact digest to a\n predicate of provenance claims. Cited under Section 12 as\n parallel work on the build-and-provenance surface\n complementary to this profile's code- authorship receipt\n format.\n\n [DRAFT-NELSON-DELEGATION]\n Independent, "Agent Delegation Receipts", Work in\n Progress, Internet-Draft, draft-nelson-agent-delegation-\n receipts, 2025, <https://datatracker.ietf.org/doc/draft-\n nelson-agent-delegation-receipts/>. Individual Internet-\n Draft proposing a delegation-receipt format that records\n scoped authority delegated between agent principals and\n the resulting authorization chain. Cited under Section 12\n as parallel work on the delegation-and-authorization\n surface complementary to this profile's code-authorship\n and per-action receipt format.\n\nGomes Marques Expires 21 January 2027 [Page 81]\nInternet-Draft Compliance Receipts Profile July 2026\n\n [DRAFT-SHARIF-AAT]\n Sharif, R., "Agent Audit Trail: A Standard Logging Format\n for Autonomous AI Systems", Work in Progress, Internet-\n Draft, draft-sharif-agent-audit-trail-00, March 2026,\n <https://datatracker.ietf.org/doc/draft-sharif-agent-\n audit-trail/>. Individual Internet-Draft defining a JSON-\n based structured logging format for autonomous AI systems\n with compliance mapping to the EU AI Act, SOC 2, ISO/IEC\n 42001, and PCI DSS v4.0.1. Cited under Section 12 as\n parallel work on the per-system audit-log surface\n complementary to this profile's cryptographically signed,\n hash-chained, third-party- signed per-action receipt\n format.\n\n [DRAFT-NARAJALA-ANSv2]\n Courtney, S., Narajala, V. S., Huang, K., Habler, I., and\n A. Sheriff, "Agent Name Service v2 (ANS): A Domain-\n Anchored Trust Layer for Autonomous AI Agent Identity",\n Work in Progress, Internet-Draft, draft-narajala-courtney-\n ansv2-01, April 2026, <https://datatracker.ietf.org/doc/\n draft-narajala-courtney-ansv2/>. Individual Internet-\n Draft defining a domain-anchored trust layer for\n autonomous AI agent identity through a dual-certificate\n model and a cryptographic Transparency Log. Cited under\n Section 12 as parallel work on the naming and identity-\n anchoring surface complementary to this profile's per-\n action receipt format; this profile's receipts are signed\n by an operator unaffiliated with the agent's operator,\n providing a per- action trust guarantee independent of the\n identity anchor.\n\nWorked Example (Informative)\n\n This appendix illustrates a Compliance Receipt that satisfies the EU\n AI Act Article 26 binding for a tool invocation by a High-Risk AI\n System deployed by a Financial Entity. The wire shape applies\n identically to United States bindings; the only differences are the\n values placed in issuer_id (LEI, EIN, or CIK depending on the regime)\n and in the risk_class and incident_class vocabularies referenced in\n the Audit Pack manifest. Field values are abbreviated for\n readability and are not cryptographically valid. The example shows a\n mid-chain receipt; a chain-genesis receipt would carry a\n previousReceiptHash of 64 zero hex characters per Section 5.3.\n\n The worked example below is illustrative. The digest-valued fields\n (action_ref, policy_digest, the hash member of payload_digest, and\n previousReceiptHash) are shown abbreviated with an internal ellipsis\n so each line fits the column width; a real receipt carries the full\n\nGomes Marques Expires 21 January 2027 [Page 82]\nInternet-Draft Compliance Receipts Profile July 2026\n\n 64-character lowercase hex digest. The keys are shown in human-\n readable order rather than JCS-canonical lexicographic order; the\n JCS-canonical bytes used as input to SHA-256 reorder keys\n lexicographically (so the on-the-wire byte order for hashing is\n action_ref, decision, issued_at, issuer_id, iteration_id,\n payload_digest, policy_digest, previousReceiptHash, reason,\n risk_class, sandbox_state, tool_name, type, with each nested object's\n keys also lexicographically sorted, per [RFC8785]). The sig value,\n the anchors value entries, and the hash hex values are deterministic\n placeholders chosen for shape rather than cryptographic validity.\n Implementations MUST NOT replay or trust this example as a real\n receipt; the example is not signed by any allocated issuer_id, is not\n anchored against any TSA or OpenTimestamps calendar, and does not\n chain into any retained predecessor.\n\nGomes Marques Expires 21 January 2027 [Page 83]\nInternet-Draft Compliance Receipts Profile July 2026\n\n {\n "payload": {\n "type": "protectmcp:decision",\n "issued_at": "2026-05-04T09:14:22.118Z",\n "issuer_id": "00000000000000000098",\n "action_ref": "c1f3a09a4d2e7f6b8c5a91e3d7b04f2a...3c5e7f9d",\n "tool_name": "deploy",\n "iteration_id": "task-2026-05-04-01a3",\n "decision": "allow",\n "reason": "policy:within_limits",\n "policy_digest": "sha256:7b214e8c3d9f4a2b1e6c8f5a...1f3a5d7b",\n "sandbox_state": "enabled",\n "payload_digest": {\n "hash": "0a44d2c8e3f5b7a9d1c4e6f8b2a5d7c9...e7f9b2a4",\n "size": 1024\n },\n "previousReceiptHash": "f80c11a3b5d7e9c2f4a6b8d1...b8d1e3c5",\n "risk_class": "deployer:financial:medium"\n },\n "signature": {\n "alg": "EdDSA",\n "kid": "00000000000000000098",\n "sig": "..."\n },\n "anchors": [\n {\n "type": "rfc3161",\n "value": "..."\n },\n {\n "type": "opentimestamps",\n "value": "..."\n }\n ]\n }\n\n The above receipt satisfies the Article 26 binding because:\n\n * issuer_id is a 20-character ISO 17442 Legal Entity Identifier\n (LEI) that resolves through the trust anchor metadata in the Audit\n Pack to the named Deployer;\n\n * policy_digest resolves to a retained policy artefact;\n\n * sandbox_state is enabled, satisfying the High-Risk system\n constraint of Section 5.1.6;\n\nGomes Marques Expires 21 January 2027 [Page 84]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * previousReceiptHash links the receipt into the chain per\n Section 5.3;\n\n * both an [RFC3161] anchor and an [OPENTIMESTAMPS] anchor are\n present per Section 5.4.\n\n Under the DORA Article 17 binding a Compliance Verifier additionally\n checks the longest applicable sectoral retention floor (1827 days as\n the default, per Section 6.3.4) and, where present, that\n incident_class flattens to the canonical vocabulary referenced in\n Section 5.5 (resolved from [REG-2025-302] Annex II field 3.23\n directly). Under the United States bindings of Section 6 the same\n verifier additionally checks the longest applicable retention floor\n (2192 days as the default for receipts under Section 7.4 or\n Section 7.6) and, where the Deployer is a NYDFS Covered Entity, a\n HIPAA Covered Entity, or a CIRCIA Covered Entity, that incident_class\n resolves to the applicable canonical category for each in-scope\n regime.\n\nChange Log\n\n [RFC Editor: please remove this appendix and its subsections before\n publication.]\n\nChanges in draft -07\n\n Reference-maintenance and editorial revision. This revision\n refreshes three reference citations to their current canonical\n locations and adds one parallel Related Work citation. No change to\n any normative requirement, signing algorithm, canonicalization\n transformation (JCS), hash-chain scope, anchor type set, retention\n floor, Audit Pack manifest, verifier reporting field, or IANA\n registry content; a -06 receipt is a conformant -07 receipt.\n\n * The normative [ACTA-RECEIPTS] reference is advanced from the -01\n to the -02 revision of the upstream draft, which is the current\n revision on the IETF Datatracker; the profiled envelope and field\n catalogue this document overlays are unchanged across that\n upstream revision.\n\n * The informative [PIPELOCK-ER2] reference target is updated from\n the retired standalone vendor page to the project's live open-\n source repository, where the EvidenceReceipt v2 format is\n documented; the citation title and framing are otherwise\n unchanged.\n\nGomes Marques Expires 21 January 2027 [Page 85]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * The informative citation for the Supply Chain Integrity,\n Transparency, and Trust architecture, cited in -06 as the\n Internet-Draft draft-ietf-scitt-architecture, is advanced to its\n published form: that draft has since been published as [RFC9943],\n and the reference and its citation label are updated from the\n Internet-Draft to the RFC. The related-work framing is unchanged.\n\n * Section 12 is extended with a cite of [LYRIE-ATP] (the Agent Trust\n Protocol, an open cryptographic trust framework for AI agent\n identity published outside the IETF process), framed as parallel\n work whose Tamper-Evident Action Log of hash-chained signed action\n records overlaps this profile's per-action receipt surface and\n whose identity and delegation primitives sit on the identity-\n anchoring layer beneath it. New informative reference:\n [LYRIE-ATP].\n\nChanges in draft -06\n\n Risk-acceptance and code-authorship revision. This revision\n registers the risk-acceptance and code-authorship receipt types and\n their extension fields, which the reference cloud implementation, the\n asqav-sdk Python and TypeScript halves, and the published /.well-\n known/governance.json already emit and accept, keeping the IETF\n surface in parity with deployed reality. The additions are additive:\n a -05 receipt is a conformant -06 receipt, and a -06 receipt that\n carries the new fields remains a conformant [ACTA-RECEIPTS] receipt\n under the upstream extension semantics of Section 4.2 (verifiers that\n do not implement the extension ignore it).\n\n * Section 11.2 Initial registry contents are extended with\n protectmcp:lifecycle:risk_acceptance, a registered sub-namespace\n under protectmcp:lifecycle recording a producer's acceptance of a\n known risk, security finding, or policy exception. It signs\n through the no-policy lifecycle path of Section 5.2\n (decision=observation, no policy evaluated), so the false-\n attestation honesty rule is preserved: no policy result is\n asserted.\n\n * New normative Section 5.10 defines the OPTIONAL signed-payload\n extension fields carried on a risk-acceptance receipt: approver_id\n and acceptance_reason (REQUIRED on the type), and OPTIONAL\n initiator_id, accepted_at, supersedes, sarif_digest, finding_ref,\n approval_ref, and the risk_snapshot object (snapshot_at,\n snapshot_source, epss, cvss, cvss_vector, kev_listed, cve_ids).\n The scope-honesty labels are normative: risk_snapshot is a\n producer-asserted snapshot the issuing platform never computes,\n fetches, verifies, queries, or vouches for and that is NOT\n reproducible from any input the platform holds; sarif_digest is a\n\nGomes Marques Expires 21 January 2027 [Page 86]\nInternet-Draft Compliance Receipts Profile July 2026\n\n shape-only existence proof of the scan artifact at issued_at,\n never a re-scan; expires_at on the type is declared, not enforced\n (no auto-revoke); and approver_id and initiator_id are bound\n fields with NO segregation-of-duties check.\n\n * Section 11.1 Initial registry contents are extended with the nine\n new risk-acceptance fields (approver_id, initiator_id,\n acceptance_reason, accepted_at, supersedes, sarif_digest,\n finding_ref, approval_ref, risk_snapshot), each labelled Scope:\n signed-payload, each carrying the normative producer-asserted\n scope labels. The existing expires_at entry is unchanged and is\n reused type-agnostically on the risk-acceptance receipt. Two\n false-attestation guards govern the type:\n risk_acceptance_missing_required_field (rejects a risk-acceptance\n receipt lacking approver_id or acceptance_reason) and\n risk_snapshot_numeric_requires_snapshot_source (rejects any\n populated epss, cvss, cvss_vector, or kev_listed without\n snapshot_source).\n\n * Section 5.4 adds a one-line note that an rfc3161 anchor MAY be\n obtained from a Time-Stamping Authority operated independently of\n the issuer (a public RFC 3161 TSA under a distinct trust root), in\n addition to or instead of an issuer-operated TSA. The\n independently operated TSA is the genuinely independent witness of\n Section 10.6 and is one of the N witnesses of witness_policy,\n never the sole anchor. The baseline single-anchor requirement of\n Section 5.4 is unchanged.\n\n * Section 11.2 Initial registry contents are extended with\n protectmcp:lifecycle:code_authorship, a registered sub-namespace\n under protectmcp:lifecycle recording a producer's assertion that\n an agent-authored change to a code repository existed at a point\n in time. It signs through the no-policy lifecycle path of\n Section 5.2 (decision=observation, no policy evaluated), so the\n false-attestation honesty rule is preserved: no policy result is\n asserted, and the receipt proves only that the change existed, was\n key-authored, and was chained at the receipt time.\n\n * New normative Section 5.11 defines eight signed-payload extension\n fields carried on a code-authorship receipt, repo_ref and\n commit_sha REQUIRED on the type and the rest OPTIONAL: repo_ref,\n commit_sha, base_sha, change_digest, change_ref,\n change_approval_ref, change_class, and the authored_by object\n (agent_id, model_id, model_version, tool, attestation_source).\n The scope-honesty labels are normative: the issuing platform NEVER\n clones the repository, re-diffs the change, verifies the code, or\n verifies the model; change_digest is a shape-only existence proof\n of the change at issued_at never re-diffed; change_class is drawn\n\nGomes Marques Expires 21 January 2027 [Page 87]\nInternet-Draft Compliance Receipts Profile July 2026\n\n from the closed vocabulary read, write, delete, execute, deploy;\n and authored_by model fields (model_id, model_version) require\n attestation_source. Authorization reuses the server-built\n authorized_under_mandate field of Section 5.9; no separate\n authorization field is defined.\n\n * Section 11.1 Initial registry contents are extended with the eight\n new code-authorship fields (repo_ref, commit_sha, base_sha,\n change_digest, change_ref, change_approval_ref, change_class,\n authored_by), each labelled Scope: signed-payload. The\n authored_by_model_requires_attestation_source guard rejects a\n populated model_id or model_version without attestation_source; a\n change_class value outside the closed vocabulary is rejected at\n signing time as an out-of-vocabulary value.\n\n * Section 12 is extended with a cite of [IN-TOTO-ATTESTATION] (the\n in-toto Attestation Framework, parallel work on the build-and-\n provenance surface) and [DRAFT-NELSON-DELEGATION] (Agent\n Delegation Receipts, parallel work on the delegation-and-\n authorization surface), both framed as complementary to the code-\n authorship layer. New informative references:\n [IN-TOTO-ATTESTATION], [DRAFT-NELSON-DELEGATION].\n\n * The abstract and the Section 5.5 overview are extended to\n enumerate the risk-acceptance and code-authorship groupings. No\n changes to the signing algorithms, the canonicalization\n transformation (JCS), the hash-chain scope, the anchor type set,\n the retention floors of Sections 5 and 6, the Audit Pack manifest\n fields, or the verifier reporting fields.\n\nGomes Marques Expires 21 January 2027 [Page 88]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * The deployed guard tokens that the issuing platform publishes in\n its /.well-known/governance.json wire-vocabulary surface are now\n named verbatim where the body defines each behaviour, completing\n the parity that Section 5.10 and Section 5.11 began:\n witness_policy_required_exceeds_confirmed (Section 5.4),\n false_attestation_guard and\n configuration_change_missing_config_manifest_digest and\n result_bound_missing_result_digest (Section 11.2),\n false_mandate_attestation_guard and\n false_control_attestation_guard (Section 5.9), and the code-\n authorship guards\n code_authorship_fields_require_code_authorship_receipt,\n code_authorship_requires_compliance_mode,\n code_authorship_requires_no_policy_decision,\n code_authorship_missing_required_field, and\n change_digest_not_sha256_wire_form (Section 5.11). repo_ref and\n commit_sha are labelled REQUIRED on the code-authorship receipt\n type, matching the deployed validator that rejects a receipt of\n the type lacking either field.\n\n * Section 5.10 names the risk_acceptance_self_approval_guard: the\n reference cloud implementation refuses at signing time a risk-\n acceptance receipt signed under compliance_mode whose initiator_id\n string-equals approver_id, because a receipt asserting an approval\n flow approved by its own initiator is incoherent on its face. The\n guard is a string-incoherence check (case-sensitive exact match),\n not identity resolution; it fires only when both fields are\n present, and an absent field never fires it. The approver_id and\n initiator_id prose and their Section 11.1 registry entries are\n updated to name the guard, matching the deployed validator and the\n published /.well-known/governance.json labels.\n\n * Deployed-vocabulary parity: the OPTIONAL informational member of\n an anchors entry carrying the Bitcoin block hash of an upgraded\n OpenTimestamps commitment is renamed to anchor_block_hash in\n Section 5.4, in the anchors entry of Section 11.1, and in the\n Appendix "Changes in draft -04" recap; the -05 member name tied\n the member to the Bitcoin chain by name, and the new name matches\n the wire key the reference implementation emits.\n\n * The tool_fingerprint wire form in Section 5.7, its Section 11.1\n entry, and the Appendix "Changes in draft -05" recap are corrected\n from sha256:<64 hex> to a bare string of 32 lowercase hexadecimal\n characters, and the digest input is pinned to the JCS\n canonicalization ([RFC8785]) of the JSON object {"tool_name":\n <tool name>, "schema": <declared input schema>}, matching the\n deployed producer and the deployed validator that rejects any\n other form.\n\nGomes Marques Expires 21 January 2027 [Page 89]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * The nonce SHOULD-form in Section 5.7 and its Section 11.1 entry\n are corrected to the lowercase hexadecimal encoding of 12 random\n bytes (24 hexadecimal characters), the form the deployed producer\n emits; the -05 text named base64url and UUID/ULID forms the\n deployed producer does not use.\n\n * The informational payload-capture manifest attribute recommended\n by the -05 text of the Appendix "Appendix - Capture Topologies for\n Compliance Receipt Emission" appendix (the eBPF observer and\n passive-telemetry entries) is struck; the deployed Audit Pack\n manifest builder carries no such attribute.\n\n * The mcp_proxy entry of Appendix "Appendix - Capture Topologies for\n Compliance Receipt Emission" is rewritten to name the manifest\n attributes the deployed Audit Pack builder carries (action_type\n and, where declared, capture_topology) in place of an invoked-\n method attribute the builder does not emit, and the entry's\n reference-implementation hint is dropped: the entry defines the\n topology vocabulary only.\n\n * Normative tightening in Section 5.6.3: where expect_ack_from is\n present, a mismatch between the acknowledging receipt's\n signature.kid and the declared identifier MUST cause the\n acknowledging receipt to be reported non-conformant, exactly as an\n envelope_hash digest mismatch is. This replaces the -05 rule\n under which the check was a SHOULD and a mismatch was reported as\n an axis flag; the check now fails closed, matching the deployed\n verifier. The expect_ack_from field definition in Section 5.6.1\n is updated to point at the tightened rule.\n\n * Section 10.3 adds the JWK Set publication rule for revoked keys:\n where the Deployer publishes verification keys through a well-\n known JWK Set endpoint, a revoked key remains published and its\n entry carries a revoked_at timestamp, so a verifier can pass a\n receipt issued before that instant and fail one issued at or after\n it, matching the deployed endpoint.\n\nChanges in draft -05\n\n Build-provenance and result-bound extension revision. This revision\n registers vocabulary that the reference cloud implementation, the\n asqav-sdk Python and TypeScript halves, and the published /.well-\n known/governance.json already emit and accept, bringing the IETF\n surface back into parity with deployed reality.\n\n * New normative Section 5.7 defines six OPTIONAL signed-payload\n extension fields: result_digest (object of the upstream\n payload_digest shape carrying the downstream Action's result-body\n\nGomes Marques Expires 21 January 2027 [Page 90]\nInternet-Draft Compliance Receipts Profile July 2026\n\n SHA-256), expires_at (ISO 8601 staleness bound additive to the\n 300-second forward-skew rule of Section 5.1.2), nonce (producer-\n unique replay-resistance value), tool_fingerprint (truncated tool-\n declaration SHA-256), config_manifest_digest (operator-defined\n configuration manifest SHA-256), and cve_inventory_digest (CVE\n inventory SHA-256 in effect at signing time). The six fields are\n type-agnostic; result_digest typically appears on receipts of the\n newly registered protectmcp:observation:result_bound namespace.\n\n * New normative Section 5.8 defines a four-tuple of OPTIONAL signed-\n payload extension fields binding the executing build to the\n receipt: executable_hash (OCI image manifest digest for container\n producers, on-disk SHA-256 for non-container executables),\n sbom_digest (CycloneDX or SPDX SBOM SHA-256),\n slsa_provenance_pointer (https URL to the SLSA Provenance v1.0 in-\n toto attestation envelope), and supply_chain_pointer (https URL to\n an in-toto, Sigstore, or Rekor transparency-log entry covering the\n build). The four fields form a layered subsumption set; an\n implementation MAY emit any subset.\n\n * Section 11.1 Initial registry contents are extended with the ten\n new fields registered in this revision (result_digest, expires_at,\n nonce, tool_fingerprint, config_manifest_digest,\n cve_inventory_digest, executable_hash, sbom_digest,\n slsa_provenance_pointer, supply_chain_pointer), each labelled\n Scope: signed-payload. The four pre-existing entries (risk_class,\n incident_class, counterparty_binding, anchors) are unchanged.\n\n * Section 11.2 Initial registry contents are extended with\n protectmcp:observation (a passive-telemetry receipt emitted under\n one of the capture topologies of Appendix "Appendix - Capture\n Topologies for Compliance Receipt Emission" when the originating\n application could not call the SDK directly) and\n protectmcp:observation:result_bound (a follow-up sub-namespace\n under protectmcp:observation for receipts carrying result_digest\n bindings to an originating protectmcp:decision receipt via\n action_ref).\n\n * The abstract and Section 1.1 overview text are rewritten to\n enumerate the full extension-field set in five groupings\n (regulatory classification; cross-agent envelope binding; per-\n action freshness and integrity plus build-provenance; server-built\n enforcement attestation; and self-declared threat-framework\n taxonomy) rather than the legacy "three extension fields" phrasing\n carried forward from -02 through -04. The wire shape, the\n signature scope, the canonicalization rule, the hash chain, and\n the anchoring rules of earlier revisions are unchanged.\n\nGomes Marques Expires 21 January 2027 [Page 91]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * New informative Section 12 cites parallel proposals under the\n Independent Submissions and individual-draft surfaces of the IETF\n Datatracker: [DRAFT-SHARIF-APKI] (certificate-based PKI for\n autonomous AI agents), [DRAFT-SHARIF-AML] (cryptographic\n attestation across the AI model lifecycle), and [PIPELOCK-ER2]\n (the Pipelock EvidenceReceipt v2 alternative receipt-format\n proposal, published as a public reference outside the IETF\n process). The section is non-exhaustive and is informative; this\n profile places no normative constraint on a Compliance Receipt\n implementation by virtue of citing parallel work.\n\n * New informative references: [DRAFT-SHARIF-APKI],\n [DRAFT-SHARIF-AML], [PIPELOCK-ER2].\n\n * The four-tuple of build-provenance extensions in Section 5.8 is\n the wire-level surface of the supply-chain notary use case;\n Deployers under [EU-AI-ACT] Article 12 read together with [DORA]\n Article 17, under 45 CFR 164.312(b) of [HIPAA-SECURITY], and under\n [SEC-17A-4] read with [NYDFS-500] 23 NYCRR 500.6, SHOULD emit at\n least executable_hash on every protectmcp:decision receipt. The\n wording is hortatory; the underlying regime obligations remain the\n load-bearing requirement.\n\n * No changes to the signing algorithms, the canonicalization\n transformation (JCS), the hash-chain scope corrected in\n Appendix "Changes in draft -04", the anchor type set, the\n retention floors of Sections 5 and 6, the Audit Pack manifest\n fields, or the verifier reporting fields. A -04 receipt that\n omits all ten new extensions is a conformant -05 receipt. A -05\n receipt that carries any of the ten new extensions remains a\n conformant [ACTA-RECEIPTS] receipt under the upstream extension\n semantics of Section 4.2 (verifiers that do not implement the\n extension ignore it).\n\n * Threat-framework taxonomy subsumption. New normative Section 5.12\n defines, and Section 11.1 Initial registry contents are further\n extended with, eight additional signed-payload entries that the\n reference cloud implementation, both SDK halves, and the published\n /.well-known/governance.json emit and accept: six caller-supplied\n taxonomy lists (mitre_techniques, mitre_atlas, owasp_llm_top10,\n nist_ai_rmf, iso_42001, eu_ai_act_articles), one caller-supplied\n opaque token (rfc3161_timestamp, a base64-encoded TimeStampResp\n per [RFC3161] preserved verbatim on the receipt for offline TSA\n chain verification independent of any platform-issued anchors),\n and one platform-set false-attestation guard boolean\n (framework_mappings_self_declared, set to true by the issuing\n platform whenever any of the six taxonomy lists is populated; a\n producer-supplied false alongside a populated taxonomy field MUST\n\nGomes Marques Expires 21 January 2027 [Page 92]\nInternet-Draft Compliance Receipts Profile July 2026\n\n be overridden). The taxonomy fields are not platform-verified;\n the guard exists so verifiers can tell self-declared\n classifications apart from platform-verified ones. Pre-existing\n entries are unchanged. The total Initial registry contents now\n enumerate twenty-two signed-payload-or-envelope-level fields.\n\n * Durable-anchoring quorum. Section 5.4 is extended with a\n normative OPTIONAL envelope-level witness_policy member (a sibling\n of payload, signature, and anchors) that the reference cloud\n implementation, both SDK halves, and the published /.well-known/\n governance.json emit and accept. witness_policy declares an N-of-M\n quorum over the anchors array: required (integer in [1, length of\n witnesses]) and witnesses (non-empty array, distinct subset of\n {rfc3161, opentimestamps}; Rekor and other transparency-log\n pointers are rejected). The quorum-met state (reported by the\n reference implementation as witness_quorum_met) is reached only\n when at least required distinct witness types each hold a\n verifiable inclusion proof; a receipt MUST NOT claim durable\n anchoring otherwise, extending the false-attestation principle to\n the anchoring quorum. Section 11.1 Initial registry contents are\n extended with the witness_policy entry, labelled Scope: envelope-\n level, bringing the total to twenty-three signed-payload-or-\n envelope-level fields. The baseline single-anchor requirement of\n Section 5.4 is unchanged and continues to apply to every\n Compliance Receipt regardless of whether witness_policy is\n present.\n\n * Section 12 is extended with a cite of [RFC9943] (IETF SCITT\n architecture) and [RFC6962] (Certificate Transparency Merkle\n inclusion) as the canonical inclusion-proof prior art that\n witness_policy generalizes; SCITT is framed as complementary (a\n SCITT Transparent Statement can carry a Compliance Receipt as its\n payload), closing the append-only-log gap deferred under\n Section 10.12. New informative references: [RFC9943], [RFC6962].\n\n * Enforcement-attestation extensions. New normative Section 5.9\n defines two OPTIONAL server-built signed-payload extension fields\n that the reference cloud implementation and the published /.well-\n known/governance.json emit: authorized_under_mandate (an object\n recording a self-declared authorizing mandate with mandate_id,\n issuer_id, a scope_digest over the mandate's authorized-action-\n types scope, and a verified boolean whose true value asserts self-\n declared issuer authority, never platform-verified third-party\n authorization; the binding is evaluated against the issuing\n platform's clock and scoped to action types, with no value cap and\n no counterparty restriction) and controls_evaluated (a server-\n built enumeration of which enforcement controls genuinely fired on\n the sign, drawn from the closed key set emergency_halt,\n\nGomes Marques Expires 21 January 2027 [Page 93]\nInternet-Draft Compliance Receipts Profile July 2026\n\n delegation_scope, quorum, mandate, policy, content_scan, result,\n where an absent key means the control did not run rather than that\n it passed silently). Both fields are server-built, never request\n inputs; a caller-supplied value is dropped before signing. Each\n field carries a false-attestation guard that rejects a present-\n but-malformed attestation at signing time. Section 11.1 Initial\n registry contents are extended with the two new entries, each\n labelled Scope: signed-payload, bringing the total to twenty-five\n signed-payload-or-envelope-level fields.\n\n * Section 12 is further extended with a cite of [A2A] (the\n Agent2Agent protocol, a Linux Foundation project with an Agent\n Card, an extension mechanism, and an Agent Card JSON Web\n Signature), [A2A-IDF] (the Agent Identity Verification and Trust\n Framework proposal under the A2A contribution process, framed as\n the identity-anchoring layer beneath this profile's per-action\n receipts), and [DRAFT-HOPLEY-X402] (the closest parallel receipt\n format: a JCS-canonicalized, SHA-256 hash-chained Compliance\n Receipt with an ALLOW, REFER, or DENY admission verdict bound to a\n payment mandate under the x402 substrate). This profile is framed\n as the broader superset of the x402 format: general agent-action\n receipts across regulatory regimes rather than payment screening\n alone, neutral third-party signing rather than self-signing by the\n screening party, organization-wide control attestation via\n controls_evaluated rather than a single admission verdict, and ML-\n DSA-65 post-quantum signing. New informative references: [A2A],\n [A2A-IDF], [DRAFT-HOPLEY-X402].\n\nChanges in draft -04\n\n Cross-agent integrity revision. The threat case is a compromised\n intermediary that swaps payload bytes between two honest agents while\n both per-agent hash chains validate independently.\n\n * Section 5.3 digest-scope correction. The chain-link digest scope\n is the canonical signing-input bytes (the JCS-canonical\n serialization of the predecessor's signed payload object, the same\n bytes the predecessor's signature covers), NOT the envelope object\n that additionally includes the signature or anchors top-level\n keys. The earlier -04 text that said the digest covers "the\n entire signed receipt object including the signature field" was a\n Security Considerations over-reach that did not match the\n reference implementation and would have required every deployed\n chain to be re-issued. The corrected scope matches both the\n reference implementation and the upstream [ACTA-RECEIPTS]\n Section 5.7 rule. The security rationale is updated accordingly:\n the chain binds the signed-over content of the predecessor\n (recomputable offline from the predecessor's payload alone), and\n\nGomes Marques Expires 21 January 2027 [Page 94]\nInternet-Draft Compliance Receipts Profile July 2026\n\n cross-agent envelope-including-signature integrity is delegated to\n counterparty_binding (Section 5.6), which IS at the envelope-\n including-signature scope precisely because the peer signature is\n the load-bearing artefact in that case. Section 9.1 is updated to\n match.\n\n * New informative Section 10.2 in Security Considerations\n acknowledges that the single-linear per-agent chain rule of\n Section 5.3 creates a per-issuer serialization bottleneck: a\n denial-of-service against the predecessor pointer (database lock,\n network partition, slow IO) bounds chain throughput. Mitigation:\n issuers SHOULD use bounded predecessor-lookup timeouts, emit a\n structured protectmcp:lifecycle audit event with a stable\n chain_emission_blocked reason code when the timeout fires, and\n document a chain-head recovery procedure for crashed emitters.\n Parallel per-issuer throughput beyond a single linear chain\n remains the existing distinct-issuer_id escape hatch.\n\n * Section 10.12 residual list is rewritten for honesty. The M+B\n collusion residual is downgraded from "M+B alone defeats\n counterparty_binding" to "M+B+(A's-storage compromise or\n unavailability) defeats counterparty_binding": the audit-time\n verifier resolves receipt_ref to A's retained envelope and\n recomputes the digest, so an honest reachable A's storage defeats\n M+B collusion alone. A new M+A collusion residual is added: M and\n A coordinating to produce a fraudulent A-signed envelope is\n fundamentally outside the receipt model's threat surface because\n every cryptographic invariant holds; mitigation is separation of\n duties between issuer and intermediary plus anchor evidence on\n independent witnesses under different trust roots.\n\n * The worked-example appendix carries an explicit disclaimer that\n the keys are shown in human-readable order (not JCS-canonical\n lexicographic order), the sig/value/hash bytes are deterministic\n placeholders, and implementations MUST NOT replay or trust the\n example as a real receipt. The disclaimer states the JCS-\n canonical key ordering that an implementer would derive on the\n wire.\n\n * Section 5.6.1 envelope_hash rule is tightened on three axes.\n First, the base64 alphabet is no longer ambiguous: standard base64\n per [RFC4648] Section 4 on emission, OR base64url per Section 5\n where the transport requires URL-safe encoding, and verifiers MUST\n accept both and normalise before comparison. Second, JSON-framed\n digest scope is now normative and mandatory-to-implement: the JCS-\n canonical UTF-8 byte sequence of A's signed envelope JSON object\n per [RFC8785], where the envelope is the three-key object\n {"payload", "signature", "anchors"} with anchors OPTIONAL and B\n\nGomes Marques Expires 21 January 2027 [Page 95]\nInternet-Draft Compliance Receipts Profile July 2026\n\n forbidden from re-canonicalizing or stripping any of the three\n keys before computing the digest. Third, cross-framing\n equivalence is explicitly addressed: JCS-canonical JSON, COSE\n deterministic encoding, and JWS Compact Serialization with JCS-\n canonical payload produce different byte sequences from the same\n semantic payload-and-signature, so envelope_hash is framing-\n specific; a transcoding intermediary that re-frames A's envelope\n MUST be treated as a tampering event, and verifiers MUST NOT\n reframe before recomputing.\n\n * Section 11.1 entries now carry an explicit Scope tag (signed-\n payload for risk_class, incident_class, counterparty_binding;\n envelope-level for anchors). The CWT claim request for\n counterparty_binding now proposes allocation from the IANA First\n Come First Served range of [RFC8392] Section 9.1 rather than the\n unqualified "unassigned integer range" placeholder, so as not to\n consume Expert Review or Standards Action space.\n\n * The [CIRCIA] reference is corrected to cite the statutory\n authority (Public Law 117-103 Division Y, codified at 6 U.S.C. 681\n et seq.) rather than CISA's general topic page; the March 15, 2022\n enactment date is retained, and the pending NPRM at 89 FR 23644\n (April 4, 2024) is named in the reference annotation.\n\n * New normative Section 4.6 (Section 5.6) defines the\n counterparty_binding extension field, an in-payload object\n carrying a base64-encoded SHA-256 digest (envelope_hash) over the\n full signed envelope of a peer agent (including the peer's\n signature bytes), a resolvable opaque receipt_ref, an OPTIONAL\n expect_ack_from identifier (kid/issuer_id of the expected\n acknowledger), and an OPTIONAL operational transport_label.\n Section 4.6.3 (Section 5.6.3) defines the MUST-reject rule when\n the bound digest does not resolve, the storage obligation on the\n Audit Pack production layer, and the pairwise default for N-\n greater-than-2 chains.\n\n * The anchors top-level array schema is now defined inline in\n Section 5.4: each entry MUST carry type and value (base64-encoded\n anchor token bytes), with OPTIONAL informational status (anchored\n / pending / failed) and anchor_block_hash (Bitcoin block hash for\n upgraded OpenTimestamps entries). The IANA Extension Fields\n Registry entry for anchors is updated to reflect the four-member\n schema.\n\n * The IANA Type Namespaces Registry initial contents now include the\n registered sub-namespace protectmcp:lifecycle:configuration_change\n emitted by the reference cloud implementation for configuration-\n change receipts under Section 6.1.1.\n\nGomes Marques Expires 21 January 2027 [Page 96]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * CIRCIA retention floor (Section 7.7.2) is rewritten to measure two\n years from the submission of the most recently required CIRCIA\n report per proposed Section 226.13(c) of the CIRCIA NPRM at 89 FR\n 23644 (April 4, 2024), not from the date of the underlying Action.\n\n * HIPAA retention (Section 7.4.2) is rewritten to cite 45 CFR\n 164.316(b)(2) with the six-year floor expressed as "six years from\n the date of creation or the date when last in effect, whichever is\n later" and the analogy basis for applying that floor to audit-log\n content explicitly named.\n\n * EU AI Act Article 26(6) retention (Section 6.1.5) is rewritten to\n express the six-month floor in calendar-arithmetic terms per\n [ISO8601-2]; the 184-day day-count figure is retained as an\n informative anchoring-interval floor, and the previously-endorsed\n 183-day pick is withdrawn.\n\n * Section 5.1.3 now states explicitly that issuer_id values MUST be\n bare identifiers without a scheme prefix where the scheme is\n unambiguous (LEI: 20-character alphanumeric self-identifying\n form), aligning the spec with the reference cloud emitter under\n the cloud-wire-conformance change.\n\n * New informative Section 9.11 (Section 10.12) documents the\n residual threat that counterparty_binding partially mitigates (M\n silently swaps bytes between honest A and B) and names three\n operational mitigations Operators SHOULD adopt: multiple\n independent anchor witnesses, regulator-driven side-by-side chain\n comparison under SEC 17a-4 audit-trail workflow, and out-of-band M\n relay logs.\n\n * Section 7 (Section 8) records two manifest-level fields shipped in\n the reference Audit Pack producer: regime_mapping_disclaimer (when\n per-receipt regime predicates derive from a producer-side mapping\n the original signer did not co-sign) and stale_pending (per-entry\n flag set when anchor evidence remains pending after the bound of\n Section 5.4).\n\n * Section 8.3 (Section 9.3) replaces the prior one-paragraph clause\n with five SHOULD-emit per-axis fields: regimes_satisfied,\n anchor_valid_ots, anchor_valid_rfc3161, policy_digest_resolved,\n duplicate_emission_candidate.\n\nGomes Marques Expires 21 January 2027 [Page 97]\nInternet-Draft Compliance Receipts Profile July 2026\n\n * New informative Section 9.9 (Section 10.10) enumerates the\n residuals counterparty_binding does not solve. New informative\n Section 9.10 (Section 10.11) records channel-level operator\n guidance citing [RFC8446], [RFC9266], [RFC5705], and [RFC9421] and\n disclaims transport-layer security as a substitute for\n application-layer byte equality.\n\n * Section 11 (Section 11) adds counterparty_binding to the Extension\n Fields Registry and requests registration as a CWT claim per\n [RFC8392].\n\n * New normative references: [RFC9052], [RFC8949], [RFC7515],\n [RFC8392]. New informative references for channel-level guidance\n only: [RFC8446], [RFC5705], [RFC9266], [RFC9421].\n\n * New normative Section 4 bounds the inputs to which the inherited\n JCS rule of [RFC8785] is applied: IEEE-754 floating-point numbers\n MUST NOT appear in the digest-covered canonical form (callers\n SHOULD serialize numerics as JSON strings or as integer-rational\n pairs in the IEEE-754 safe range), and tool-version-specific\n semantic equivalence (SQL case folding, path normalization,\n locale-aware string collation, numeric tolerance, URL percent-\n encoding choices) is OUT OF SCOPE for the chain layer. The chain\n answers byte equality for one agent identity at one wall-clock\n time only; semantic equivalence belongs in the policy_digest\n artefact and the Audit Pack manifest.\n\n * Section 5.3 now states explicitly that each issuer MUST maintain a\n single linear per-agent chain and MUST serialize concurrent in-\n agent emission (parallel tool calls, thread-pool fan-out) through\n a single predecessor pointer in emission order. Parallel sub-\n chains within one agent identity (a per-receipt chain_id\n discriminator) are NOT defined by this profile; an issuer that\n requires parallel sub-chains MUST express each parallel path as a\n distinct agent identity with its own issuer_id, signing key, and\n chain rooted at the all-zero genesis value.\n\n * Wire tightenings introduced in this revision (additive at the\n message level, restrictive at the verifier level): (a) the anchors\n entry value member is now REQUIRED where the upstream profile\n leaves it OPTIONAL; (b) issuer chains are normatively single-\n linear per issuer (no parallel chain_id discriminator), so a -03\n producer that ran parallel sub-chains under one issuer_id emits\n non-conformant -04 receipts; and (c) IEEE-754 floating-point\n numbers MUST NOT appear in the canonical form covered by SHA-256\n digests. A -03 receipt with a missing anchor value, parallel sub-\n chains, or a digest-covered float is not a conformant -04 receipt.\n Implementations targeting -04 SHOULD re-emit -03 receipts under\n\nGomes Marques Expires 21 January 2027 [Page 98]\nInternet-Draft Compliance Receipts Profile July 2026\n\n -04 emission rules. The signing algorithms, the canonicalization\n transformation itself (JCS), the anchor types, and the regime\n bindings of Sections 5 and 6 are unchanged. A -03 verifier\n remains conformant for receipts that do not carry\n counterparty_binding; -03 verifiers encountering the field will\n ignore it per [ACTA-RECEIPTS] Section 4.2 extension semantics.\n\n * Rationale paragraph of Section 4 is rewritten to ground the\n IEEE-754 float ban on documented divergence between mainstream\n JSON serializers (Python json.dumps, Go encoding/json, Java\n Jackson) and the ECMA-262 Number-to-String algorithm referenced by\n Section 3.2.2.3 of [RFC8785], rather than on a misstated claim\n that JCS itself fails to specify float serialization outside the\n safe integer range. The Unicode-normalization bullet of Section 4\n is corrected to acknowledge that Section 3.1 of [RFC8785] mandates\n as-is preservation of Unicode strings (no NFC default).\n\n * Security Considerations Section 10.1 is corrected to reflect the\n tiered DORA deadlines: the four-hour initial-notice clock (with\n 72-hour intermediate-report and one-month final-report bounds) per\n DORA Article 17 and the RTS in [REG-2025-301], rather than a flat\n 72-hour reporting deadline. New informative reference\n [REG-2025-301] added.\n\n * The Annex II field 3.23 (Type of the incident) citation in\n Section 5.5 and the incident_class initial-registry entry of\n Section 11.1 no longer reproduces the enumeration verbatim;\n verifiers MUST resolve the canonical values from [REG-2025-302]\n directly.\n\n * Section 5.2 extends the wire decision vocabulary with observation,\n a fourth value reserved to type protectmcp:lifecycle for receipts\n emitted when an Action was signed without any policy evaluation.\n The new value is the regulator-honest alternative to a misleading\n allow on the "no policy matched" path; emitters MUST refuse to\n issue a protectmcp:decision receipt that carries observation, and\n verifiers MUST reject the combination. The vocabulary-namespace\n registry entry for protectmcp:decision in Section 11.2 is updated\n to reflect that observation is reserved to protectmcp:lifecycle.\n\n * New informative appendix (Appendix "Appendix - Capture Topologies\n for Compliance Receipt Emission") catalogues six capture\n topologies an operator can use to emit conformant Compliance\n Receipts in environments where the originating application code\n cannot be modified to call the receipt-emitting SDK directly:\n in_process_sdk, network_proxy, browser_extension, ebpf_observer,\n mcp_proxy, passive_telemetry. The appendix is non-normative; the\n capture_topology attribute it defines is OPTIONAL at the wire\n\nGomes Marques Expires 21 January 2027 [Page 99]\nInternet-Draft Compliance Receipts Profile July 2026\n\n layer and, where present, lives in the Audit Pack manifest entry\n rather than inside the signed payload object, so the topology\n declaration does not alter signed bytes. The six values form a\n closed initial vocabulary at this revision;\n Appendix "capture_topology Vocabulary and Considerations for a\n Future IANA Registry" sketches a future "Compliance Receipt\n Capture Topologies" IANA registry under the "Compliance Receipts"\n registry group with Specification Required registration policy per\n [RFC8126] for a follow-on revision, and names reserved-value\n avoidance guidance for early extenders.\n\nChanges in draft -03\n\n Multi-jurisdiction consolidation. The European Union profile\n (formerly the only profile in -02) and the United States profile\n (formerly the separate draft draft-marques-asqav-us-compliance-\n receipts-00) are merged into a single document with two regional\n bindings sections: Section 5 (European Union) and Section 6 (United\n States). Sections 1 through 4 (Introduction, Conventions,\n Relationship to upstream, Receipt Field Profile) and Sections 7\n through 11 (Audit Pack, Verifier, Security, IANA, Acknowledgements)\n are shared across both regimes. Conventions terms that differ across\n regimes are now disambiguated with regime suffixes (Deployer (EU AI\n Act) vs Deployer (Colorado AI Act); High-Risk AI System (EU AI Act)\n vs High-Risk AI System (Colorado AI Act)). The incident_class\n extension field now lists every applicable canonical category in one\n place: ICT-related incident under [DORA] with the Annex II reporting\n enumeration, Cybersecurity Event/Incident under [NYDFS-500], Covered\n Cyber Incident under [CIRCIA], and security incident under\n [HIPAA-SECURITY]. The issuer_id rule now permits EIN or CIK as\n alternatives to LEI for US Deployers without an allocated LEI. The\n Tamper Resistance security consideration extends the one-hour\n anchoring SHOULD to NYDFS 500.17 and CIRCIA in addition to DORA\n Article 17. The Privacy security consideration extends to GDPR for\n EU data subjects and CCPA / VCDPA / HIPAA Privacy Rule for US data\n subjects. The Worked Example notes that the wire shape applies\n identically to US bindings, with only the issuer_id identifier and\n the vocabularies differing. IANA registries are unchanged; the\n Initial registry contents for incident_class now describe the multi-\n regime category set. No changes to the wire format, the field\n profile, the hash chain, the anchoring rules, the Audit Pack\n contents, or the Verifier checks. Section 4.1.6 (sandbox_state) and\n Section 4.5 (risk_class) corrected to attribute the EU risk-\n management documentation requirement to Article 9 of [EU-AI-ACT]\n (Provider's risk management system) rather than Article 26, with\n Article 26(1) cited as the deployer's instructions-for-use obligation\n that links to the Provider's Article 9 documentation. Section 6.5.3\n (nydfs-retention) corrected to a single-tier five-year floor under 23\n\nGomes Marques Expires 21 January 2027 [Page 100]\nInternet-Draft Compliance Receipts Profile July 2026\n\n NYCRR 500.6(b) (verified verbatim against LII Cornell); the prior\n tiered 5-year/3-year split (claimed against the DFS Second Amendment)\n was incorrect because the Second Amendment does not amend\n Section 500.6, leaving the 2017 single-tier text in force. The\n 1096-day three-year audit-trail floor previously stated for NYDFS is\n removed.\n\nChanges in draft -02\n\n Submission-ready EU-only profile. Wire-shape alignment with upstream\n [ACTA-RECEIPTS] (payload/signature/anchors envelope; payload_digest\n object form; tool_name REQUIRED for protectmcp:decision; issuer_id\n equals kid). EU AI Act and DORA bindings authored against Official\n Journal text. Anchor MUST (at least one of RFC 3161 or\n OpenTimestamps); both RECOMMENDED; 7-day OpenTimestamps upgrade\n deadline profile-imposed. Six-month AI Act floor expressed as 184\n days; DORA-bound default expressed as 1827 days. IANA registries\n created.\n\nChanges in draft -01\n\n Initial wire-shape alignment with upstream and addition of dual-\n anchor, hash-chain, retention, and DORA classification bindings.\n Subsequent revisions superseded the specific values introduced here.\n\nChanges in draft -00\n\n Initial version. Defines a profile of [ACTA-RECEIPTS] that binds\n receipt fields to EU AI Act Article 12, EU AI Act Article 26, and\n DORA Article 17.\n\nAppendix - Capture Topologies for Compliance Receipt Emission\n\n This appendix is informational and non-normative. It catalogues six\n capture topologies an operator can use to emit conformant Compliance\n Receipts in environments where the originating application code\n cannot be modified to call the receipt-emitting SDK directly. The\n topologies are listed in order of payload fidelity, from highest (in-\n process SDK, full payload digest) to lowest (passive telemetry, post-\n hoc log ingestion only). All six emit receipts that satisfy the wire\n profile of Sections 3 and 4; they differ in trust boundary, payload\n coverage, and the operational identity that the receipt binds. The\n intent is to give an operator vocabulary for declaring which topology\n produced a given receipt, so that a verifier or auditor can interpret\n the receipt's evidentiary weight without re-deriving the architecture\n from out-of-band documentation.\n\nGomes Marques Expires 21 January 2027 [Page 101]\nInternet-Draft Compliance Receipts Profile July 2026\n\n An operator MAY declare the producing topology by including a\n capture_topology attribute in the Audit Pack manifest entry for the\n receipt. The attribute is informational at the wire layer and\n OPTIONAL. The vocabulary defined below is closed for the topologies\n catalogued in this appendix; future revisions or third-party profiles\n MAY extend it through the future-IANA-registry mechanism noted at the\n end of this appendix.\n\nIn-Process SDK\n\n The originating application links the receipt-emitting SDK directly\n and calls it inline with the action being recorded. This is the\n baseline pattern [ACTA-RECEIPTS] and Sections 3 and 4 of this\n document are written against. The receipt carries a full\n payload_digest covering the action's request bytes; the SDK has\n direct access to the application's principal identity, the policy\n decision, and the request body. Vocabulary value: in_process_sdk.\n Trust boundary: the application process itself; the SDK runs inside\n the application's memory space and inherits its principal. Threat-\n model note: captures the full request and response payloads, the\n deciding principal, and the policy context; does NOT capture out-of-\n process side effects or actions taken by sibling processes that do\n not link the SDK. Reference implementation hint: the Asqav Python\n and TypeScript SDKs published under the asqav-sdk umbrella implement\n this pattern; an operator MAY substitute any other conformant\n [ACTA-RECEIPTS] implementation.\n\nNetwork-Layer Egress Proxy\n\n A customer-owned reverse proxy or egress gateway (Envoy, NGINX, or an\n equivalent forward proxy) sits in the network path between the\n application and the downstream LLM provider. The proxy tees the\n request to a co-located Compliance Signer process, which receives the\n request bytes, applies the policy evaluation, and emits a receipt via\n a signer RPC. A DNS-rewrite on-ramp (CoreDNS rewriting the LLM\n hostname to the proxy address) or a Server Name Indication (SNI)\n router (SNIProxy at Layer 4) MAY be used to force application traffic\n onto the proxy without per-application configuration. Vocabulary\n value: network_proxy. Trust boundary: the customer's network egress;\n the proxy and signer run under the customer's operational control,\n and the receipt is signed by a key the customer's signer holds.\n Threat-model note: captures the request and response bytes that\n traverse the proxy and the network-layer principal identity (source\n IP, mTLS client cert if present); does NOT capture traffic that\n bypasses the proxy (direct outbound from a non-routed host, DNS-over-\n HTTPS to a hard-coded resolver, or TLS connections to certificate-\n pinned endpoints that the customer's enterprise CA cannot inspect).\n The receipt's issuer_id binds the customer's signer, not the\n\nGomes Marques Expires 21 January 2027 [Page 102]\nInternet-Draft Compliance Receipts Profile July 2026\n\n originating application; the application's identity, where captured,\n appears as an attribute resolved through the Audit Pack manifest.\n Reference implementation hint: CoreDNS for the DNS on-ramp, SNIProxy\n by dlundquist for the SNI router, and Envoy for the Layer-7 reverse\n proxy plane; none of these are normative requirements.\n\nBrowser Extension\n\n A managed-browser Manifest V3 (MV3) extension installed on employee\n workstations via the enterprise Mobile Device Management (MDM) system\n intercepts fetch, XMLHttpRequest, and EventSource requests to a\n configured list of LLM hostnames. The extension POSTs the\n intercepted request and response bytes to a Compliance Signer\n endpoint, which emits the receipt. For LLM hosts that pin their TLS\n certificates, the customer's enterprise root Certificate Authority\n (CA) MUST be installed in the browser trust store via MDM so that the\n extension's content-script interception can observe decrypted bytes.\n Vocabulary value: browser_extension. Trust boundary: the managed\n browser process on the employee workstation; the extension runs under\n the browser's sandbox and the employee's interactive session.\n Threat-model note: captures the full request and response payload for\n LLM calls initiated from the browser by the human user, and binds the\n receipt to the browser's principal identity (the user's enterprise\n single-sign-on subject, where the extension can read it). Does NOT\n capture LLM calls made by native desktop applications, server-side\n daemons, or browsers without the extension installed; does NOT\n capture traffic in incognito or private-window modes unless the\n extension is explicitly authorised for those contexts. Reference\n implementation hint: the open-source Chrome MV3 extension scaffolding\n published by Google under the chrome-extensions-samples repository is\n a useful starting point; the customer's signer endpoint is the Asqav\n signer or any conformant [ACTA-RECEIPTS] implementation.\n\neBPF SNI Observer\n\n A kernel-level extended Berkeley Packet Filter (eBPF) probe attached\n to the host's network stack observes outbound TLS ClientHello\n records. The probe extracts the SNI hostname, the JA3 client\n fingerprint, the source and destination addresses and ports, and the\n connection timestamp, and emits a lower-fidelity receipt that binds\n the employee, the device, the wall-clock time, and the LLM host\n without observing payload content. Vocabulary value: ebpf_observer.\n Trust boundary: the kernel of the host on which the probe runs; the\n probe operates below the application's user-space process and\n observes traffic regardless of application configuration. Threat-\n model note: captures the existence and counterparty of an LLM call\n (the "did the call happen" evidence class) and the device-and-\n employee binding through host attestation; does NOT capture request\n\nGomes Marques Expires 21 January 2027 [Page 103]\nInternet-Draft Compliance Receipts Profile July 2026\n\n or response bytes, the prompt content, the model parameters, or the\n decision-relevant context. Useful when payload capture is\n operationally infeasible (TLS certificate pinning that the enterprise\n CA cannot defeat, third-party SaaS that egresses outside the\n customer's proxy plane) but the operator still needs evidence that a\n regulated LLM interaction occurred. Reference implementation hint:\n Inspektor Gadget and Tetragon both expose SNI and connection-metadata\n events from eBPF probes; neither is a normative requirement.\n\nMCP Transparent Proxy\n\n A transparent proxy sits in-path between a Model Context Protocol\n (MCP) client and one or more downstream MCP servers, terminating the\n client's stdio, Server-Sent Events (SSE), or streamable-HTTP\n transport on one side and re-establishing the same transport to each\n downstream server on the other side. The proxy observes every tools/\n call and resources/read JSON-RPC method invocation, signs a receipt\n at the moment the call is forwarded, and emits a second acknowledging\n receipt carrying a counterparty_binding (see Section 5.6) at the\n moment the downstream server's response returns. Both sides of the\n call are therefore bound bilaterally, with the proxy's signing key\n serving as the integrity anchor for the pair. Vocabulary value:\n mcp_proxy. The Audit Pack manifest entry for a proxy-captured\n receipt carries the receipt's action_type and, where declared, the\n capture_topology attribute, so a verifier can filter proxy-captured\n receipts without re-parsing payload bytes. Trust boundary: the proxy\n process and its signing key; the upstream MCP client and the\n downstream MCP server are both treated as honest endpoints under the\n threat model of Section 10.12, with the proxy itself being the named\n intermediary whose tampering risk counterparty_binding mitigates.\n Threat-model note: captures the full MCP request and response\n payload, the method name, and the client and server principal\n identities visible at the transport boundary; does NOT capture MCP\n traffic that bypasses the proxy or that uses a transport the proxy\n does not implement. This entry defines the topology and its\n vocabulary value only; no particular proxy implementation is\n referenced or required.\n\nPassive Telemetry Ingestion\n\n A passive ingestion pipeline reads structured records the originating\n application or its runtime has already emitted (for example,\n OpenTelemetry spans, application access logs, vendor-managed\n observability exports, or batch CSV drops) and synthesises a\n Compliance Receipt for each record after the fact. The synthesiser\n holds the signing key, applies the receipt-format wire profile, and\n emits the receipt to the same downstream sink that the in-process SDK\n and network-proxy paths feed. Vocabulary value: passive_telemetry.\n\nGomes Marques Expires 21 January 2027 [Page 104]\nInternet-Draft Compliance Receipts Profile July 2026\n\n Trust boundary: the telemetry pipeline operator's signing key plus\n the integrity of the upstream observability source; the receipt binds\n the producer of the telemetry, not the originating application's per-\n request principal. Threat-model note: captures whatever the upstream\n telemetry source preserved (typically a subset of the action's bytes\n and metadata, often without request or response payload) plus the\n wall-clock and counterparty identifiers visible in the telemetry\n record; does NOT capture data the upstream source dropped, sampled\n out, or never emitted, and inherits any tampering risk the upstream\n source carries between emission and ingestion. Useful when the in-\n process SDK, network proxy, browser extension, eBPF observer, and MCP\n proxy topologies are all operationally infeasible (legacy\n applications without instrumentation hooks, third-party SaaS with\n read-only export, fleet migrations where the producer has only logs\n to work from) but the operator still needs a signed evidence artefact\n tied to the historical action. Reference implementation hint: any\n OpenTelemetry collector exporter feeding a conformant receipt-\n emitting signer; the upstream telemetry source is out of scope of\n this profile.\n\ncapture_topology Vocabulary and Considerations for a Future IANA\nRegistry\n\n The six values defined in this appendix (in_process_sdk,\n network_proxy, browser_extension, ebpf_observer, mcp_proxy,\n passive_telemetry) form the closed initial vocabulary for the\n capture_topology attribute. The attribute is OPTIONAL at the wire\n layer and, where present, MUST appear in the Audit Pack manifest\n entry for the receipt rather than inside the signed payload object,\n so that the topology declaration is producer-side metadata that does\n not alter the receipt's signed bytes. A verifier MUST NOT treat the\n absence of a capture_topology attribute as a non-conformance\n condition; absence simply means the producer did not declare a\n topology.\n\nGomes Marques Expires 21 January 2027 [Page 105]\nInternet-Draft Compliance Receipts Profile July 2026\n\n This document is an Independent Submission and does not request IANA\n action for the capture_topology vocabulary at this revision. A\n future revision MAY request creation of a "Compliance Receipt Capture\n Topologies" registry under the same "Compliance Receipts" registry\n group described in Section 11, with the registration policy of\n Specification Required per [RFC8126] and an initial set populated\n from the six values above. Until such a registry exists,\n implementations that extend the vocabulary SHOULD document the new\n value in a reference specification and SHOULD avoid colliding with\n the six reserved values above. The Designated Expert(s) for any\n future registry SHOULD verify that a candidate value names a distinct\n topology (a different trust boundary or a materially different\n payload-fidelity class) rather than a variant of an existing one, and\n that the candidate's threat-model note states what is captured and\n what is not, in the form used by the six entries in this appendix.\n\nAuthor's Address\n\n Joao Andre Gomes Marques\n Asqav\n Portugal\n Email: info@asqav.com\n\nGomes Marques Expires 21 January 2027 [Page 106]\n\n