Compliance Profile of Signed Action Receipts for AI Agents
draft-marques-asqav-compliance-receipts-09
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | João André Gomes Marques | ||
| Last updated | 2026-09-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Additional Web Page
Other Repository |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-marques-asqav-compliance-receipts-09
Network Working Group J. A. Gomes Marques
Internet-Draft Asqav
Intended status: Informational 21 September 2026
Expires: 25 March 2027
Compliance Profile of Signed Action Receipts for AI Agents
draft-marques-asqav-compliance-receipts-09
Abstract
This document defines a profile for signed action receipts and
independently checkable evidence about agent activity. It specifies
versioned payload and signature semantics, hash-chain linkage,
timestamp and witness policy, receipt verification and bounded
regulatory-evidence mappings. It draws on ACTA-RECEIPTS but states
its profile-specific overrides explicitly. A receipt supports checks
about recorded bytes, identity, linkage and retained evidence; it
does not by itself establish that an action occurred, that all
actions were captured, or that an organization complies with a law.
The profile supports retained historical receipts through explicit
version and legacy rules rather than rewriting their committed bytes.
Its intended core and implementation limitations are described in the
body.
Note to the Independent Submissions Editor
This note is to be removed before publishing as an RFC.
This document requests no new IANA registry. The two tables in
Section 13 are administered outside IANA. Section 4 of [RFC8726]
generally precludes new IANA registries on the Independent Submission
Stream, with a limited exception for a subcode registry tied to an
allocation from an existing registry. This document does not invoke
that exception. Section 5 excludes Specification Required and Expert
Review policies for new subregistries created through that stream.
The requested CWT claim allocation remains subject to the existing
registry policy and expert review under Section 2. Any future
proposal to move the external tables to IANA would require the
applicable procedures and approvals; IETF Stream progression would
not itself transfer them.
Editor's Note: Target Design
This note is to be removed before publishing as an RFC.
Gomes Marques Expires 25 March 2027 [Page 1]
Internet-Draft Compliance Receipts Profile September 2026
This local edition describes the completed target design selected for
the core milestone. The specification uses present-tense
requirements on that basis. It does not report current
implementation completion, test results, customer deployment or
publication approval. Those facts are maintained in a separate
release evidence record. Remove this note only when the release
evidence supports the publication being submitted.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Profile and Explicit Overrides . . . . . . . . . . . . . 7
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 8
3. Relationship to ACTA-RECEIPTS . . . . . . . . . . . . . . . . 10
4. Canonicalization Scope . . . . . . . . . . . . . . . . . . . 11
5. Receipt Field Profile . . . . . . . . . . . . . . . . . . . . 13
5.1. Signature Object and Algorithm Contract . . . . . . . . . 13
5.2. Common Payload Fields . . . . . . . . . . . . . . . . . . 14
5.2.1. v (No Upstream Equivalent) . . . . . . . . . . . . . 14
Gomes Marques Expires 25 March 2027 [Page 2]
Internet-Draft Compliance Receipts Profile September 2026
5.2.2. mode (No Upstream Equivalent) . . . . . . . . . . . . 15
5.2.3. type . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.4. issued_at . . . . . . . . . . . . . . . . . . . . . . 18
5.2.5. issuer_id . . . . . . . . . . . . . . . . . . . . . . 19
5.2.6. payload_digest (OPTIONAL upstream, REQUIRED in this
profile) . . . . . . . . . . . . . . . . . . . . . . 20
5.2.7. action_ref (OPTIONAL upstream, REQUIRED in this
profile) . . . . . . . . . . . . . . . . . . . . . . 20
5.2.8. sandbox_state (OPTIONAL upstream, REQUIRED for
High-Risk in this profile) . . . . . . . . . . . . . 21
5.2.9. iteration_id (OPTIONAL upstream, REQUIRED for
multi-step in this profile) . . . . . . . . . . . . . 21
5.2.10. key_thumbprint (No Upstream Equivalent) . . . . . . . 21
5.2.11. Sequence Counter . . . . . . . . . . . . . . . . . . 22
5.3. Decision Receipt Fields (type protectmcp:decision) . . . 23
5.3.1. reason (OPTIONAL upstream, REQUIRED for deny/rate_limit
in this profile) . . . . . . . . . . . . . . . . . . 23
5.3.2. policy_digest . . . . . . . . . . . . . . . . . . . . 23
5.4. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this
profile) . . . . . . . . . . . . . . . . . . . . . . . . 24
5.5. Anchoring (No Upstream Equivalent) . . . . . . . . . . . 26
5.6. Signer-Outage Evidence (unsigned_gap) . . . . . . . . . . 28
5.7. Extension Fields . . . . . . . . . . . . . . . . . . . . 29
5.8. Counterparty Binding . . . . . . . . . . . . . . . . . . 30
5.8.1. Wire Shape . . . . . . . . . . . . . . . . . . . . . 31
5.8.2. Emitter Behaviour . . . . . . . . . . . . . . . . . . 33
5.8.3. Verifier Behaviour . . . . . . . . . . . . . . . . . 34
5.9. Result-Bound and Validity-Window Extensions . . . . . . . 35
5.10. Build-Provenance Extensions . . . . . . . . . . . . . . . 38
5.11. Enforcement-Control Record Extensions . . . . . . . . . . 40
5.12. Risk-Acceptance Extensions . . . . . . . . . . . . . . . 42
5.13. Oversight Ruling Receipts . . . . . . . . . . . . . . . . 44
5.14. Code-Authorship Extensions . . . . . . . . . . . . . . . 46
5.15. Threat-Framework Taxonomy Extensions . . . . . . . . . . 49
5.16. Environment Attestation Extensions
(Normative-Optional) . . . . . . . . . . . . . . . . . . 51
5.17. Receipt Lineage Extensions . . . . . . . . . . . . . . . 52
5.18. Heartbeat and Denial Evidence . . . . . . . . . . . . . . 53
5.19. Capture Coverage and Enforcement Authority . . . . . . . 54
6. Legal Applicability and Evidence Policy . . . . . . . . . . . 55
7. European Union Bindings . . . . . . . . . . . . . . . . . . . 56
7.1. EU AI Act Article 12 Binding . . . . . . . . . . . . . . 56
7.1.1. Article 12(1), automatic recording of events . . . . 56
7.1.2. Article 12(2)(a), identifying situations that may
result in the high-risk AI system presenting a risk
within the meaning of Article 79(1) or in a substantial
modification . . . . . . . . . . . . . . . . . . . . 57
Gomes Marques Expires 25 March 2027 [Page 3]
Internet-Draft Compliance Receipts Profile September 2026
7.1.3. Article 12(2)(b), facilitating the post-market
monitoring referred to in Article 72 . . . . . . . . 57
7.1.4. Article 12(2)(c), monitoring the operation of high-risk
AI systems referred to in Article 26(5) . . . . . . . 57
7.1.5. Retention . . . . . . . . . . . . . . . . . . . . . . 57
7.2. EU AI Act Article 26 Binding . . . . . . . . . . . . . . 58
7.2.1. Article 26(1), in accordance with the instructions for
use . . . . . . . . . . . . . . . . . . . . . . . . . 58
7.2.2. Article 26(2), assign human oversight . . . . . . . . 58
7.2.3. Article 26(5), monitor the operation . . . . . . . . 58
7.2.4. Article 26(6), of at least six months . . . . . . . . 58
7.3. EU AI Act Article 50 Binding . . . . . . . . . . . . . . 59
7.3.1. Article 50(1), informing a natural person that they are
interacting with an AI system . . . . . . . . . . . . 59
7.3.2. Article 50(2), marking synthetic output in a
machine-readable format . . . . . . . . . . . . . . . 59
7.3.3. Article 50(3), informing persons exposed to emotion
recognition or biometric categorisation . . . . . . . 60
7.3.4. Article 50(4), disclosing artificially generated or
manipulated content . . . . . . . . . . . . . . . . . 60
7.3.5. Timing, Accessibility and Retention . . . . . . . . . 60
7.4. DORA Article 17 Binding . . . . . . . . . . . . . . . . . 60
7.4.1. Article 17(1), ICT-related incident management
process . . . . . . . . . . . . . . . . . . . . . . . 60
7.4.2. Article 17(2), record all ICT-related incidents and
significant cyber threats . . . . . . . . . . . . . . 61
7.4.3. Article 17(3)(b), establish procedures to identify,
track, log, categorise and classify ICT-related
incidents . . . . . . . . . . . . . . . . . . . . . . 61
7.4.4. Retention . . . . . . . . . . . . . . . . . . . . . . 61
8. United States Bindings . . . . . . . . . . . . . . . . . . . 61
8.1. NIST AI RMF Binding . . . . . . . . . . . . . . . . . . . 61
8.1.1. GOVERN function . . . . . . . . . . . . . . . . . . . 62
8.1.2. MAP function . . . . . . . . . . . . . . . . . . . . 62
8.1.3. MEASURE function . . . . . . . . . . . . . . . . . . 62
8.1.4. MANAGE function . . . . . . . . . . . . . . . . . . . 62
8.2. Colorado Automated Decision-Making Technology Act (SB
26-189) Binding . . . . . . . . . . . . . . . . . . . . . 62
8.2.1. Section 6-1-1704(1), pre-use notice . . . . . . . . . 63
8.2.2. Section 6-1-1704(3), post-adverse-outcome
disclosure . . . . . . . . . . . . . . . . . . . . . 63
8.2.3. Section 6-1-1705(1)(a)(II), meaningful human
review . . . . . . . . . . . . . . . . . . . . . . . 64
8.2.4. Section 6-1-1703, deployer record keeping . . . . . . 64
8.2.5. Section 6-1-1706, enforcement . . . . . . . . . . . . 64
8.3. Texas Responsible AI Governance Act (HB 149) Binding . . 65
8.3.1. Defence-to-liability evidentiary support . . . . . . 65
8.3.2. Prohibited-use detection . . . . . . . . . . . . . . 65
Gomes Marques Expires 25 March 2027 [Page 4]
Internet-Draft Compliance Receipts Profile September 2026
8.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart
C) . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4.1. 45 CFR 164.312(b), audit controls . . . . . . . . . . 66
8.4.2. Security Rule Documentation and Retention . . . . . . 66
8.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part
500) . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.5.1. 23 NYCRR 500.6, audit trail . . . . . . . . . . . . . 67
8.5.2. 23 NYCRR 500.17, notices to superintendent . . . . . 67
8.5.3. 23 NYCRR 500.6 retention . . . . . . . . . . . . . . 67
8.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR
240.17a-4) . . . . . . . . . . . . . . . . . . . . . . . 67
8.6.1. 17 CFR 240.17a-4(f), electronic recordkeeping
system . . . . . . . . . . . . . . . . . . . . . . . 68
8.6.2. 17 CFR 240.17a-4(a) and (b) retention . . . . . . . . 68
8.7. CIRCIA: Provisional Evidence Mapping . . . . . . . . . . 68
8.7.1. Incident Evidence Support . . . . . . . . . . . . . . 69
8.7.2. Preservation Rule . . . . . . . . . . . . . . . . . . 69
9. Attestation Statements and Authoritative Re-Derivation . . . 69
9.1. Attestation Statement Envelope . . . . . . . . . . . . . 69
9.2. Authoritative Code-Authorship Re-Derivation . . . . . . . 71
9.3. Capture-Layer Integrity . . . . . . . . . . . . . . . . . 73
9.4. Independent Verification Protocol . . . . . . . . . . . . 74
9.5. Honest Tiering of Capture Claims . . . . . . . . . . . . 75
9.6. Service Identity, JWKS, and Revocation . . . . . . . . . 76
10. Audit Pack Composition . . . . . . . . . . . . . . . . . . . 76
10.1. Signed Audit Pack Projection . . . . . . . . . . . . . . 78
11. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . . 80
11.1. Verifier Independence . . . . . . . . . . . . . . . . . 80
11.2. Mandatory Checks . . . . . . . . . . . . . . . . . . . . 81
11.3. Optional Checks . . . . . . . . . . . . . . . . . . . . 83
11.4. Reporting . . . . . . . . . . . . . . . . . . . . . . . 83
11.5. Verification Verdict and Hash-Algorithm Vocabulary . . . 84
12. Security Considerations . . . . . . . . . . . . . . . . . . . 86
12.1. Tamper Resistance . . . . . . . . . . . . . . . . . . . 86
12.2. Chain- and Signature-Scope Confusion . . . . . . . . . . 86
12.3. Chain Availability Under Single-Linear Per-Agent
Serialization . . . . . . . . . . . . . . . . . . . . . 87
12.4. Key Compromise . . . . . . . . . . . . . . . . . . . . . 88
12.5. Retention and Long-Term Verifiability . . . . . . . . . 88
12.6. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 89
12.7. Anchor Trust . . . . . . . . . . . . . . . . . . . . . . 89
12.8. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 90
12.9. Cross-Regime Conflict . . . . . . . . . . . . . . . . . 90
12.10. Algorithm Agility . . . . . . . . . . . . . . . . . . . 91
12.11. Issuer-Misrepresentation Residual . . . . . . . . . . . 91
12.12. Cross-Agent Integrity Trust Boundary . . . . . . . . . . 93
12.13. Compromised Intermediary Between Two Honest Endpoints . 93
12.14. What a Compliance Receipt Does Not Prove . . . . . . . . 96
Gomes Marques Expires 25 March 2027 [Page 5]
Internet-Draft Compliance Receipts Profile September 2026
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 99
13.1. Regime Mapping Vocabulary . . . . . . . . . . . . . . . 100
13.2. Compliance Receipt Extension Fields Registry . . . . . . 100
13.3. Compliance Receipt Type Namespaces Registry . . . . . . 115
14. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 118
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 119
15.1. Asqav Platform . . . . . . . . . . . . . . . . . . . . . 119
15.2. Python Verifier . . . . . . . . . . . . . . . . . . . . 119
15.3. TypeScript Verifier . . . . . . . . . . . . . . . . . . 119
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 120
17. Normative References . . . . . . . . . . . . . . . . . . . . 120
18. Informative References . . . . . . . . . . . . . . . . . . . 125
Appendix A. Worked Examples (Informative) . . . . . . . . . . . 129
A.1. A production receipt, byte-exact in the corpus . . . . . 129
A.2. An illustrative decision receipt for the Article 26
binding . . . . . . . . . . . . . . . . . . . . . . . . . 132
A.3. The counterparty_binding member (illustrative) . . . . . 134
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 134
B.1. Changes in draft -09 . . . . . . . . . . . . . . . . . . 134
B.2. Changes in draft -08 . . . . . . . . . . . . . . . . . . 135
B.3. Changes in draft -07 . . . . . . . . . . . . . . . . . . 135
B.4. Changes in draft -06 . . . . . . . . . . . . . . . . . . 135
B.5. Changes in draft -05 . . . . . . . . . . . . . . . . . . 135
B.6. Changes in draft -04 . . . . . . . . . . . . . . . . . . 135
B.7. Changes in draft -03 . . . . . . . . . . . . . . . . . . 135
B.8. Changes in draft -02 . . . . . . . . . . . . . . . . . . 135
B.9. Changes in draft -01 . . . . . . . . . . . . . . . . . . 136
B.10. Changes in draft -00 . . . . . . . . . . . . . . . . . . 136
Appendix C. Capture Topologies for Compliance Receipt
Emission . . . . . . . . . . . . . . . . . . . . . . . . 136
C.1. In-Process SDK . . . . . . . . . . . . . . . . . . . . . 136
C.2. Network-Layer Egress Proxy . . . . . . . . . . . . . . . 136
C.3. Browser Extension . . . . . . . . . . . . . . . . . . . . 137
C.4. eBPF SNI Observer . . . . . . . . . . . . . . . . . . . . 137
C.5. MCP Transparent Proxy . . . . . . . . . . . . . . . . . . 137
C.6. Passive Telemetry Ingestion . . . . . . . . . . . . . . . 138
C.7. capture_topology Vocabulary and Considerations for a Future
IANA Registry . . . . . . . . . . . . . . . . . . . . . . 139
C.8. Regulatory Currency and Verification Dates . . . . . . . 139
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 140
1. Introduction
Gomes Marques Expires 25 March 2027 [Page 6]
Internet-Draft Compliance Receipts Profile September 2026
1.1. Profile and Explicit Overrides
This specification draws on the receipt model in [ACTA-RECEIPTS].
Its conformance requirements are defined here and in its normative
references. ACTA records design history; its requirements are not
incorporated by reference. Implementers use Section 3, Section 4 and
Section 5. Shared names do not establish wire compatibility.
1.2. Scope
This document fills the regulatory binding gap on two surfaces.
Section 6 binds the receipt to European Union obligations: Article 12
(record-keeping), Article 26 (deployer obligations) and Article 50
(transparency) of the EU AI Act, and Article 17 (ICT-related incident
management) of DORA. Section 7 binds the receipt to United States
obligations: the voluntary functions of the NIST AI Risk Management
Framework, the deployer obligations of Colorado's Automated Decision-
Making Technology law (SB 26-189) and the Texas Responsible AI
Governance Act, the audit-trail and incident-reporting obligations of
NYDFS Part 500, the audit controls and documentation retention of the
HIPAA Security Rule, the broker-dealer recordkeeping requirements of
SEC Rule 17a-4, and a provisional CIRCIA incident-evidence mapping.
The bindings are written from the Deployer's perspective, where
Deployer is used in the regime-specific sense (Article 3(4) of
[EU-AI-ACT] for EU bindings; Section 6-1-1701(7) of the Colorado
Revised Statutes for Colorado bindings). Where another statute uses
a different term (Provider, Financial Entity, Covered Entity or
Business Associate for HIPAA, Covered Entity for NYDFS, Broker-Dealer
for SEC, Covered Entity for CIRCIA), the binding section names the
term as the source statute uses it.
An upstream-only verifier can validate only the algorithms, framing
and digest scopes it actually implements. Profile conformance and
regulatory-evidence mapping require the checks of this document;
cryptographic validity alone does not establish either.
The required core consists of the receipt envelope, supported
algorithms, chain and key semantics, selected witness policy,
evidence export and verifier reporting. Type-specific extensions
impose their rules when that type or extension is selected; they do
not require every issuer to implement every listed product
integration. Unsupported required extensions are reported as
unverifiable. A release conformance statement lists the supported
types and policies.
Gomes Marques Expires 25 March 2027 [Page 7]
Internet-Draft Compliance Receipts Profile September 2026
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are used in this document.
Action: An operation performed by an AI agent that is subject to a
policy evaluation. Examples include a tool invocation, an
external API call, a write to durable storage, and the issuance of
an irreversible instruction to another system.
Action Receipt: A signed record of an agent-related action or
decision. The term does not imply conformance to an external
receipt specification.
Compliance Receipt: A receipt satisfying the envelope, common
fields, selected type and verification requirements defined in
this document.
Deployer (EU AI Act): As defined in Article 3(4) of [EU-AI-ACT].
Deployer (Colorado ADMT Act): As defined in Section 6-1-1701(7) of
the Colorado Revised Statutes, as enacted by [COLORADO-ADMT].
Developer (Colorado ADMT Act): As defined in Section 6-1-1701(8) of
[COLORADO-ADMT].
Covered ADMT: As defined in Section 6-1-1701(5) of [COLORADO-ADMT];
"automated decision-making technology" is defined at
Section 6-1-1701(2).
Consequential Decision (Colorado ADMT Act): As defined in
Section 6-1-1701(3) of [COLORADO-ADMT].
Adverse Outcome (Colorado ADMT Act): As defined in
Section 6-1-1701(1) of [COLORADO-ADMT].
Materially Influence (Colorado ADMT Act): As defined in
Section 6-1-1701(13) of [COLORADO-ADMT].
Meaningful Human Review (Colorado ADMT Act): As defined in
Section 6-1-1701(15) of [COLORADO-ADMT].
High-Risk AI System (EU AI Act): As defined in Article 6 of
Gomes Marques Expires 25 March 2027 [Page 8]
Internet-Draft Compliance Receipts Profile September 2026
[EU-AI-ACT].
Financial Entity: The entities listed in Article 2(1), points (a) to
(t), that Article 2(2) of [DORA] collectively calls financial
entities, subject to the applicable exclusions and scope
provisions.
Covered Entity (HIPAA): As defined in 45 CFR 160.103, namely a
health plan, a health care clearinghouse, or a health care
provider that transmits health information in electronic form in
connection with a covered transaction.
Covered Entity (NYDFS): As defined in 23 NYCRR 500.1(e), namely any
person operating under or required to operate under a license,
registration, charter, certificate, permit, accreditation or
similar authorization under the Banking Law, the Insurance Law or
the Financial Services Law, regardless of whether the covered
entity is also regulated by other government agencies.
Broker-Dealer: As defined in section 3(a)(4) and 3(a)(5) of the
Securities Exchange Act of 1934, subject to recordkeeping under
[SEC-17A-4].
Covered Entity (CIRCIA): A covered entity within the statutory
framework of 6 U.S.C. 681 and the operative implementing rule.
This draft's provisional mapping does not use proposed scope
criteria to establish a present reporting duty; see Section 8.7.
Audit Pack: A bundle of Compliance Receipts, the chain commitments
that link them, the public verification keys, the trust anchor
metadata, and the regime mapping required by the EU and US
evidence mappings of this document, packaged for delivery to a
regulator or auditor.
Counterparty: The entity on the receiving side of an Action
performed by another party's agent: the participant whose rights,
systems, or funds the Action touches, and for whom the Compliance
Receipt covering that Action is evidence. The Counterparty
occupies the demand side of the receipt: it consumes verification
verdicts; it does not emit receipts.
Acceptor: The role a Counterparty occupies when it conditions
acceptance of an incoming Action, or of the Action's output, on
the verdict of a Compliance Verifier. An Acceptor gates the
incoming Action on verification and treats an unverified receipt
as non-acceptable input; the gating policy itself is outside the
scope of this profile.
Gomes Marques Expires 25 March 2027 [Page 9]
Internet-Draft Compliance Receipts Profile September 2026
A normative reference supplies rules needed to implement the core or
a selected extension or regulatory-evidence mapping. Sources used
only by a selected mapping apply to that mapping; their
classification does not make the mapping mandatory for every
deployment or establish legal compliance. Provisional mappings
remain provisional. Explanatory sources and design antecedents are
informative. Reference categories describe technical dependency, not
institutional prestige.
3. Relationship to ACTA-RECEIPTS
This document derives from [ACTA-RECEIPTS] but does not claim byte-
level compatibility with every upstream verifier. For Compliance
Receipts, the versioned shape in Section 5.2.1, the signature scope
in Section 5.4, and the anchor and counterparty scopes in Section 5.5
and Section 5.8 govern. Implementations MUST NOT infer a digest
scope or signature encoding merely from the ACTA family name.
The core envelope contains payload and signature; anchors MAY be
omitted or an empty array under Section 5.5. Profile members belong
inside the signed payload. Flat legacy transport representations are
handled under an explicitly selected legacy format and MUST NOT
silently change the bytes supplied to signature or chain
verification.
The supported signature algorithms and their key representations are
defined in Section 5.1 and Section 5.2.10. ML-DSA-65 uses [RFC9964].
New profile issuance uses unpadded base64url for signature.sig;
retained legacy signature strings MUST remain byte-for-byte
unchanged. A verifier accepting a legacy encoding MUST report the
applicable legacy policy. Re-encoding the same signature bytes can
change an anchor or counterparty commitment and MUST NOT be used to
repair retained history.
Where this profile tightens an upstream optional field, its type-
bound presence rule applies. Unknown signed members remain covered
by the signature and are handled by Section 5.7. A failed mandatory
profile check does not imply that the underlying signature is
invalid, nor does verification under an older revision establish
conformance to this revision.
ACTA-RECEIPTS is an informative antecedent. No conformance
requirement depends on its publication or on later changes to that
draft. The local field, algorithm, signing-input, trust and type
rules are authoritative. Shared field or namespace spellings do not
import additional ACTA requirements. Supporting a bare ACTA receipt
is a separate format choice and is not required for this profile.
Gomes Marques Expires 25 March 2027 [Page 10]
Internet-Draft Compliance Receipts Profile September 2026
4. Canonicalization Scope
This section is normative. The canonicalization rule itself (JCS,
[RFC8785]) is specified directly by [RFC8785]; this section bounds
the inputs the rule is applied to, so that the cross-implementation
byte equality on which the hash chain of Section 5.4, the anchor
scope of Section 5.5, and the cross-agent binding of Section 5.8 all
depend is achievable in practice.
This profile restricts digest-covered JSON numbers to exact integers
in the closed interval [-(2^53-1), 2^53-1]. This is an Asqav input-
domain restriction, not a requirement of [RFC8785], which also
defines fractional-number serialization. Callers MUST represent
other exact values as strings or explicitly defined integer-rational
pairs. Verifiers MUST apply this profile restriction at the raw-
input parse boundary, before a general-purpose parser can lose
precision, and report an unsupported or malformed numeric input as
unverifiable. An already parsed object cannot demonstrate that the
original bytes passed this check. Historical formats with a
different numeric domain MUST be evaluated under their documented
legacy policy.
A duplicated member name inside any digest-covered object is a
terminal parse failure. An implementation MUST raise it before any
hashing, canonicalization or signature check runs, at any nesting
depth, and MUST report the receipt unverifiable rather than invalid,
because nothing about the receipt was proven false: it could not be
read. Last-wins ingest, in which a parser silently keeps the final
occurrence, is never conformant here. The rule exists because the
two occurrences give two different documents to two readers that both
believe they parsed the same bytes, so a signature verified over one
of them says nothing about what the other acted on; deferring the
check until after canonicalization does not help, since
canonicalization has by then already chosen one of the two.
Object member names MUST be ordered by UTF-16 code unit, as
Section 3.2.3 of [RFC8785] requires. A verifier MUST NOT order
member names by Unicode code point, and MUST NOT order them by UTF-8
byte sequence. The three orders agree across the whole Basic
Multilingual Plane and can diverge when supplementary-plane and high-
BMP characters are compared. An implementation that sorts by code
point therefore emits a different canonical byte sequence, and so a
different digest, for the same receipt.
Rationale: this is a live interoperability hazard rather than a
theoretical one, because the natural implementation in several
languages is the incorrect one. Python sorted and
json.dumps(sort_keys=True) order by code point, and Rust and Go
Gomes Marques Expires 25 March 2027 [Page 11]
Internet-Draft Compliance Receipts Profile September 2026
string comparison orders by UTF-8 byte sequence, which for this
purpose is the same order; ECMAScript string comparison orders by
UTF-16 code unit and is already correct. A conformance corpus whose
member names are all drawn from the Basic Multilingual Plane cannot
distinguish the two, so implementations can agree on every published
vector and still disagree on a receipt whose caller-supplied object
carries an emoji or supplementary-plane key. Implementers SHOULD
test against a vector that carries such a key; [ASQAV-SDK] carries
one in its canonicalization corpus (conformance/vectors.json) as
asqav-24-jcs-astral-key-order, together with a negative case
presenting the code-point ordering that a conformant implementation
MUST NOT produce.
Conformant JCS implementations serialize the same supported input
consistently. Ordinary JSON serializers are not necessarily JCS
implementations. The narrower domain above reduces implementation
burden; it does not justify asserting that two conformant JCS
implementations disagree.
Tool-version-specific semantic equivalence is OUT OF SCOPE for the
chain layer of this profile. The chain layer checks commitments to
canonical bytes under its cryptographic assumptions. Examples of
semantic equivalence that this profile does not assert and does not
require a verifier to assert: SQL keyword case folding (SELECT vs
select), filesystem path normalization (trailing slash, redundant
separators, symlink resolution), Unicode normalization in any form
(NFC, NFD, NFKC, NFKD); Section 3.1 of [RFC8785] requires that all
components depending on JCS preserve Unicode string data as-is, and
Section 3.2.2.2 of [RFC8785] serializes each code point without
normalization, so callers MUST NOT rely on a verifier normalizing
strings before comparison, locale-aware string collation (Turkish
dotted-i, German sharp-s case folding, ICU collation tables),
application-specific approximate numeric comparisons, or URL percent-
encoding choices below the RFC 3986 unreserved set. Higher-level
semantic equivalence is a per-tool concern and, where required by a
regulator, MUST be expressed in the policy artifact resolved through
policy_digest (Section 5.3.2) rather than in the chain.
The chain layer establishes relationships among recorded canonical
payloads. It does not establish that the underlying action occurred
at the issuer's declared time. Timestamp evidence supplies only the
time properties supported by the authenticated construction and trust
policy; those properties are reported separately from chain
integrity.
The core envelope has two required members, payload and signature,
and the optional anchors member. Signed content lives inside
payload. The signature input is the receipt's canonical payload; a
Gomes Marques Expires 25 March 2027 [Page 12]
Internet-Draft Compliance Receipts Profile September 2026
chain link commits the predecessor's canonical payload. Anchor and
counterparty commitments cover the core envelope with the anchors key
removed, retaining the exact signature string. Legacy transports are
separately identified and never silently normalized into this framing
before verification.
5. Receipt Field Profile
This section defines the fields and explicit upstream overrides used
by this profile. The requirements below, including the version and
legacy rules, govern profile verification.
The core JSON envelope has REQUIRED payload and signature members.
The signature object contains alg, kid and sig. New profile issuance
encodes sig as unpadded base64url under [RFC4648]. Historical
encodings are accepted only under an explicit legacy policy and
retain their exact committed strings. An OPTIONAL anchors array
holds the proof objects defined in Section 5.5. A storage projection
MUST preserve the signed and committed bytes; it MUST NOT repair
historical receipts by renaming, re-encoding or reconstructing
authenticated content.
5.1. Signature Object and Algorithm Contract
The core JSON signature is an object with three REQUIRED string
members: alg, kid and sig. kid is a nonempty key-selection hint,
subject to independent issuer authorization under Section 5.2.5. New
issuance under this revision MUST use alg="ML-DSA-65"; a conforming
verifier MUST implement that algorithm. The public key is an AKP JWK
with kty="AKP", alg="ML-DSA-65" and unpadded-base64url pub under
[RFC9964]. The public key is 1952 octets and the signature is 3309
octets under [FIPS204].
The algorithm choice above carries an interoperability cost that
implementers need stated plainly. A verifier that implements only
the mandatory-to-implement signature baseline of [ACTA-RECEIPTS],
which is Ed25519 under [RFC8032], will not validate ML-DSA-65
receipts issued under this revision. That upstream draft lists ML-
DSA-65 as RECOMMENDED rather than mandatory; what this profile adds
is the [RFC9964] algorithm string and AKP JWK form, the
Section 5.2.10 binding, and the selection of ML-DSA-65 for the
reference platform.
Gomes Marques Expires 25 March 2027 [Page 13]
Internet-Draft Compliance Receipts Profile September 2026
The JSON signing input is the UTF-8 JCS serialization of the complete
payload object. Use pure ML-DSA with an empty context string, not
HashML-DSA and not an extra SHA-256 prehash. sig is the resulting
signature encoded as unpadded base64url under [RFC4648]. COSE and
JWS use their own protected framing and signing-input rules under
[RFC9964], [RFC9052] and [RFC7515]; a JSON signature MUST NOT be
reused as a framed signature without the required signing operation.
A separately selected historical format MAY accept Ed25519 under
[RFC8032] or another explicitly documented historical algorithm.
That policy MUST specify the identifier, key representation, original
signing input and original signature encoding; acceptance is reported
as historical verification, not new-revision conformance. Unknown or
unsupported algorithms are unverifiable. A verifier MUST NOT select
an algorithm from signature length, kid spelling or successful trial
verification, and MUST NOT downgrade after a failed check. Unsigned
algorithm metadata is interpreted only within the independently
authorized key/algorithm policy.
Unsupported ML-DSA-65 is reported as an unverifiable signature axis;
antecedent-format support alone cannot satisfy this requirement.
5.2. Common Payload Fields
5.2.1. v (No Upstream Equivalent)
REQUIRED. v is a wire-version integer identifying the receipt shape a
verifier should read; its value under this document is 1. It is the
first member a verifier reads, because it fixes the shape under which
every other member is interpreted. An issuer conforming to this
document MUST emit v on every Compliance Receipt. It is server-built
in the sense of Section 5.2.10: a caller-supplied value MUST be
dropped before signing.
The version member is inside the signed payload in the core envelope,
for both payload and hash modes. It MUST be authenticated before its
claims are trusted. A flat legacy API response is a distinct
transport representation; a verifier MAY support it through an
explicit, documented adapter preserving its original signed bytes.
The presence of a null payload is not authority to guess the
signature scope.
Gomes Marques Expires 25 March 2027 [Page 14]
Internet-Draft Compliance Receipts Profile September 2026
A verifier MUST report an unsupported version as unverifiable and
MUST NOT guess its shape. The reference source inspected for this
reconciliation emits v=1 with the payload_digest shape defined in
Section 5.2.6. The corpus's version-2 signer canary does not by
itself establish a released version-2 production contract. A new
emitted version requires a complete shape definition and migration
evidence before release.
Absence is a distinct case from an unrecognised value, and it is the
case an implementer meets first, because every receipt issued under a
revision preceding this one carries no v. A receipt carrying no v
member is not a Compliance Receipt of this document. It is either a
receipt of another format, the absence being what distinguishes the
two wire formats under the interoperability note of Section 5.4, or a
receipt issued under an earlier revision of this profile. A verifier
MAY process such a receipt under the rules of that earlier revision,
and MUST NOT report it as verified under this document. A verifier
MUST NOT infer version 1 from absence: inferring it would erase the
only signal separating this profile's receipts from a bare upstream
receipt.
5.2.2. mode (No Upstream Equivalent)
REQUIRED. mode records how the Action was captured: payload or hash.
It does not select the enclosing wire shape. In a Compliance Receipt
it appears inside the signed payload object, which can carry either
value. A verifier claiming conformance to this profile MUST
determine the expected member set from the mode and the enclosing
wire shape before applying the checks of Section 11.2. A successful
signature check alone does not establish that conformance.
payload means the issuing platform computes the Action-context
digest. The signed payload carries action_type, timestamp, and
payload_digest, in addition to the common profile members. The
context member is OPTIONAL: the platform may receive a context
without carrying it in the receipt. In the reference signing path,
payload_digest.hash is SHA-256 over the canonical caller-supplied
context, or over the empty object {} when no context was supplied.
Omission of context from the receipt does not mean that the caller
supplied an empty object. A verifier cannot recompute the digest
from that receipt alone when context is absent or JSON null, and that
absence is not a failure of the recomputation check. When a non-null
context is carried, it MUST reproduce the committed digest under
Section 11.2 and MUST observe the content restrictions of
Section 12.6.
Gomes Marques Expires 25 March 2027 [Page 15]
Internet-Draft Compliance Receipts Profile September 2026
hash means the caller supplied a fingerprint instead of the Action
context. A Compliance Receipt with this mode carries hash,
hash_algo, and server_timestamp inside its signed payload, alongside
the common profile members, including v, mode, action_id, agent_id,
org_id, policy_digest, decision, and payload_digest. Its metadata
member is optional. The reference platform emits neither context nor
action_type on this path. The hash member carries the caller's self-
describing fingerprint; payload_digest.hash carries its unprefixed
digest value. Without a carried context the recomputation check does
not apply. The mode does not exempt a Compliance Receipt carrying a
non-null context from the consistency check in Section 11.2.
For interoperability, the reference SDK also accepts flat hash
signature receipts whose payload is JSON null. Their signed input is
an eleven-member object: v, mode, hash, hash_algo, metadata,
server_timestamp, action_id, agent_id, org_id, policy_digest, and
policy_decision. The SDK's flat-path structure check rejects an
absent or null value for every member except policy_digest; that
member may be absent or null and is reconstructed as null in the
signing input. This compatibility rule applies to the flat signing
input. It does not require policy_decision on the nested Compliance
Receipt, which uses decision, or make metadata mandatory there.
Acceptance of a flat signature receipt does not establish this
profile's chain and anchor requirements.
Implementation note: the reference Python SDK's
verify_receipt_offline() entry point uses the native oracle adapter,
which enforces the member set on its flat hash path. For a nested
payload, that adapter delegates to the common structure check without
deriving a mode-specific set. The standalone verify_receipt.py
artifact performs no mode-dependent member-set validation. Neither
implementation's successful result establishes conformance to the
full member-set requirement above; that requirement binds any
verifier claiming conformance to this profile.
action_type and tool_name are JSON strings naming the operation and
tool respectively, with the presence conditions stated for the
selected mode and receipt type. Payload-mode timestamp is an RFC
3339 string with an explicit timezone recording the issuer's signing-
time assertion. It is distinct from the original Action descriptor
timestamp in Section 5.2.7. In version-1 payload mode, absent
hash_algo means sha256; hash mode requires the member. An explicitly
supplied unsupported value is not absence and MUST NOT trigger that
default.
Gomes Marques Expires 25 March 2027 [Page 16]
Internet-Draft Compliance Receipts Profile September 2026
5.2.3. type
Compliance Receipts MUST set type to a value registered in the
Compliance Receipt Type Namespaces Registry of Section 13.3, or to an
extension namespace registered for use with this profile. That
registry, not this paragraph, is the authoritative vocabulary: it
carries protectmcp:decision, protectmcp:restraint and
protectmcp:lifecycle together with protectmcp:acknowledgment,
protectmcp:observation and their sub-namespaces, so a verifier that
treats the first three as the whole set rejects receipts this profile
defines.
A selected type uses the common fields of Section 5.2, the mode-bound
fields of Section 5.2.2, the decision/policy rules of Section 5.3 and
its explicitly named extension rules in Section 13.3. No additional
field is required solely because the type spelling also appears in
ACTA. In particular, that spelling does not implicitly add a
manifest version or lifecycle event discriminator. A separately
selected extension that requires such a field must define it
explicitly.
The protectmcp namespace and every sub-namespace under it are
reserved to this document and are not available for third-party
registration. A verifier that cannot resolve a receipt's type
against the registry of Section 13.3 MUST therefore distinguish two
cases, because they are not the same finding and collapsing them
hides both.
Gomes Marques Expires 25 March 2027 [Page 17]
Internet-Draft Compliance Receipts Profile September 2026
A verifier resolves a type against the initial entries defined by the
selected revision of this profile and the additions authorized by the
selected registry edition. A protectmcp: value absent from that
applicable vocabulary is a non-conformance of the receipt: report
unverified with failure_class invalid under Section 11.5. Absence
from an older or incomplete local registry copy alone does not
establish that mismatch. If the verifier lacks the applicable
vocabulary, report the type-resolution axis as unverifiable and
derive the unverified summary and failure_class under Section 11.5,
identifying the missing profile or registry revision. This
distinction preserves the normative initial entries in Section 13.3
and does not authorize third-party use of a reserved name. An
unknown value outside the protectmcp namespace is the opposite case:
it MUST be reported as an unregistered namespace and MUST NOT be
treated as a failure, because a registry that has not yet caught up
with a legitimate third-party extension must not turn that party's
valid receipts into invalid ones. Such a receipt terminates in
unverified with failure_class unverifiable. A registered value that
this verifier has not implemented is also unverifiable, and a report
SHOULD name it as a gap in the verifier rather than a defect of the
receipt.
In none of these cases may the verifier return verified or
verified_keyed, and in none of them is the finding a signature or
binding failure: the cryptography of such a receipt may be entirely
sound. A verifier MUST report the selected profile revision and the
registry edition it resolved against, or state that the required
edition was unavailable. This identifies the vocabulary used for the
result without implying that an older local copy establishes the
contents of a newer edition.
5.2.4. issued_at
REQUIRED in this profile. The value MUST be an RFC 3339 timestamp
with an explicit UTC offset. The producing system MUST source the
value from a clock synchronized to a recognized time authority and
MUST NOT backdate it. Verifiers MUST reject receipts whose issued_at
is more than 300 seconds ahead of the verifier's own clock under this
profile's future-time rule. A receipt's age alone does not establish
cryptographic invalidity. Historical verification applies the
selected issuance revision, relevant key authorization and revocation
evidence, and documented appraisal-time policy; it does not guarantee
a passing result. A retention obligation is neither a maximum
cryptographic age nor proof that retained evidence is sufficient.
Action freshness and retention are evaluated separately.
Gomes Marques Expires 25 March 2027 [Page 18]
Internet-Draft Compliance Receipts Profile September 2026
5.2.5. issuer_id
issuer_id is REQUIRED and identifies the issuing principal in the
selected profile. It is an opaque, stable identifier. The trust
policy binds that principal to its authorized signing keys,
responsible organization and role. A principal identifier is not
itself proof of a legal entity's identity. Implementations MUST NOT
infer authority from the identifier's spelling, length or apparent
namespace.
signature.kid identifies candidate key material; it is distinct from
the issuer's identity. This profile does not require the two strings
to be equal for new issuance. Historical receipts that used equality
remain interpretable under their issuance policy. The verifier MUST
authenticate the key-to-issuer relationship independently, check the
permitted algorithm and key purpose, and use a signed key_thumbprint
when present to constrain key selection. The JSON signature object's
metadata is outside the signed payload; a kid alone is not an
authenticated authority claim.
A trusted export or an independently authenticated directory can
supply historical keys. Conflicting authoritative records or
unresolved ambiguity make key authorization unverifiable; the
verifier MUST NOT prefer a caller-supplied key merely because it
appears in an Audit Pack. Multiple rotated keys under an issuer are
permitted when key selection and historical authorization are
unambiguous. Current directory contents alone are not proof of past
authorization.
An organization MAY publish an LEI under [ISO17442] or a DID under
[W3C-DID] in its identity metadata. This profile does not require a
person or an organization to disclose a tax identifier in each
receipt. The example's synthetic identifier is illustrative and must
not be used as a production trust anchor. Existing identifiers and
signed history MUST NOT be rewritten to match a later naming
convention.
A kid is an unauthenticated lookup hint and may match multiple keys.
Implementations MUST NOT assume it is globally unique or equal to
issuer_id; ambiguity is resolved only through the authorized key set,
algorithm, signed thumbprint when present and issuance policy.
Gomes Marques Expires 25 March 2027 [Page 19]
Internet-Draft Compliance Receipts Profile September 2026
5.2.6. payload_digest (OPTIONAL upstream, REQUIRED in this profile)
payload_digest is a REQUIRED JSON object containing REQUIRED hash and
size members and an OPTIONAL preview. hash is exactly 64 lowercase
hexadecimal characters, without a sha256: prefix. size is a
nonnegative integer within the numeric domain of Section 4; it counts
the exact input octets covered by the digest. It is not the encoded
digest length. A producer MUST NOT invent zero as a substitute for
an unknown input length. A hash-mode caller must supply the original
length if a conforming descriptor is to be issued.
The input and algorithm follow Section 5.2.2 and Section 11.5: in
payload mode, hash the canonical context. In hash mode, use the
input defined by the caller's identified fingerprinting contract,
which may include a wrapper; size counts that input's bytes. Use the
defined keyed construction when hash_algo selects it. When a non-
null context is carried, the additional consistency check of
Section 11.2 applies. preview, when present, is a JSON string of at
most 256 Unicode scalar values, subject to Section 12.6. It is
optional display material, never an input from which the full digest
may be inferred. Its presence cannot replace retained required
evidence. Missing required input makes recomputation unverifiable; a
demonstrated digest or length mismatch is invalid. Historical
descriptors retain their actual version and committed bytes.
5.2.7. action_ref (OPTIONAL upstream, REQUIRED in this profile)
action_ref is REQUIRED and is the JSON string sha256: followed by 64
lowercase hexadecimal characters. It commits an Action descriptor A
containing exactly four members: agentId, actionType, scopeRequired
and timestamp. The first two are strings identifying the actor and
operation in the selected action vocabulary; timestamp is the
original action timestamp as an RFC 3339 string. scopeRequired is an
array of strings identifying the required scopes. Before
canonicalization, sort that array by UTF-16 code-unit order; preserve
repeated values and string contents without normalization. No other
members belong in A.
Compute action_ref = "sha256:" || lowercase_hex(SHA-
256(UTF8(JCS(A)))), with JCS and the input restrictions of Section 4.
Retain A in the authorized evidence-resolution material, with its
vocabulary and construction revision. Parties correlating the same
Action MUST use the same original descriptor; a verifier MUST NOT
substitute a later receipt timestamp or infer scopeRequired from a
policy name. Missing descriptor evidence makes this recomputation
unverifiable. It does not authorize guessing an empty array. An
opaque action ID, payload_digest.hash and action_ref have different
constructions and MUST NOT be substituted for one another.
Gomes Marques Expires 25 March 2027 [Page 20]
Internet-Draft Compliance Receipts Profile September 2026
This makes the inherited four-member construction explicit. The
typing and ordering rules above resolve previously underspecified
cases for new issuance. A historical action reference is evaluated
under its documented original construction; its committed value MUST
NOT be rewritten. The digest binds the descriptor, not a peer
receipt envelope, execution outcome or delivery acknowledgment.
5.2.8. sandbox_state (OPTIONAL upstream, REQUIRED for High-Risk in this
profile)
REQUIRED for receipts produced by High-Risk AI Systems under
[EU-AI-ACT]. sandbox_state is a JSON string describing observed OS-
level containment, with exactly three permitted values: enabled,
disabled or unavailable. The declaration does not by itself prove
containment. A Deployer that operates a High-Risk AI System and
produces a stream of receipts in which sandbox_state is consistently
disabled SHOULD treat that stream as a finding under the applicable
risk-management documentation requirement (Article 9 of [EU-AI-ACT]
for the Provider's risk management system, with which a Deployer
operating per Article 26(1) is required to be consistent) and
document the rationale in the Audit Pack metadata.
5.2.9. iteration_id (OPTIONAL upstream, REQUIRED for multi-step in this
profile)
iteration_id is REQUIRED for multi-step agent workflows and is a
stable JSON string identifying the logical task across its receipts.
An OPTIONAL session_id is an opaque JSON string used for transport-
session correlation. They have different scopes; neither is an
authenticated identity credential. A Compliance Receipt MAY carry
both.
5.2.10. key_thumbprint (No Upstream Equivalent)
No upstream equivalent. OPTIONAL for receipts emitted in
compatibility with prior revisions of this profile (earlier receipts
are evaluated under their selected revision; absence alone is allowed
only where that revision permits it); implementations conformant to
this revision SHOULD emit the field on every new receipt, and the
issuing platform MUST compute it when it does. The value is a JSON
string of the form sha256:<64 lowercase hex chars> carrying the JWK
Thumbprint of the receipt's signing key, computed per Section 3 of
[RFC7638]: SHA-256 over the canonical JSON serialization of the JWK
containing only the required members of the key's kty, with members
in lexicographic order and no whitespace. For an ML-DSA key the kty
is AKP and its required members are kty, alg and pub, per [RFC9964],
whose lexicographic order is alg, kty, pub; so the thumbprint input
for an ML-DSA-65 key is exactly {"alg":"ML-DSA-
Gomes Marques Expires 25 March 2027 [Page 21]
Internet-Draft Compliance Receipts Profile September 2026
65","kty":"AKP","pub":"..."}.
The pub member is base64url WITHOUT padding. That encoding is
relevant rather than cosmetic: the same key bytes rendered in the
standard base64 alphabet produce a different digest, which no third-
party verifier reproduces. The JWK input form is the one in which
the issuing platform publishes the verification key under Section 9.6
or the Audit Pack trust-anchor metadata, so a verifier recomputes the
thumbprint from the resolved key with no additional distribution.
The field is server-built: it is populated by the issuing platform at
signing time from its own signing key, never carried in the
producer's signing request, and a caller-supplied value MUST be
dropped before signing. The field is covered by the signature scope
of Section 5.4.
The signed thumbprint binds the receipt to exact public-key material.
A mismatch is an invalid key-binding check. A matching thumbprint
does not independently authenticate the issuer: an attacker can
create a different key and sign a different receipt containing its
thumbprint. The verifier still establishes issuer authorization
under Section 5.2.5. Absence is evaluated under the selected
revision and legacy policy, and is reported as an unchecked key-
binding axis where allowed.
5.2.11. Sequence Counter
seq is an OPTIONAL positive integer within the profile's safe-integer
range. It starts at 1 at genesis and increases by one for each
receipt in the same chain. The chain scope follows Section 5.4: the
core profile defines one linear chain per issuing principal, not two
independent counters under that principal. The producer assigns the
counter and predecessor in the same serialized emission operation and
ignores a caller-supplied counter.
A verifier compares counters only within the identified chain and
format contract. A present non-integer, boolean or non-positive
value is malformed. A repeated, decreasing or unexpectedly skipped
value fails sequence continuity; it establishes an inconsistency, not
whether its cause was withholding, a producer defect or missing
input. Missing legacy counters leave continuity unchecked.
Unsupported cross-format continuity is unverifiable unless an
explicit migration contract supplies it.
Gomes Marques Expires 25 March 2027 [Page 22]
Internet-Draft Compliance Receipts Profile September 2026
A sequence gap can expose missing entries within the observed series.
A valid prefix cannot expose an omitted tail without a trusted later
checkpoint, expected coverage interval or independently retained
later receipt. No counter proves that actions without receipts were
captured. The report states the observed interval and available
checkpoint evidence.
5.3. Decision Receipt Fields (type protectmcp:decision)
A protectmcp:decision receipt records a policy evaluation and uses
decision allow, deny or rate_limit. It carries the policy digest and
the tool identifier required by this type. The observation value is
not valid for this type.
When no policy was evaluated, the producer either declines to issue a
receipt or uses a defined lifecycle or observation type with decision
observation and the no-policy rule in Section 5.3.2. An internal
policy_decision value of none maps to that observation state only at
the documented emission boundary. Export of a retained receipt
preserves its existing signed values. Each lifecycle subtype's own
presence and decision rules apply.
tool_name is REQUIRED for protectmcp:decision. A signed decision is
evidence of the producer's recorded evaluation, not independent proof
that the policy was appropriate or correctly executed.
5.3.1. reason (OPTIONAL upstream, REQUIRED for deny/rate_limit in this
profile)
REQUIRED for Compliance Receipts where decision is deny or
rate_limit. The value MUST be a machine-readable reason code drawn
from a vocabulary documented in the Deployer's Audit Pack metadata.
5.3.2. policy_digest
policy_digest is REQUIRED. When a policy was evaluated, its value is
sha256:<64 lowercase hex chars>, committing the retained policy
artifact under its defined canonical-byte rule. The verifier
recomputes that digest where required by the selected evidence
policy. Unavailable required content is unverifiable; a demonstrated
mismatch is invalid.
Gomes Marques Expires 25 March 2027 [Page 23]
Internet-Draft Compliance Receipts Profile September 2026
The defined no-policy lifecycle and observation paths carry JSON null
and decision observation. Null does not assert that a policy passed.
Historical receipts with a documented no-policy sentinel digest
retain that issuance-version interpretation and the referenced
sentinel artifact; implementations MUST NOT rewrite those signed
values. Null is not permitted for a decision that claims policy
evaluation.
5.4. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile)
Each Compliance Receipt MUST contain previousReceiptHash in its
signed payload. At genesis the value is 64 zero characters.
Otherwise it is the 64-character lowercase hexadecimal encoding of
SHA-256(JCS(R)), where R is the complete signed payload of the
immediately preceding receipt emitted under the same issuer_id. The
literal member name is case-sensitive; aliases are not accepted. The
digest excludes the predecessor's signature object and anchors.
The JSON receipt signature separately authenticates its own payload
under Section 5.1. COSE and JWS carry that payload using their
respective protected signing constructions. A chain verifier MUST
recompute the predecessor-payload digest, verify each applicable
receipt signature and report the two checks separately. A link
cannot replace verification of the predecessor's signature.
Informative comparison: the cited revision of [ACTA-RECEIPTS]
specifies a chain over the complete signed receipt, including its
signature. This profile instead links the predecessor's signed
content. Where a peer's signature value must also be committed,
Section 5.8 defines the separate envelope commitment. This
comparison imports no additional ACTA requirements.
New streams under this revision use the local construction above.
Previously signed or anchored history MUST NOT be rewritten to change
its scope. A verifier that supports a different historical format
selects its actual documented construction explicitly and reports
that format; it MUST NOT silently substitute another digest scope.
Each issuer MUST maintain a single linear per-agent chain. When one
agent identity emits receipts from multiple concurrent execution
paths (for example parallel tool calls dispatched within a single
agent loop, or fan-out work performed by a thread pool inside one
issuer), the issuer MUST serialize emission through a single
predecessor pointer at a time: each newly emitted receipt's
previousReceiptHash MUST resolve to SHA-256(JCS(R)) for the
immediately prior receipt emitted by that same issuer_id (R as
defined at the start of this section), taken in emission order,
regardless of which concurrent execution path produced it. Parallel
Gomes Marques Expires 25 March 2027 [Page 24]
Internet-Draft Compliance Receipts Profile September 2026
sub-chains within one agent identity (for example, a per-receipt
chain_id discriminator that would partition one issuer's stream into
multiple independently advancing chains) are NOT defined by this
profile. An issuer that requires parallel sub-chains MUST express
each parallel path as a distinct agent identity, with its own
issuer_id value, its own signing key, and its own per-agent chain
rooted at the all-zero SHA-256 genesis value. Rationale:
deterministic verification of the chain segment covering an audit
window, as required by the regime bindings of Sections 6 and 7 (in
particular Section 7.4.2, Section 8.5.1, and Section 8.6.1), depends
on a single linear total order over the receipts emitted under each
agent identity. A verifier reconstructing the chain from a
regulator-supplied issuer_id needs that ordering to be well-defined
without out-of-band metadata.
Interoperability note: receipts of this profile chain over the
payload member R, whereas receipts of the bare [ACTA-RECEIPTS] format
chain over the whole-receipt object that includes the signature; the
two wire formats are distinguished by the REQUIRED v member of
Section 5.2.1: a receipt of this profile carries v, while the cited
ACTA revision carries none. Version is interpreted within an
explicitly selected format; its presence alone is not a universal
format identifier. The anchors key MUST NOT be used for this
purpose, because Section 5.5 makes an absent anchors member
conformant and an absent member distinguishes nothing; a present
anchors key is a corroborating signal and never a decisive one. The
type namespace MUST NOT be used either: it is shared with the
upstream format, and the published acta-02-chain-link vector carries
a payload.type of protectmcp:decision, so a prefix test on type
declines precisely the upstream receipt it is meant to admit. The
normative scope rule is the one defined in this section. The
published conformance vectors asqav-03-chain-link (payload scope) and
acta-02-chain-link (whole-receipt scope) corroborate it byte-for-byte
and are published in the asqav-sdk repository ([ASQAV-SDK],
maintained by this draft's author and commit-pinned in the reference
below), so an implementer or independent verifier choosing between
the two scopes need not maintain one fixture set per candidate scope.
Ed25519 uses [RFC8032]. JWK algorithm identifiers are interpreted
with [RFC7518] and the profile-specific algorithm rules. A verifier
MUST NOT infer an algorithm from the key identifier alone or silently
substitute another algorithm.
Gomes Marques Expires 25 March 2027 [Page 25]
Internet-Draft Compliance Receipts Profile September 2026
5.5. Anchoring (No Upstream Equivalent)
The commitment formula in this section applies to the core JSON
framing. This revision does not define a complete COSE or JWS anchor
transport. A separately selected transport profile must specify its
exact commitment bytes and proof carriage; a verifier MUST NOT apply
the JSON formula to non-JSON bytes or infer full anchor conformance
from a counterparty-binding digest.
Issuers SHOULD obtain timestamp evidence over each receipt,
individually or through a batch with a retained inclusion proof.
Synchronous RFC 3161 acquisition SHOULD be available where the
deployment can support it. Best-effort TSA availability is not a
hard guarantee. A selected regulatory-evidence profile or relying-
party policy MAY impose a stricter anchor floor; that floor MUST name
its authority and applicability and MUST NOT be presented as the
literal wording of a law without the supporting provision.
For both [RFC3161] and [OPENTIMESTAMPS], the commitment input is SHA-
256(JCS(envelope_minus_anchors)), with the anchors key removed
completely and the original payload and signature retained. Setting
the key to null or an empty array in the commitment input is
incorrect. Stored signed and anchored bytes MUST NOT be rewritten
during an encoding or schema migration. An anchor entry is a VALID
ANCHOR when its value bytes cryptographically re-verify against that
commitment input at verification time; an entry whose bytes do not
re-verify, or whose proof has not yet been produced, is not a valid
anchor, and a verifier MUST NOT derive validity from the presence of
anchor metadata alone.
An issuer-operated timestamp is not an independent witness.
Independently operated evidence MAY arrive later; the verifier MUST
report the observed evidence and its validation state separately from
the issuer's signature. An OpenTimestamps commitment that has been
submitted to a calendar but has not yet upgraded to a Bitcoin block
attestation is pending. This profile sets the upgrade bound at seven
days from issuance; it is a profile-imposed bound, not a property of
the OpenTimestamps protocol, whose calendar-to-block time depends on
the calendar operator's publication interval. When the selected
policy requires such an upgrade, exceeding the bound fails that
policy; it does not retroactively make the payload signature invalid.
RFC 3161 responses, OTS proofs and aggregate inclusion paths MUST be
retained for the applicable evidence-retention period.
The anchors array MAY be absent or empty, both meaning that no anchor
evidence was presented. A null value is malformed under this
revision; an explicitly selected legacy format may define a different
rule. Absent evidence MUST NOT be reported valid. Whether it
Gomes Marques Expires 25 March 2027 [Page 26]
Internet-Draft Compliance Receipts Profile September 2026
prevents full verification depends on the required axes of the
selected profile and relying-party policy. Verifiers MUST still
report other independently evaluable axes.
Each anchor entry has a required type of rfc3161 or opentimestamps
and a required value holding base64-encoded TimeStampResp DER or OTS
proof bytes respectively. An optional status of anchored, pending or
failed is operational metadata. Optional anchor_block_hash, tsa_url
and operator_id are likewise metadata. No metadata value establishes
proof validity, a trust root or operator independence. Verifiers
MUST validate the cryptographic evidence against independently
configured trust material. They MUST NOT fetch a caller-supplied URL
as a trust decision. A historical qualified-timestamp claim requires
the applicable certificate, time, revocation and trusted-list policy,
not only a root certificate.
witness_policy is an OPTIONAL signed-payload object. It contains a
REQUIRED positive integer required and a REQUIRED nonempty array
witnesses of distinct operator identifiers. required MUST NOT exceed
the array length. Operator identifiers name trust-policy records,
not anchor-type labels. Each counted entry MUST re-verify over the
committed bytes and resolve to an independently trusted operator in
that policy. Multiple entries or different protocols controlled by
one operator count once. An unresolved identity or independence
relationship is unverifiable and MUST NOT be counted.
When witness_policy is present, the verifier MUST recompute the count
and compare it with the signed threshold. It MUST NOT trust a
producer's witness_quorum_met flag. When the member is absent, the
receipt-declared policy axis is undeclared, not satisfied. The
relying party's external floor is evaluated separately: a weak or
absent producer policy cannot waive it. The governance document may
publish issuance defaults, but changing that document cannot change
the policy committed by an existing receipt.
This reverses the prior -09 working text's declaration-only policy.
Both the threshold and the selected operator set must travel under
the signature so a holder can evaluate the declaration without
trusting a later mutable governance document. Legacy declarations
absent from the signed bytes remain unavailable to that evaluation
and MUST NOT be reconstructed as authenticated claims.
The optional signed beacon_ref and its construction-specific limits
remain defined in Section 5.5, Paragraph 11. A public round number
or issuer-supplied observation time alone establishes no lower time
bound. Beacon evidence is separate from timestamp anchoring and does
not satisfy a witness quorum.
Gomes Marques Expires 25 March 2027 [Page 27]
Internet-Draft Compliance Receipts Profile September 2026
The OPTIONAL signed-payload member beacon_ref commits to a cached
public randomness beacon response. In the reference platform it
carries the five members registered in Section 13.2. A verifier
seeking a lower time bound must independently authenticate the
carried signature for the declared chain and round, using trusted
chain parameters and the applicable drand scheme ([DRAND-SPEC]). A
receipt's commitment to an unpredictable, authenticated beacon
signature can support such a bound under the beacon's
unpredictability and timing assumptions; the round number, chain
identifier, or issuer's observed_at assertion alone cannot. The
reference platform's structural check does not authenticate the BLS
signature, and the reference SDK does not perform that
authentication. A successful receipt-verification result therefore
does not establish a beacon-derived time bound. The beacon is
separate from the anchor evidence and does not satisfy an anchor or
witness requirement.
RFC 3161 certificate identification uses the applicable update in
[RFC5816]. Successful token parsing is separate from certificate-
path, historical validity, message-imprint and trust-policy checks.
5.6. Signer-Outage Evidence (unsigned_gap)
This section is normative. The hash chain of Section 5.4 links the
receipts that exist and is silent about Actions for which no receipt
could be minted, so a chain verifies perfectly across a signer
outage. An issuing platform that fails to mint a receipt for an
Action because its signer was unavailable MUST tally that failure and
MUST carry the tally in the unsigned_gap member of the signed payload
of the next receipt it successfully mints for that issuer. The
member is an object with three REQUIRED members. count is a JSON
integer greater than or equal to 1. from and to are ISO 8601
timestamps with explicit timezone bounding the outage, where from is
not later than to. The member is absent when no outage precedes the
receipt, so receipts minted in normal operation are unchanged.
The tally MUST be cleared only when a receipt carrying it has been
signed. A signing attempt refused for an authorization reason (a
revoked or suspended agent identity, or a failed policy gate) is NOT
a signer outage and MUST NOT be tallied. Such refusals are
decisions, evidenced under Section 5.3. The member is server-built
in the sense of Section 5.11: a caller-supplied value MUST be dropped
before signing. A verifier MUST NOT read it as evidence that the
unsigned Actions were policy-evaluated.
Gomes Marques Expires 25 March 2027 [Page 28]
Internet-Draft Compliance Receipts Profile September 2026
5.7. Extension Fields
This profile registers extension fields across seven groupings that
MAY appear in the signed payload object alongside the common fields
defined in Section 5.2: (a) regulatory classification fields
(risk_class, incident_class) defined in this section; (b) the cross-
agent envelope-binding field counterparty_binding defined in
Section 5.8; (c) per-action validity-window and integrity fields
(result_digest, expires_at, nonce, tool_fingerprint,
config_manifest_digest, cve_inventory_digest) and build-provenance
fields (executable_hash, sbom_digest, slsa_provenance_pointer,
supply_chain_pointer) defined in Section 5.9 and Section 5.10; (d)
server-built enforcement-control record fields
(authorized_under_mandate, controls_evaluated) defined in
Section 5.11; (e) producer-asserted risk-acceptance fields
(approver_id, initiator_id, acceptance_reason, accepted_at,
supersedes, sarif_digest, finding_ref, approval_ref, risk_snapshot)
defined in Section 5.12; (f) producer-asserted code-authorship fields
(repo_ref, commit_sha, base_sha, change_digest, change_ref,
change_approval_ref, change_class, authored_by) defined in
Section 5.14; and (g) self-declared threat-framework taxonomy fields
(mitre_techniques, mitre_atlas, owasp_llm_top10, nist_ai_rmf,
iso_42001, eu_ai_act_articles), the opaque caller-supplied
rfc3161_timestamp token, and the platform-set guard
framework_mappings_self_declared defined in Section 5.15. All
extension fields appear inside the signed payload object and are
therefore covered by the signature scope defined in Section 5.4.
risk_class: A vocabulary term identifying the risk classification of
the Action under the Deployer's risk management documentation.
The vocabulary MUST be referenced in the Audit Pack metadata.
Where the Deployer operates under [EU-AI-ACT], the documentation
is the Provider's Article 9 risk management system as referenced
via the instructions for use under Article 26(1); where the
Deployer operates under [COLORADO-ADMT], there is no statutory
risk-management-programme document to reference: the reenacted
Part 17 carries no such duty. The documentation is instead
whatever the Deployer maintains to satisfy the pre-use notice of
Section 6-1-1704(1) and, where the Deployer is also a developer,
the technical documentation of Section 6-1-1702
incident_class: A vocabulary term identifying the incident
classification of the Action under the applicable regime: an ICT-
related incident under [DORA], with classification criteria in
[REG-2024-1772] and the canonical reporting enumeration of Annex
II data glossary, field 3.23 (Type of the incident) of
[REG-2025-302] (verifiers MUST resolve the canonical values from
the regulation directly); a Cybersecurity Event under 23 NYCRR
Gomes Marques Expires 25 March 2027 [Page 29]
Internet-Draft Compliance Receipts Profile September 2026
500.1(f) (or, where the Section 500.17(a) reporting threshold is
met, a Cybersecurity Incident under 23 NYCRR 500.1(g)) for Covered
Entities of [NYDFS-500]; a Covered Cyber Incident under [CIRCIA]
once the final rule takes effect; or a security incident under 45
CFR 164.304 for covered entities and business associates within
the scope of [HIPAA-SECURITY]. Implementations MAY refine the
set, provided the flattened mapping in the Audit Pack manifest
(Section 10) projects each refinement to the applicable canonical
category for each in-scope regime.
risk_class MUST be encoded as a JSON string. incident_class MUST be
encoded as a JSON string drawn from the canonical vocabulary
referenced in the Audit Pack, OR as a JSON array of such strings to
preserve cross-regime classification (for example, a single Action
that is both a DORA ICT-related incident and a CIRCIA Covered Cyber
Incident, or both a NYDFS Cybersecurity Incident and a CIRCIA Covered
Cyber Incident). Both fields are OPTIONAL at the syntactic level but
MAY be REQUIRED by the regime bindings in Sections 6 and 7 of this
document.
Implementations MAY define additional extension fields. Such fields
MUST NOT collide with names defined by this document or its local
registries. No moving external field list is incorporated.
Implementations defining extension fields SHOULD register them in the
registry described in Section 13.
A verifier that encounters a signed-payload member it does not
recognise MUST preserve it byte-for-byte, because it lies inside the
signature scope of Section 5.4 and dropping or rewriting it destroys
the signature. The verifier MUST ignore the member for the purpose
of determining conformance and MUST NOT report its presence as a
failure or as a reason to withhold a verdict. This rule does not
apply to v: an unrecognised wire version is not an unrecognised
member, and Section 5.2.1 governs it. An unrecognised member carries
no protectmcp semantics, and a claim about such semantics is reported
under Section 13.3 rather than inferred from the member name.
5.8. Counterparty Binding
This section is normative. counterparty_binding is an in-payload
object an acknowledging agent ("B") emits to carry a cryptographic
digest of the envelope-minus-anchors object of an originating agent
("A"). It provides cross-agent byte-equality evidence when a shared
intermediary sits between two honest agents and the per-agent hash
chains of Section 5.4 validate independently regardless of whether
B's observed bytes equal A's signed bytes. action_ref binds an Action
descriptor under Section 5.2.7; it does not bind the peer receipt
envelope; counterparty_binding moves the evidence onto B's own COSE
Gomes Marques Expires 25 March 2027 [Page 30]
Internet-Draft Compliance Receipts Profile September 2026
or JWS signature, which the verifier already trusts.
5.8.1. Wire Shape
The field MUST appear inside the signed payload object. It MUST NOT
appear in unprotected COSE or JWS header parameters, or in
external_aad per [RFC9052] Section 4.3 when the receipt is used for
audit (external_aad is permissible only in transport-optimized modes
out of scope for Compliance Receipts). For COSE-framed receipts the
field sits inside the COSE_Sign1 or COSE_Sign payload per [RFC9052]
Section 4.1; for JWS-framed receipts it is a top-level claim per
[RFC7515].
The field is an object with the following members.
envelope_hash: REQUIRED string. Base64url-encoded SHA-256 digest
computed over A's signed envelope with the anchors array excluded,
that is over the envelope-minus-anchors object of Section 5.5,
which includes A's signature bytes. The digest input is framing-
specific:
* For JSON framing, preserve A's parsed payload values and exact
signature object, remove the anchors member, and apply JCS once
to the resulting two-key envelope. Do not normalize strings,
change payload values, or decode and re-encode the signature
string. The digest input is the UTF-8 JCS encoding of
{"payload": A.payload, "signature": A.signature}. This is the
JSON anchor commitment input defined in Section 5.5.
* For a separately selected COSE framing, commit the exact
retained COSE signed-object bytes. Do not re-encode an already
signed object merely to change map ordering.
* For a separately selected JWS framing, commit the exact
retained JWS Compact Serialization bytes. Do not reconstruct
its header or payload encoding.
Gomes Marques Expires 25 March 2027 [Page 31]
Internet-Draft Compliance Receipts Profile September 2026
The digest algorithm is SHA-256 (mandatory-to-implement). The
encoding MUST be base64url without padding per [RFC4648]
Section 5, the single alphabet of Section 5, for receipts issued
on or after the publication date of this revision. A receipt
issued before that date MAY carry the standard base64 alphabet of
[RFC4648] Section 4; a verifier MUST decode either alphabet, with
or without padding, and compare the decoded 32 digest bytes rather
than the encoded strings, so a pre-cutover receipt does not fail
on encoding alone. Including A's signature in the digest scope
binds the signed-over content of A's receipt at the envelope level
and prevents an intermediary that re-signs A's claims with a
different key from escaping detection.
Excluding the anchors array is deliberate, and three reasons
govern it. Anchors are OPTIONAL and change after issuance under
this profile's own rules: Section 5.5 permits late attachment
within a documented bound, an [OPENTIMESTAMPS] proof upgrades from
a calendar attestation to a Bitcoin block attestation, and an
issuing platform MAY add a qualified external token later, so a
digest that covered them would pin a passing state of A's receipt
rather than A's signed bytes and would break as soon as A's
anchoring completed. The non-JSON binding constructions are
separate; this revision does not define their complete anchor
transport. For the core JSON framing, one digest input serves
both the anchor commitment of Section 5.5 and the acknowledgment
of this section, so an anchor and an acknowledgment commit to the
same bytes and every verifier computes one value rather than two.
The binding preserves the peer's selected framing and exact
committed representation. JSON, COSE and JWS can produce
different commitment bytes for related content. A verifier MUST
NOT transcode before checking a binding. A digest mismatch
establishes disagreement with the commitment; its cause must not
be asserted without further evidence.
This revision fixes the binding digest to SHA-256. Another digest
construction requires an explicitly versioned binding
specification; an out-of-band algorithm label MUST NOT change this
field's interpretation.
scope: REQUIRED string from this revision onward. The only value
defined by this profile is envelope_minus_anchors, naming the
digest scope stated above. A binding that carries no scope member
was computed under the three-key text of revisions -04 through
-08, whose scope this revision corrects; a verifier MUST report
such a binding as unverifiable, legacy scope, and MUST NOT report
it as verified or as failed on byte-equality grounds. Where the
Audit Pack retains A's envelope exactly as B received it,
Gomes Marques Expires 25 March 2027 [Page 32]
Internet-Draft Compliance Receipts Profile September 2026
including A's anchors array as B saw it, a verifier MAY verify a
legacy binding against that retained snapshot and MUST label the
outcome as verified under the legacy scope. A verifier MUST NOT
try both scopes and report whichever matches: a digest that
matches under a scope the receipt did not declare is not evidence,
and trying both would let a mismatch be laundered into a pass.
receipt_ref: REQUIRED opaque content-addressed locator the verifier
resolves through the Audit Pack or a Deployer-published index to
A's signed envelope as A emitted it, from which the verifier
derives the envelope-minus-anchors digest input. The value is an
opaque string from the verifier's perspective; producers MAY use
any stable identifier scheme (URI, content-addressed digest,
opaque database id) so long as the Audit Pack resolution layer
returns the correct envelope bytes. Future profiles (for example,
a SCITT-style inclusion-proof profile layered under the extension-
field rules of Section 5.7) MAY layer on this field.
expect_ack_from: OPTIONAL string identifying the expected
acknowledging principal. For new issuance, compare it with the
acknowledging receipt's authenticated payload.issuer_id after
validating key authorization. It is not an external signature.kid
match. Historical key-identifier expectations require an
explicitly selected legacy interpretation.
transport_label: OPTIONAL string (mcp, bus, orchestrator, http).
Operational only; verifiers MUST NOT derive trust from this label.
"counterparty_binding": {
"envelope_hash": "bDqg...v5PE",
"scope": "envelope_minus_anchors",
"receipt_ref": "asqav-receipt://org/123/agent_A/seq/4811",
"expect_ack_from": "00000000000000000098",
"transport_label": "mcp"
}
The COSE form follows the same member set under deterministic CBOR
map ordering per [RFC8949] Section 4.2.
5.8.2. Emitter Behaviour
B SHOULD emit counterparty_binding when a signed acknowledgment
expectation or the selected policy requires it. B MUST compute the
commitment using the framing-specific construction in Section 5.8.1.
For JSON, that construction applies JCS to the envelope with anchors
removed and the original signature string preserved. Changes to
whitespace or member order that preserve the JCS representation do
not change the commitment. Where one acknowledgment confirms several
Gomes Marques Expires 25 March 2027 [Page 33]
Internet-Draft Compliance Receipts Profile September 2026
peers, each binding is evaluated separately; it does not prove that
all peers received identical application data.
5.8.3. Verifier Behaviour
A Compliance Verifier processing a receipt carrying
counterparty_binding MUST, in addition to Section 11.2, resolve
receipt_ref through the Audit Pack or a Deployer-published index to
A's signed envelope, reduce it to the envelope-minus-anchors object
by removing the anchors key, recompute the SHA-256 digest of that
object under the scope rule of Section 5.8.1, encode the result, and
compare to envelope_hash. A non-resolving receipt_ref or a digest
mismatch MUST cause the acknowledging receipt to be reported non-
conformant; liveness loss at A MUST NOT be silently treated as
success. A verifier that has no resolution mechanism available at
all, such as an offline verifier with neither an Audit Pack nor a
published index, has not performed this check rather than failed it:
it MUST report the binding as unverified and MUST NOT report the
receipt as verified on the strength of a binding it never resolved.
An unresolved counterparty binding supplies no verified
corroboration. Where expect_ack_from is present, the verifier MUST
compare it with the acknowledging receipt's authenticated
payload.issuer_id after establishing the key's authorization for that
principal. A demonstrated mismatch is invalid. Legacy key-
identifier expectations are handled only under their documented
issuance policy.
The verifier MUST read the scope member before recomputing. A
binding declaring envelope_minus_anchors is recomputed under the rule
above. A binding with no scope member is a legacy binding under the
superseded three-key scope of revisions -04 through -08: the verifier
MUST report it as unverifiable, legacy scope, and MUST NOT report it
as verified, unless the Audit Pack retains A's envelope exactly as B
received it, in which case the verifier MAY recompute against that
retained snapshot and MUST label the outcome as verified under the
legacy scope. A verifier MUST NOT recompute under both scopes and
report whichever matches. A binding declaring a scope value this
profile does not define is reported unverifiable on the same axis,
never verified.
The holder retains peer envelopes and supporting evidence according
to their lawful record-specific policy. Unavailable required peer
evidence leaves the binding unverifiable. Chains of several parties
use pairwise bindings; a co-signed envelope does not automatically
establish the same sequence of acknowledgements.
Gomes Marques Expires 25 March 2027 [Page 34]
Internet-Draft Compliance Receipts Profile September 2026
5.9. Result-Bound and Validity-Window Extensions
This section is normative. It defines six OPTIONAL extension fields
that may appear inside the signed payload object to bind the receipt
to the byte-equality of a downstream result, to bound the validity
window of a decision, to declare the tool and configuration that
produced the action, and to record the supply-chain Common
Vulnerabilities and Exposures (CVE) inventory in effect at signing
time. The fields are independently OPTIONAL; an implementation MAY
emit any subset. All six are covered by the signature scope defined
in Section 5.4.
result_digest: OPTIONAL JSON string formatted sha256:<64 lowercase
hex chars>. It is NOT an object and NOT the shape of
payload_digest: the two fields are described together elsewhere
and they differ on both axes, since payload_digest is an object
whose hash member is unprefixed hexadecimal, while this field is a
bare string in the self-describing prefixed form. There is no
size or preview member on this field. The digest covers the
canonicalized bytes of the downstream Action's result body
(response payload, tool output, model completion). The field is
emitted on a follow-up protectmcp:observation:result_bound receipt
that references the originating protectmcp:decision via
action_ref; a verifier processing a result-bound observation MUST
treat a digest mismatch between result_digest and the verifier's
local recomputation over retained result bytes as a non-
conformance condition. Result bytes covered by result_digest
follow their own lawful evidence policy under the legal-
applicability and privacy rules.
expires_at: OPTIONAL RFC 3339 timestamp with an explicit UTC offset,
encoded as a JSON string. Declares the wall-clock time after
which the producing system considers the decision result stale and
not safe to replay. The field provides the upper bound of the
decision's validity window, additive to the 300-second forward-
skew bound on issued_at of Section 5.2.4; expires_at bounds replay
safety from above, the forward-skew rule bounds emission honesty
from above. The window is declared, not enforced, by this field:
enforcement against a replaying action is the verifier's and the
Deployer's obligation under the next paragraph, and the receipt
record itself never expires. A verifier MUST reject a downstream
action that replays a decision whose expires_at lies in the past
relative to the replay's wall clock; verifiers MUST NOT reject the
originating receipt itself solely because expires_at has elapsed
(the receipt remains valid as a record of the decision at
issued_at).
nonce: OPTIONAL JSON string carrying a producer-generated value that
Gomes Marques Expires 25 March 2027 [Page 35]
Internet-Draft Compliance Receipts Profile September 2026
is unique across the producer's emission stream for the lifetime
of the cryptographic key identified by kid. The field SHOULD be
the lowercase hexadecimal encoding of 12 random bytes (24
hexadecimal characters). Verifiers SHOULD reject a second receipt
that carries the same nonce under the same issuer_id as a replay
candidate; the rejection is informational where the bound action
is idempotent and relevant where the bound action is not. The
field is OPTIONAL at the syntactic level but is a SHOULD-emit for
any producer whose downstream actions are not idempotent. The
nonce is NOT a challenge-response freshness proof: it is generated
by the producer, not an unpredictable challenge generated and
retained by the party appraising the evidence, so it supports
emission correlation and replay-candidate flagging but does not
prove uniqueness or execution.
tool_fingerprint: OPTIONAL JSON string of 32 lowercase hexadecimal
characters carrying the first 32 hexadecimal characters (128 bits)
of the SHA-256 digest over the JCS canonicalization ([RFC8785]) of
the JSON object {"tool_name": <tool name>, "schema": <declared
input schema>}, where schema is the JSON object form of the tool's
declared input schema (an empty object when the tool declares
none). The field binds a receipt to a specific tool identity; a
verifier or auditor reproducing the Action can detect tool drift
(the same tool name with a different declared schema) by comparing
fingerprints across receipts in the same chain, and a fingerprint
change under an unchanged tool name surfaces naming collisions and
registry shadowing. The field is OPTIONAL and complementary to
action_ref: action_ref identifies the call, tool_fingerprint
identifies the callee.
config_manifest_digest: OPTIONAL JSON string formatted sha256:<64
lowercase hex chars> over the canonical bytes of the producer's
configuration manifest in effect at the time the Action was
signed. The manifest content is operator-defined and SHOULD
include the producer's policy bundle reference, model identifiers
and versions, prompt template digests, retrieval index
identifiers, and inputs relevant to any separately applicable
modification test, including Article 43 of [EU-AI-ACT] and the
intentional and substantial modification definition in
Section 6-1-1701(12) of [COLORADO-ADMT]. A configuration change
alone does not establish that either legal test is met. Because
the manifest content is operator-defined, an operator's manifest
MAY include an attestation or appraisal digest among its inputs;
this profile registers no dedicated field for one. The field is
OPTIONAL but, when emitted, SHOULD resolve through the Audit Pack
to retained manifest bytes for its lawful record-specific
retention period.
Gomes Marques Expires 25 March 2027 [Page 36]
Internet-Draft Compliance Receipts Profile September 2026
cve_inventory_digest: OPTIONAL JSON string formatted sha256:<64
lowercase hex chars> over the canonical bytes of the producer's
CVE inventory at the time the Action was signed. The inventory
content SHOULD list the CVE identifiers known to apply to the
producer's executing image and its declared runtime dependencies,
plus the producer's accepted-residual rationale per [EU-AI-ACT]
Article 15 robustness obligations or the equivalent obligations
under the EU and US evidence mappings. The field binds a snapshot
of the producer's known-vulnerability surface to the receipt; a
regulator examining the receipt can resolve the digest through the
Audit Pack to the canonical inventory bytes that were in effect
when the Action was signed, rather than relying on a later-time
inventory that may have been updated after the Action was
performed.
Implementations emitting result_digest SHOULD use the dedicated
protectmcp:observation:result_bound type registered in Section 13.3
for the follow-up receipt that carries the bound digest.
Implementations MAY emit expires_at, nonce, tool_fingerprint,
config_manifest_digest, and cve_inventory_digest on any receipt type
defined by this profile; the fields are type-agnostic.
Two type-bound presence rules attach to the fields of this section.
The reference cloud implementation rejects at signing time, as the
configuration_change_missing_config_manifest_digest guard, a receipt
of type protectmcp:lifecycle:configuration_change (registered in
Section 13.3) that lacks a well-formed config_manifest_digest; and it
rejects at signing time, as the result_bound_missing_result_digest
guard, a receipt of type protectmcp:observation:result_bound that
lacks a well-formed result_digest.
Layering note on the validity window: this profile places the
validity-window bounds in the receipt itself. nonce and expires_at
ride inside the signed payload, and the conformant verifier enforces
them: the expires_at replay rejection is a mandatory check of
Section 11.2, and a verifier that maintains a seen-nonce index flags
duplicate emissions on the duplicate_emission_candidate axis of
Section 11.4. Enforcement of the nonce uniqueness bound requires
that seen-nonce state and is therefore conditional; enforcement
against replay of an expired decision is an application decision
point the verifier's rejection feeds. Section 14.1 of
[DRAFT-SOKOLOV-AEP-COMPOSITION] reports that in that composition the
freshness check was enforced outside the conformant Verifier, in the
application's own appraisal step; a producer composing that pattern
with this profile SHOULD emit nonce and expires_at so the receipt
layer carries the bounds.
Gomes Marques Expires 25 March 2027 [Page 37]
Internet-Draft Compliance Receipts Profile September 2026
5.10. Build-Provenance Extensions
This section is normative. It defines four OPTIONAL fields for
evidence about the software associated with an Action:
executable_hash identifies an artifact, sbom_digest commits to an
SBOM document, slsa_provenance_pointer locates a build attestation,
and supply_chain_pointer locates transparency-log evidence. An
implementation MAY emit any subset. All four fields are covered by
the signature scope in Section 5.4. Signing a digest or locator
binds the producer's assertion; it does not by itself authenticate
the referenced artifact, prove execution or establish complete
dependency coverage.
executable_hash: OPTIONAL JSON string formatted sha256:<64 lowercase
hex chars>. For a container, its value is the SHA-256 content
digest of the exact platform-specific OCI image manifest
identified by the runtime for the executing image, computed over
that manifest's bytes under the OCI Image Specification v1.1.1
content-descriptor rules (https://github.com/opencontainers/image-
spec/blob/v1.1.1/descriptor.md). It is not a hash of the digest
string, a mutable tag lookup, an image-index digest or an
assertion about every file in a running container. For a non-
container executable, it is SHA-256 over the binary file bytes
observed at the resolved execution path. The Audit Pack records
the artifact kind and observation method. A file or manifest
digest alone does not prove which bytes actually executed. A
verifier MAY compare this identity with an authenticated build
attestation's subject. A mismatch for the same artifact and
digest scope is reported as inconsistent evidence; different
scopes require an evidenced mapping and otherwise remain
incomparable. A required comparison that is inconsistent or
unverifiable prevents full verification under Section 11.5.
sbom_digest: OPTIONAL JSON string formatted sha256:<64 lowercase hex
Gomes Marques Expires 25 March 2027 [Page 38]
Internet-Draft Compliance Receipts Profile September 2026
chars>, computed over an SBOM document in CycloneDX JSON or SPDX
JSON form. This profile uses the complete document canonicalized
under [RFC8785] as the digest input; it does not assume that every
edition of either SBOM format defines a common canonicalization
algorithm. The Audit Pack manifest MUST identify the format,
exact specification version, digest input rule and retained
document. The document MUST satisfy JCS input constraints;
otherwise this encoding cannot be used. The receipt payload's
additional safe-integer restriction does not apply to numbers
inside the separately retained SBOM document. Existing receipts
using a different declared digest rule retain that rule under an
explicit legacy adapter; missing or ambiguous rules are
unverifiable and MUST NOT be guessed. The digest commits to the
document, not to the accuracy or completeness of its dependency
claims.
slsa_provenance_pointer: OPTIONAL JSON string carrying an HTTPS URL
for a SLSA build provenance attestation about the artifact
identified by executable_hash. The target SHOULD use the SLSA
Provenance v1 predicate (https://slsa.dev/spec/v1.0/provenance) in
an in-toto Statement v1. Other supported versions require
explicit version selection. A verifier checks the attestation
signature, the independently authorized signer-builder pair and
the subject digest under its selected policy before reporting
verified provenance. A URL, a recognized format or the presence
of a signature does not establish those checks. Missing required
evidence remains unverifiable. The build platform's statements
remain bounded by its trust policy and do not prove that the
artifact later executed.
supply_chain_pointer: OPTIONAL JSON string carrying an HTTPS URL for
transparency-log evidence concerning the identified build
artifact. An in-toto statement is an attestation format; Sigstore
is a signing and verification ecosystem; Rekor is a transparency-
log service used by Sigstore. They are not three interchangeable
log formats, and this profile gives them no preference order. The
Audit Pack identifies the supported log and entry format and
retains the evidence needed for verification. A verifier claiming
verified log inclusion MUST validate the artifact or attestation
binding, inclusion proof and authenticated log checkpoint under
its independently configured log trust policy. A locator alone is
not inclusion evidence. Unsupported or missing required evidence
is unverifiable. Log inclusion does not establish the truth of an
attestation, complete capture or independent corroboration of a
SLSA statement recorded in that same log.
Gomes Marques Expires 25 March 2027 [Page 39]
Internet-Draft Compliance Receipts Profile September 2026
Executable hashes, SBOMs and build attestations can help investigate
which software produced a recorded action. Their use here is a
profile recommendation. The cited logging and incident-management
provisions do not themselves prescribe this particular set of
artifacts. Retain each artifact under its lawful evidence policy and
report any unavailable input as a verification limit.
5.11. Enforcement-Control Record Extensions
This section is normative. It defines two OPTIONAL extension fields
that record, inside the signed payload object, which authorization
and enforcement controls the issuing platform actually evaluated when
it signed the receipt. Both fields are server-built: they are
populated by the issuing platform at signing time, never carried in
the producer's signing request, and a caller-supplied value for
either field MUST be dropped by the issuing platform before signing.
Both fields are covered by the signature scope defined in
Section 5.4. The design rule for both fields is omission-over-false
attestation: a control that did not run is represented by the absence
of its key, never by a present key asserting a result the control did
not produce. The same omission discipline extends to freshness
(informatively): a deployment that cannot perform an external
freshness check inside the party that appraises evidence records that
limitation by the absence of any freshness assertion, never by
treating an affirming result as fresh. The two fields each carry a
false-attestation guard that rejects a present-but-malformed
attestation, in the same spirit as the
framework_mappings_self_declared guard of Section 5.15 and the
witness_policy quorum guard of Section 5.5. The key set of this
section is closed: both fields are server-built, unknown keys MUST be
rejected, and this section does not convey remote attestation
results.
authorized_under_mandate: OPTIONAL object recording that the Action
was signed under a self-declared authorizing mandate. The object
carries four members: mandate_id (REQUIRED string, the issuer-
scoped identifier of the mandate the Action was authorized under),
issuer_id (REQUIRED string, the identifier of the party that
issued the mandate, in the bare-identifier form required by
Section 5.2.5), scope_digest (REQUIRED string formatted sha256:<64
lowercase hex chars> over the canonical bytes of the mandate's
authorized-action-types scope), and verified (REQUIRED boolean).
The trust semantics are deliberately narrow: verified=true asserts
self-declared issuer authority, the same trust level as
framework_mappings_self_declared of Section 5.15, and is NEVER an
issuing-platform attestation of verified third-party
authorization. The mandate binding is self-declared by the
issuer, is evaluated against the issuing platform's own clock at
Gomes Marques Expires 25 March 2027 [Page 40]
Internet-Draft Compliance Receipts Profile September 2026
signing time, and scopes the Action to a set of authorized action
types; this profile does NOT define a value cap, a counterparty
restriction, or any other constraint on the mandate, and a
verifier MUST NOT infer one from the presence of this field. A
verifier resolves scope_digest by retrieving the mandate
identified by mandate_id through the Audit Pack or a Deployer-
published mandate index and recomputing the digest over the
canonical scope bytes; a mismatch MUST be reported as a non-
conformance condition. The false-attestation guard for this
field, published as false_mandate_attestation_guard in the issuing
platform's wire vocabulary, rejects an authorized_under_mandate
object that is present but does not carry all of mandate_id,
issuer_id, verified=true, and a well-formed scope_digest: a
present-but-malformed attestation is rejected at signing time
rather than signed and surfaced as truth.
controls_evaluated: OPTIONAL object enumerating the enforcement
controls that genuinely fired when the issuing platform signed the
Action, plus the allow result. The member keys are drawn from a
closed set: emergency_halt, delegation_scope, quorum, mandate,
policy, content_scan, and result; an unknown key MUST be rejected.
Each control key is present ONLY when its control actually ran on
this sign; an absent key means the control never ran on this sign,
and a verifier MUST NOT infer from an absent key that the control
ran and passed silently. The quorum member, when present, MUST
carry fired=true together with a 64-lowercase-hex attestation_hash
proving the quorum evaluation; the policy member, when present and
asserting a policy was evaluated, MUST carry matched_count greater
than or equal to 1. The false-attestation guard for this field,
published as false_control_attestation_guard in the issuing
platform's wire vocabulary, rejects a present-but-malformed
controls_evaluated object: an unknown control key, a quorum member
lacking fired=true plus a 64-hex attestation_hash, or a policy
member asserting evaluation without matched_count greater than or
equal to 1, is rejected at signing time. Because the field is
server-built and a caller-supplied controls_evaluated is dropped
before signing, a verifier MAY treat the enumerated keys as the
issuing platform's own record of which controls it ran.
Both fields are type-agnostic and MAY appear on any receipt type
defined by this profile, though they are most commonly emitted on
protectmcp:decision receipts where an authorization or enforcement
evaluation produced the recorded decision. Neither field replaces
the policy-evaluation honesty rule that an issuing platform MUST NOT
assert a control ran when it did not (the design note carried under
Section 12): controls_evaluated records which controls ran, not that
any control blocked, and an absent control key is the conformant
representation of a control that did not run.
Gomes Marques Expires 25 March 2027 [Page 41]
Internet-Draft Compliance Receipts Profile September 2026
5.12. Risk-Acceptance Extensions
This section is normative. It defines OPTIONAL extension fields that
appear inside the signed payload object of a receipt of type
protectmcp:lifecycle:risk_acceptance (registered in Section 13.3),
which records a producer's decision to accept a known risk, security
finding, or policy exception. A risk-acceptance receipt is a
lifecycle record, not a policy-evaluation outcome: it is emitted
through the no-policy lifecycle path of Section 5.3, carries decision
observation, and asserts that no policy was evaluated for the
acceptance. The signature binds the producer's recorded assertions,
including its asserted issued_at. Chain links and optional anchor
evidence provide their separately defined integrity and time
properties (Section 5.4, Section 5.5); they do not establish that the
acceptance was authored or chained at that exact time. The receipt
does NOT make any accepted risk safe, any snapshot value true,
reproducible, or verified, or any declared expiry enforced. The
scope-honesty labels in the field definitions below are normative and
mirror the labels published in the issuing platform's /.well-known/
governance.json wire-vocabulary surface.
approver_id: REQUIRED JSON string carrying the producer-asserted
identity that authored the risk acceptance, in the bare-identifier
form of Section 5.2.5 (a bare kid or issuer_id). The field is
bound into the signed bytes only: the issuing platform performs NO
authority check, NO authentication of the named identity, and NO
identity resolution; the only comparison it makes is the string-
equality refusal against initiator_id applied to Compliance
Receipts (the risk_acceptance_self_approval_guard of the
initiator_id entry below). A risk-acceptance receipt that omits
approver_id MUST be rejected at signing time by the false-
attestation guard named in Section 13.2.
initiator_id: OPTIONAL JSON string carrying the producer-asserted
identity that requested the acceptance, in the same bare-
identifier form. The field is bound into the signed bytes only.
The reference cloud implementation refuses at signing time, as the
risk_acceptance_self_approval_guard, a risk-acceptance Compliance
Receipt whose initiator_id string-equals approver_id, because a
receipt asserting an approval flow approved by its own initiator
is incoherent on its face. The guard is a string-incoherence
check (case-sensitive exact match), NOT identity resolution: it
fires only when both fields are present, an absent field never
fires it, and any real segregation-of-duties decision belongs to
the Deployer's enforcement layer, not to this record format.
acceptance_reason: REQUIRED JSON string carrying the free-text
Gomes Marques Expires 25 March 2027 [Page 42]
Internet-Draft Compliance Receipts Profile September 2026
producer rationale for accepting the risk. The signed field binds
the issuer to the recorded rationale and its asserted issued_at;
it is never parsed, scored, or validated by the issuing platform.
A risk-acceptance receipt that omits acceptance_reason MUST be
rejected at signing time by the same false-attestation guard as
approver_id.
accepted_at: OPTIONAL RFC 3339 timestamp with an explicit UTC
offset, encoded as a JSON string, carrying the producer-asserted
wall-clock time at which the acceptance was authored. This value
is self-declared by the producer; the only times the issuing
platform attests are issued_at (Section 5.2.4) and the anchors
evidence (Section 5.5). The field is distinct from issued_at so
that an acceptance back-dated relative to emission is auditable.
supersedes: OPTIONAL JSON string carrying a producer-asserted
pointer to the prior risk-acceptance receipt this one replaces,
encoded either as an opaque receipt locator or as a sha256:<64
lowercase hex chars> digest. The field binds the supersession
claim together with the asserted issued_at; resolution is the
verifier's job, and the issuing platform NEVER invalidates the
prior receipt: the recorded signed bytes remain unchanged and
supersedes in the later receipt points to the earlier receipt.
sarif_digest: OPTIONAL JSON string formatted sha256:<64 lowercase
hex chars> over the producer-declared canonical bytes of the
static-analysis (SARIF) scan artifact the acceptance rested on.
The digest is a producer-supplied commitment. Checking its syntax
does not establish that the SARIF artifact exists or existed at
the asserted time. The issuing platform NEVER parses, fetches,
re-runs, or validates the scan; a verifier recomputes SHA-256 over
the SARIF bytes retained in the Audit Pack and treats a mismatch
as a tamper signal, in the same manner as config_manifest_digest
of Section 5.9.
finding_ref: OPTIONAL JSON string carrying a producer-asserted
opaque pointer to the specific finding or rule identifier inside
the SARIF artifact (for example a ruleId plus a location). The
field is free-text; it binds the asserted reference and issued_at
and is never resolved or validated by the issuing platform.
approval_ref: OPTIONAL JSON string carrying a producer-asserted
opaque correlation pointer to a human-in-the-loop approval
identifier or an external ticket. The field is free-text; it
binds the asserted correlation pointer and issued_at and is never
resolved or validated by the issuing platform.
risk_snapshot: OPTIONAL object carrying a point-in-time snapshot of
Gomes Marques Expires 25 March 2027 [Page 43]
Internet-Draft Compliance Receipts Profile September 2026
THIRD-PARTY risk signals as the producer read them, with members:
snapshot_at (REQUIRED RFC 3339 timestamp with an explicit UTC
offset, the producer-asserted read-time the snapshot is pinned
to), snapshot_source (free-text string naming where the signals
came from, for example a named EPSS feed, the CISA KEV catalog, or
an NVD CVSS record; OPTIONAL when only snapshot_at and cve_ids are
populated, REQUIRED whenever any of epss, cvss, cvss_vector, or
kev_listed is populated), epss (OPTIONAL string), cvss (OPTIONAL
string), cvss_vector (OPTIONAL string), kev_listed (OPTIONAL
boolean), and cve_ids (OPTIONAL JSON array of CVE-identifier
strings). The object is a producer-asserted snapshot, NOT a value
the issuing platform computed, fetched, verified, queried, or
vouched for; it binds the producer-supplied signals and asserted
snapshot_at, and is explicitly NOT reproducible from any input the
issuing platform holds. A verifier MUST NOT read any member as an
issuing-platform-derived or verified score. All numeric risk
signals (epss, cvss) MUST be encoded as JSON strings, not as JSON
numbers, consistent with the IEEE-754 float prohibition of
Section 4; this string encoding is relevant for the snapshot-not-
score semantics. Whenever any of epss, cvss, cvss_vector, or
kev_listed is populated, snapshot_source MUST be present; a
populated numeric or KEV signal without snapshot_source MUST be
rejected at signing time by the false-attestation guard named in
Section 13.2, so that a value can never be read as an issuing-
platform-derived score.
A risk-acceptance receipt MAY additionally carry the type-agnostic
expires_at field of Section 5.9 to declare the wall-clock time after
which the Deployer considers the acceptance stale, and the server-
built authorized_under_mandate field of Section 5.11. Consistent
with Section 5.9, expires_at on a risk-acceptance receipt is
declared, not enforced: the issuing platform records the declared
expiry but NEVER auto-revokes an expired acceptance, and a verifier
MUST NOT reject the originating risk-acceptance receipt itself solely
because expires_at has elapsed. The named identities (approver_id,
initiator_id) are bound fields; beyond the string-incoherence refusal
of the risk_acceptance_self_approval_guard, NO separation-of-duties
check is performed by this profile.
5.13. Oversight Ruling Receipts
This section is normative. It defines the sub-namespace
protectmcp:lifecycle:oversight_ruling (registered in Section 13.3)
and the extension fields that appear inside the signed payload of a
receipt of that type. An oversight ruling receipt records a human
ruling made about one or more Actions after those Actions were
recorded, and references the receipts it judges. The profile names
oversight review in several bindings but, before this revision,
Gomes Marques Expires 25 March 2027 [Page 44]
Internet-Draft Compliance Receipts Profile September 2026
defined no record for the ruling itself, so the reviewed and
unreviewed cases were indistinguishable on the wire.
An oversight ruling receipt is a lifecycle record, not a policy-
evaluation outcome. It is emitted through the no-policy lifecycle
path of Section 5.3, carries decision observation and the
policy_digest of the sentinel artefact, exactly as Section 5.12 does,
so the false-attestation honesty rule is preserved: no policy result
is asserted by the act of ruling. The type-bound presence rule
applies, so a receipt of this type that omits judged_action_refs or
ruling is refused at signing time rather than emitted incomplete.
The ruling receipt is an ordinary member of the chain, emitted at the
time of the ruling. It never rewrites, re-signs or re-anchors the
receipts it judges: the judged receipts stand exactly as they were
signed, and the ruling is a later, separately signed statement about
them.
judged_action_refs REQUIRED on this receipt type. A non-empty JSON
array of action_ref values identifying the receipts the ruling is
about. A verifier MUST resolve every entry against the Audit Pack
of Section 10 or the chain segment presented alongside the ruling.
A reference that does not resolve is a non-conformance OF THE
RULING RECEIPT, and MUST NOT be reported as a defect of any judged
receipt: an unresolvable reference means the ruling names evidence
it did not supply, which says nothing about the receipts that do
resolve.
ruling REQUIRED on this receipt type. One of: confirm, the reviewer
upholds the recorded outcome; override, the reviewer replaces the
recorded outcome with a different one; escalate, the reviewer
refers the matter onward without deciding it; flag, the reviewer
marks the matter for attention while leaving the outcome standing.
ruling_reason OPTIONAL machine-readable reason code, under the same
discipline as the reason code of Section 5.3.
reviewer REQUIRED on this receipt type. An object with principal,
an opaque identifier of the natural person who ruled, which MUST
NOT carry a name, an email address or any other direct identifier
in clear; role, free text naming the reviewer's function; and
OPTIONAL attestation, an object with method (one of sso,
hardware_key, signed_statement, manual_assertion) and, where
method is not manual_assertion, evidence carrying the platform-
verified artefact digest.
Gomes Marques Expires 25 March 2027 [Page 45]
Internet-Draft Compliance Receipts Profile September 2026
When attestation is absent or its method is manual_assertion, the
human-review claim remains unverified. Signature, chain and anchor
results are reported separately; the overall summary follows all
required axes in Section 11.4. If the selected policy requires
authenticated human-review evidence, its absence prevents full
verification. A signed ruling binds the issuer's assertion and
stated time but does not alone establish that a qualified human
conducted a review. A verifier MUST NOT report the review as
verified solely because the receipt signature passes.
Bindings. Under Section 7.2.2 an oversight ruling receipt can
contribute to evidence of the human-oversight assignment Article
26(2) requires. Under Section 8.2.3 it can contribute to evidence of
an opportunity for meaningful human review and reconsideration, and
the statutory definition there is deliberately demanding: it requires
a reviewer with authority to approve, modify or override, who
considers relevant available primary evidence, is trained to conduct
the review, DOES NOT DEFAULT TO THE SYSTEM OUTPUT, and has access to
enough information to understand the output's intended use, material
limitations and categories of inputs, and the principal factors that
generated it. The ruling receipt alone cannot establish reviewer
training, authority or non-deference; those matters require separate
evidence. An oversight ruling receipt therefore evidences that a
ruling was recorded and, where an attestation was independently
validated, the scoped reviewer-authentication result; the remaining
elements of the statutory standard stay the Deployer's own
responsibility, and a verifier MUST NOT report them as satisfied
solely from the ruling receipt; any separate evaluation identifies
its supporting evidence and limitations. Under the NIST AI Risk
Management Framework the receipt is evidence toward the MANAGE
function.
5.14. Code-Authorship Extensions
This section defines extension fields in the signed payload of a
protectmcp:lifecycle:code_authorship receipt (Section 13.3). It
records a producer's assertion about a repository change. The
receipt uses the no-policy lifecycle path in Section 5.3, carries
decision=observation and asserts no policy-evaluation outcome. The
issuer MUST enforce the type-bound required-field and no-policy rules
at signing time and reject use of these fields on an incompatible
type.
The signature binds the recorded assertions; chain links and optional
timestamp evidence provide their separately defined integrity and
time properties (Section 5.4, Section 5.5). They do not prove that
the change exists, was authored by the named model, was executed at
issued_at, or is correct, safe, reviewed or buildable. The receipt
Gomes Marques Expires 25 March 2027 [Page 46]
Internet-Draft Compliance Receipts Profile September 2026
layer does not fetch the repository or validate the code. The
separately selected rederivation feature in Section 9.2 reports the
specific source bytes it actually fetched and recomputed. Required
but unavailable rederivation prevents full verification under
Section 11.4.
repo_ref: REQUIRED JSON string carrying a producer-asserted opaque
pointer to the repository the change was authored against (for
example a clone URL or an internal repository identifier). The
field is free-text; it binds the asserted reference and issued_at
and is never resolved, cloned, or validated by the issuing
platform. A code-authorship receipt that omits repo_ref MUST be
rejected at signing time by the
code_authorship_missing_required_field guard named in
Section 13.2.
commit_sha: REQUIRED JSON string carrying the producer-asserted
commit identifier of the authored change (for example a Git object
name). The field is bound into the signed bytes only: the issuing
platform NEVER fetches the named commit, never verifies that it
exists, and never verifies its contents. It binds the producer-
supplied commit identifier and asserted issued_at. A code-
authorship receipt that omits commit_sha MUST be rejected at
signing time by the same guard as repo_ref.
base_sha: OPTIONAL JSON string carrying the producer-asserted base
commit identifier the change was authored on top of. Like
commit_sha, the field is bound into the signed bytes only and is
NEVER fetched or verified by the issuing platform; it binds the
producer-supplied base identifier and asserted issued_at.
change_digest: OPTIONAL JSON string formatted sha256:<64 lowercase
hex chars> over the producer-declared canonical bytes of the
change (for example a unified diff). The digest is a producer-
supplied commitment. Checking its syntax does not establish that
the change exists or existed at the asserted time. The issuing
platform NEVER fetches, re-diffs, or re-computes the change; a
verifier recomputes SHA-256 over the change bytes retained in the
Audit Pack and treats a mismatch as a tamper signal, in the same
manner as sarif_digest of Section 5.12 and config_manifest_digest
of Section 5.9. A change_digest value outside the sha256:<64
lowercase hex chars> wire form MUST be rejected at signing time by
the change_digest_not_sha256_wire_form guard.
change_ref: OPTIONAL JSON string carrying a producer-asserted opaque
Gomes Marques Expires 25 March 2027 [Page 47]
Internet-Draft Compliance Receipts Profile September 2026
pointer to the change as a unit (for example a pull-request or
merge-request identifier). The field is free-text; it binds the
asserted reference and issued_at and is never resolved or
validated by the issuing platform.
change_approval_ref: OPTIONAL JSON string carrying a producer-
asserted opaque correlation pointer to a human-in-the-loop
approval identifier or an external review ticket for the change.
The field is free-text; it binds the asserted correlation pointer
and issued_at and is never resolved or validated by the issuing
platform, in the same manner as approval_ref of Section 5.12.
change_class: OPTIONAL JSON string drawn from the closed vocabulary
read, write, delete, execute, or deploy, declaring the producer-
asserted class of the change. The value is self-declared; the
issuing platform records it but does NOT verify that the change
matches the declared class. A value outside the closed vocabulary
MUST be rejected at signing time, the field being constrained to
the closed vocabulary.
authored_by: OPTIONAL object carrying a producer-asserted
description of the authoring agent, with members: agent_id
(OPTIONAL string identifying the authoring agent), model_id
(OPTIONAL string naming the model), model_version (OPTIONAL string
naming the model version), tool (OPTIONAL string naming the
authoring tool), and attestation_source (OPTIONAL string naming
where the authorship description came from). The object is
producer-asserted, NOT a value the issuing platform computed,
verified, queried, or vouched for; it binds the producer-supplied
values and asserted issued_at. The issuing platform NEVER
verifies the named model. Whenever any of model_id or
model_version is populated, attestation_source MUST be present; a
populated model field without attestation_source MUST be rejected
at signing time by the false-attestation guard named in
Section 13.2, so that a model claim can never be read as an
issuing-platform-verified attestation.
A code-authorship receipt MAY additionally carry the server-built
authorized_under_mandate field of Section 5.11 to record the self-
declared authorizing mandate the change was signed under; this
profile reuses that field for code-authorship authorization and does
not define a separate authorization field. Consistent with
Section 5.11, authorized_under_mandate asserts self-declared issuer
authority only and is NEVER an issuing-platform attestation of
verified third-party authorization.
Gomes Marques Expires 25 March 2027 [Page 48]
Internet-Draft Compliance Receipts Profile September 2026
Statements in these field definitions and their registry entries that
the issuing platform does not fetch, resolve or verify describe
ordinary receipt issuance. Separately requested authoritative
rederivation follows Section 9.2 and reports its actual scope and
result.
5.15. Threat-Framework Taxonomy Extensions
This section is normative. It defines seven OPTIONAL caller-supplied
taxonomy fields, one OPTIONAL caller-supplied opaque timestamp token,
and one platform-set false-attestation guard boolean, all of which
MAY appear inside the signed payload object. The seven taxonomy
fields record producer-asserted mappings of the Action into
established threat-and-control catalogues; they are self-declared and
are NOT verified by the issuing platform. The guard boolean exists
so that a verifier can tell a self-declared classification apart from
a platform-verified one. All nine fields are covered by the
signature scope defined in Section 5.4, and an implementation MAY
emit any subset.
mitre_techniques: OPTIONAL JSON array of MITRE ATT&CK technique
identifiers (for example T1059, T1078) self-declared by the
producer. The values are referenced by identifier from the MITRE
ATT&CK enterprise matrix. The field is not verifier-checked by
the issuing platform; when the array is populated the issuing
platform MUST set framework_mappings_self_declared to true.
mitre_atlas: OPTIONAL JSON array of MITRE ATLAS identifiers (for
example AML.T0051) covering AI-system-specific adversary
techniques, self-declared by the producer and referenced by
identifier from the MITRE ATLAS catalogue. ATT&CK and ATLAS are
VERSIONED catalogues whose identifiers are re-scoped between
releases, so a receipt carrying either field SHOULD also carry the
catalogue version it drew the identifiers from, either as a
version member alongside the array or as a suffix on each value
under a convention documented in the Audit Pack metadata. Without
it an identifier is only as stable as the reader's assumption
about which release was meant. When populated the issuing
platform MUST set framework_mappings_self_declared to true.
owasp_llm_top10: OPTIONAL JSON array of OWASP Top 10 for LLM
Applications identifiers, self-declared by the producer. Values
MUST be edition-qualified, in the form LLM01:2025, and a bare
LLM01 MUST be rejected. The qualifier is relevant rather than
decorative: the numbering changed between the 2023 and 2025 lists,
so a bare identifier names a different risk depending on which
edition the reader assumes. When populated the issuing platform
MUST set framework_mappings_self_declared to true.
Gomes Marques Expires 25 March 2027 [Page 49]
Internet-Draft Compliance Receipts Profile September 2026
owasp_agentic_top10: OPTIONAL JSON array of identifiers from the
OWASP Top 10 for Agentic Applications 2026, self-declared by the
producer. This profile uses ASI01 through ASI10 for that edition,
without a year suffix in the identifier. The issuing platform
MUST set framework_mappings_self_declared to true when this field
is populated. These identifiers name the agentic catalogue, not
the OWASP Top 10 for LLM Applications. Any separately selected
catalogue edition MUST be identified explicitly and MUST NOT
silently change the meaning of a retained identifier. The
official OWASP GenAI catalogue crosswalk (https://genai-security-
project.github.io/crosswalk/agentic-ai-top10/) lists the ten
identifiers for the 2026 edition; their use here makes no claim
that a receipt demonstrates a mitigation or that an external
framework mapping has been independently validated.
nist_ai_rmf: OPTIONAL JSON array of NIST AI Risk Management
Framework function identifiers and subcategories (for example
GOVERN-1.1, MEASURE-2.7), self-declared by the producer and
referenced from [NIST-AI-RMF]. When populated the issuing
platform MUST set framework_mappings_self_declared to true.
iso_42001: OPTIONAL JSON array of ISO/IEC 42001:2023 control
identifiers (for example A.6.2.6), self-declared by the producer
and referenced from ISO/IEC 42001:2023. When populated the
issuing platform MUST set framework_mappings_self_declared to
true.
eu_ai_act_articles: OPTIONAL JSON array of EU AI Act article
identifiers (for example Article-12, Article-15, Article-50),
self-declared by the producer and referenced from [EU-AI-ACT].
When populated the issuing platform MUST set
framework_mappings_self_declared to true.
rfc3161_timestamp: OPTIONAL JSON string carrying a base64-encoded
[RFC3161] TimeStampResp (DER) supplied by the producer at signing
time and preserved verbatim on the receipt for offline TSA chain
verification independent of any platform-issued anchors. The
payload entry is an opaque caller-supplied token, NOT the per-
receipt anchor produced by the platform under Section 5.5; the
base64 encoding is per [RFC4648]. It never counts toward the
anchoring requirement of Section 5.5 or toward a witness_policy
quorum, and a verifier MUST NOT read it as the receipt's
timestamping evidence. This field does not flip
framework_mappings_self_declared.
framework_mappings_self_declared: OPTIONAL JSON boolean false-
Gomes Marques Expires 25 March 2027 [Page 50]
Internet-Draft Compliance Receipts Profile September 2026
attestation guard set by the issuing platform. The platform MUST
set it to true whenever any of mitre_techniques, mitre_atlas,
owasp_llm_top10, owasp_agentic_top10, nist_ai_rmf, iso_42001, or
eu_ai_act_articles is populated. A producer-supplied value of
false alongside a populated taxonomy field MUST be overridden by
the issuing platform, in the same spirit as the false-attestation
guards of Section 5.11 and the witness_policy quorum guard of
Section 5.5. The guard does not assert that the self-declared
mappings are correct; it asserts only that they are self-declared
rather than platform-verified, and a verifier MUST NOT treat a
populated taxonomy field as platform-verified.
The nine fields are type-agnostic and MAY appear on any receipt type
defined by this profile.
5.16. Environment Attestation Extensions (Normative-Optional)
This optional extension carries signed environment-state claims
asserted before an Action, drawing on the environment-record concept
in [DRAFT-MSEBENZI-EVIDENCE-ACTION]. Absence is permitted by the
base profile. A selected relying-party policy may require the
extension; its required checks then participate in the summary under
Section 11.4.
environment_attestation: OPTIONAL object carrying boolean
environment-state claims attested before the Action (for example
sandbox liveness, egress state, secret-store lock state), signed
by an environment key distinct from the receipt's signing key
(separation of duty: the runtime asserts facts about itself under
its own key, under a documented attester trust policy). Members:
claims (REQUIRED object whose values are booleans), attester_kid
(REQUIRED string identifying the environment key), attested_at
(REQUIRED RFC 3339 timestamp with an explicit UTC offset), and sig
(REQUIRED standard padded base64 signature over the JCS
canonicalization per [RFC8785] of the attestation object with the
sig member removed, under the algorithm declared for the
environment key). The object is covered by the receipt's own
signature scope of Section 5.4 in addition to carrying its
detached environment-key signature. A verifier that checks the
field verifies sig against the resolved environment key and bounds
the staleness of attested_at relative to the receipt's issued_at
under the verifier's documented bound; a stale, unverifiable or
malformed attestation is reported on its own axis and prevents
full verification when that check is required by the selected
policy under Section 11.5.
Gomes Marques Expires 25 March 2027 [Page 51]
Internet-Draft Compliance Receipts Profile September 2026
An environment attestation supplies evidence to an authorization
policy; it does not replace that policy or authorize an Action by
itself. A valid receipt can faithfully record a denial. Receipt
verification and permission to perform the Action remain distinct
decisions. Absence of this extension has no adverse effect on the
base-profile summary unless the selected external policy requires it.
A verified environment signature establishes an assertion by the
authorized attester, subject to key custody, measurement provenance,
freshness and appraisal policy. Hardware custody of a signing key
alone does not establish that its claims are authentic measurements
or that a remote-attestation procedure succeeded. This extension
does not define such a procedure. A report states which claims and
trust assumptions it actually appraised and does not present producer
assertions as independently observed facts.
5.17. Receipt Lineage Extensions
This section is normative. It defines one OPTIONAL extension field,
derived_from, that appears inside the signed payload object and names
the parent receipts a derived Action was computed from, together with
the lineage reference object that the array carries. The field is
registered in Section 13.2. Lineage is a directed acyclic graph over
receipts: node and edge identity reuse the SHA-256 and JCS
canonicalization already defined in Section 4, so this section
introduces no new cryptography.
derived_from: OPTIONAL JSON array of lineage reference objects, each
naming one parent receipt by full identity. A producer MUST byte-
sort the array by each element's merkle_root member before
signing, so that independent producers of the same child compute
identical signed bytes. The member sits inside the signature
scope of Section 5.4: re-pointing a parent changes the child's
signed bytes and so breaks the child's signature. A producer with
no parent to name omits the member entirely rather than emitting
an empty array.
A lineage reference object carries exactly the four members defined
below, and a producer MUST NOT emit any other member inside one. The
closed member set is what makes the sort deterministic: an
unrecognised member could carry ordering significance that a sorting
producer and a verifying consumer would resolve differently.
merkle_root: REQUIRED JSON string carrying sha256: followed by 64
lowercase hexadecimal characters, holding SHA-256 over the JCS
canonicalization of the parent's signed envelope, that is the
object carrying the parent's payload and signature members. The
parent's anchors member is EXCLUDED from this digest, because
Gomes Marques Expires 25 March 2027 [Page 52]
Internet-Draft Compliance Receipts Profile September 2026
anchors are attached after signing and including them would change
a parent's identity every time an anchor accrued. This member is
the array's sort key.
data_hash: REQUIRED JSON string in the same sha256: form, holding
SHA-256 over the JCS canonicalization of the parent's payload
member alone. It binds the parent's signed content independently
of the parent's signature bytes, so a consumer holding only the
parent's payload can still check the edge.
schema: REQUIRED JSON string carrying the schema identifier of the
parent receipt. The JSON key is the literal schema, case-
sensitive.
relationship: REQUIRED JSON string carrying the provenance verb that
relates the child to the named parent, with a value drawn from
exactly this set: derivedFrom, parentOf, componentOf, inputTo.
The vocabulary is reused verbatim from established content-
provenance and provenance interchange work, so the graph carries
no verb coined by this document.
A lineage reference binds the producer's parent claim and asserted
child time. A resolved parent whose recomputed commitments differ
from the referenced values fails that binding check. The reference
alone establishes neither parent availability, parent signature
validity nor actual derivation. Each is a separate applicable check
under Section 11.2. An unresolved parent does not by itself
invalidate the child's signature, but prevents full verification when
parent resolution or derivation evidence is required by the selected
policy (Section 11.4).
5.18. Heartbeat and Denial Evidence
A heartbeat is a lifecycle observation with
type=protectmcp:lifecycle, action_type=asqav:heartbeat,
decision=observation and the no-policy JSON null value of
Section 5.3. Its signed heartbeat_interval_seconds is a positive
safe integer expressing the declared interval. On a sequenced chain
it consumes a sequence number like any other receipt. The first
counter value remains one.
Gomes Marques Expires 25 March 2027 [Page 53]
Internet-Draft Compliance Receipts Profile September 2026
Silence beyond the declared interval is a coverage/liveness
uncertainty and must be compared with the observation window and
retained checkpoints. It is not proof of a missing action. A
verifier without a trusted later checkpoint cannot infer that a
retained prefix has no omitted tail. A locally self-signed denial
that never enters the platform chain may lack seq; it MUST be labeled
outside platform-sequence coverage and must not satisfy a platform-
chain completeness claim.
5.19. Capture Coverage and Enforcement Authority
Capture topology, capture layer and enforcement authority are
separate axes. The coverage vocabulary is harness_enforced,
framework_callback, in_path_proxy, model_invoked and passive. The
name describes placement, not a universal guarantee. An
implementation claiming enforcement MUST document the exact harness
version, hook family, settings authority, covered actions, deadline
and failure policy, and retain evidence for the installed path. A
configuration attestation does not itself prove ongoing enforcement
or coverage outside that boundary.
The Claude Code hook reference distinguishes a timed-out
command/HTTP/MCP-tool hook on PreToolUse, which renders no blocking
decision, from an Agent SDK callback timeout, which blocks the tool
call. The reference defines five handler types, command, http,
mcp_tool, prompt and an experimental agent type, and it distinguishes
that agent handler from the separately documented Agent SDK callback
hook. Its timeout rule names the first three; it does not state the
same outcome for a prompt or agent handler. An enforcement claim
over a handler whose timeout outcome the reference does not state
MUST NOT assume that handler blocks, and MUST identify the handler
type it relies on rather than the transport alone. A hook that fails
to start falls in the same non-blocking class as a timed-out one: the
reference records a non-blocking status for a handler that is missing
or not executable, and for most events the action proceeds. An
enforcement claim MUST therefore state its startup-failure policy
alongside its deadline, because an unstarted hook and a satisfied one
leave the same trace in the action's outcome. The reference also
documents exit-code and JSON output behavior, and carries version
qualifiers on individual fields rather than on a single versioned
contract. Implementers MUST use the supported version's actual event
semantics and MUST NOT treat every callback as non-enforcing or every
in-process hook as unbypassable. Managed settings constrain
configuration authority but do not independently establish complete
coverage of other execution paths. See [CLAUDE-HOOKS].
Gomes Marques Expires 25 March 2027 [Page 54]
Internet-Draft Compliance Receipts Profile September 2026
The reference product does not build a model-invoked tool as its
enforcement boundary. Observation-only integrations remain useful if
labeled accordingly. A remote MCP authorization profile is distinct
from a local stdio integration; audience-bound OAuth semantics are
specified by [MCP-AUTH] for the applicable HTTP transport.
6. Legal Applicability and Evidence Policy
The technical profile can be used in different jurisdictions. The
mappings below explain possible uses of its evidence; they do not
establish worldwide compliance, legal admissibility, a presumption of
truth, or approval by a regulator. A receipt cannot make a
prohibited activity lawful. An issuer signature authenticates a
recorded statement under a trusted key; it does not establish the
truth of every statement.
Before applying a legal mapping, the responsible organization
identifies the jurisdiction, regulated role, system and activity,
affected people, record class, applicable provision, effective date,
exemptions and competent authority. It records the source version
and the person responsible for that determination. A product label,
an issuer-selected regime code or the location of a timestamp server
is insufficient to establish applicability.
Uppercase requirement words specify this document's technical
conformance rules. They do not rank laws or convert an optional
profile policy into a statutory duty. Requirements within a legal
mapping apply only when that mapping is selected and its
applicability has been established. A stricter contractual or
organizational policy is identified separately, with its authority
and scope. An unresolved applicability question is reported as
unknown; it MUST NOT be reported as legal compliance.
Retention policy specifies the record class, legal basis, triggering
event, calendar period, access restrictions, deletion conditions and
any lawful hold. A period measured from a decision, record creation,
last use, report submission or end of a relationship is not
interchangeable with the receipt's issued_at. Calendar months and
years are not replaced by a universal number of days. The applicable
law determines the calculation and exceptions. Data minimization,
access, correction, erasure and transfer restrictions apply to
receipts and supporting evidence where those records contain personal
or otherwise protected information.
A jurisdiction-specific extension SHOULD publish this applicability
information and identify each evidence claim, required input,
verification rule, unknown state and limitation. Its conformance
examples SHOULD include exemptions, missing evidence, a changed law
Gomes Marques Expires 25 March 2027 [Page 55]
Internet-Draft Compliance Receipts Profile September 2026
and conflicting retention or deletion duties. Such extensions do not
require a new core receipt format or additional personal data on a
public chain. Machine-readable legal mappings remain versioned
policy artifacts, not legal conclusions signed into existence.
7. European Union Bindings
Article 113, third paragraph, point (c), of the EU AI Act
[EU-AI-ACT], as amended by Article 1(40)(b) of [EU-2026-1744], sets
the application dates for Chapter III, Sections 1 to 3, except
Article 6(5): 2 December 2027 for AI systems classified as high-risk
under Article 6(2) and Annex III, and 2 August 2028 for those
classified as high-risk under Article 6(1) and Annex I. The Article
12 and Article 26 mappings below concern duties within those
sections, subject to the applicable scope and Article 111
transitional provisions. Before the relevant duties apply to a
deployment, use of these two mappings is voluntary early adoption.
This does not make duties that already apply voluntary.
Article 50 generally applies from 2 August 2026 under Article 113,
second paragraph. Article 111(4) gives providers of the specified
synthetic-content systems placed on the market before that date until
2 December 2026 to comply with Article 50(2); that transition does
not defer all of Article 50. DORA has applied since 17 January 2025
under Article 64 of [DORA]. A selected mapping MUST record its
provision, role, scope, application date and relevant exceptions
under Section 6.
7.1. EU AI Act Article 12 Binding
Each subsection cites the operative phrase of Article 12 and binds it
to the receipt field that provides evidence for it.
7.1.1. Article 12(1), automatic recording of events
Article 12(1) requires High-Risk AI Systems to technically allow for
the automatic recording of events (logs) over the lifetime of the
system. The signed-receipt format provides one mechanism supporting
that logging capability; alternative mechanisms remain valid. Where
this profile is chosen, a Compliance Receipt SHOULD be produced for
every Action against an external resource, and a configuration change
that disables receipt generation SHOULD be recorded as a
protectmcp:lifecycle Compliance Receipt. Implementations MAY emit at
finer or coarser granularity so long as the log set, taken together,
covers Article 12(2)(a) through (c).
Gomes Marques Expires 25 March 2027 [Page 56]
Internet-Draft Compliance Receipts Profile September 2026
7.1.2. Article 12(2)(a), identifying situations that may result in the
high-risk AI system presenting a risk within the meaning of
Article 79(1) or in a substantial modification
The combination of type, decision, reason, and policy_digest MUST be
sufficient for an auditor to identify, by query alone, receipts that
correspond to risk situations enumerated in the Deployer's risk
management documentation. Where the Deployer classifies an Action as
risk-bearing, the receipt MUST carry a risk_class extension field.
7.1.3. Article 12(2)(b), facilitating the post-market monitoring
referred to in Article 72
The hash-chain linkage required by Section 5.4 provides evidence for
post-market monitoring traceability. The chain head MUST be made
available to the Provider and to the competent authority on request.
7.1.4. Article 12(2)(c), monitoring the operation of high-risk AI
systems referred to in Article 26(5)
When the policy changes, the producer MUST bind subsequent receipts
to the policy version used for those records. It retains the
relevant policy artifact for the lawful evidence period of the
receipts that reference it. A later receipt does not automatically
extend retention of every earlier payload or policy artifact
indefinitely.
A change in policy_digest between two otherwise-comparable Actions
may also be examined as a candidate substantial-modification event
under Article 43. That reading belongs to Article 12(2)(a), whose
binding is in Section 7.1.2, and is noted here only so the cross-
reference is not lost; it is not a 12(2)(c) obligation.
7.1.5. Retention
Article 12 does not itself set a retention period. Article 26(6)
addresses logs under a deployer's control: retention is appropriate
to the intended purpose, with a six-month minimum unless applicable
Union or national law provides otherwise. Article 19(1) contains a
provider-side rule. The responsible organization identifies the role
and applicable exception rather than assigning every receipt the same
expiry date.
Gomes Marques Expires 25 March 2027 [Page 57]
Internet-Draft Compliance Receipts Profile September 2026
For a selected deployer mapping, retention policy MUST identify the
log scope, purpose, calendar calculation and applicable legal
exceptions. It MUST NOT replace six calendar months with a fixed
183-day or 184-day rule. Supporting proofs and public verification
material are retained for the lawful period in which the related
evidence must remain verifiable. Sector-specific rules are assessed
under Section 7.4.4 and Section 6.
7.2. EU AI Act Article 26 Binding
7.2.1. Article 26(1), in accordance with the instructions for use
policy_digest MUST resolve through Section 10 to a retained artifact
(machine check). The Deployer SHOULD demonstrate consistency with
the Provider's instructions for use (process check). Inability to
perform the machine check leaves the Article 26(1) obligation
unevidenced by this profile; this document creates no evidentiary
presumption under Union or national law.
7.2.2. Article 26(2), assign human oversight
Article 26(2) concerns assignment of human oversight to people with
the required competence, training, authority and support. A receipt
can record an assignment or an observed review. Where an applicable
instruction or control requires review before an action, a later
review record does not satisfy that prerequisite. Recording that
oversight was absent documents a failure; it is not an alternative
means of meeting the oversight duty. The organization remains
responsible for the required human arrangements.
7.2.3. Article 26(5), monitor the operation
For a selected monitoring mapping, the producer MUST support an Audit
Pack for the requested interval within its lawfully retained
evidence. The pack states its coverage, known gaps, unavailable
records and the basis of its time claims. This capability supports
monitoring; it does not replace the deployer's operational, incident-
response or notification duties under Article 26(5).
7.2.4. Article 26(6), of at least six months
Retention under this mapping follows Section 7.1.5. Any sector-
specific rule is assessed for the relevant entity and record class;
the profile does not automatically apply a financial-sector duration
to every receipt.
Gomes Marques Expires 25 March 2027 [Page 58]
Internet-Draft Compliance Receipts Profile September 2026
7.3. EU AI Act Article 50 Binding
This binding differs from the Article 12 and 26 bindings above in the
one respect that matters on the day this document publishes: those
Articles sit inside the high-risk regime that Regulation (EU)
2026/1744 deferred, while Article 50 has applied since 2 August 2026.
A reader adopting this profile for AI Act reasons alone is otherwise
pointed at obligations nobody has to meet yet, which is why this
section exists and why it says so plainly.
The duties include informing people, marking output and disclosing
certain synthetic content. Receipts can bind evidence about those
activities; the statutory duties are not reducible to receipt shape
or a timestamp. A producer assertion must be distinguished from
observed delivery and independently checked output.
A receipt that evidences one of these duties SHOULD declare
Article-50 in eu_ai_act_articles (Section 5.15), so that an issuing
platform can attest the declaration by the receipt's shape: a
protectmcp:lifecycle disclosure receipt for Article 50(1) and 50(3),
a receipt carrying result_digest over the emitted or published bytes
for Article 50(2) and 50(4). The attestation is to the shape only;
it does not assert that a disclosure was understood or that an
exception under Article 50(4) applies.
7.3.1. Article 50(1), informing a natural person that they are
interacting with an AI system
A receipt can record the producer's claimed disclosure time and a
reference to the relevant interaction. Evidence that information was
presented to the person by the required interaction time is assessed
separately. The issuer's issued_at alone does not establish
delivery. A relationship to another action is expressed through a
defined reference or Audit Pack relationship, not by silently
changing the meaning of action_ref.
7.3.2. Article 50(2), marking synthetic output in a machine-readable
format
The marking duty concerns the output. A result_digest can bind
presented output bytes to a recorded claim; it does not prove which
system produced them, when the production occurred, or that a
compliant marking was applied. Assessment requires the retained
output and evidence relevant to the marking requirement. Article
50(2)'s limited transition for systems placed on the market before 2
August 2026 must be distinguished from the general application date,
as explained by the Commission guidance.
Gomes Marques Expires 25 March 2027 [Page 59]
Internet-Draft Compliance Receipts Profile September 2026
7.3.3. Article 50(3), informing persons exposed to emotion recognition
or biometric categorisation
For emotion recognition or biometric categorisation, evidence SHOULD
connect the system, disclosure and relevant interaction without
repurposing action_ref, which identifies the Action under
Section 5.2.7. The Audit Pack MAY retain an explicit relationship
and the disclosure material. A declared issued_at alone does not
establish that a person received the information before processing.
7.3.4. Article 50(4), disclosing artificially generated or manipulated
content
For content constituting a deep fake, and for text published to
inform the public on matters of public interest, the Deployer SHOULD
emit a Compliance Receipt recording the disclosure, carrying
result_digest over the published bytes so the disclosure is bound to
the specific content rather than to the publication as a whole.
Where an exception in Article 50(4) is relied on, the receipt SHOULD
carry a reason code naming it; the issuing platform performs no check
that the exception applies, and a verifier MUST report the code as
producer-asserted.
7.3.5. Timing, Accessibility and Retention
Article 50 specifies no general receipt-retention duration. The
responsible organization must determine applicable retention and
deletion rules rather than infer a universal limitation-period floor
from this binding. Paragraph 5 also requires clear, distinguishable
and accessible information by the first interaction or exposure.
Exceptions and the duties of each provider or deployer must be
evaluated under the applicable text; a signed reason code is not
proof that an exception applies.
7.4. DORA Article 17 Binding
7.4.1. Article 17(1), ICT-related incident management process
A Compliance Receipt produced inside a Financial Entity's ICT
environment may serve as the canonical record of an Action that
triggered an ICT-related incident. action_ref MUST be carried into
the Financial Entity's incident workflow as the primary correlation
key.
Gomes Marques Expires 25 March 2027 [Page 60]
Internet-Draft Compliance Receipts Profile September 2026
7.4.2. Article 17(2), record all ICT-related incidents and significant
cyber threats
The hash chain required by Section 5.4 supports the recording
obligation of Article 17(2) by making after-the-fact alteration of
recorded incidents detectable. The Financial Entity MUST be able to
produce, on request, the chain segment covering the period of an
incident, together with the anchor evidence with the time bounds
supported by the verified construction.
7.4.3. Article 17(3)(b), establish procedures to identify, track, log,
categorise and classify ICT-related incidents
For Actions identified as part of an ICT-related incident, the
producing system MUST emit incident_class. The classification
criteria are those set out in Article 18(1) of [DORA], with further
specification in [REG-2024-1772]. The canonical reporting
enumeration to which incident_class flattens is bound by Annex II
field 3.23 of [REG-2025-302] (see Section 5.7). Implementations MUST
publish a flattened mapping in the Audit Pack manifest as required by
Section 5.7.
7.4.4. Retention
DORA Article 17 requires an incident-management process and records,
but does not set a uniform numeric retention period for every
receipt. The financial entity identifies the applicable record class
and Union, national and supervisory requirements. This profile does
not invent a five-year default by analogy to other financial rules.
For a selected mapping, the evidence policy MUST state its retention
basis and triggering event under Section 6. Retained verification
material supports the lawful evidence window. A timestamp protocol
or a signed chain alone does not establish compliance with DORA's
incident-management, classification or reporting requirements.
8. United States Bindings
8.1. NIST AI RMF Binding
[NIST-AI-RMF] is a voluntary framework. Adoption of this profile, on
its own, does not establish conformity with the AI RMF; it provides a
tamper-evident receipt substrate that an AI RMF program can use as
evidence under the MEASURE function and as a structured input to the
GOVERN, MAP, and MANAGE functions. [NIST-GENAI-PROFILE] applies the
AI RMF functions to generative AI; the profile bindings below apply
to generative and non-generative AI agent deployments alike unless
explicitly noted.
Gomes Marques Expires 25 March 2027 [Page 61]
Internet-Draft Compliance Receipts Profile September 2026
8.1.1. GOVERN function
The GOVERN function requires that organizations document AI policies
and procedures. The combination of policy_digest and the Audit Pack
manifest provides a machine-readable binding between every Action and
the policy artefact in force at the time of the Action. A change to
the policy artefact MUST produce a new policy_digest value (per
Section 5.3.2); the Audit Pack therefore records every policy change
in a tamper-evident manner.
8.1.2. MAP function
The MAP function requires that the context, capabilities, and risks
of an AI system be characterised. The combination of type,
tool_name, action_ref, and iteration_id SHOULD be sufficient for an
auditor to reconstruct the operational context of any Action without
dereferencing the underlying payload.
8.1.3. MEASURE function
Receipt continuity can support risk tracking under the MEASURE
function of [NIST-AI-RMF]. Assessing and tracking risks requires
additional evidence and organizational processes.
8.1.4. MANAGE function
The MANAGE function requires that AI risks be prioritised and acted
upon based on projected impact. The risk_class extension field
carries the Deployer's risk classification of the Action; together
with decision, reason, and policy_digest, it supports prioritisation
and incident response without requiring the verifier to re-derive
risk from the underlying payload.
8.2. Colorado Automated Decision-Making Technology Act (SB 26-189)
Binding
SB 26-189, [COLORADO-ADMT], repeals and reenacts Part 17 of Article 1
of Title 6. The reenacted text includes developer documentation
duties in Section 6-1-1702 and deployer record-keeping duties in
Section 6-1-1703. The main operative date is 1 January 2027, with
the upon-passage exceptions in Section 5(2) of the act; Section 5(3)
addresses consequential decisions made on or after that date. This
mapping concerns the reenacted ADMT duties and does not determine the
applicability of the earlier law to earlier activity.
SCOPE OF THIS BINDING. It applies only where the Deployer determines
that the Agent's Action uses a covered ADMT to materially influence a
consequential decision, as those terms are defined in
Gomes Marques Expires 25 March 2027 [Page 62]
Internet-Draft Compliance Receipts Profile September 2026
Section 6-1-1701. A receipt recording any other Action carries no
obligation under this binding, and a verifier MUST NOT report a
Colorado obligation as unmet for a receipt outside that scope. The
conditional HIPAA exclusion in Section 6-1-1708(3)(a) applies to the
specified sections, subject to its business-associate service
limitation, Colorado scope and employment exception. The location
and disclosure provisions in subsections (3)(b) through (e) must also
be assessed; the exclusion does not remove every duty in Part 17.
8.2.1. Section 6-1-1704(1), pre-use notice
The statute requires that "PRIOR TO A DEPLOYER USING A COVERED ADMT
TO MATERIALLY INFLUENCE A CONSEQUENTIAL DECISION, THE DEPLOYER SHALL
PROVIDE A CLEAR AND CONSPICUOUS NOTICE TO A CONSUMER" that a covered
ADMT was or will be used, together with instructions for obtaining
the further information the section describes. The Deployer SHOULD
record the notice artifact in force as a protectmcp:lifecycle
Compliance Receipt carrying the digest of that artefact, emitted
before the first covered consequential decision. The digest MUST
resolve through Section 10. The receipt evidences that a notice
artifact of a given content existed and was chained at a given time;
it does not evidence that the notice reached any particular consumer,
and a verifier MUST NOT report delivery as shown.
8.2.2. Section 6-1-1704(3), post-adverse-outcome disclosure
Where a covered ADMT materially influences a consequential decision
"THAT RESULTS IN AN ADVERSE OUTCOME FOR A CONSUMER", the statute
requires the Deployer to provide, "WITHIN THIRTY DAYS AFTER MAKING
THE DECISION", a plain language description of the decision and the
role the covered ADMT played in it, instructions and a simple-to-
follow process for requesting further information, and an explanation
of the consumer rights in Section 6-1-1705. The Deployer SHOULD
record the disclosure as a protectmcp:lifecycle Compliance Receipt
that references the decision receipt by action_ref and carries the
digest of the disclosure artefact.
The verifier MAY report the interval between the disclosure and
decision receipt issuance times. It MUST report the legal disclosure
deadline as unevaluated unless reliable evidence establishes the
decision date and actual provision of disclosure. A timely receipt
alone does not establish that the disclosure was provided or that its
content satisfies the statute.
Gomes Marques Expires 25 March 2027 [Page 63]
Internet-Draft Compliance Receipts Profile September 2026
8.2.3. Section 6-1-1705(1)(a)(II), meaningful human review
Following an adverse outcome, the statute entitles the consumer to
request, and requires the Deployer to provide, "AN OPPORTUNITY FOR
MEANINGFUL HUMAN REVIEW AND RECONSIDERATION OF THE CONSEQUENTIAL
DECISION, TO THE EXTENT COMMERCIALLY REASONABLE." Where such a
review occurs, the Deployer SHOULD record it as an oversight ruling
receipt per Section 5.13, naming the judged decision receipt in
judged_action_refs.
Section 6-1-1701(15) defines meaningful human review as review by an
individual designated by the Deployer who has authority to approve,
modify or override the consequential decision, and who considers
relevant available primary evidence, is trained to conduct the
review, does not default to the system output, and has access to
sufficient information to understand the output's intended use,
material limitations and categories of inputs, and the principal
factors used to generate the output. A ruling receipt alone does not
establish reviewer training or independent consideration. Other
evidence may support those facts; a verifier MUST NOT infer them
solely from the presence of a ruling receipt. The oversight ruling
receipt therefore evidences that a ruling was recorded, by whom in
opaque form, and the scoped reviewer-authentication result where an
attestation was independently validated. The remaining elements
remain the Deployer's own responsibility and a verifier MUST NOT
report them as satisfied solely from the ruling receipt; any separate
evaluation identifies its supporting evidence and limitations.
8.2.4. Section 6-1-1703, deployer record keeping
The cited Colorado enactment distinguishes deployer records measured
from a consequential decision from developer records measured from
record creation. Its three-year provisions apply to their respective
record classes and roles, with longer periods where applicable law
requires them. The selected mapping MUST identify the role,
statutory trigger, applicability date, exemptions and relevant
implementing rules. It MUST NOT substitute a universal 1096-day
period from the receipt's issuance time.
8.2.5. Section 6-1-1706, enforcement
Section 6-1-1706 provides for Attorney General enforcement through
the Colorado Consumer Protection Act. Subsection (3) conditions
notice on the Attorney General deeming cure possible and provides a
sixty-day cure period after notice, with an exception for knowing or
repeated violations. Subsection (3) repeals on 1 January 2030. Part
17 creates no new private right of action and preserves existing
rights and remedies. This profile imposes no technical binding on
Gomes Marques Expires 25 March 2027 [Page 64]
Internet-Draft Compliance Receipts Profile September 2026
enforcement.
8.3. Texas Responsible AI Governance Act (HB 149) Binding
Section 1 of enrolled HB 149 names the Act the Texas Responsible
Artificial Intelligence Governance Act. The Act takes effect on 1
January 2026. Section 4 adds Texas Business and Commerce Code
Subtitle D, including the AI requirements and enforcement provisions
discussed here. The selected mapping follows the enacted text of
[TEXAS-TRAIGA] and its applicability conditions.
Section 552.104 provides a notice and opportunity-to-cure procedure.
An Audit Pack can support evidence about a claimed response, but
neither a timestamp nor a policy digest establishes that the
violation was cured. Section 552.105 contains conditional defenses.
The internal-review route in subsection (e)(2)(D) is qualified by
substantial compliance with the most recent NIST Generative AI
Profile or another recognized AI risk-management framework. It is
not blanket immunity for using this receipt format.
8.3.1. Defence-to-liability evidentiary support
The internal-review discovery route in Section 552.105(e)(2)(D) is
conditional on the defendant substantially complying with the named
NIST Generative AI Profile or another qualifying framework. The
discovery route and the defendant's framework compliance are separate
factual questions. An Audit Pack MAY support evidence about them; it
does not establish entitlement to a defense or a general safe harbor.
8.3.2. Prohibited-use detection
A receipt can record a producer's prohibited-use classification and a
deny decision. That classification is an assertion, not a legal
determination. The record is retained under the applicable evidence
policy and any lawful preservation duty. This profile sets no
independent six-year retention floor for Texas deny records.
8.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart C)
Under 45 CFR 164.302, covered entities and business associates must
meet the applicable Security Rule requirements for a covered entity's
electronic protected health information. See [HIPAA-SECURITY]. This
mapping concerns relevant activity in information systems that
contain or use electronic protected health information, including
applicable administrative and security activity. An individual
action or receipt need not itself contain or directly reference that
information.
Gomes Marques Expires 25 March 2027 [Page 65]
Internet-Draft Compliance Receipts Profile September 2026
For a deployment in which Asqav performs business-associate
functions, this mapping is applied from the business associate's
perspective. A deployment selecting this mapping MUST identify
whether the responsible organization is a covered entity, a business
associate, or both for the relevant activity. That status depends on
its functions and legal relationship; signing receipts alone does not
determine HIPAA status. Any Colorado exemption is assessed
separately under the conditions of Section 6-1-1708(3).
8.4.1. 45 CFR 164.312(b), audit controls
45 CFR 164.312(b) requires implementation of "hardware, software,
and/or procedural mechanisms that record and examine activity in
information systems that contain or use electronic protected health
information". The combination of type, action_ref, tool_name, and
the hash-chain linkage required by Section 5.4 provides evidence
toward the recording requirement; the verification rules of
Section 11.2 provide evidence toward the examination requirement.
The responsible covered entity or business associate remains
responsible for satisfying the audit-control standard across the
information systems within its applicable HIPAA scope. 164.312(b) is
a standard that carries no implementation specifications, required or
addressable; standards are themselves mandatory under 45 CFR
164.306(c).
8.4.2. Security Rule Documentation and Retention
The six-year requirement in 45 CFR 164.316(b)(2)(i) concerns the
documentation required by that rule, measured from creation or the
date it was last in effect, whichever is later. It is not a general
six-year retention requirement for every individual audit-log record.
See the required-documentation categories in 45 CFR 164.316(b)(1) and
the retention rule in 45 CFR 164.316(b)(2)(i), [HIPAA-SECURITY].
The selected mapping MUST classify each record and apply its actual
retention rule. A receipt that references electronic protected
health information does not acquire a six-year statutory period
merely because of that reference. Other federal, state, contractual
or organizational requirements may apply and are recorded separately.
This profile sets no additional six-year analogy floor.
8.5. NYDFS Cybersecurity Regulation Binding (23 NYCRR Part 500)
[NYDFS-500] applies to Covered Entities (NYDFS) operating under New
York Banking, Insurance, or Financial Services Law. The bindings
below apply only to receipts produced by such Covered Entities.
Gomes Marques Expires 25 March 2027 [Page 66]
Internet-Draft Compliance Receipts Profile September 2026
8.5.1. 23 NYCRR 500.6, audit trail
Section 500.6 addresses applicable systems for reconstructing
material financial transactions and audit trails for detecting and
responding to the specified cybersecurity events. Hash chains can
support integrity of retained evidence. They do not by themselves
satisfy the reconstruction, detection or response requirements.
Applicability and exemptions are assessed under the current
[NYDFS-500] text.
8.5.2. 23 NYCRR 500.17, notices to superintendent
23 NYCRR 500.17(a)(1) requires that "Each covered entity shall notify
the superintendent electronically in the form set forth on the
department's website as promptly as possible but in no event later
than 72 hours after determining that a cybersecurity incident has
occurred at the covered entity, its affiliates, or a third-party
service provider." The reporting trigger is a Cybersecurity Incident
under 23 NYCRR 500.1(g), not any Cybersecurity Event under 500.1(f).
For Actions identified as part of such an Incident, the producing
system MUST emit incident_class with a value indicating Cybersecurity
Incident under 23 NYCRR 500.1(g), and the Covered Entity MUST be able
to produce, on request, the chain segment covering the period of the
Incident together with the anchor evidence with the time bounds
supported by the verified construction.
8.5.3. 23 NYCRR 500.6 retention
Subject to the applicable scope and exemptions, 23 NYCRR 500.6(b)
distinguishes five years for paragraph (a)(1) financial-transaction
records from three years for paragraph (a)(2) cybersecurity audit
trails. The selected mapping MUST identify the record class and
applicable calculation. It MUST NOT treat every AI-action receipt as
both classes or convert the rule into a universal number of days.
Section 500.19 exemptions must be assessed for the entity and
provision.
8.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4)
Rule 17a-4 applies to the broker-dealer records within its scope.
Rule 18a-6 governs stand-alone Security-Based Swap Dealers and Major
Security-Based Swap Participants; its paragraph (e)(2) technical
system requirements apply to entities without a prudential regulator.
The 2022 release amended both rules. A selected evidence mapping
identifies the entity, record class and operative paragraph rather
than applying the same rule to all three classes. See [SEC-17A-4].
Gomes Marques Expires 25 March 2027 [Page 67]
Internet-Draft Compliance Receipts Profile September 2026
8.6.1. 17 CFR 240.17a-4(f), electronic recordkeeping system
The November 3, 2022 amendments to 17 CFR 240.17a-4 (compliance date
May 3, 2023) added an audit-trail alternative at 17 CFR 240.17a-
4(f)(2)(i)(A), which stands as an alternative to the write-once-read-
many (WORM) limb at (f)(2)(i)(B) rather than as an addition to it.
The alternative requires a complete time-stamped audit trail carrying
four elements, not one: (1) all modifications to and deletions of the
record or any part of it; (2) the date and time of actions that
create, modify, or delete the record; (3) where applicable, the
identity of the individual creating, modifying, or deleting the
record; and (4) any other information needed to maintain an audit
trail in the required manner, which "will permit re-creation of the
original record if it is modified or deleted". Re-creation is the
tail of the fourth element and not the whole requirement. The hash-
chain linkage required by Section 5.4 together with the retention
rule in Section 8.6.2 and the anchor evidence required by Section 5.5
provides evidence toward the technical recreation capability the
audit-trail alternative requires; the accompanying undertaking
obligations (designated-executive-officer and third-party-access
arrangements among them) are outside this profile's scope and remain
the broker's or dealer's own responsibility.
8.6.2. 17 CFR 240.17a-4(a) and (b) retention
Rule 17a-4 assigns different periods and accessibility conditions to
specified records. Paragraphs (a) and (b) include six-year and
three-year classes, with the first two years in an easily accessible
place. The selected mapping MUST identify the actual class,
triggering event and current rule, rather than impose a receipt-wide
2192-day or 1096-day formula. The 2022 adopting release is a source
for that amendment, not a substitute for checking later amendments to
the current rule.
8.7. CIRCIA: Provisional Evidence Mapping
Under 6 U.S.C. 681b(a)(7), the reporting and preservation
requirements in paragraphs (a)(1) through (a)(4) take effect on dates
prescribed in the final rule; see [CIRCIA-681B]. This mapping
remains provisional because the 13 September 2026 review did not
establish an operative final rule. It does not assert a present
reporting duty for any particular entity. A regulatory-agenda target
for publication is not a published final rule or an effective date.
Gomes Marques Expires 25 March 2027 [Page 68]
Internet-Draft Compliance Receipts Profile September 2026
8.7.1. Incident Evidence Support
An Audit Pack MAY support preparation of a report by identifying the
relevant retained records, known coverage gaps and bounded time
evidence. A receipt's declared incident class does not establish
that the statutory definition is met. The responsible entity
determines coverage, reporting triggers, exceptions, deadlines and
required content under the operative rule.
8.7.2. Preservation Rule
Section 681b(a)(4) requires preservation under the final rule's
procedures, and Section 681b(c)(6) assigns the preservation period to
that rule; see [CIRCIA-681B]. A proposed retention period is not an
established current legal floor. A selected mapping MUST identify
the operative instrument, applicability date, relevant records,
preservation period and exceptions. An organization may adopt a
lawful interim policy, labeled as its own policy, without implying
that a proposal is law.
9. Attestation Statements and Authoritative Re-Derivation
This section is normative. It defines an attestation statement
envelope that the issuing platform emits on top of, and distinct
from, the Compliance Receipt envelope of Section 5. The receipt
envelope of Section 5 remains the unit that the European Union and
United States regime bindings bind to; the attestation statement
defined here is an additional, independently verifiable artifact that
wraps a claim about an Action (or about a code change) in a form a
third party can re-derive from independent evidence. An
implementation MAY emit attestation statements in addition to
receipts; a Compliance Receipt remains conformant whether or not any
attestation statement is emitted. The attestation statement does not
modify the receipt envelope, the canonicalization rule of Section 4,
the signature scope and the hash chain of Section 5.4, or the
anchoring rules of Section 5.5.
9.1. Attestation Statement Envelope
An attestation statement is a Dead Simple Signing Envelope (DSSE,
[DSSE]) whose payload is an in-toto Statement v1 (
[IN-TOTO-ATTESTATION]) and whose signature is computed over the DSSE
Pre-Authentication Encoding (PAE) of that payload. The envelope and
the pre-image are distinct objects and this profile keeps them
distinct. The issuing platform MUST emit a DSSE JSON envelope
carrying payload (the base64 encoding of the serialized Statement
bytes), payloadType, and a signatures array; the PAE never appears in
an envelope, and the envelope is not itself signed. The value of
Gomes Marques Expires 25 March 2027 [Page 69]
Internet-Draft Compliance Receipts Profile September 2026
payloadType MUST be exactly application/vnd.in-toto+json. Stating it
is relevant rather than editorial: the PAE is "DSSEv1" SP
LEN(payloadType) SP payloadType SP LEN(body) SP body, so the pre-
image depends on the exact octets and the octet length of that
string, and a verifier given no value cannot compute the bytes the
signature covers.
The issuing platform MUST sign PAE(payloadType, serialized Statement
bytes) with ML-DSA-65 ( [FIPS204]) under the service identity of
Section 9.6; the signature MUST NOT be computed over any ad-hoc
serialization of the statement. The in-toto Statement MUST set _type
to exactly https://in-toto.io/Statement/v1, which is the member that
identifies it as a v1 Statement, and MUST set predicateType to a
versioned value under the asqav predicate namespace
https://asqav.com/, of the form https://asqav.com/
receipt/<namespace>/<verb>/v1, so the predicate type carries its own
major version as [IN-TOTO-ATTESTATION] requires of a TypeURI. The
statement's subject array carries one or more subjects, each
identified by an in-toto DigestSet. The DSSE PAE defined by [DSSE]
is the signing pre-image and is independent of the JCS rule that
governs the receipt envelope of Section 5
.
Two tiers of attestation statement are defined. The tier is a
property the issuing platform sets and a verifier reads from the
statement; a caller MUST NOT select the tier.
Voluntary (observation) attestation: The statement's subject digest
is a caller-supplied digest. The issuing platform signs the
digest the caller supplied without independently re-deriving it.
This tier is a voluntary cryptographic attestation: it supplies
cryptographic attribution within the authorized signing key's
scope (the signature authenticates the platform's assertion of the
supplied digest and timestamp; an independent time bound requires
separately verified timestamp evidence), but it is explicitly NOT
a capture and is NOT unbypassable. The producer-asserted receipts
of Section 5.14 and Section 5.12 are the receipt-layer expression
of this tier: the platform signs the producer's asserted values
and never re-fetches, re-diffs, re-runs, or otherwise re-derives
them. A verifier MUST NOT read a voluntary attestation as
evidence that the attested content corresponds to any
independently observed fact.
Authoritative attestation: The statement's subject digest is server-
Gomes Marques Expires 25 March 2027 [Page 70]
Internet-Draft Compliance Receipts Profile September 2026
re-derived by the issuing platform from independent evidence, per
Section 9.2. The caller-supplied digest, if any, is advisory only
and is never the signed subject. This tier is the only tier that
supports the independent re-derivation check of Section 9.4.
9.2. Authoritative Code-Authorship Re-Derivation
This section is normative and is the principal addition of revision
-08. For an authoritative attestation whose subject is a code
change, the issuing platform (acting as verifier of the change) MUST
re-derive the subject digest from the source host rather than trust
any client-supplied digest. The canonical re-derivation rule is as
follows.
The re-derivation input is a commit RANGE, not a single commit. A
change authored as a pull request ordinarily carries more than one
commit, so a digest computed over the named commit alone would cover
only part of the authored change. The issuing platform MUST
therefore resolve a base commit identifier for the range before
fetching, in the following order, and MUST NOT silently guess one:
(a) the base identifier supplied with the attestation request, where
it is a full 40-character lowercase hexadecimal object name (this
request parameter is distinct from the producer-asserted base_sha
receipt field of Section 5.14, which is bound into the signed bytes
and never fetched); (b) otherwise the base the source host records
for the pull request associated with commit_sha, which the host
reports as a field distinct from the merge base (it is the three-dot
form of the comparison, stated below, that anchors the diff at the
merge base and keeps it stable across merge and squash commits); (c)
otherwise, where commit_sha names a parentless commit, the empty tree
object name 4b825dc642cb6eb9a060e54bf8d69288fbee4904. Where none of
(a) through (c) yields a base, the platform MUST refuse to emit an
authoritative attestation rather than infer a base from the commit
parents, which are ambiguous for merge and squash commits.
Given that resolved base identifier, the named commit identifier
commit_sha (the field of Section 5.14) and the named repository
repo_ref, the issuing platform MUST fetch the raw unified diff for
the range from the source host (for a GitHub-hosted repository, the
REST comparison endpoint /repos/{repo}/compare/{base}...{commit_sha},
whose three-dot form is what anchors the comparison at the merge base
of the two revisions rather than at the base revision itself) with
the HTTP Accept header set to application/vnd.github.diff, so that
the response body is the raw unified diff of that range. The subject
digest the platform signs is the SHA-256 digest computed over the
exact response bytes returned by that fetch, with no re-encoding, re-
serialization, whitespace normalization, or truncation applied before
hashing. The digest is carried in the subject entry as an in-toto
Gomes Marques Expires 25 March 2027 [Page 71]
Internet-Draft Compliance Receipts Profile September 2026
DigestSet, that is {"sha256": "<64 lowercase hex chars>"}, with the
algorithm in the member name and a bare lowercase hexadecimal value.
The sha256:-prefixed wire form used elsewhere in this profile is NOT
valid in a DigestSet and MUST NOT appear there: it is 71 characters
and is not hexadecimal, so a consumer reading the statement as
[IN-TOTO-ATTESTATION] defines it cannot parse it. The prefixed form
stops at the receipt layer.
Scope of this rule: the canonical re-derivation rule is defined for
GitHub-hosted repositories only. It depends on a proprietary,
unregistered media type (application/vnd.github.diff) and on GitHub's
diff rendering (rename detection, context lines, binary-file stubs),
which is not a versioned specification; if that rendering changes,
digests signed under the earlier rendering no longer re-derive, which
the detection rule below surfaces rather than hides. Repositories
hosted elsewhere require a host-specific rule defined on the same
principle - fetch the host's raw diff rendering of the range and hash
the exact response bytes - and this revision defines no such rule.
A client-supplied digest (for example a value the caller placed in
change_digest of Section 5.14) is ADVISORY only under the
authoritative tier. The issuing platform MAY compare the advisory
digest to the re-derived digest and SHOULD flag a mismatch in the
attestation predicate, but the signed subject digest MUST be the re-
derived value; the advisory value MUST NOT be substituted for it,
signed in its place, or treated as the subject under any mismatch
handling. A mismatch is evidence that the client's view of the
change diverges from the source host's view; it does not promote the
client value to the signed subject.
The property reproducibility gives an authoritative attestation is
unforgeability, not unbypassability: any third party holding
repo_ref, commit_sha, and the base identifier recorded in the
attestation predicate can re-fetch the same range from the source
host under the same Accept: application/vnd.github.diff rule,
recompute SHA-256 over the exact response bytes, and obtain the same
digest the platform signed, without trusting the platform and without
trusting the client. Reproducibility does NOT make the attestation
unbypassable: a client that never requests an attestation bypasses it
entirely, and unbypassability is a property of the deployment per
Section 9.5, never of this digest rule. The canonical re-derivation
rule above is therefore stated precisely so that the recomputation is
byte-for-byte deterministic across independent verifiers.
Where the source host returns different bytes for the same range at
different times (for example after a force-push that rewrites the
commit), the re-derived digest changes and the earlier attestation no
longer re-derives; this is the intended detection behaviour, not a
Gomes Marques Expires 25 March 2027 [Page 72]
Internet-Draft Compliance Receipts Profile September 2026
failure of the rule. The platform MUST record both the commit_sha
and the resolved base identifier it re-fetched in the attestation
predicate, so that the whole re-derivation input is named and no
verifier has to infer the range. A verifier MUST re-derive over the
range the predicate names and MUST NOT substitute a range of its own
choosing. The signed subject digest is a claim about exactly that
range, and it is not a claim that the range covers every change the
producer authored.
9.3. Capture-Layer Integrity
This section is normative. The attestation predicate carries a
server-derived capture_layer member that names the independent
evidence the issuing platform relied on, and a server-enforced
receipt_type member that encodes whether the statement is
authoritative or an observation. Both members are set by the issuing
platform at signing time; a caller-supplied value for either member
MUST be dropped before signing, in the same manner as the server-
built fields of Section 5.11.
The capture_layer member MUST be derived from independent evidence
rather than asserted by the caller. The following values are
defined.
github_sha_pull: The platform re-fetched the raw unified diff for
the named commit range from the source host per Section 9.2. This
is independent evidence and supports an authoritative attestation.
network_proxy: The platform observed the Action as routed HTTP
egress through a proxy under the deployer's control (the topology
catalogued as network_proxy in Appendix C). This is independent
evidence for the routed egress the proxy actually saw and supports
an authoritative attestation for that egress only.
in_process_sdk: The evidence originates from an SDK linked into the
application's own process (the topology catalogued as
in_process_sdk in Appendix C). This is OBSERVATION only: the
evidence is produced by the same process whose behaviour is being
attested, so it is not independent. An in_process_sdk capture
layer MUST NOT mint an authoritative decision attestation; it
yields a voluntary observation attestation only.
passive_telemetry: The evidence originates from a post-hoc telemetry
ingestion pipeline (the topology catalogued as passive_telemetry
in Appendix C). This is OBSERVATION only and MUST NOT mint an
authoritative decision attestation.
Gomes Marques Expires 25 March 2027 [Page 73]
Internet-Draft Compliance Receipts Profile September 2026
The capture_layer vocabulary of this section and the capture_topology
vocabulary of Appendix C are distinct vocabularies at distinct
layers: capture_layer names the evidence class an attestation
statement relied on (the four values above), while capture_topology
names the emission topology of a receipt (six values). Emission
topologies with no independent-evidence capture_layer counterpart
(browser_extension, ebpf_observer, mcp_proxy) can never mint an
authoritative attestation; conversely github_sha_pull is a re-
derivation evidence class and has no emission-topology counterpart.
A deployment mapping one vocabulary onto the other MUST do so per
this paragraph and MUST NOT invent values in either.
Within this attestation schema, receipt_type is authoritative only
for the independently re-derived evidence paths github_sha_pull and
network_proxy; in_process_sdk and passive_telemetry use observation.
This classification describes subject-evidence provenance, not all
possible enforcement mechanisms. Native harness enforcement is
evaluated separately under Section 5.19. If required independent
evidence is unavailable, the signer MUST refuse an authoritative
attestation or emit a correctly labelled observation. It MUST reject
an inconsistent type and layer combination.
9.4. Independent Verification Protocol
A third party evaluates an attestation using authenticated
verification material and independently obtained or retained subject
evidence. The checks can require access to a source host or an
authorized egress-log export. A network dependency is identified
explicitly; protected evidence need not be public. Retained evidence
can support offline checks when it preserves the required source
binding. Missing evidence is unverifiable, while a demonstrated
digest or signature mismatch is invalid.
* Fetch the verification key from the issuing platform's published
JWK Set at /.well-known/jwks.json (Section 9.6), narrowing the
candidate keys by the signature's keyid where one is present.
[DSSE] names this member keyid, makes it OPTIONAL, treats an unset
value as set-but-empty, and states that it MUST NOT be used for
security decisions because it sits outside the PAE and is
therefore unauthenticated; this profile does not override that. A
verifier MUST therefore treat keyid only as a hint that orders the
keys it tries, and MUST base rejection on the signature failing to
verify under every candidate key in the resolved set rather than
on the hint failing to resolve. An envelope carries a signatures
array and MAY carry more than one signature; a verifier evaluates
each. The verifier MUST NOT trust a verification key embedded in
the attestation statement itself, mirroring the rule of
Section 11.2 for receipts.
Gomes Marques Expires 25 March 2027 [Page 74]
Internet-Draft Compliance Receipts Profile September 2026
* Verify the ML-DSA-65 signature ([FIPS204]) over the DSSE PAE of
the in-toto Statement, per Section 9.1. A signature that does not
verify under the resolved key MUST cause the attestation to be
rejected.
* Re-derive the subject digest from independent evidence using the
same canonical rule the platform used: for a code subject, re-
fetch the raw unified diff for the range named in the predicate
(its base identifier and commit_sha) from the source host under
Accept: application/vnd.github.diff and recompute SHA-256 over the
exact response bytes per Section 9.2; for a routed-egress subject,
read the deployer's egress log for the observed flow. The
verifier MUST require equality between the re-derived digest and
the signed subject digest; a mismatch MUST cause the attestation
to be rejected.
These checks supplement receipt verification. Successful
recomputation establishes agreement with the evidence and source
boundary actually checked. It does not prove code authorship,
source-host honesty, complete capture or the behavior of an executed
artifact. The verifier reports which assertions were independently
checked and which remain producer assertions.
9.5. Honest Tiering of Capture Claims
This section is normative and states, precisely and without
overclaim, what each deployment tier does and does not capture. The
two product tiers and their honest guarantees are as follows.
SaaS-SDK tier: This tier produces a voluntary cryptographic
attestation per Section 9.1. The attestation supplies
cryptographic attribution within the authorized signing key's
scope (the signature authenticates the platform's assertion of the
supplied digest and timestamp; an independent time bound requires
separately verified timestamp evidence), but it is NOT a capture
and is NOT unbypassable: the platform signs what the client
presents and does not independently observe the client's
behaviour. A verifier or regulator MUST NOT read a SaaS-SDK-tier
attestation as evidence that the attested action is the complete
set of actions the client performed.
Enterprise-proxy tier: This tier produces a real capture, but only
for routed HTTP egress to public model APIs that actually
traverses the deployer's proxy, and only when the deployer both
firewalls egress so that the model-API traffic is forced through
the proxy and configures the proxy and signer to fail closed.
Under those deployer-controlled conditions the capture is
authoritative for the egress the proxy observed, per the
Gomes Marques Expires 25 March 2027 [Page 75]
Internet-Draft Compliance Receipts Profile September 2026
network_proxy capture layer of Section 9.3. The unbypassability
of this tier is a property of the deployer's network policy (the
firewalling and fail-closed configuration), NOT a property of the
product: a deployer that does not firewall egress, or that
configures fail-open, has not deployed an unbypassable capture,
and the product MUST NOT be represented as providing one in that
configuration. This profile does NOT claim, and the Enterprise-
proxy tier does NOT provide, host-level capture of arbitrary
process behaviour: it does not claim eBPF-based or shell-based
capture of actions that do not traverse the routed HTTP egress.
The eBPF-observer and passive-telemetry topologies catalogued in
Appendix C remain observation-only evidence classes under
Section 9.3 and do not mint authoritative attestations.
9.6. Service Identity, JWKS, and Revocation
Attestation statements use a dedicated ML-DSA-65 service identity,
distinct from an agent or deployer identity. Public keys are
published as RFC 9964 AKP JWKs with kty, alg and unpadded-base64url
pub. The profile uses /.well-known/jwks.json as a documented
implementation location; the path is not presented as an IANA
registration. The relying party authenticates the origin or obtains
a trusted export. DSSE keyid and a JSON receipt's external
signature.kid are key-selection hints, not independently signed
authority claims. Authorization follows Section 5.2.5 and
Section 9.4.
Publish historical public keys and authenticated status information
sufficient for the retention policy. A verifier MUST distinguish key
retirement, revocation, compromise and an unknown status. It
evaluates the relevant authorization period using its trust policy
and available time evidence. An issuer-declared timestamp alone
cannot prove that a signature preceded compromise. A demonstrated
authorization violation is invalid; missing reliable historical
status is unverifiable. Neither can support full verification.
Current rotation alone does not invalidate all earlier receipts.
10. Audit Pack Composition
This section is normative. It defines the contents of an Audit Pack
as introduced in Section 2, on which the resolution requirements of
Section 5.3.2 and Section 11.2 depend.
An Audit Pack contains the following items.
* The set of Compliance Receipts covered by the requested time
window, in the envelope form defined by Section 5, preserving each
receipt's authenticated representation.
Gomes Marques Expires 25 March 2027 [Page 76]
Internet-Draft Compliance Receipts Profile September 2026
* The chain commitments that link the receipts: for each receipt,
the value of previousReceiptHash and the recomputed chain-link
digest of its predecessor per Section 5.4.
* The anchor evidence: [RFC3161] tokens, OpenTimestamps proofs, or
both. Each anchor item MUST be associated, by hash, with the
receipt or aggregate it covers.
* The trust anchor metadata that identifies the Deployer or other
regulated entity associated with each issuer_id value.
* The verification key material for every kid value present, in a
form that does not require online retrieval.
* Vocabularies referenced by reason, risk_class, incident_class, and
extension fields, embedded as JSON arrays with a stable
identifier. The Audit Pack MUST expose a digest-resolution
facility that, given a policy_digest, returns the retained
artefact.
* A regime mapping document that names which receipts the producer
asserts as evidence under any of the regimes addressed by the EU
and US evidence mappings of this document (EU AI Act Article 12,
EU AI Act Article 26, EU AI Act Article 50, DORA Article 17, NIST
AI RMF, Colorado Automated Decision-Making Technology Act, Texas
Responsible AI Governance Act, NYDFS Part 500, HIPAA Security
Rule, SEC Rule 17a-4, and the provisional CIRCIA evidence
mapping).
* The chain heads valid at the start and end of the time window,
signed by the Deployer or other regulated entity.
The deterministic APS gateway fixtures at aps-gateway-enforcement/2-
external-verification in the [SCOPEBLIND] corpus use a public test
seed. Their signature covers the whole receipt object minus the
signature field, a different scope from the signature scope defined
in Section 5.4. A verifier processing a mixed corpus therefore has
to select the signature scope by the receipt's format, never assume
it. The fixture illustrates a format difference; it does not
establish deployment, ecosystem adoption or general interoperability.
An Audit Pack MUST carry the signed-bundle construction of
Section 10.1. The required fields include bundle_digest,
bundle_signature, bundle_signature_algorithm, bundle_public_key and
algorithm_registry_version. Their scope and authorization rules are
defined locally.
Gomes Marques Expires 25 March 2027 [Page 77]
Internet-Draft Compliance Receipts Profile September 2026
The following manifest-level fields SHOULD appear on an Audit Pack
bundle when the underlying receipt stream exposes the corresponding
semantics. Each is informative and does not alter the wire shape of
individual receipts.
regime_mapping_disclaimer: String emitted on bundles whose per-
receipt regime predicates derive from mapping logic the original
producing system did not sign. The value identifies the producer
of the mapping, the document version under which it was computed,
and a disclaimer that the regime-satisfaction flags are advisory
and remain subject to the verifier's own check against the EU and
US evidence mappings.
stale_pending: Boolean flag set per bundle entry whose anchor
evidence is still pending after the bound of Section 5.5 (7 days
for OpenTimestamps; synchronous for RFC 3161). When true, the
entry has exceeded that bound, which fails a selected policy
requiring the upgrade under Section 5.5 rather than making the
receipt non-conformant on its own, and a Compliance Verifier
consumes the flag to drive anchor_valid_* false in its per-axis
report (see Section 11.4). A verify endpoint over the same bundle
SHOULD surface stale_pending in its response.
10.1. Signed Audit Pack Projection
This section defines the JSON bundle construction. The digest and
signature cover a projection P of the delivered bundle, not archive-
container bytes. P contains exactly these required members:
organization_id (string), start and end (RFC 3339 strings), agent_id
(string or null), only_compliance (boolean),
algorithm_registry_version (string), receipt_count (nonnegative
integer), receipts (array of objects), revocation_manifest (array of
objects) and regime_mapping (object mapping regime strings to arrays
of receipt identifiers). The receipt count MUST equal the array
length. Array order and strings are preserved. The interval start
MUST NOT be later than end.
Each receipt entry referenced by regime_mapping carries a nonempty
string signature_id. These identifiers MUST be unique within the
bundle and each mapping reference MUST resolve to exactly one entry.
For a core receipt entry, extract only payload, signature and, when
present, anchors as the receipt envelope. Other entry members are
bundle metadata and MUST NOT enter receipt signature, anchor or
counterparty calculations. A separately selected historical
transport defines its own original envelope boundary.
Gomes Marques Expires 25 March 2027 [Page 78]
Internet-Draft Compliance Receipts Profile September 2026
If present and non-null, copy content_disclosure (object),
regime_mapping_disclaimer (string), regime_provenance (string), jwks
(JWK Set object) and exit_manifest (object) into P. Copy
attested_framework_coverage when it is a nonempty object. Absent
optional members stay absent; null optional values are not copied.
Other bundle members, including the digest, signature, algorithm
label and public-key carrier, are excluded from P. A verifier MUST
NOT describe an excluded member as authenticated by this bundle
signature. New bundles that declare regimes MUST include
regime_provenance, stating that regimes_satisfied records signature-
gated membership in producer-supplied mapping lists, not independent
evaluation or legal compliance. The existing
regime_mapping_disclaimer remains a separate signal about missing
per-receipt evidence. Historical bundles that omit regime_provenance
retain their original projection; a verifier may explain their
producer-asserted mapping semantics in its report, but MUST NOT
represent that generated explanation as text signed in the historical
bundle. Unknown required extensions make full bundle verification
unverifiable rather than silently entering the projection.
Let B be UTF8(JCS(P)), subject to Section 4. bundle_digest MUST equal
"sha256:" || lowercase_hex(SHA-256(B)). bundle_signature is a base64
string carrying a pure ML-DSA-65 signature over B with an empty
context; it does not sign the digest string or the 32 digest octets.
bundle_signature_algorithm is the string ML-DSA-65. bundle_public_key
is a base64 string carrying the 1952 public-key octets. For this
bundle transport, base64 uses the standard alphabet and padding rules
of [RFC4648] Section 4; the receipt's signature.sig encoding is a
separate field. A legacy transport may document another original
encoding without changing retained bytes.
The algorithm_registry_version value for the currently defined
registry edition is 2026-05-04.v1. It identifies algorithm policy,
not a licence to change P or the wire shape. New-revision issuance
uses the ML-DSA-65 contract above. An unknown registry edition or a
different historical algorithm requires an explicitly selected policy
and cannot silently change verification. A revised bundle projection
needs its own identified transport revision; it MUST NOT reuse these
semantics without disclosing the change. The regime_provenance
inclusion rule belongs to this revision of the bundle profile. Its
absence in a retained bundle does not establish the bundle's issuance
date or profile revision; select historical interpretation from
authenticated revision information or an explicitly configured
compatibility policy.
The verifier recomputes B and the digest, verifies the signature and
independently authenticates the bundle signer's authority to export
for the named organization. It MUST NOT trust the carried public key
Gomes Marques Expires 25 March 2027 [Page 79]
Internet-Draft Compliance Receipts Profile September 2026
solely because it verifies the bundle. Each receipt, timestamp,
policy artifact and key-status claim still requires its own
applicable verification. The bundle signature proves inclusion of
the projected content, not the truth of the assertions or
completeness of the export window. Externally resolved artifacts
require their own verified digest commitments; a locator is not such
a commitment. Required unavailable evidence prevents full
verification.
The projection above records the selected target contract.
Historical bundles retain their original projection and encoding. A
flat stored receipt inside a bundle is evaluated under its original
receipt format; the bundle signature does not make that receipt
conformant to this profile.
11. Verifier Behaviour
A verifier conformant to this profile is referred to as a Compliance
Verifier.
11.1. Verifier Independence
Verification of the receipt's signature and other checks for which
the holder has the required evidence MUST be possible without asking
the issuer to compute or approve the verdict. The profile's
verification procedure and required public-key representations MUST
be documented. A holder must be able to export lawfully available
receipt bytes, proofs and historical public verification material for
use by another implementation.
Independence does not require unrestricted public access to private
records, source code or personal data. A verifier MAY receive
protected evidence through lawful access controls or an authorized
export. Missing access leaves the affected axis unverifiable; it
does not make the evidence false or the available cryptographic
checks invalid. An issuer-operated service alone is insufficient if
no independent implementation can evaluate the exported evidence.
Reproducible verdicts require the same receipt bytes, evidence set,
profile revision, verification time and trust policy. Operators with
different trust roots or access to different evidence can reach
different results. Offline checks use retained evidence; live checks
identify their network dependencies. Both report those limits
explicitly under Section 11.4.
Gomes Marques Expires 25 March 2027 [Page 80]
Internet-Draft Compliance Receipts Profile September 2026
11.2. Mandatory Checks
A Compliance Verifier MUST perform at minimum all of the following
checks before treating a receipt as a Compliance Receipt, together
with the conditional checks of Section 5.5 (pending-anchor bound and
witness quorum), Section 5.8.3, Section 5.9, and Section 5.11.
* Verify the signature over the signed bytes defined in Section 5.4,
using the permitted algorithm and signing-input rules of
Section 5.1.
* Resolve candidate keys from independently authenticated JWK Sets,
configured trust anchors or authenticated historical exports under
Section 5.2.5 and Section 9.6. The profile documents /.well-
known/jwks.json as its key location. A verifier MUST establish
the key-to-issuer authorization and algorithm policy independently
of the received envelope or bundle. A carried public key alone is
not a trust anchor.
* Verify that all fields marked REQUIRED by Section 5 are present
and well-formed.
* Verify the hash-chain linkage by recomputing the chain-link digest
of the immediately preceding receipt per Section 5.4 and comparing
the lowercase hex encoding to previousReceiptHash. An explicit
JSON null, an empty string, or an absent member is a malformed
chain link, not a genesis marker; the genesis value is the all-
zero SHA-256 value of Section 5.4.
* Evaluate presented anchors and any declared witness policy per
Section 5.5. Apply the selected relying-party or regulatory-
evidence floor, report absent or unvalidated evidence explicitly,
and never derive validity from metadata presence.
* Verify the future-skew bound on issued_at per Section 5.2.4. Past
skew MUST NOT cause non-conformance when the receipt is within
retention.
* Where the receipt carries expires_at, reject a downstream action
that replays that decision after expires_at per Section 5.9; the
receipt itself MUST NOT be rejected solely because expires_at has
elapsed. Where the verifier maintains a seen-nonce index, a
duplicate nonce under the same issuer_id MUST be flagged as a
replay candidate on the reporting axis of Section 11.4.
* Where policy_digest is non-null and required for the selected
receipt type, resolve the policy artifact and recompute its
defined digest. JSON artifacts use JCS; other formats require an
Gomes Marques Expires 25 March 2027 [Page 81]
Internet-Draft Compliance Receipts Profile September 2026
explicit canonical-byte rule. Missing required evidence is
unverifiable and a demonstrated mismatch is invalid. The defined
no-policy lifecycle path permits null and is reported as not
applicable for this axis, rather than as successful policy
evaluation.
* Where the receipt carries key_thumbprint per Section 5.2.10,
recompute the RFC 7638 thumbprint of the resolved verification key
per [RFC7638] and require equality. A mismatch is a key-
substitution failure and MUST be reported as non-conformant, never
downgraded to a warning or reported as verified. Absence of the
field is the legacy case of Section 5.2.10 and is not itself a
failure.
* Where a non-null context and payload_digest are carried, select
the computation from the signed hash_algo and the versioned
contract. For sha256, recompute SHA-256 over JCS(context). For
hmac-sha256, recompute HMAC-SHA256 over the same bytes with
authorized holder key material. Missing required content or key
material makes this axis unverifiable; a demonstrated mismatch is
invalid. payload_digest.size is the byte length of that canonical
context. Compare the decoded digest bytes to payload_digest.hash,
not differently prefixed strings. When context is absent or null,
this carried-context consistency check is not applicable; any
separate requirement to resolve the underlying commitment is
reported under the selected policy. A hash-only commitment does
not prove that the issuer saw its input.
* When required by the selected evidence policy, resolve the
retained Action descriptor, recompute action_ref under
Section 5.2.7 and report the action-descriptor check separately.
Missing required descriptor evidence is unverifiable; a
demonstrated mismatch is invalid. When the check is not required
and is not performed, report it as unchecked, not valid.
A demonstrated mismatch fails its applicable check. Unavailable
evidence or unsupported evaluation is reported unverifiable. Both
prevent full verification when the axis is required, but neither
changes the result of independently evaluable axes.
Verification keys carried in an Audit Pack are not automatically
trusted. The verifier MUST establish the issuer and key
authorization through its configured trust policy, preserve
historical key-purpose and revocation semantics, and refuse ambiguous
key resolution. Current key rotation alone does not invalidate an
earlier valid signature.
Gomes Marques Expires 25 March 2027 [Page 82]
Internet-Draft Compliance Receipts Profile September 2026
11.3. Optional Checks
A Compliance Verifier MAY additionally perform any of the following.
* Cross-check the issuer_id against an external registry (LEI, EIN,
CIK, NPI, GLEIF, or a Deployer-published list).
* Resolve the policy artifact referenced by policy_digest and
compare it to a Provider-supplied or Deployer-supplied reference
policy.
* Recompute the chain head and compare it to a Deployer-published
value.
* Validate incident_class (each element if encoded as an array) and
risk_class extension values against the vocabularies referenced in
the Audit Pack.
11.4. Reporting
A verifier MUST distinguish the signature, schema, chain, digest, key
authorization, anchor, witness policy, freshness, replay observation
and any applicable extension checks. Each reported axis identifies
its input scope, policy and trust material and has a state of valid,
invalid, unverifiable, pending, unchecked or not_applicable, with a
reason. unchecked means an applicable check was not performed;
not_applicable means its applicability condition is false, not that
evidence is missing. The receipt-declared witness-policy axis may
additionally be undeclared as specified in Section 5.5. Missing
evidence, unsupported implementation and an unavailable dependency
MUST NOT be reported as a valid check.
A structured report SHOULD carry axes, a map from the axis name to an
object with status, reason and required, together with the evaluated
profile revision, verification time and trust-policy identity. These
are verifier-report fields, not new signed-payload members. The
required-axis set comes from the selected profile and relying-party
policy, not a test fixture or producer's preferred declaration. A
report MUST NOT claim full verification when a required axis is
invalid, pending, unverifiable, unchecked or undeclared. A fixture
testing only the chain axis cannot waive required production checks.
Gomes Marques Expires 25 March 2027 [Page 83]
Internet-Draft Compliance Receipts Profile September 2026
Legacy boolean fields such as anchor_valid_ots, anchor_valid_rfc3161
and policy_digest_resolved MAY remain for compatibility, accompanied
by the corresponding explicit axis status. A false value must not be
interpreted as a demonstrated mismatch when the check was not
performed. Likewise, duplicate_emission_candidate=false means no
duplicate was found only when an index with a stated scope was
actually checked; without such an index the replay-observation axis
is unverifiable.
In the retained Audit Pack compatibility report, regimes_satisfied
lists the keys in the producer-supplied regime_mapping whose receipt-
ID lists contain the receipt, and is populated only after the receipt
signature check passes. This is signature-gated mapping membership,
not independent evaluation of the mapped requirements or a legal-
compliance conclusion. Reports MUST label this provenance
explicitly. Any independently evaluated technical binding has its
own evidence, applicability and per-axis results. Unevaluated
applicability remains unknown. The compatibility key colorado_ai is
retained; in the mapping revision defined here it identifies the
SB26-189 binding in Section 8.2. colorado_admt is the source-register
identifier, not a newly introduced wire alias. A mapping identifies
its instrument version and relevant decision date; historical signed
mappings MUST NOT be relabeled as compliance with a later law.
Independent implementations are compared using the same receipt
bytes, available evidence, verification time, profile and trust
policy.
The summary vocabulary in Section 11.5 remains separate from per-axis
results. A cryptographic mismatch is distinguished from an inability
to evaluate. A valid signature can coexist with an unverified
overall result.
An undeclared witness-policy axis prevents full verification when the
selected external policy requires a signed declaration. It MUST NOT
be counted as a satisfied quorum. When no declaration is required,
the verifier still reports that none was presented.
11.5. Verification Verdict and Hash-Algorithm Vocabulary
The summary vocabulary is verified, verified_keyed and unverified.
It summarizes the required axes selected under Section 11.4.
Optional missing evidence is still reported on its own axis. A
summary never means that every underlying claim is true or that a
legal obligation is satisfied.
verified All required axes passed. Any context commitment is
Gomes Marques Expires 25 March 2027 [Page 84]
Internet-Draft Compliance Receipts Profile September 2026
unkeyed. The report identifies whether the underlying content was
actually available and recomputed; signature verification alone
does not establish the content.
verified_keyed All required axes passed and the receipt carries a
keyed context commitment. The report states whether the verifier
actually recomputed that commitment with an authorized key. Where
the selected policy requires recomputation and the key or content
is unavailable, the result is unverified, not this state.
unverified At least one required axis failed or could not be
completed. A pending required anchor prevents full verification.
An optional pending anchor does not by itself invalidate an
otherwise passing summary, and remains pending on its own axis.
hash_algo identifies sha256 or hmac-sha256. Under the retained hash-
mode contract, the hash string uses the sha256: prefix for both,
while payload_digest.hash is unprefixed. The signed algorithm
member, not that historical prefix, identifies the computation. A
keyed commitment MUST carry hash_algo=hmac-sha256. Absence means
unkeyed only where the selected version explicitly defines that
default. Unknown algorithms are unverifiable. Historical bytes are
preserved.
A holder salt means the secret HMAC key. It MUST NOT be included in
a public receipt, anchor or ordinary Audit Pack export. Where
authorized recomputation is required, key access is supplied
separately under the holder's policy. Destruction of that key does
not prove erasure of every source record or identifying link.
For a non-passing summary, failure_class distinguishes a demonstrated
cryptographic or policy mismatch (invalid) from unavailable evidence
or unsupported computation (unverifiable). If both occur, the report
retains both per-axis findings and uses invalid for the summary
class. A legacy display label MUST NOT override the required-axis
result or turn a missing check into success.
The retained hosted display vocabulary is a separate compatibility
surface: verified, verified_keyed, not_rederivable, pending and
failed, alongside a separate boolean verified. The boolean is not a
sixth string label. A valid_commitment_not_rederivable detail
selects not_rederivable before the boolean is considered. Otherwise
a true boolean selects verified_keyed only when the keyed-digest
check passes, or verified. With a false boolean, a valid signature,
the anchor_pending_no_cryptographic_proof detail, no false
counterparty-binding result and no stale-pending indication select
pending; other cases select failed. The display mapping does not
change the boolean.
Gomes Marques Expires 25 March 2027 [Page 85]
Internet-Draft Compliance Receipts Profile September 2026
These compatibility labels MUST NOT be used as a substitute for the
required-axis summary. In particular, failed does not distinguish a
proven mismatch from unavailable evidence, and not_rederivable cannot
satisfy a policy that requires recomputation of the unavailable
claim. The hosted keyed check recomputes a mint-time keyed-digest
tag with the held holder salt; that check alone does not demonstrate
recomputation from the original content. An adapter reports the
input surface and version and derives the current summary from actual
axis results, rather than renaming failed to unverified and assuming
equivalence.
12. Security Considerations
The security requirements are stated in this document:
canonicalization and scope validation, issuer/key authorization,
compromise and revocation, replay appraisal, privacy, evidence
availability and incomplete-chain limits. No external receipt draft
supplies additional unstated security requirements. A verifier MUST
place its own identity and results in a separate report; adding them
to an existing receipt does not authenticate them under the original
signature. Unsupported evidence extensions MUST NOT receive a
positive assurance merely because they are present.
12.1. Tamper Resistance
Signatures and chain links expose changes to the committed bytes
under their cryptographic assumptions. A signer with a compromised
key can create alternative signed history. Independently retained
checkpoints and verified timestamp evidence can constrain that
attack, but they do not eliminate all rollback or omission windows.
The verifier states which history and checkpoint it actually received
and the limits described in Section 12.14.
12.2. Chain- and Signature-Scope Confusion
A verifier that processes more than one receipt format MUST determine
the signature scope and the chain-digest scope from the receipt's
format before it begins verification, and MUST NOT retry verification
under a different scope when the first attempt fails. For Compliance
Receipts both scopes are fixed by Section 5.4: the signature covers
the JCS-canonical serialization of the payload member, and the chain
link digests the predecessor's payload member R. Receipts of the
bare [ACTA-RECEIPTS] format chain over the whole-receipt object
including the signature, and the cited APS fixtures sign the receipt
object minus the signature field (the APS gateway receipts in the
[SCOPEBLIND] corpus, per Section 10); this profile's receipts are
identified by the REQUIRED v member of Section 5.2.1, per the
interoperability note of Section 5.4, and not by the top-level
Gomes Marques Expires 25 March 2027 [Page 86]
Internet-Draft Compliance Receipts Profile September 2026
anchors key. A scope-derived verification failure MUST be reported
distinctly from an integrity failure under the correct scope:
retrying the alternate scope on failure converts a format mismatch
into an apparent integrity result, concealing both the wrong-format
case and the tampered case from the consumer of the verification
report.
12.3. Chain Availability Under Single-Linear Per-Agent Serialization
This section is informative. The single-linear per-agent chain
requirement of Section 5.4 serializes receipt emission for a given
issuer_id through a single predecessor pointer. A denial-of-service
against the predecessor pointer (database row lock contention,
network partition between the emitter and the predecessor store, slow
IO, or an adversary deliberately holding the chain-tail lock)
therefore bounds the per-agent emission throughput, because every new
receipt MUST resolve the digest of the immediately prior receipt
before it can be linked. A partial-write failure between
predecessor-pointer commit and signature commit can additionally
produce chain-head ambiguity if not handled defensively.
Issuers SHOULD use a bounded predecessor-lookup timeout (operator-
tuned, typically on the order of seconds rather than tens of seconds)
and SHOULD emit a structured audit event with type
protectmcp:lifecycle and a stable reason code (RECOMMENDED:
chain_emission_blocked) when the timeout fires, rather than silently
dropping the receipt or stalling caller threads. Issuers SHOULD
additionally document a chain-head recovery procedure for crashed
emitters: on restart, the issuer re-reads the predecessor row,
verifies that no orphan signature exists for the next sequence
position, and resumes emission. Operators that require parallel per-
issuer throughput beyond what a single linear chain sustains MUST use
distinct issuer_id values per parallel path, with separate signing
keys and chains rooted at the all-zero genesis value, per the rule in
Section 5.4.
The threat profile here is availability, not confidentiality or
integrity: a successful chain-availability attack delays or drops
emission, but it cannot tamper with already-emitted receipts (those
are protected by Section 12.1) and it cannot forge receipts (those
are protected by Section 12.4). The chain_emission_blocked lifecycle
receipt is itself a Compliance Receipt and therefore links into the
chain once emission resumes, so the gap is detectable rather than
silent.
Gomes Marques Expires 25 March 2027 [Page 87]
Internet-Draft Compliance Receipts Profile September 2026
12.4. Key Compromise
On suspected compromise, the responsible operator publishes
authenticated key-status information identifying the key, known or
suspected compromise interval and affected use. It preserves
historical public verification material where lawful and follows
Section 9.6 for status evaluation.
A producer's issued_at cannot by itself prove pre-compromise
issuance. A verifier uses the available independent time evidence
and its historical authorization policy. A demonstrated unauthorized
signature is invalid; insufficient reliable history is unverifiable.
An untrusted revoked_at value in a supplied Audit Pack cannot
establish revocation or authorize a different key.
12.5. Retention and Long-Term Verifiability
Long-term verification depends on retained receipt bytes, proofs,
historical public keys, key authorization records and the applicable
trust policy. The retention schedule follows Section 6.
Implementations SHOULD plan cryptographic renewal and preserve the
evidence needed to interpret older formats without rewriting their
committed bytes.
The omission and rollback limits of Section 12.14 are constrained
only by checkpoint, witness and anchor evidence that is still
available when a verifier needs it. An operator whose completeness
claims rely on independently retained checkpoints SHOULD retain that
material, together with the inclusion evidence a verifier needs to
use it, for at least the retention period of the receipts it covers,
and SHOULD keep at least one copy recoverable independently of the
log that produced it. A checkpoint recoverable only with that log is
not independently retained: the same event removes both, and it then
constrains a compromised signer no more than the log's own history
does. Loss of that material does not invalidate a retained receipt;
it narrows the window in which an omission is detectable, and the
verifier reports the narrowed limit rather than claiming complete
history.
ML-DSA is a digital-signature standard, not an encryption mechanism.
Its use can address a post-quantum signature requirement; it does not
protect stored personal data from disclosure or prove that the signer
was authorized. Algorithm selection and migration follow the relying
party's documented threat model and policy. Public verification keys
SHOULD remain available for the lawful evidence window even after the
private signing key is retired.
Gomes Marques Expires 25 March 2027 [Page 88]
Internet-Draft Compliance Receipts Profile September 2026
12.6. Privacy
Signed payloads MUST NOT contain raw prompts, tool arguments,
credentials or free-text personal data in taxonomy fields. Producers
SHOULD minimize stable identifiers and linkable metadata. Digests,
public keys, timestamps and opaque references may still identify a
person in context; hashing alone does not establish anonymity. See
[GDPR] and the distinctions in [ICO-ANON].
Underlying content is stored separately with appropriate access
controls, a documented purpose and a lawful retention schedule.
Access to a receipt or Audit Pack does not authorize disclosure of
its referenced content. Public anchoring SHOULD disclose only the
commitment needed for verification. An organization must assess
whether even that commitment exposes protected information or creates
a restricted transfer. A receipt does not supply consent or a
transfer mechanism.
A valid erasure, correction or restriction obligation applies to
every affected copy within its legal scope, including receipt
metadata and backups. This profile does not require retaining a
receipt when the applicable law requires its deletion. Where
continued retention is lawful, the organization records its basis and
minimizes the retained information. A correction may be linked to an
earlier record without presenting the earlier statement as current
truth. Lawful deletion may leave a verification gap; the verifier
MUST report that limit rather than claim complete history.
Low-entropy environment identifiers MUST NOT be committed using an
unkeyed hash. Where this profile permits hmac-sha256, use a secret,
high-entropy key with separation between holders and purposes,
following [RFC2104]. A so-called holder salt is a secret HMAC key,
not a public salt. Its destruction can prevent later digest
recomputation, but does not prove that all copies, auxiliary data or
identifying links have been erased. The privacy assessment must
consider the whole deployment.
12.7. Anchor Trust
RFC 3161 evidence depends on the selected timestamp authority and its
certificate, time and revocation policy. OpenTimestamps evidence
depends on its verified commitment path and the selected Bitcoin
chain and confirmation policy. Different protocol labels do not
establish independent operators. A verifier evaluates the
construction and failure assumptions of each witness under
Section 5.5; it MUST NOT count an unverified proof or two labels
controlled by one operator as two independent witnesses.
Gomes Marques Expires 25 March 2027 [Page 89]
Internet-Draft Compliance Receipts Profile September 2026
The optional tsa_url and operator_id members are producer-supplied
metadata. They do not authorize a trust root or network request.
The verifier MUST resolve trust independently and MUST NOT fetch a
supplied URL merely because it appears in a receipt. Unknown trust
material produces an unverifiable anchor axis, not a valid timestamp.
12.8. Replay
An action_ref mismatch detects a change in the committed Action
descriptor. Equality does not establish identical arguments,
execution identity or absence of replay. Applicable context
commitments, nonces and replay indexes are evaluated separately. The
300-second issued_at skew bound of Section 5.2.4 bounds only future
skew: it rejects receipts dated ahead of the verifier's clock and
places no lower bound on past skew, so it does not by itself bound
the window in which a replayed receipt can be presented as recent.
Clock-based replay bounding is available only through the OPTIONAL
validity-window fields of Section 5.9: expires_at, which the verifier
enforces against replayed decisions, and nonce, which flags duplicate
emission where the verifier maintains a seen-nonce index. A receipt
carrying neither is bounded only by retention: a replayed receipt
whose issued_at lies within the applicable retention window passes
the skew check of Section 5.2.4, and its replay is detectable only
through action_ref, chain-link, or index evidence.
Where the verifier supports it, two receipts sharing action_ref and
issuer_id SHOULD be flagged as a candidate duplicate-emission event
for human review. This profile does not require verifiers to
maintain a cross-receipt index; deployers needing duplicate-emission
detection should arrange it at the Audit Pack production layer.
12.9. Cross-Regime Conflict
The organization determines which laws and policies apply using
Section 6. It cannot resolve a conflict between laws by comparing
this document's MUST and SHOULD words or by always choosing the
longer retention period. Legal hierarchy, territorial scope,
exceptions, regulatory orders and the actual record class require
separate assessment.
When an applicable requirement remains unresolved, a verifier MUST
report the affected evidence-policy axis as unverifiable. The system
MUST NOT claim that all relevant regimes are satisfied. Whether the
underlying activity, storage or disclosure may continue is a decision
under the applicable law and authority. A minimal conflict record
MAY be retained where lawful; this profile does not impose a
recursive duty to issue another receipt or a duty to create
prohibited records.
Gomes Marques Expires 25 March 2027 [Page 90]
Internet-Draft Compliance Receipts Profile September 2026
12.10. Algorithm Agility
Historical algorithm acceptance and key authorization follow the
selected trust policy, authenticated historical status and available
time evidence. The issuer's issued_at assertion alone cannot
establish eligibility for an earlier policy. Later retirement or
revocation does not automatically invalidate every earlier signature.
A demonstrated historical violation is invalid; unresolved
authorization is unverifiable.
Receipts under this profile are signed with ML-DSA-65 [FIPS204],
whose security rests on lattice assumptions, and retention
obligations in the regimes this profile addresses run for years.
Carrying a single family of hardness assumptions across that window
is the profile's principal long-horizon exposure. The hedge this
profile intends is to place a second, independent assumption at the
periodic-checkpoint layer rather than on each receipt, so that
receipts stay lattice-signed while the integrity of retained history
can rest on hash assumptions; the checkpoint structure and its
verification rules are not defined in this revision.
Per-receipt dual signing is out of scope. An SLH-DSA-SHA2-192s
signature is 16224 octets [FIPS205] against 3309 octets for ML-DSA-65
[FIPS204], roughly five times the signature bytes on an artifact
minted once per Action, and the "s" parameter sets are the ones
[FIPS205] characterises as favouring small signatures rather than
fast signature generation, so that size is not bought back in signing
speed. Independently, [LAMPS-COMPOSITE] defines eighteen composite
combinations and requests their registration and every one pairs ML-
DSA with a traditional algorithm; none pairs ML-DSA with SLH-DSA or
with any other post-quantum algorithm, so a dual-signed receipt would
be defining its own profile rather than following the combinations in
that work-in-progress proposal.
12.11. Issuer-Misrepresentation Residual
Per-agent hash chains under Section 5.4 detect tampering inside a
single issuer's stream but not the cross-agent attack in which a
compromised intermediary silently swaps payload bytes between two
honest agents. Both per-agent chains validate; action_ref binds the
Action descriptor of Section 5.2.7, not the peer receipt envelope.
Without a cross-agent binding primitive, a regulator obtains no
cryptographic answer to "did the acknowledging agent acknowledge the
bytes the originating agent actually sent". This profile defines
counterparty_binding (Section 5.8) as the partial mitigation; the
following residuals remain.
Gomes Marques Expires 25 March 2027 [Page 91]
Internet-Draft Compliance Receipts Profile September 2026
* Endpoint collusion. If both signing keys are compromised by the
same attacker, the attacker produces a coordinated forgery; no
signature scheme defends against this case.
* Intermediary holds the originating agent's key. In hosted-agent
deployments where the intermediary possesses the originating
agent's private key, it can sign anything as either party. Remote
attestation of key origin is the appropriate countermeasure and is
out of scope here.
* Originator offline at verification time. Section 5.8.3 requires
the originating envelope to be retrievable; if unpublished,
offline, or rate-limited, the binding becomes unverifiable
(liveness loss, observable as failure).
* Fan-out witness gap. When an originator broadcasts to N
acknowledgers, each emits an independent pairwise binding; none
witnesses any other. Append-only log profiles (future SCITT-style
transparency) are deferred to a later revision.
* Key rotation orphan. If the originating agent rotates keys after
emission but before an acknowledger binds it, the storage
obligation of Section 5.8.3 still requires the old envelope to
remain retrievable; if retention discipline fails, the binding
orphans.
* Privacy of envelope hashes. envelope_hash is computed over A's
envelope-minus-anchors object, which carries A's signature bytes;
an observer of B's receipt learns a stable identifier for A's
exact action and therefore can correlate B's behaviour across
receipts even when A's payload is otherwise confidential. Where
this correlation is unacceptable, a commitment scheme (for
example, HMAC over the envelope with a per-counterparty key
disclosed only to the verifier) is appropriate; this profile does
not specify one.
* Real-time prevention. counterparty_binding is detective, not
preventive: B has already accepted the bytes by the time the
binding is signed. Verifiers detect tampering only at audit time;
the in-flight bytes were not blocked. Where prevention is
required, transport-level integrity per Section 12.12 is the
appropriate primitive in addition to (not instead of) this
profile.
Gomes Marques Expires 25 March 2027 [Page 92]
Internet-Draft Compliance Receipts Profile September 2026
* A commitment establishes equality only under its defined framing
and byte construction. In JSON framing, whitespace or member-
order changes that preserve the JCS representation are not
detected. Changed signed values or a different retained signature
string change the commitment. This is evidence about the defined
representation, not every original transport byte.
12.12. Cross-Agent Integrity Trust Boundary
This section is informative. It records operator guidance for cases
where channel-level protection is the only available defense and
counterparty_binding per Section 5.8 has not yet been adopted by both
endpoints. For channels between named principals, implementers
should secure the channel using mutually authenticated TLS 1.3 per
[RFC9846]; may use the tls-exporter channel binding per [RFC9266]
derived via [RFC5705] where higher channel uniqueness is required;
and may layer HTTP Message Signatures per [RFC9421] where
intermediaries perform legitimate transformations.
Operators must not interpret transport-layer security alone as
evidence of cross-agent byte equality. Only counterparty_binding
produces application-layer, signed, replay-after-the-fact evidence
answering that question. Topologies where the intermediary
terminates TLS (CDN edges, MCP servers, message buses, orchestrators)
defeat transport-layer integrity against the threat case of
Section 12.11; in those topologies counterparty_binding is the only
defence this profile offers, and the absence of channel-binding
evidence in the Audit Pack should be documented as a known residual.
12.13. Compromised Intermediary Between Two Honest Endpoints
This section is informative. Where an Action travels from a sending
agent A to a receiving agent B through one or more intermediary
processes M, and where M is compromised in such a way that M presents
byte sequence X to A and a different byte sequence X' to B, neither
A's nor B's cryptographic signature detects the divergence in
isolation: each endpoint signs the bytes it observed, and each
endpoint's per-agent hash chain per Section 5.4 remains internally
valid. Absent the counterparty_binding primitive this profile
introduces, the only available cross-agent primitive is action_ref as
a SHA-256 join key per Section 5.2.7; both A's chain and B's chain
remain valid in isolation, and divergence is only recoverable through
a regulator-driven post-hoc comparison of the two chains.
counterparty_binding introduced in Section 5.8 closes the case where
M silently swaps bytes between two honest endpoints A and B. An
acknowledging receipt under this binding is required to carry an
envelope_hash computed over the exact byte stream B received (SHA-
Gomes Marques Expires 25 March 2027 [Page 93]
Internet-Draft Compliance Receipts Profile September 2026
256(A's envelope) under the digest-scope rule of Section 5.8.1), as
specified normatively in Section 5.8.1. A verifier resolves
receipt_ref to A's stored envelope, recomputes the digest, and
compares; a mismatch indicates that the bytes B signed are not the
bytes A signed, and the acknowledging receipt is reported non-
conformant per Section 5.8.3. The binding is detective rather than
preventive: it does not stop M from performing the swap in flight,
but it produces signed, replay-after-the-fact evidence that the swap
occurred.
The following residuals remain and are not closed by
counterparty_binding alone. The list is intentionally honest about
the audit-time, not sign-time, nature of the detective evidence: a
verifier resolves receipt_ref to A's retained envelope and recomputes
the digest at audit time, so any residual reasoning that depends on
"A is not in the loop at sign time" is rhetorical, not relevant.
* Collusion of M and B. If M and B are jointly compromised, M swaps
the bytes in flight and B issues an acknowledging receipt carrying
an envelope_hash computed over the altered bytes that B signs as
if they were A's. Under counterparty_binding the audit-time
verifier resolves receipt_ref to A's retained envelope and
recomputes the digest, so the binding is reported non-conformant
when A's storage is honest and reachable; M+B collusion alone does
NOT silently succeed. M+B collusion silently succeeds only when
the collusion ALSO extends to corrupting A's retained envelope,
suppressing A's chain segment, or making A's storage unreachable
to the auditor; that is, the true residual is M+B+(A's-storage
compromise or unavailability). Operator mitigation: anchor A's
chain on independent witnesses (combined [RFC3161] +
[OPENTIMESTAMPS] anchors per Section 5.5, and OPTIONAL deployer-
operated transparency logs) so that A's anchored chain-segment
digests are independently recoverable from public evidence;
regulator-side comparison of A's anchored chain against B's stored
chain detects the divergence even when A's local storage is
impeached.
* Collusion of M and A. If M and A are jointly compromised, A signs
a fabricated envelope at M's direction and M relays it to B; B
verifies M's relay normally, B's counterparty_binding correctly
digests the bytes A signed, A's per-agent chain validates, and B's
per-agent chain validates. Every cryptographic invariant in this
profile holds because the binding correctly attests that the bytes
B received were the bytes A signed; the fraud is in A's intent,
not in any byte mismatch. This residual is fundamentally outside
the receipt model's threat surface: no application-layer
cryptographic primitive in this profile distinguishes a fraudulent
A-signed envelope from an honest A-signed envelope when M is also
Gomes Marques Expires 25 March 2027 [Page 94]
Internet-Draft Compliance Receipts Profile September 2026
colluding to corroborate plausibility (relay logs, timestamping,
message ordering). Operator mitigation: separation of duties
between issuer (A) and intermediary (M) so that the same operator
cannot control both signing keys and relay logs; anchor evidence
on independent witnesses under different trust roots so that an
attacker controlling A and M still cannot retroactively coordinate
anchor inclusion across uncolluding timestamping authorities; out-
of-band attestation by the regulator or auditor of A's operational
context (provenance, code signing, runtime attestation) where the
policy regime authorises it.
* Compromise of B itself. A B that has been compromised (private
key extraction, supply-chain compromise, or insider operation) can
sign any envelope_hash the attacker chooses; counterparty_binding
proves only that the signing key acknowledged some bytes, not that
those bytes match what an honest B would have observed.
* Loss of A's stored envelope. counterparty_binding requires the
verifier to resolve receipt_ref to A's signed envelope; if A's
chain segment is unavailable (retention discipline failure, key
rotation orphan, deliberate withholding), the binding becomes
unverifiable and the receipt is reported non-conformant on
liveness grounds rather than on byte-equality grounds. An
adversary who can arrange A-envelope unavailability and then re-
emit colluding bytes can degrade the binding from a byte-equality
check to a liveness-loss flag.
* Anchor stripping by the intermediary. Because the anchors array
is outside the issuer's signature, M can remove entries from what
it relays, and B sees a receipt carrying fewer witnesses than A
emitted. This is a reduction, not a forgery: each surviving entry
still re-verifies against SHA-256(JCS(envelope_minus_anchors)),
and M cannot fabricate an entry that does so without the
cooperation of a timestamp authority or the Bitcoin chain. The
visible effect is that a witness_policy quorum A believed it had
satisfied may not be satisfiable from B's copy. Operator
mitigation: the holder's retained copy and the Audit Pack manifest
record the anchors as issued, so a stripped relay is detectable by
comparison at audit time rather than by B in flight.
Operators concerned about these residuals in the absence of single-
point cryptographic defense should:
* Anchor receipts to multiple independent witnesses. Where both
[RFC3161] and [OPENTIMESTAMPS] anchors are present per
Section 5.5, a coordinated M-B collusion attack must also induce
both timestamping authorities to anchor the colluding bytes within
the operator's anchor interval, raising the conjunction-cost of
Gomes Marques Expires 25 March 2027 [Page 95]
Internet-Draft Compliance Receipts Profile September 2026
the attack. Operators may add further anchors (e.g. a Deployer-
operated transparency log or a witness service) without changing
the wire format defined here.
* Use side-by-side chain comparison under regulator subpoena. The
audit-trail alternative semantics established for SEC 17a-4
recordkeeping (see Section 8.6.1) and the post-market surveillance
regime of EU AI Act Articles 12 and 26 (see Section 7.1 and
Section 7.2) authorise the regulator to compel both A's and B's
Audit Packs and to reconstruct the relay by joining on action_ref
per Section 5.2.7. counterparty_binding reduces the regulator's
workload from "compare both chains and detect divergence" to
"verify B's bound digest against A's stored envelope"; the
underlying subpoena-and-compare workflow remains the regulator's
ultimate authority and remains operative when the binding is
unverifiable.
* Document M's relay logs out-of-band. Where the intermediary M is
identifiable (a named MCP server, message bus, orchestrator, or
relay), the operator should require M to produce signed relay logs
covering the time window of the Action and should submit those
logs to the same Audit Pack production layer as A's and B's
chains. Out-of-band relay logs do not require a wire-format
change in this profile; they are operational evidence that
complements counterparty_binding rather than replacing it.
Detection depends on the selected anchoring schedule, successful
commitment, monitoring and availability of the evidence needed for
comparison. The selected profile MUST state these assumptions. No
fixed detection interval is established here by DORA, NYDFS Part 500
or CIRCIA, and an anchor alone does not guarantee recovery of records
that are unavailable.
12.14. What a Compliance Receipt Does Not Prove
The preceding subsections state the residual attacks case by case.
This subsection consolidates the limits of the artifact itself, so
that a regulator or auditor appraising a Compliance Receipt does not
credit it with guarantees the format does not provide. A Compliance
Receipt, even one that passes every check of Section 11.2, does not
prove any of the following.
* That the Action was executed, completed, or produced any outcome,
or that its effect occurred exactly once. A receipt binds the
issuer's recorded claims and committed bytes; it does not
independently prove that those bytes passed through a named agent.
Timestamp evidence establishes only the time property of its
authenticated construction. For example, an RFC 3161 token
Gomes Marques Expires 25 March 2027 [Page 96]
Internet-Draft Compliance Receipts Profile September 2026
supports the existence of committed data by the stated time under
the TSA trust policy, not the Action's execution at that exact
time ([RFC3161]). A fresh nonce distinguishes receipt emissions,
not effects. The optional duplicate-emission observation under
Section 12.8 is not a count of executed effects. Effect
idempotency is the receiving system's responsibility.
* That two byte sequences are semantically equivalent under a
downstream tool. The chain layer checks commitments to canonical
bytes under its cryptographic assumptions; keyword case folding,
path normalization, Unicode normalization, and numeric tolerance
are out of scope per Section 4.
* That the policy was correct, lawful, complete or retained.
policy_digest commits a digest value. Only resolving and
recomputing the artifact under Section 5.3.2 establishes its
correspondence to that value; the digest alone proves neither
availability nor retention. Policy suitability and retention
require separate evidence.
* That the execution environment was intact. The core receipt
signature does not establish environment integrity. The optional
claims in Section 5.16 are appraised separately under an explicit
trust policy and remain limited by their provenance and coverage.
* That the issuer has a particular real-world identity merely
because a signature verifies. Section 5.2.5 requires independent
key-to-principal authorization. The resulting identity assurance
is limited by that trust policy and its evidence; an opaque
identifier or a self-supplied Audit Pack key cannot establish it.
* That the signing key remained uncompromised, or that the endpoints
did not collude. Signature validity is bounded by the revocation
discipline of Section 12.4, and the collusion and key-compromise
residuals are stated in Section 12.11 and Section 12.13.
* That a declared constraint was enforced at runtime. An expires_at
claim does not itself stop execution (Section 5.9). The producer-
asserted fields in Section 5.15, Section 5.12 and Section 5.14
bind the producer's assertions, including its asserted time; they
do not independently establish those assertions or their timing.
A voluntary-tier attestation is not a capture and is not
unbypassable (Section 9.5).
* That the Action was prevented in real time. The receipt is
detective, audit-time evidence; it does not block in-flight bytes
(Section 12.11).
Gomes Marques Expires 25 March 2027 [Page 97]
Internet-Draft Compliance Receipts Profile September 2026
* That the artifact is tamper-proof. Signature and link checks
detect changes inconsistent with the presented signatures and
commitments. Detecting removal, replacement or re-signed history
also depends on independently retained receipts, authenticated
checkpoints or anchors under Section 12.1. A self-consistent
replacement history cannot be distinguished solely by verifying
its newly produced signatures. These checks reveal specified
inconsistencies; they do not prevent alteration or omission.
* That the receipt is neutral third-party attestation. The
producer's signature binds its claims. Counterparty or
environment signatures can bind assertions by separately
authorized parties, within their stated scopes, but a separate or
unaffiliated signer does not by itself establish independent
observation or the truth of every claim. A report identifies the
attester, asserted fact, verification scope and trust evidence
(Section 12.11).
* That the underlying transaction was delivered, settled or
otherwise reached commercial finality. Delivery, settlement and
payment finality are out of scope. When cited alongside a
payment-gate format such as [DRAFT-HOPLEY-X402], the receipt
supplies only its stated action-side claims and evidence.
* That every Action produced a receipt. A chain that passes every
mandatory check of Section 11.2 establishes the checked signature
and link relationships among the receipts presented; it is silent
about an Action for which no receipt was ever minted. Selective
omission is therefore invisible to chain integrity: an omitted
Action leaves the chain verifying exactly as it would if the
Action had never occurred, because the counter of Section 5.2.11
advances only when a receipt is minted and so cannot register an
Action that produced none. Counters reveal internal
discontinuities or repeats. Detecting a missing prefix or tail
requires an authenticated boundary, checkpoint or independently
retained receipt. Where the counter is absent, which stays
conformant, a truncated tail is still itself a valid chain, and
the anchors of Section 5.5 fix the presented receipts in time
without revealing that later ones were withheld. Completeness
comes from deployment, not from the format. Fail-closed capture
(Section 9.5) refuses the Action when no receipt can be minted,
and an Acceptor (Section 2) refuses to act on an Action that
arrives without a verifiable receipt. The issuer evidences the
gaps it can itself observe: a signer outage through unsigned_gap
(Section 5.6), and a blocked emission through the
chain_emission_blocked lifecycle receipt (Section 12.3).
Independent custody of later receipts, whether by a counterparty
whose counterparty_binding (Section 5.8) digests them, by the
Gomes Marques Expires 25 March 2027 [Page 98]
Internet-Draft Compliance Receipts Profile September 2026
Acceptor that gated on them, or by the holder of an Audit Pack
(Section 10) covering them, turns a truncated tail from invisible
into contradicted. [ASQAV-SDK] carries these cases as conformance
vectors (asqav-14-omitted-action-chain, asqav-15-unsigned-gap, and
asqav-16-chain-emission-blocked); these illustrate that chain
integrity alone cannot detect an unrecorded Action and that a
signed gap report can remain structurally conformant. Their
fixture outcomes are not a substitute for the required checks of a
selected production policy.
13. IANA Considerations
This document requests one allocation from an existing IANA registry,
and requests no new IANA registry. The allocation is the
counterparty_binding CWT claim of Section 13.2, which Section 2 of
[RFC8726] permits an Independent Submission to request because the
registry already exists and the document follows its assignment
policy.
This Independent Stream document requests no new IANA registry. RFC
8726 generally prohibits new IANA registries for this stream, with a
narrow exception for subcode registries tied to an allocated code
point. That exception does not establish authority for the
standalone tables here. These are externally maintained profile
tables. Any future IANA request must satisfy the applicable
registration policy and publication procedure. See [RFC8726].
Administration therefore sits outside IANA, at
https://github.com/jagmarques/asqav-registry, whose registration
process is published at https://github.com/jagmarques/asqav-
registry/blob/79f5d28fd132c97bc4a5eae02a2bafce72b145af/
REGISTRATION.md. That is a commit-pinned citation of the procedure
this document was written against, so a reader can retrieve the exact
text; the living procedure is maintained on the repository default
branch and a later revision of it does not change what this document
specifies. The tables below remain the normative definition of the
initial contents; the external registry administers additions and
never overrides this document for an entry defined here. A future
proposal to move these external tables to IANA would require an
explicit registration request under the applicable procedures and
approvals. Section 6 of [RFC8726] concerns transfer of control of an
existing IANA registry between streams; it does not itself authorize
migration of these external tables.
Gomes Marques Expires 25 March 2027 [Page 99]
Internet-Draft Compliance Receipts Profile September 2026
13.1. Regime Mapping Vocabulary
The following identifiers have distinct scopes. They do not
establish legal applicability or compliance, and they do not add
signed-payload fields.
* colorado_ai: retained compatibility key for the Colorado mapping.
In this revision its mapping concerns SB 26-189, as described in
Section 8.2. Interpret historical evidence with its recorded
mapping revision, legal-source edition and applicable decision
date; do not rewrite signed bytes or silently reinterpret an
earlier statutory mapping.
* colorado_admt: source-mapping identifier for the SB 26-189
mapping, not a new wire alias for colorado_ai.
13.2. Compliance Receipt Extension Fields Registry
This table defines the extension fields of this profile. It is
administered at the external registry named in Section 13 under the
registry title "Compliance Receipt Extension Fields", and is not a
requested IANA registry.
This registry covers both signed-payload fields and envelope-level
fields (siblings of payload and signature), as well as declarations
that govern signing but never appear on the wire; each entry's Scope
value identifies which.
Each entry contains:
* Field Name: the exact, case-sensitive JSON object key. New names
use lowercase ASCII letters, digits and underscore; the initial
entry previousReceiptHash preserves its established spelling.
* Scope: one of signed-payload, envelope-level, signing-time
declaration, or anchor entry, disambiguating fields inside the
signed payload from envelope-level fields, from declarations that
are not wire members, and from members carried inside an entry of
the anchors array rather than at the top level of the receipt.
* Description: a one-line summary of the field's purpose.
* Reference: the document that defines the field's semantics.
* Vocabulary: a URL or registry pointer for the controlled
vocabulary that field values are drawn from, or "free-form" if
none.
Gomes Marques Expires 25 March 2027 [Page 100]
Internet-Draft Compliance Receipts Profile September 2026
* Change Controller: the party authorized to request changes to the
entry. For the initial entries defined by this Independent
Submission, it is the document author identified in the front
matter. This designation does not imply IETF ownership or
endorsement.
A registration is accepted when the field name does not collide with
a common field defined in Section 5.2 or a field already present in
this table, the Reference is a stable and dereferenceable
specification, and the Vocabulary is documented sufficiently for an
independent verifier to validate values. These are this external
registry's review criteria. They do not appoint an IANA Designated
Expert or establish an IANA registration policy. Registrations are
made through the published registration process and are reviewed
against these criteria in public.
Initial registry contents:
* seq - Scope: signed payload. Optional positive integer in the
single issuer chain. Continuity exposes an inconsistency within
observed evidence; it does not prove withholding or reveal an
omitted tail without a later trusted checkpoint. Defined in
Section 5.2.11.
* risk_class - Scope: signed-payload - Risk classification term
under the Deployer's risk management documentation; defined in
Section 5.7 - This document - Vocabulary referenced in Audit Pack
metadata.
* incident_class - Scope: signed-payload - Incident classification
term spanning DORA Article 18(1) (with further specification in
[REG-2024-1772] and the canonical reporting enumeration of Annex
II field 3.23 of [REG-2025-302]), 23 NYCRR 500.1 Cybersecurity
Event/Incident, [CIRCIA] Covered Cyber Incident subject to the
operative-rule conditions of the provisional mapping in
Section 8.7, and HIPAA security incident under 45 CFR 164.304;
defined in Section 5.7 - This document - Audit Pack metadata.
* counterparty_binding - Scope: signed-payload - Signed-payload
object carrying a base64url-encoded SHA-256 digest (envelope_hash)
of a peer agent's envelope-minus-anchors object, which includes
that peer's signature bytes and excludes its anchors array, a
REQUIRED digest-scope declaration (scope, whose only defined value
is envelope_minus_anchors and whose absence marks a legacy binding
under the superseded three-key scope of revisions -04 through
-08), a resolvable opaque locator (receipt_ref), an optional
expected-acknowledger identifier (expect_ack_from), and an
optional operational transport_label; see Section 5.8 for the full
Gomes Marques Expires 25 March 2027 [Page 101]
Internet-Draft Compliance Receipts Profile September 2026
member set and the digest-scope rule - This document - Member
vocabulary defined in Section 5.8.1, including the scope value set
{envelope_minus_anchors}; digest algorithm is SHA-256 under
Section 5.8.1 with base64url encoding per [RFC4648] Section 5.
* result_digest - Scope: signed-payload - JSON string in the self-
describing form sha256:<64 lowercase hex chars> carrying a SHA-256
digest of the downstream Action's result body. It is not an
object and does not carry the payload_digest members size or
preview; defined in Section 5.9 - This document - Digest algorithm
is SHA-256 with hex encoding under the sha256:<64 hex> form.
* expires_at - Scope: signed-payload - RFC 3339 timestamp with an
explicit UTC offset declaring the wall-clock time after which the
producing system considers the decision result stale and not safe
to replay; declared, not enforced, against the receipt itself (the
receipt record never expires); defined in Section 5.9 - This
document - RFC 3339 JSON string with an explicit UTC offset.
* nonce - Scope: signed-payload - Producer-generated string unique
across the producer's emission stream for the lifetime of kid;
defined in Section 5.9 - This document - Any unique string; the
lowercase hexadecimal encoding of 12 random bytes (24 hexadecimal
characters) is the recommended form.
* hash_algo - Scope: signed-payload - Member of the payload
recording how the receipt's context digest was produced; sha256
denotes an unkeyed SHA-256 digest and hmac-sha256 an HMAC-SHA256
keyed digest under a holder salt; the hash-only hash member keeps
the sha256:<64 hex> wire form in both cases and the algorithm is
read from hash_algo, never from the label; defined in Section 11.5
- This document - Value vocabulary {sha256, hmac-sha256} per
Section 11.5.
* tool_fingerprint - Scope: signed-payload - JSON string of 32
lowercase hex characters carrying the truncated (first 128 bits)
SHA-256 digest of the JCS-canonical ([RFC8785]) serialization of
the JSON object {"tool_name": <tool name>, "schema": <declared
input schema>}; defined in Section 5.9 - This document - Digest
algorithm is SHA-256 over [RFC8785] canonical bytes, truncated to
its first 32 hexadecimal characters.
* config_manifest_digest - Scope: signed-payload - JSON string
formatted sha256:<64 hex> over the canonical bytes of the
producer's configuration manifest in effect at signing time;
defined in Section 5.9 - This document - Manifest content is
operator-defined; canonicalization rule is operator-declared in
the Audit Pack manifest entry.
Gomes Marques Expires 25 March 2027 [Page 102]
Internet-Draft Compliance Receipts Profile September 2026
* cve_inventory_digest - Scope: signed-payload - JSON string
formatted sha256:<64 hex> over the canonical bytes of the
producer's CVE inventory at signing time; defined in Section 5.9 -
This document - Inventory content lists CVE identifiers per the
producer's accepted-residual rationale.
* executable_hash - Scope: signed-payload - JSON string formatted
sha256:<64 hex> identifying the exact OCI image manifest or
observed binary file under the digest and evidence rules of
Section 5.10; defined in Section 5.10 - This document - Digest
algorithm is SHA-256.
* sbom_digest - Scope: signed-payload - JSON string formatted
sha256:<64 hex> over the canonical bytes of the CycloneDX or SPDX
SBOM document covering the executing image; defined in
Section 5.10 - This document - SBOM format, exact version and
digest input rule declared in the Audit Pack manifest entry;
current-profile JCS and explicit legacy handling are defined in
Section 5.10.
* slsa_provenance_pointer - Scope: signed-payload - JSON string
carrying an https URL resolving to the SLSA provenance attestation
envelope for the build of the executable identified by
executable_hash; defined in Section 5.10 - This document - Target
should be the SLSA Provenance v1.0 in-toto statement form.
* supply_chain_pointer - Scope: signed-payload - JSON string
carrying an HTTPS URL for transparency-log evidence concerning the
build artifact identified by executable_hash; defined in
Section 5.10 - This document - Supported log and entry format,
artifact binding and authenticated inclusion evidence are checked
under the selected verification policy.
* anchors - Scope: envelope-level - Envelope-level array of
timestamping anchors covering the signed envelope; entries carry a
required type discriminator (rfc3161 or opentimestamps;
transparency-log pointers are not anchor types) and a required
value field, plus optional informational members status (anchored
/ pending / failed) and anchor_block_hash (string Bitcoin block
hash for upgraded OpenTimestamps entries); full schema is defined
in Section 5.5 - This document - Anchor type vocabulary: rfc3161
per [RFC3161], opentimestamps per [OPENTIMESTAMPS].
* witness_policy - Scope: signed-payload - OPTIONAL quorum
declaration with required and distinct operator identifiers in
witnesses; authenticated threshold, missing-policy state and
independently trusted operator counting are defined in Section 5.5
- This document - Profile-specific witness policy.
Gomes Marques Expires 25 March 2027 [Page 103]
Internet-Draft Compliance Receipts Profile September 2026
* mitre_techniques - Scope: signed-payload - JSON array of MITRE
ATT&CK technique identifiers (for example T1059, T1078) self-
declared by the producer; not verifier-checked by the issuing
platform; flips framework_mappings_self_declared to true when
populated; defined in Section 5.15 - This document - Vocabulary
referenced by id from the MITRE ATT&CK enterprise matrix.
* mitre_atlas - Scope: signed-payload - JSON array of MITRE ATLAS
identifiers (for example AML.T0051) covering AI-system-specific
adversary techniques; self-declared; flips
framework_mappings_self_declared to true when populated; defined
in Section 5.15 - This document - Vocabulary referenced by id from
the MITRE ATLAS catalogue.
* owasp_llm_top10 - Scope: signed-payload - JSON array of OWASP Top
10 for LLM Applications identifiers (edition-qualified, for
example LLM01:2025; a bare LLM01 is rejected); self-declared;
flips framework_mappings_self_declared to true when populated;
defined in Section 5.15 - This document - Vocabulary referenced by
id from the OWASP Top 10 for LLM Applications publication.
* owasp_agentic_top10 - Scope: signed-payload - JSON array of OWASP
Top 10 for Agentic Applications 2026 identifiers; the exact
edition and identifier convention are defined in Section 5.15;
self-declared; flips framework_mappings_self_declared to true when
populated - This document.
* nist_ai_rmf - Scope: signed-payload - JSON array of NIST AI Risk
Management Framework function identifiers and subcategories (for
example GOVERN-1.1, MEASURE-2.7); self-declared; flips
framework_mappings_self_declared to true when populated; defined
in Section 5.15 - This document - Vocabulary referenced from NIST
AI RMF 1.0.
* iso_42001 - Scope: signed-payload - JSON array of ISO/IEC
42001:2023 control identifiers (for example A.6.2.6); self-
declared; flips framework_mappings_self_declared to true when
populated; defined in Section 5.15 - This document - Vocabulary
referenced from ISO/IEC 42001:2023.
* eu_ai_act_articles - Scope: signed-payload - JSON array of EU AI
Act article identifiers (for example Article-12, Article-15,
Article-50); self-declared; flips framework_mappings_self_declared
to true when populated; defined in Section 5.15 - This document -
Vocabulary referenced from [EU-AI-ACT].
Gomes Marques Expires 25 March 2027 [Page 104]
Internet-Draft Compliance Receipts Profile September 2026
* rfc3161_timestamp - Scope: signed-payload - JSON string carrying a
base64-encoded RFC 3161 TimeStampResp (DER) supplied by the
producer at signing time and preserved verbatim on the receipt for
offline TSA chain verification independent of any platform-issued
anchors; payload entry is an opaque caller-supplied token, not the
per-receipt anchor produced by the platform; defined in
Section 5.15 - This document - Bytes are an RFC 3161 TimeStampResp
per [RFC3161]; base64 encoding per [RFC4648].
* framework_mappings_self_declared - Scope: signed-payload - JSON
boolean false-attestation guard set by the issuing platform to
true whenever any of mitre_techniques, mitre_atlas,
owasp_llm_top10, owasp_agentic_top10, nist_ai_rmf, iso_42001, or
eu_ai_act_articles is populated; a producer-supplied value of
false alongside a populated taxonomy field is overridden by the
issuing platform; defined in Section 5.15 - This document -
Boolean.
* authorized_under_mandate - Scope: signed-payload - Server-built
object recording a self-declared authorizing mandate the Action
was signed under; carries required mandate_id, required issuer_id,
a required scope_digest formatted sha256:<64 hex> over the
mandate's authorized-action-types scope, and a required verified
boolean whose only conformant value is true, asserting self-
declared issuer authority (the same trust level as
framework_mappings_self_declared, never issuing-platform-verified
third-party authorization); a present-but-malformed object,
including one carrying verified=false, is rejected at signing time
by the false_mandate_attestation_guard; defined in Section 5.11 -
This document - Member vocabulary defined in Section 5.11;
scope_digest digest algorithm is SHA-256.
* controls_evaluated - Scope: signed-payload - Server-built object
enumerating the enforcement controls that genuinely fired on this
sign plus the allow result; member keys are a closed set
(emergency_halt, delegation_scope, quorum, mandate, policy,
content_scan, result) and an unknown key is rejected; a key is
present only when its control ran (omission-over-false
attestation), quorum requires fired=true plus a 64-hex
attestation_hash, and a policy member asserting evaluation
requires matched_count at least 1; a caller-supplied value is
dropped before signing (the false_control_attestation_guard);
defined in Section 5.11 - This document - Control-key vocabulary
defined in Section 5.11.
* approver_id - Scope: signed-payload - Producer-asserted identity
(bare kid or issuer_id) that authored a risk acceptance on a
protectmcp:lifecycle:risk_acceptance receipt; a FIELD bound into
Gomes Marques Expires 25 March 2027 [Page 105]
Internet-Draft Compliance Receipts Profile September 2026
the signed bytes with NO authority check, NO authentication, and
NO identity resolution performed by the issuing platform, only the
string-equality refusal against initiator_id applied to Compliance
Receipts (the risk_acceptance_self_approval_guard); required on
the receipt type and enforced by the
risk_acceptance_missing_required_field false-attestation guard;
defined in Section 5.12 - This document - Bare-identifier form per
Section 5.2.5.
* judged_action_refs - Scope: signed-payload - Non-empty array of
action_ref values naming the receipts an oversight ruling judges;
REQUIRED on protectmcp:lifecycle:oversight_ruling and enforced at
signing time; an entry that does not resolve is a non-conformance
of the ruling receipt and not of any judged receipt; defined in
Section 5.13 - This document - Values are action_ref digests per
Section 5.7.
* ruling - Scope: signed-payload - The human ruling recorded by an
oversight ruling receipt; REQUIRED on
protectmcp:lifecycle:oversight_ruling and enforced at signing
time; defined in Section 5.13 - This document - One of confirm,
override, escalate, flag.
* ruling_reason - Scope: signed-payload - OPTIONAL machine-readable
reason code accompanying a ruling; defined in Section 5.13 - This
document - Vocabulary referenced in Audit Pack metadata.
* reviewer - Scope: signed-payload - Object naming the natural
person who ruled, by opaque principal and role, with an OPTIONAL
attestation whose method and evidence record how that person was
authenticated; REQUIRED on protectmcp:lifecycle:oversight_ruling;
absent attestation, or method manual_assertion, leaves the human-
review claim unverified; defined in Section 5.13 - This document -
method is one of sso, hardware_key, signed_statement,
manual_assertion.
* initiator_id - Scope: signed-payload - Producer-asserted identity
(bare kid or issuer_id) that requested the acceptance; a FIELD
bound into the signed bytes; for a Compliance Receipt a value that
string-equals approver_id is refused at signing time by the
risk_acceptance_self_approval_guard (a string-incoherence check,
not identity resolution; an absent field never fires it); defined
in Section 5.12 - This document - Bare-identifier form per
Section 5.2.5.
* acceptance_reason - Scope: signed-payload - Free-text producer
rationale for accepting a risk; binds the issuer to the recorded
rationale and asserted issued_at, never parsed or scored; required
Gomes Marques Expires 25 March 2027 [Page 106]
Internet-Draft Compliance Receipts Profile September 2026
on the risk-acceptance receipt type and enforced by the
risk_acceptance_missing_required_field guard; defined in
Section 5.12 - This document - Free-form string.
* accepted_at - Scope: signed-payload - Producer-asserted
acceptance-authoring time, encoded as an RFC 3339 JSON string with
an explicit UTC offset; distinct from the asserted receipt
issuance time and any independently verified anchor time evidence;
defined in Section 5.12 - This document - RFC 3339 string with
explicit UTC offset.
* supersedes - Scope: signed-payload - Producer-asserted pointer
(opaque receipt locator OR sha256:<64 hex>) to the prior risk-
acceptance receipt this one replaces; binds the supersession claim
and asserted issued_at; the issuing platform NEVER invalidates the
prior receipt (the recorded signed bytes remain unchanged; this
later statement points to the earlier receipt); defined in
Section 5.12 - This document - Opaque locator or sha256:<64 hex>
digest.
* sarif_digest - Scope: signed-payload - JSON string formatted
sha256:<64 hex> over the producer-declared canonical bytes of the
SARIF scan artifact the acceptance rested on; a producer-supplied
commitment whose syntax alone establishes neither the artifact's
existence nor its existence at the asserted time; the issuing
platform NEVER parses, fetches, re-runs, or validates the scan;
defined in Section 5.12 - This document - Digest algorithm is SHA-
256; canonicalization rule declared in the Audit Pack manifest
entry.
* finding_ref - Scope: signed-payload - Producer-asserted opaque
free-text pointer to a finding or rule id inside the SARIF
artifact; binds the asserted reference and issued_at, never
resolved or validated; defined in Section 5.12 - This document -
Free-form string.
* approval_ref - Scope: signed-payload - Producer-asserted opaque
free-text correlation pointer to a human-in-the-loop approval id
or external ticket; binds the asserted pointer and issued_at,
never resolved or validated; defined in Section 5.12 - This
document - Free-form string.
* risk_snapshot - Scope: signed-payload - Object carrying a
producer-asserted point-in-time snapshot of THIRD-PARTY risk
signals (snapshot_at, snapshot_source, optional epss, cvss,
cvss_vector, kev_listed, cve_ids); the issuing platform does NOT
fetch, compute, verify, query, or vouch for these values, and the
snapshot is explicitly NOT reproducible from any input the
Gomes Marques Expires 25 March 2027 [Page 107]
Internet-Draft Compliance Receipts Profile September 2026
platform holds; numerics are strings (floats prohibited per
Section 4) and snapshot_source is required whenever any of epss,
cvss, cvss_vector, or kev_listed is populated (a populated signal
without it is rejected at signing time by the
risk_snapshot_numeric_requires_snapshot_source guard) so a value
can never be read as a platform-derived or verified score; defined
in Section 5.12 - This document - Third-party feed vocabulary
named per-receipt in snapshot_source; the platform defines no
controlled vocabulary for the signal values.
* repo_ref - Scope: signed-payload - Producer-asserted opaque
pointer to the repository a change was authored against, carried
on a protectmcp:lifecycle:code_authorship receipt; required on the
receipt type and enforced by the
code_authorship_missing_required_field false-attestation guard;
free-text, binds the asserted reference and issued_at, never
resolved, cloned, or validated by the issuing platform; defined in
Section 5.14 - This document - Free-form string.
* commit_sha - Scope: signed-payload - Producer-asserted commit
identifier of the authored change; required on the receipt type
and enforced by the code_authorship_missing_required_field false-
attestation guard; bound into the signed bytes only, NEVER fetched
or verified by the issuing platform, binds the producer assertion
and asserted issued_at; defined in Section 5.14 - This document -
Free-form string.
* base_sha - Scope: signed-payload - Producer-asserted base commit
identifier the change was authored on top of; bound into the
signed bytes only, NEVER fetched or verified by the issuing
platform; defined in Section 5.14 - This document - Free-form
string.
* change_digest - Scope: signed-payload - JSON string formatted
sha256:<64 hex> over the producer-declared canonical bytes of the
change; a producer-supplied commitment whose syntax alone
establishes neither the artifact's existence nor its existence at
the asserted time; the issuing platform NEVER fetches, re-diffs,
or re-computes the change; a value outside the sha256:<64 hex>
wire form is rejected at signing time by the
change_digest_not_sha256_wire_form guard; defined in Section 5.14
- This document - Digest algorithm is SHA-256; canonicalization
rule declared in the Audit Pack manifest entry.
Gomes Marques Expires 25 March 2027 [Page 108]
Internet-Draft Compliance Receipts Profile September 2026
* change_ref - Scope: signed-payload - Producer-asserted opaque
free-text pointer to the change as a unit (for example a pull-
request id); binds the asserted reference and issued_at, never
resolved or validated; defined in Section 5.14 - This document -
Free-form string.
* change_approval_ref - Scope: signed-payload - Producer-asserted
opaque free-text correlation pointer to a human-in-the-loop
approval id or external review ticket for the change; binds the
asserted pointer and issued_at, never resolved or validated;
defined in Section 5.14 - This document - Free-form string.
* change_class - Scope: signed-payload - Producer-asserted class of
the change drawn from the closed vocabulary read, write, delete,
execute, deploy; self-declared, the issuing platform records but
does NOT verify the change matches the class; a value outside the
closed vocabulary is rejected at signing time as an out-of-
vocabulary value; defined in Section 5.14 - This document - Closed
vocabulary {read, write, delete, execute, deploy}.
* authored_by - Scope: signed-payload - Object carrying a producer-
asserted description of the authoring agent (agent_id, model_id,
model_version, tool, attestation_source); the issuing platform
does NOT verify the named model; attestation_source is required
whenever model_id or model_version is populated (a populated model
field without it is rejected at signing time by the
authored_by_model_requires_attestation_source guard) so a model
claim can never be read as a platform-verified attestation;
defined in Section 5.14 - This document - Member vocabulary
defined in Section 5.14; the platform defines no controlled
vocabulary for the member values.
* unsigned_gap - Scope: signed-payload - Server-built object
evidencing a signer outage that preceded this receipt: count
(REQUIRED integer greater than or equal to 1, the number of
Actions the issuer attempted to sign and could not while the
signer was unavailable), from and to (REQUIRED ISO 8601 timestamps
with explicit timezone bounding the outage, with from not later
than to). Absent when no outage preceded the receipt. The member
is populated by the issuing platform from its own signer-failure
tally, never carried in the producer's signing request, and a
caller-supplied value MUST be dropped before signing. It makes a
gap in the Action stream evidenced rather than silent: the chain
links only receipts that exist, so without this member an Action
for which no receipt could be minted leaves no trace. A verifier
MUST NOT read the member as an assertion that the unsigned Actions
were policy-evaluated; defined in Section 5.6 - This document -
count is a JSON integer; timestamps follow [RFC3339].
Gomes Marques Expires 25 March 2027 [Page 109]
Internet-Draft Compliance Receipts Profile September 2026
* The entries that follow are IMPLEMENTATION MEMBERS. Every one is
signed into receipts the reference issuing platform emits today,
and each is registered here because a registry that omits what the
wire carries understates the signed surface a verifier must
preserve byte-for-byte under Section 5.7.
* action_id - Scope: signed-payload - REQUIRED JSON string carrying
the issuing platform's identifier for the Action the receipt
covers, in the form act_<opaque>. It is an identifier, never a
digest, and MUST NOT be read as one; the digest of the Action is
action_ref. - This document - Implementation member of the
reference issuing platform; carried under the signature on
production receipts.
* agent_id - Scope: signed-payload - REQUIRED JSON string
identifying the agent within the issuing platform, in the form
agt_<opaque>. It is not globally unique and does not establish
issuer or key authority. The local meaning applies to every
selected receipt type without importing additional fields from
another draft. - This document.
* org_id - Scope: signed-payload - REQUIRED JSON string carrying the
identifier of the organization the signing agent belongs to, as a
UUID. It is an internal tenancy identifier and is NOT the legal-
entity identifier a verifier resolves; that is issuer_id. A
verifier MUST NOT resolve a key through this member. - This
document - Implementation member of the reference issuing
platform; carried under the signature on production receipts.
* action_type - Scope: signed payload. Presence is mode-
conditioned: required for the defined payload mode; not a member
emitted by the defined hash mode. Unsupported or malformed mode
combinations are not silently repaired. Defined in Section 5.2.2.
* context - Scope: signed-payload - OPTIONAL JSON object carrying
the Action's input as the producer supplied it. Most receipts
omit it and carry only payload_digest, which is the privacy-
preserving default; when both are present the recomputation of
Section 11.2 applies. An explicit JSON null reads as absent. -
This document - Implementation member of the reference issuing
platform; carried under the signature on production receipts.
* mode - Scope: signed payload. Both core modes use a nested signed
payload. Mode determines the required content and digest
interpretation; flat legacy inputs use a separately selected
adapter. Defined in Section 5.2.2.
Gomes Marques Expires 25 March 2027 [Page 110]
Internet-Draft Compliance Receipts Profile September 2026
* hash - Scope: signed payload. Hash-mode commitment string. Its
digest bytes equal payload_digest.hash under that mode; the former
has the retained prefix and the latter is unprefixed. Algorithm
interpretation follows the signed hash_algo and selected version.
Defined in Section 5.2.2.
* metadata - Scope: signed-payload - OPTIONAL JSON object carrying
operational annotations supplied by the producer or issuing
platform. The issuing platform may filter or interpret these
annotations before signing. The signature binds the retained
object; it does not establish that each annotation is true. - This
document - Implementation member of the reference issuing
platform; carried under the signature on production receipts.
* decision - Scope: signed payload. Required value governed by the
receipt type. Decision types record an actual policy evaluation;
defined no-policy types use observation. Defined in Section 5.3.
* policy_decision - Scope: signed-payload - OPTIONAL JSON string
carrying the policy engine's own verdict, for example permit. It
is the engine's vocabulary rather than this profile's, and a
verifier MUST NOT map it onto decision without the producer's
documented mapping. - This document - Implementation member of the
reference issuing platform; carried under the signature on
production receipts.
* receipt_type - Scope: signed-payload - OPTIONAL JSON string
mirroring type for implementations that read a distinct member.
Where both are present they MUST carry the same value, and a
receipt whose two members disagree is non-conformant. This entry
registers the receipt payload member ONLY. It is distinct from,
and shares nothing but its name with, the server-enforced
receipt_type member of the attestation statement predicate defined
in Section 9.3, whose value is drawn from authoritative or
observation and which never appears in a receipt payload. An
implementation MUST resolve the name by the object it appears in.
- This document - Implementation member of the reference issuing
platform; carried under the signature on production receipts.
* server_timestamp - Scope: signed-payload - REQUIRED on a hash-mode
Compliance Receipt and absent from the reference payload-mode
receipt, which carries timestamp in its place (see Section 5.2.2).
JSON string carrying an RFC 3339 timestamp with explicit timezone
assigned by the issuing platform for signing. The reference
platform assigns the same clock value to this member and
issued_at. This is a signed platform-clock assertion, not
independent evidence of the Action time or the completion of
signing; anchor evidence is evaluated separately under
Gomes Marques Expires 25 March 2027 [Page 111]
Internet-Draft Compliance Receipts Profile September 2026
Section 5.5. - This document - Implementation member of the
reference issuing platform; carried under the signature on
production receipts.
* derived_from - Scope: signed-payload - OPTIONAL JSON array of
parent lineage references naming the receipts a derived Action was
computed from. Each entry is a lineage reference object as
defined in Section 5.17, and the array MUST be byte-sorted by its
merkle_root member before signing so that independent producers of
the same child compute identical signed bytes. The member sits
inside the signature scope of Section 5.4, so re-pointing a parent
breaks the child's signature. It is omitted rather than emitted
empty when there is no parent. - This document - Implementation
member of the reference issuing platform; carried under the
signature on production receipts.
* timestamp - Scope: signed payload. Presence and meaning follow
the selected mode and version. Do not treat a payload-mode
requirement as universally optional or as an independently trusted
event time. Defined in Section 5.2.2.
* previousReceiptHash - Scope: signed-payload - REQUIRED on every
receipt including a chain's first, where it carries the all-zero
SHA-256 value of Section 5.4; an absent member, a JSON null and an
empty string are each a malformed chain link and never a genesis
marker. JSON string carrying the unprefixed lowercase hexadecimal
SHA-256 of the predecessor receipt under the chain scope of
Section 5.4. The member name is deliberately camel-case, matching
the deployed wire, and MUST NOT be normalized to snake case, which
would change the canonical bytes and break every signature. - This
document - Implementation member of the reference issuing
platform; carried under the signature on production receipts.
* tool_name - Scope: signed payload. Required for
protectmcp:decision and otherwise governed by the selected type
and mode. It is not universally optional. Defined in
Section 5.3.
Gomes Marques Expires 25 March 2027 [Page 112]
Internet-Draft Compliance Receipts Profile September 2026
* beacon_ref - Scope: signed-payload - OPTIONAL JSON object carrying
the reference platform's cached drand Quicknet beacon reference:
source (the string drand), chain (the 64-character lowercase
hexadecimal chain hash), round (a positive JSON integer),
signature (the 48-byte Quicknet BLS signature, encoded as 96
lowercase hexadecimal characters), and observed_at (an RFC 3339
timestamp recording when the platform cached the response). Its
evidence limits are defined in Section 5.5, Paragraph 11. It is
not an anchor and MUST NOT count toward the anchoring requirement
or a witness quorum. - This document - Implementation member of
the reference issuing platform; carried under the signature on
production receipts.
* v - Scope: signed payload. Required nested payload version for
the core format. Known shapes and legacy adapters are explicitly
selected. A version-2 canary does not define a released
production contract, and unknown versions are unverifiable.
Defined in Section 5.2.1.
* tsa_url - Scope: anchor entry - OPTIONAL producer-supplied string
naming the timestamp authority an rfc3161 anchor entry was
obtained from. It is an operational label only. A verifier MUST
NOT fetch it and MUST NOT treat it as a trust decision: a caller-
supplied URL naming its own timestamp authority is an assertion by
the party being checked, not evidence about it, and trust in a TSA
comes from key material the verifier holds independently per
Section 12.7 - This document - No vocabulary; the value is a JSON
string.
* key_thumbprint - Scope: signed-payload - Server-built JSON string
formatted sha256:<64 hex> carrying the RFC 7638 JWK Thumbprint of
the receipt's signing key, committing the receipt to the exact key
material so a key substituted under the same identifier is
detected at verification; a caller-supplied value is dropped
before signing; verifiers recompute the thumbprint of the resolved
key and report mismatch as non-conformant, while absence is the
legacy case and not itself a failure; defined in Section 5.2.10 -
This document - Digest algorithm is SHA-256 over the RFC 7638
canonical JWK form per [RFC7638].
Gomes Marques Expires 25 March 2027 [Page 113]
Internet-Draft Compliance Receipts Profile September 2026
* environment_attestation - Scope: signed-payload - Normative-
optional object carrying pre-action boolean environment-state
claims (claims) attested under a distinct environment key
(attester_kid, attested_at, detached sig over the attestation
object minus sig); informs the policy gate and the Audit Pack
evidence list but never replaces the gate; a stale or unverifiable
attestation is reported on its own axis; defined in Section 5.16 -
This document - Member vocabulary defined in Section 5.16; claim
names are free-form booleans.
* heartbeat_interval_seconds - Scope: signed-payload - Positive
safe-integer declared heartbeat interval; missing observations do
not prove missing actions. Defined in Section 5.18 - This
document - Profile-specific lifecycle evidence.
This document additionally requests that IANA register
counterparty_binding as a new claim in the "CBOR Web Token (CWT)
Claims" registry established by Section 9.1 of [RFC8392], with the
semantics defined in Section 5.8. The requested claim key is to be
allocated by IANA under the Specification Required policy of that
registry, from the integer range 256 to 65535 (or equivalently from
the range -65536 to -257); this document does not request a specific
value, so as not to consume the Standards Action space of the -256 to
255 range. The registration template of [RFC8392] Section 9.1.1 is
completed as follows.
Claim Name: counterparty_binding
Claim Description: Cross-agent envelope binding: an object carrying
a base64url-encoded SHA-256 digest of a peer agent's envelope-
minus-anchors object, which includes that peer's signature bytes
and excludes its anchors array, a REQUIRED digest-scope
declaration, a resolvable opaque locator for that envelope, and
optional members, as defined in the Counterparty Binding section
of the specification document below.
JWT Claim Name: N/A. The claim is specific to the compliance-
receipt envelope of this profile; no equivalent JWT claim exists.
Claim Key: To be allocated by IANA from the Specification Required
range.
Claim Value Type(s): Map (CBOR major type 5).
Change Controller: Joao Andre Gomes Marques, the document author
identified in the front matter.
Specification Document(s): This document, the section titled
Gomes Marques Expires 25 March 2027 [Page 114]
Internet-Draft Compliance Receipts Profile September 2026
"Counterparty Binding" (Section 5.8).
The JSON-form claim name is the literal string counterparty_binding
as registered above in the Compliance Receipt Extension Fields
Registry.
The environment_attestation field carries the environment-state
claims defined in Section 5.16. This document does not define a
dedicated RATS attestation-result format. A proposal to add such a
format would be reviewed under the external registration process in
this section and would need a stable specification of its semantics.
No new IANA registry or Designated Expert is created for that
purpose.
Anchor-entry metadata operator_id, tsa_url, status and
anchor_block_hash are scoped to the unsigned anchor object and have
the semantics in Section 5.5. They are not additional signed-payload
fields or independent trust assertions.
13.3. Compliance Receipt Type Namespaces Registry
This table defines the receipt type namespaces of this profile. It
is administered at the same external registry named in Section 13,
under the registry title "Compliance Receipt Type Namespaces", and is
not a requested IANA registry.
Each entry contains:
* Namespace: a colon-separated identifier prefix used as a value of
the type field, lowercase ASCII letters, digits, hyphen,
underscore, and colon.
* Description: a one-line summary of the receipt category.
* Reference: the document that defines the namespace.
A registration is accepted when the namespace does not collide with
any namespace already in this table, and the Reference is a stable
specification. As in Section 13.2, these are registration review
criteria applied through the published registration process rather
than an IANA registration policy.
Sub-namespaces are delegated to this registry: a namespace of the
form parent:suffix under a registered namespace (for example a
further sub-namespace under protectmcp:lifecycle or
protectmcp:observation) is registered by a request that names the
parent entry and the suffix, under the same registration review
criteria and with the same Change Controller as the parent entry.
Gomes Marques Expires 25 March 2027 [Page 115]
Internet-Draft Compliance Receipts Profile September 2026
Initial registry contents:
* protectmcp:acknowledgment - A receipt emitted by the acknowledging
party ("B") in a counterparty_binding pair under the emitter
behaviour of Section 5.8.2, carrying the counterparty_binding
object that digests the bound A-party envelope per Section 5.8 -
This document.
* protectmcp:decision - A receipt recording a policy evaluation
outcome (allow, deny, rate_limit) for an MCP-mediated tool call
where a policy was actually evaluated; observation is reserved to
protectmcp:lifecycle and protectmcp:observation per Section 5.3 -
This document.
* protectmcp:restraint - A receipt recording the application of an
enforcement restraint on an agent (e.g., quota, rate limit,
sandbox tightening); emission otherwise follows the decision path
of Section 5.3 - This document.
* protectmcp:lifecycle - A receipt recording an agent or system
lifecycle event (e.g., configuration change, key rotation,
oversight review, or a decision=observation record indicating an
Action was signed without policy evaluation per Section 5.3) -
This document.
* protectmcp:lifecycle:configuration_change - A receipt recording a
configuration change to an agent or producing system, including
changes that disable or re-enable receipt generation (see
Section 7.1.1); a registered sub-namespace under
protectmcp:lifecycle that the reference cloud implementation emits
today; a receipt of this type that lacks a well-formed
config_manifest_digest (Section 5.9) is rejected at signing time
per the type-bound presence rule of Section 5.9 - This document.
* protectmcp:lifecycle:risk_acceptance - A receipt recording a
producer's acceptance of a known risk, security finding, or policy
exception; a registered sub-namespace under protectmcp:lifecycle
that signs through the no-policy lifecycle path
(decision=observation, no policy evaluated) and carries the risk-
acceptance extension fields of Section 5.12 - This document.
Gomes Marques Expires 25 March 2027 [Page 116]
Internet-Draft Compliance Receipts Profile September 2026
* protectmcp:lifecycle:oversight_ruling - A receipt recording a
human ruling made about one or more previously recorded Actions,
referencing them by action_ref; a registered sub-namespace under
protectmcp:lifecycle that signs through the no-policy lifecycle
path (decision=observation, no policy evaluated) and carries the
oversight-ruling fields of Section 5.13. Absent a reviewer
attestation, the human-review claim it carries is unverified -
This document.
* protectmcp:lifecycle:code_authorship - A receipt recording a
producer's assertion that an agent-authored change to a code
repository existed at a point in time; a registered sub-namespace
under protectmcp:lifecycle that signs through the no-policy
lifecycle path (decision=observation, no policy evaluated) and
carries the code-authorship extension fields of Section 5.14; the
receipt binds the issuer to the recorded change assertion; it does
not establish the change's existence or exact execution time, and
the issuing platform never clones the repository, re-diffs the
change, verifies the code, or verifies the model - This document.
* protectmcp:observation - A receipt recording passive telemetry
about an Action that was signed without a policy evaluation,
emitted under one of the capture topologies catalogued in
Appendix C (typically network_proxy, browser_extension,
ebpf_observer, or mcp_proxy) where the originating application
could not call the receipt-emitting SDK directly; the reference
cloud implementation rejects at signing time, as the
false_attestation_guard, a receipt that declares the
passive_telemetry capture topology but carries a type outside
protectmcp:observation and its sub-namespaces - This document.
* protectmcp:observation:result_bound - A sub-namespace under
protectmcp:observation for a follow-up observation receipt that
carries a result_digest (Section 5.9) binding the byte-equality of
a downstream Action's result to the originating
protectmcp:decision receipt identified by action_ref; the
reference cloud implementation emits this type for tool calls
whose downstream result is regulator-relevant (LLM completions
under EU AI Act Article 12, audit-log entries under HIPAA
164.312(b), broker-dealer communications under SEC 17a-4); a
receipt of this type that lacks a well-formed result_digest is
rejected at signing time per the type-bound presence rule of
Section 5.9 - This document.
Gomes Marques Expires 25 March 2027 [Page 117]
Internet-Draft Compliance Receipts Profile September 2026
14. Related Work
These references explain nearby technical approaches. Published RFCs
and W3C Recommendations have the status stated by their publishers.
Individual Internet-Drafts are work in progress and do not imply IETF
endorsement or consensus. No reference in this section requires
adoption of another product or guarantees interoperability.
* [RFC9943] describes SCITT transparency architecture. Registration
and receipt verification support evidence about registered
statements; they do not establish the truth of those statements.
This profile also separates issuer claims, evidence availability
and relying-party trust.
* [RFC9162] describes Certificate Transparency. Its append-only log
mechanisms offer a useful comparison for inclusion and consistency
evidence, but its certificate-specific semantics do not
automatically apply to agent actions.
* [RFC9334] and [RFC9999] provide the RATS architecture and a
message wrapper. Device or environment evidence must be appraised
within that trust model; it does not by itself prove which
application action occurred. [DRAFT-SOKOLOV-AEP-COMPOSITION] is
related work in progress on this composition.
* [DRAFT-MSEBENZI-EVIDENCE-ACTION] describes post-hoc action
evidence. Its explicit evidence limits and verification states
are relevant comparisons. This profile defines its own framing,
issuer and chain rules, with timestamp policy under Section 5.5;
no byte-level interoperability is implied.
* [DRAFT-HOPLEY-X402] addresses screening receipts for agentic
payments. This profile supplies action-side evidence; it defines
neither payment settlement nor a universal delegation
authorization system.
* [W3C-VC-2] and [W3C-VC-DI] address credential exchange and
integrity. Wrapping a receipt in another signed format does not
replace verification of the embedded receipt or establish the
truth of its claims.
Implementation and conformance-corpus references identify inspectable
artifacts. A first-party corpus demonstrates the cases it contains;
it is not independent certification or proof that every mandatory
clause has shipped. External comparisons must identify the versions
and trust assumptions used.
Gomes Marques Expires 25 March 2027 [Page 118]
Internet-Draft Compliance Receipts Profile September 2026
15. Implementation Status
This section identifies the reference implementation surfaces for the
target design, following [RFC7942]. It is removed before RFC
publication. Implementation listings are not endorsements. The
normative body defines the intended behavior; a release evidence
record identifies the exact versions and clauses verified for any
particular release.
The record distinguishes platform behavior, installed Python and
TypeScript entry points, retained historical formats and optional
extensions. It records the source revision, package digest,
conformance inputs, trust policy, results and independent reviewer.
No aggregate test count substitutes for coverage of each applicable
clause. This edition makes no claim about paying customers, unlisted
implementations or independently reproduced test totals.
15.1. Asqav Platform
The issuer and hosted verifier maintain the receipt chain, publish
authorized verification material and export retained evidence. The
implementation follows the selected capture, key, witness and
evidence policies.
The release evidence record identifies the distributed artifact,
license, dependency scope and independently reproduced acceptance.
See [ASQAV-SDK] for the cited source artifact.
15.2. Python Verifier
The Python verification surface evaluates exported receipts and
evidence under an explicit profile and trust policy. Offline
operation does not require an issuer account or an issuer-computed
verdict.
The release evidence record identifies the distributed artifact,
license, dependency scope and independently reproduced acceptance.
See [ASQAV-SDK] for the cited source artifact.
15.3. TypeScript Verifier
The TypeScript verification surface applies the same versioned
contract and conformance inputs. Cross-language agreement is
evaluated with equivalent evidence and policy inputs; it does not
establish organizational independence.
Gomes Marques Expires 25 March 2027 [Page 119]
Internet-Draft Compliance Receipts Profile September 2026
The release evidence record identifies the distributed artifact,
license, dependency scope and independently reproduced acceptance.
See [ASQAV-SDK] for the cited source artifact.
This revision defines Python and TypeScript verification surfaces. A
separate WebAssembly verifier is not required. Offline verification
claims identify the actual surface, build and supported cryptographic
capabilities in the release evidence record.
16. Acknowledgements
The author thanks Tom Farley for [ACTA-RECEIPTS], on which this
profile is built. This profile would not exist without the field
catalogue and envelope structure that the upstream draft defines.
The author thanks Anton Sokolov (Tyche Institute) for review of the
attestation and validity-window surface and for
[DRAFT-SOKOLOV-AEP-COMPOSITION], and Michael Msebenzi for technical
reviews of the published -07 and -08 that corrected the signature-
scope and envelope-shape text. The author also thanks the Asqav
community for review of early drafts. Acknowledgement of review does
not imply endorsement of this document's content by any reviewer
named here.
17. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[FIPS205] National Institute of Standards and Technology, "Stateless
Hash-Based Digital Signature Standard", FIPS 205,
DOI 10.6028/NIST.FIPS.205, 13 August 2024,
<https://csrc.nist.gov/pubs/fips/205/final>.
Gomes Marques Expires 25 March 2027 [Page 120]
Internet-Draft Compliance Receipts Profile September 2026
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS 204,
DOI 10.6028/NIST.FIPS.204, 13 August 2024,
<https://csrc.nist.gov/pubs/fips/204/final>.
[RFC5816] Santesson, S. and N. Pope, "ESSCertIDv2 Update for RFC
3161", RFC 5816, DOI 10.17487/RFC5816, April 2010,
<https://www.rfc-editor.org/info/rfc5816>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.
[OPENTIMESTAMPS]
OpenTimestamps, "OpenTimestamps Python Library: Timestamp
Serialization and Verification", Source revision
3af46432efc4a4c4e7bba439c1f49bce808eb3e5; accessed 12
September 2026. This implementation or project
specification is not an IETF standard., 2025,
<https://github.com/opentimestamps/python-
opentimestamps/blob/3af46432efc4/opentimestamps/core/
timestamp.py>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing
and Encryption (JOSE) and CBOR Object Signing and
Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May
2026, <https://www.rfc-editor.org/info/rfc9964>.
[RFC7638] Jones, M., Sakimura, N., and J. Bradley, "JSON Web Key
(JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638,
September 2015, <https://www.rfc-editor.org/info/rfc7638>.
[ISO17442] ISO, "Financial services - Legal entity identifier (LEI) -
Part 1: Assignment", ISO 17442-1:2020, August 2020,
<https://www.iso.org/standard/78829.html>.
Gomes Marques Expires 25 March 2027 [Page 121]
Internet-Draft Compliance Receipts Profile September 2026
[W3C-DID] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July
2022, <https://www.w3.org/TR/did-1.0/>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC8726] Farrel, A., "How Requests for IANA Action Will Be Handled
on the Independent Stream", RFC 8726,
DOI 10.17487/RFC8726, February 2020,
<https://www.rfc-editor.org/info/rfc8726>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[IN-TOTO-ATTESTATION]
in-toto project, a Cloud Native Computing Foundation
project, "in-toto Attestation Framework: Statement v1",
Source revision 2dcd055e9f72e746687c306e35f4e59720ff45be;
accessed 12 September 2026. This implementation or project
specification is not an IETF standard., 2026,
<https://github.com/in-
toto/attestation/blob/2dcd055e9f72/spec/v1/statement.md>.
[DSSE] Secure Systems Lab, New York University, "Dead Simple
Signing Envelope: Envelope Specification", Source revision
1d3370f62565bca041e97c8310b873ac340edc2e; accessed 12
September 2026. This implementation or project
specification is not an IETF standard., 2026,
<https://github.com/secure-systems-
lab/dsse/blob/1d3370f62565bca041e97c8310b873ac340edc2e/
envelope.md>.
Gomes Marques Expires 25 March 2027 [Page 122]
Internet-Draft Compliance Receipts Profile September 2026
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[DRAND-SPEC]
drand, "drand Protocol Specification", Protocol
Specification, commit
0a551bdc229a139c1a6862306bcbf0899ee3ea53; accessed 13
September 2026., 25 April 2025, <https://github.com/drand/
drand-docs/blob/0a551bdc229a/docs/
concepts/03-Specification.md>.
[EU-AI-ACT]
European Parliament and Council, "Regulation (EU)
2024/1689 of the European Parliament and of the Council of
13 June 2024 laying down harmonised rules on artificial
intelligence and amending Regulations (EC) No 300/2008,
(EU) No 167/2013, (EU) No 168/2013, (EU) 2018/858, (EU)
2018/1139 and (EU) 2019/2144 and Directives 2014/90/EU,
(EU) 2016/797 and (EU) 2020/1828 (Artificial Intelligence
Act) (Text with EEA relevance)", 12 July 2024,
<https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.
[EU-2026-1744]
European Parliament and Council of the European Union,
"Regulation (EU) 2026/1744 of the European Parliament and
of the Council of 8 July 2026 amending Regulations (EU)
2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards
the simplification of the implementation of harmonised
rules on artificial intelligence (Digital Omnibus on AI)",
OJ L 2026/1744, 24.7.2026, 8 July 2026, <https://eur-
lex.europa.eu/legal-content/EN/TXT/
HTML/?uri=CELEX:32026R1744>.
[DORA] European Parliament and Council, "Regulation (EU)
2022/2554 of the European Parliament and of the Council of
14 December 2022 on digital operational resilience for the
financial sector and amending Regulations (EC) No
1060/2009, (EU) No 648/2012, (EU) No 600/2014, (EU) No
909/2014 and (EU) 2016/1011 (Text with EEA relevance)", 27
December 2022,
<https://eur-lex.europa.eu/eli/reg/2022/2554/oj>.
[REG-2024-1772]
European Commission, "Commission Delegated Regulation (EU)
2024/1772 of 13 March 2024 supplementing Regulation (EU)
2022/2554 of the European Parliament and of the Council
with regard to regulatory technical standards specifying
Gomes Marques Expires 25 March 2027 [Page 123]
Internet-Draft Compliance Receipts Profile September 2026
the criteria for the classification of ICT-related
incidents and cyber threats, setting out materiality
thresholds and specifying the details of reports of major
incidents (Text with EEA relevance)", 25 June 2024,
<https://eur-lex.europa.eu/eli/reg_del/2024/1772/oj>.
[REG-2025-302]
European Commission, "Commission Implementing Regulation
(EU) 2025/302 of 23 October 2024 laying down implementing
technical standards for the application of Regulation (EU)
2022/2554 of the European Parliament and of the Council
with regard to the standard forms, templates, and
procedures for financial entities to report a major ICT-
related incident and to notify a significant cyber threat
(Text with EEA relevance)", 20 February 2025,
<https://eur-lex.europa.eu/eli/reg_impl/2025/302/oj>.
[COLORADO-ADMT]
State of Colorado, Seventy-Fifth General Assembly, Second
Regular Session, "Senate Bill 26-189, Automated Decision-
Making Technology", 14 May 2026,
<https://leg.colorado.gov/bills/sb26-189>.
[TEXAS-TRAIGA]
State of Texas, 89th Legislature, Regular Session, "House
Bill 149, Texas Responsible Artificial Intelligence
Governance Act", 22 June 2025,
<https://capitol.texas.gov/tlodocs/89R/billtext/html/
HB00149F.HTM>.
[HIPAA-SECURITY]
United States Department of Health and Human Services,
"HIPAA Security Rule, 45 CFR Part 164, Subpart C, Security
Standards for the Protection of Electronic Protected
Health Information", 20 February 2003,
<https://www.ecfr.gov/current/title-45/subtitle-A/
subchapter-C/part-164>.
[NYDFS-500]
New York State Department of Financial Services, "23 NYCRR
Part 500, Cybersecurity Requirements for Financial
Services Companies", 1 March 2017,
<https://www.dfs.ny.gov/system/files/documents/2023/12/
rf23_nycrr_part_500_amend02_20231101.pdf>.
[SEC-17A-4]
United States Securities and Exchange Commission,
"Electronic Recordkeeping Requirements for Broker-Dealers,
Gomes Marques Expires 25 March 2027 [Page 124]
Internet-Draft Compliance Receipts Profile September 2026
Security-Based Swap Dealers, and Major Security-Based Swap
Participants (Rule 17a-4 Amendments)", 3 November 2022,
<https://www.federalregister.gov/
documents/2022/11/03/2022-22670/electronic-recordkeeping-
requirements-for-broker-dealers-security-based-swap-
dealers-and-major>.
[CIRCIA-681B]
United States Congress, "6 U.S.C. 681b - Required
reporting of certain cyber incidents", United States Code,
2024 Edition, Title 6, Chapter 1, Subchapter XVIII, Part
D, Section 681b. Official GPO source read 13 September
2026. The edition marker was read from the govinfo granule
metadata record (accessId USCODE-2024-title6-chap1-
subchapXVIII-partD-sec681b, baseEditionYear 2024,
isCurrentEdition true); the section PDF itself carries no
edition string. Access route: the citation resolver
https://www.govinfo.gov/link/uscode/6/681b redirected to
this edition-pinned granule on that date. The resolver is
not version-pinned and will move to a later edition once
one is published, so the granule above is the citation of
record. The corresponding House U.S. Code section URL was
attempted but retrieval timed out; the successful GPO
access is recorded separately., 2024,
<https://www.govinfo.gov/content/pkg/USCODE-2024-
title6/pdf/USCODE-2024-title6-chap1-subchapXVIII-partD-
sec681b.pdf>.
[CIRCIA] United States Congress, "Cyber Incident Reporting for
Critical Infrastructure Act of 2022, enacted as Division Y
of the Consolidated Appropriations Act, 2022 (Public Law
117-103); statutory authority codified at 6 U.S.C. 681 et
seq.", 15 March 2022,
<https://www.congress.gov/117/plaws/publ103/PLAW-
117publ103.pdf>.
[NIST-AI-RMF]
National Institute of Standards and Technology,
"Artificial Intelligence Risk Management Framework (AI RMF
1.0)", NIST AI 100-1, DOI 10.6028/NIST.AI.100-1, 26
January 2023,
<https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf>.
18. Informative References
[LAMPS-COMPOSITE]
IETF LAMPS Working Group, "Composite Module-Lattice-Based
Digital Signature Algorithm (ML-DSA) for use in X.509
Gomes Marques Expires 25 March 2027 [Page 125]
Internet-Draft Compliance Receipts Profile September 2026
Public Key Infrastructure", Work in Progress. Citation
does not imply IETF endorsement or publication as an RFC.,
Work in Progress, Internet-Draft, draft-ietf-lamps-pq-
composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[RFC9846] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266,
DOI 10.17487/RFC9266, July 2022,
<https://www.rfc-editor.org/info/rfc9266>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/info/rfc9421>.
[NIST-GENAI-PROFILE]
National Institute of Standards and Technology,
"Artificial Intelligence Risk Management Framework:
Generative Artificial Intelligence Profile", NIST AI
600-1, DOI 10.6028/NIST.AI.600-1, 26 July 2024,
<https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf>.
[DRAFT-HOPLEY-X402]
Hopley, C., "Categorical Compliance Screening Receipt
Format for Agentic-Payment Flows", Work in Progress.
Citation does not imply IETF endorsement or publication as
an RFC., Work in Progress, Internet-Draft, draft-hopley-
x402-compliance-receipt-02, 30 May 2026,
<https://datatracker.ietf.org/doc/html/draft-hopley-x402-
compliance-receipt-02>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/info/rfc9162>.
Gomes Marques Expires 25 March 2027 [Page 126]
Internet-Draft Compliance Receipts Profile September 2026
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
[RFC9999] Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig,
"Remote ATtestation procedureS (RATS) Conceptual Message
Wrapper (CMW)", RFC 9999, DOI 10.17487/RFC9999, July 2026,
<https://www.rfc-editor.org/info/rfc9999>.
[DRAFT-SOKOLOV-AEP-COMPOSITION]
Sokolov, A., "Composing Application-Layer Action Evidence
with Remote Attestation Procedures", Work in Progress.
Citation does not imply IETF endorsement or publication as
an RFC., Work in Progress, Internet-Draft, draft-sokolov-
rats-aep-composition-06, 31 August 2026,
<https://datatracker.ietf.org/doc/html/draft-sokolov-rats-
aep-composition-06>.
[DRAFT-MSEBENZI-EVIDENCE-ACTION]
Msebenzi, M., "The evidence.* Family: Post-Hoc,
Independently Recomputable Evidence Records for AI Agent
Actions", Work in Progress. Citation does not imply IETF
endorsement or publication as an RFC., Work in Progress,
Internet-Draft, draft-msebenzi-evidence-action-00, 28 July
2026, <https://datatracker.ietf.org/doc/html/draft-
msebenzi-evidence-action-00>.
[ASQAV-SDK]
Asqav, "asqav-sdk: Verifier Conformance Vectors", 2026,
<https://github.com/jagmarques/asqav-sdk/
tree/6137cb95edcfcd820ecff0e11c6f603b2da664b1>.
[SCOPEBLIND]
ScopeBlind, "Shared test vectors for conformance between
implementations of draft-farley-acta-signed-receipts",
2026, <https://github.com/ScopeBlind/agent-governance-
testvectors/
tree/9ad0856164e459024755d60f16f9f172868949ee>.
Gomes Marques Expires 25 March 2027 [Page 127]
Internet-Draft Compliance Receipts Profile September 2026
[CLAUDE-HOOKS]
Anthropic, "Claude Code Hooks Reference", Accessed 12
September 2026; runtime-specific behavior is version-
dependent., 12 September 2026,
<https://code.claude.com/docs/en/hooks>.
[MCP-AUTH] Model Context Protocol contributors, "Model Context
Protocol Authorization, 2025-11-25", Accessed 12 September
2026; runtime-specific behavior is version-dependent., 12
September 2026, <https://modelcontextprotocol.io/
specification/2025-11-25/basic/authorization>.
[W3C-VC-2] W3C, "Verifiable Credentials Data Model v2.0", 15 May
2025, <https://www.w3.org/TR/vc-data-model-2.0/>.
[W3C-VC-DI]
W3C, "Verifiable Credential Data Integrity 1.0: Securing
the Integrity of Verifiable Credential Data", 15 May 2025,
<https://www.w3.org/TR/vc-data-integrity/>.
[GDPR] European Parliament and Council, "Regulation (EU) 2016/679
(General Data Protection Regulation)", Official source;
accessed 12 September 2026., 2016,
<https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng>.
[ICO-ANON] Information Commissioner's Office, "Introduction to
Anonymisation", Official source; accessed 12 September
2026., 2025, <https://ico.org.uk/for-organisations/uk-
gdpr-guidance-and-resources/data-sharing/anonymisation/
introduction-to-anonymisation/>.
[CHROME-CONTENT-SCRIPTS]
Chrome for Developers, "Content Scripts", Official source;
accessed 12 September 2026., 2026,
<https://developer.chrome.com/docs/extensions/develop/
concepts/content-scripts>.
[CHROME-WEBREQUEST]
Chrome for Developers, "chrome.webRequest", Official
source; accessed 12 September 2026., 2026,
<https://developer.chrome.com/docs/extensions/reference/
api/webRequest>.
[RFC9849] RFC Editor, "TLS Encrypted Client Hello", Official source;
accessed 12 September 2026., 2026,
<https://www.rfc-editor.org/info/rfc9849>.
Gomes Marques Expires 25 March 2027 [Page 128]
Internet-Draft Compliance Receipts Profile September 2026
[ACTA-RECEIPTS]
Farley, T., "Signed Decision Receipts for Machine-to-
Machine Access Control", Work in Progress. Citation does
not imply IETF endorsement or publication as an RFC., Work
in Progress, Internet-Draft, draft-farley-acta-signed-
receipts-03, 29 August 2026,
<https://datatracker.ietf.org/doc/html/draft-farley-acta-
signed-receipts-03>.
Appendix A. Worked Examples (Informative)
This appendix shows two receipts and one member. The first receipt
is a Compliance Receipt exactly as the reference issuing platform
emitted it in production on 2026-09-04 (signature identifier
sig_XcmE-To6pSVUUJI6SUGx9g, issued under the platform operator's own
organisation): a hash-mode protectmcp:lifecycle receipt signed with
ML-DSA-65, carrying seq 63, a key_thumbprint, and both anchor types,
with the OpenTimestamps commitment upgraded to Bitcoin block 965451.
It is published byte-exact, with its seq 62 predecessor and the key
set that resolves it, as conformance vector asqav-24-anchor-block-
hash-prod in the receipt corpus (verifier/conformance-vectors/) of
[ASQAV-SDK], so every value below can be checked against the bytes.
The second receipt is illustrative: a payload-mode
protectmcp:decision receipt for the Section 7.2 binding, carrying the
member set the reference implementation emits in payload mode, with
abbreviated values and placeholder signature and anchors. The third
fragment shows the counterparty_binding member of Section 5.8.1,
which no production receipt carried on 2026-09-04 and which is
therefore shown separately and marked illustrative.
Rendering conventions, both examples: members appear in JCS-canonical
lexicographic order ([RFC8785]), which is the byte order the
signature and every digest of this profile are computed over; digest-
valued strings are shown as their first sixteen and last eight
hexadecimal characters joined by an ellipsis; the three long base64
values of the first receipt (the signature, 4412 characters; the RFC
3161 token, 6528 characters; the OpenTimestamps proof, 1772
characters) are elided with their lengths stated, and every other
value of the first receipt is verbatim.
A.1. A production receipt, byte-exact in the corpus
The receipt:
Gomes Marques Expires 25 March 2027 [Page 129]
Internet-Draft Compliance Receipts Profile September 2026
{
"anchors": [
{
"type": "rfc3161",
"value": "<6528 base64 characters, elided>"
},
{
"anchor_block_hash": "0000000000000000...6499b499",
"status": "anchored",
"type": "opentimestamps",
"value": "<1772 base64 characters, elided>"
}
],
"payload": {
"action_id": "act_yDx9hcwMgBqewK1mktn1Fg",
"action_ref": "sha256:b15eeb40a51b1a0d...a1908488",
"agent_id": "agt_uJgllxkGt5xQ6Xks",
"decision": "observation",
"hash": "sha256:b15eeb40a51b1a0d...a1908488",
"hash_algo": "sha256",
"issued_at": "2026-09-04T07:20:51.935103Z",
"issuer_id": "f94f66c0-c580-432d-a041-29374f7aee07",
"key_thumbprint": "sha256:5b98a75dd05ba63d...8ad848bb",
"metadata": {
"heartbeat_description": {
"idle_seconds": 3617,
"interval_seconds": 3600
}
},
"mode": "hash",
"org_id": "f94f66c0-c580-432d-a041-29374f7aee07",
"payload_digest": {
"hash": "b15eeb40a51b1a0d...a1908488",
"size": 45
},
"policy_digest": "sha256:5ad43b4f60033435...836e467c",
"previousReceiptHash": "1149a5d06a774a3c...48f4f5f7",
"seq": 63,
"server_timestamp": "2026-09-04T07:20:51.935103Z",
"type": "protectmcp:lifecycle",
"v": 1
},
"signature": {
"alg": "ML-DSA-65",
"kid": "f94f66c0-c580-432d-a041-29374f7aee07",
"sig": "<4412 base64 characters, elided>"
}
}
Gomes Marques Expires 25 March 2027 [Page 130]
Internet-Draft Compliance Receipts Profile September 2026
The key set entry it resolves to, as published at the platform's
/.well-known/jwks.json (Section 9.6). The pub member is the raw ML-
DSA-65 public key, 1952 bytes, in unpadded base64url; recomputing
SHA-256 over the JCS form of {"alg","kty","pub"} from this entry
reproduces the receipt's key_thumbprint (Section 5.2.10).
{
"agent_id": "agt_uJgllxkGt5xQ6Xks",
"alg": "ML-DSA-65",
"issuer_id": "f94f66c0-c580-432d-a041-29374f7aee07",
"key_thumbprint": "sha256:5b98a75dd05ba63d...8ad848bb",
"kid": "YS-AwmqpURR7omdnBsGU0A",
"kty": "AKP",
"org_id": "f94f66c0-c580-432d-a041-29374f7aee07",
"pub": "<2603 base64 characters, elided>",
"status": "active"
}
What an offline verifier establishes from these bytes and this key
set, and what it cannot:
* Signature: ML-DSA-65 over the JCS serialization of the payload
member verifies under the published key. The kid in the signature
object carries the issuing organisation's identifier on the hosted
tier; the signing key is selected through the signed agent_id and
confirmed by key_thumbprint, so a key substituted under the same
identifier is detected (Section 5.2.10).
* Chain: SHA-256 over the JCS serialization of the predecessor's
payload member equals previousReceiptHash (Section 5.4), and seq
63 follows the predecessor's 62 with nothing withheld between them
(Section 5.2.11).
* payload_digest: This receipt carries no context, so the
recomputation of Section 11.2 does not apply; the separate hash
member holds the self-describing fingerprint of the Action, and
hash_algo records how it was produced.
* Anchors (Section 5.5): the RFC 3161 token binds the envelope-
minus-anchors digest and verifies only against the issuing TSA's
key material; the OpenTimestamps proof carries a Bitcoin
attestation at height 965451 and completes only against a Bitcoin
header source. The corpus ships neither, so a conforming verifier
run on the corpus alone reports the anchoring axis as unverifiable
rather than failed, and reports status and anchor_block_hash as
the informational members they are. With a header source, the
block whose hash is the anchor_block_hash shown is the one the
proof resolves into.
Gomes Marques Expires 25 March 2027 [Page 131]
Internet-Draft Compliance Receipts Profile September 2026
A.2. An illustrative decision receipt for the Article 26 binding
This synthetic example illustrates a payload-mode decision receipt.
Values are placeholders or abbreviated, and it is not a
cryptographically valid test vector. It MUST NOT be replayed or
trusted. Reproducible conformance vectors require complete source-
bound bytes, keys, expected results and the selected verification
policy.
{
"payload": {
"action_id": "act_5f4nc7MqiGHwN5_RRgOXqw",
"action_ref": "sha256:fc9deb0c3dc4acf2...e8482781",
"action_type": "tool_call",
"agent_id": "agt_DAsgntrbV_VAIBbl",
"context": {
"tool": "deploy",
"target_digest": "sha256:3c0f1a...9e21"
},
"controls_evaluated": {
"content_scan": {"blocking": false, "ran": true},
"emergency_halt": {"checked": true, "halted": false},
"policy": {"evaluated": true, "matched_count": 1},
"result": "allowed"
},
"decision": "allow",
"expires_at": "2026-09-02T21:17:18.504801Z",
"issued_at": "2026-09-01T21:17:18.504801Z",
"issuer_id": "00000000000000000098",
"iteration_id": "task-2026-09-01-01a3",
"key_thumbprint": "sha256:8fd93ce505a84acf...d405c1e2",
"mode": "payload",
"nonce": "59d1668bab924760317f4c39",
"org_id": "f94f66c0-c580-432d-a041-29374f7aee07",
"payload_digest": {
"hash": "0a44d2c8e3f5b7a9...e7f9b2a4",
"size": 61
},
"policy_digest": "sha256:7eb08c4ee16e9744...51935a1c",
"previousReceiptHash": "3fd8f9f8093db756...d5618f38",
"reason": "policy:within_limits",
"risk_class": "deployer:financial:medium",
"sandbox_state": "enabled",
"seq": 10,
"timestamp": "2026-09-01T21:17:18.504801Z",
"tool_name": "deploy",
"type": "protectmcp:decision",
"v": 1
Gomes Marques Expires 25 March 2027 [Page 132]
Internet-Draft Compliance Receipts Profile September 2026
},
"signature": {
"alg": "ML-DSA-65",
"kid": "00000000000000000098",
"sig": "<4412 base64url characters, placeholder>"
},
"anchors": [
{"type": "rfc3161", "value": "<placeholder>"},
{"type": "opentimestamps", "value": "<placeholder>",
"status": "anchored",
"anchor_block_hash": "<64 lowercase hex, placeholder>"}
]
}
The example illustrates these profile fields:
* issuer_id resolves through the trust anchor metadata in the Audit
Pack to the named Deployer (shown here as a 20-character ISO 17442
Legal Entity Identifier; the reference platform's hosted tier
emits the organisation identifier, as the first example shows);
* policy_digest resolves to a retained policy artefact and
controls_evaluated records which controls ran, per the false-
attestation guard of the extension registry;
* sandbox_state records the producer's sandbox assertion. It does
not establish an OS boundary or satisfy a statutory sandbox
requirement.
* previousReceiptHash and seq link the receipt into the chain per
Section 5.4 and Section 5.2.11;
* both an RFC 3161 anchor and an OpenTimestamps anchor are present
per Section 5.5.
For each selected legal mapping, the verifier checks the applicable
record-specific evidence policy and reports unavailable evidence or
unresolved applicability. Incident classification is checked only
where that mapping applies. These technical checks do not establish
legal compliance.
Gomes Marques Expires 25 March 2027 [Page 133]
Internet-Draft Compliance Receipts Profile September 2026
A.3. The counterparty_binding member (illustrative)
When agent B's receipt binds agent A's receipt, B's signed payload
carries the member below (Section 5.8, Section 5.8.1): receipt_ref
names A's receipt, envelope_hash is the base64url SHA-256 digest of
A's envelope-minus-anchors object as A served it, and scope declares
that digest scope. The fragment is illustrative and makes no claim
about production issuance.
"counterparty_binding": {
"receipt_ref": "sig_ptqHVATi_BiVw8I4ASihcA",
"envelope_hash": "<43 base64url characters>",
"scope": "envelope_minus_anchors"
}
Appendix B. Change Log
This appendix records the scope of the local working revision.
Earlier editorial detail remains in the preserved source revision and
its audit archive. It is historical, not an additional set of
conformance requirements. Remove this appendix before RFC
publication.
B.1. Changes in draft -09
The local 12 September 2026 reconciliation clarifies wire and digest
scopes, version handling, optional anchors, signed operator-based
witness policy, capture limits, heartbeat evidence and per-axis
unknown results. It removes unsupported legal retention floors and
evidence guarantees, corrects legal applicability and privacy rules,
and revises reference status and language. These changes describe
target behavior pending implementation acceptance.
This edition makes the receipt definitions, Action-descriptor digest,
signature contract, signed Audit Pack projection, key trust and
extension rules self-contained. ACTA remains an informative
antecedent. OpenTimestamps, DSSE and in-toto remain technical
dependencies; drand is pinned and normative for the selected beacon
verification feature. Catalogue-only APKI, AML, AAT and delegation
references are removed, and fixture claims are limited to the cited
corpus. These specification changes require implementation and
vector reconciliation; this note is not a claim that those checks
have passed.
The base profile recommends timestamp anchoring with SHOULD so that
issuance and offline evidence retention do not depend on immediate
access to an external timestamp service. A selected binding or
relying-party policy can require an anchor and then withhold full
Gomes Marques Expires 25 March 2027 [Page 134]
Internet-Draft Compliance Receipts Profile September 2026
verification while it is pending. This choice does not require a
particular hosted service tier or establish a statutory timestamp
requirement. The signed-optional witness-policy design binds any
producer-declared quorum to the receipt while allowing relying
parties to impose stronger external requirements; absent declarations
are reported explicitly rather than assumed satisfied.
B.2. Changes in draft -08
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.3. Changes in draft -07
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.4. Changes in draft -06
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.5. Changes in draft -05
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.6. Changes in draft -04
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.7. Changes in draft -03
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.8. Changes in draft -02
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
Gomes Marques Expires 25 March 2027 [Page 135]
Internet-Draft Compliance Receipts Profile September 2026
B.9. Changes in draft -01
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
B.10. Changes in draft -00
Historical revision. Its changes are incorporated only to the extent
retained in the current normative body; superseded wording does not
govern this revision.
Appendix C. Capture Topologies for Compliance Receipt Emission
This appendix describes deployment patterns and their limits.
Placement alone does not establish payload visibility, identity,
enforcement or complete capture. Each implementation documents the
actual transport, permissions, configuration and failure behavior.
The coverage requirements in Section 5.19 are normative; the topology
examples are informative.
capture_topology MAY appear as an informational Audit Pack attribute.
It does not change the receipt signature or authorize a stronger
verification claim. A new topology needs an explicit evidence
mapping rather than an assumed IANA registration.
C.1. In-Process SDK
An application may link the receipt SDK and invoke it in the action
path. The application process is the trust boundary; sibling or
alternative execution paths are outside that coverage unless
separately controlled. Captured fields depend on the configured
privacy mode, and a digest does not imply the SDK retained full
request or response content. Enforcing callbacks and passive
callbacks must be distinguished by their documented native semantics
under Section 5.19.
C.2. Network-Layer Egress Proxy
An in-path proxy records the traffic that actually passes through its
supported transport. TLS payload visibility requires an applicable
termination or application integration; DNS rewriting or an SNI
router alone does not decrypt payloads or prove that alternate routes
are blocked. Certificate pinning and encrypted handshake metadata
can constrain visibility.
Gomes Marques Expires 25 March 2027 [Page 136]
Internet-Draft Compliance Receipts Profile September 2026
Vocabulary value: network_proxy. Coverage depends on routing,
identity binding and the deployment's failure policy. A proxy record
attests to what the proxy observed. It does not by itself identify
the initiating employee or prove that every application used the
proxy. Sensitive network identifiers remain subject to Section 12.6.
C.3. Browser Extension
A browser extension can observe or instrument supported page activity
within its granted permissions and execution contexts. Content
scripts normally run in an isolated world; intercepting page-defined
functions requires a deliberately designed integration. Extension
APIs and permissions do not imply access to every response body,
stream, frame or browser session.
Vocabulary value: browser_extension. The implementation declares
which requests and fields it captures, when instrumentation begins
and which contexts are excluded. Installing an enterprise
certificate authority is not a general prerequisite for content-
script access to page data and does not establish complete capture.
A separate network interception design has separate TLS requirements.
See [CHROME-CONTENT-SCRIPTS] and [CHROME-WEBREQUEST].
C.4. eBPF SNI Observer
A host sensor can record the kernel events and metadata exposed by
its installed probes and permissions. Available fields depend on the
operating system, probe placement, application transport and
encryption. Encrypted ClientHello can conceal the inner server name;
see [RFC9849]. A connection event alone does not prove that a
particular model call occurred or identify the responsible employee.
Vocabulary value: ebpf_observer. The report distinguishes observed
process or connection metadata from inferred activity. It does not
claim prompt or response visibility without a separate demonstrated
capture path. This topology is an observation pattern, not proof of
complete host enforcement.
C.5. MCP Transparent Proxy
An MCP proxy observes messages that traverse the transports it
implements. It declares the protocol revision, request and response
coverage, identity source and authentication boundary. HTTP
authorization and local stdio credentials are distinct deployment
concerns under [MCP-AUTH].
Gomes Marques Expires 25 March 2027 [Page 137]
Internet-Draft Compliance Receipts Profile September 2026
Vocabulary value: mcp_proxy. A proxy may record a request and its
observed response. Two receipts signed only by that proxy remain two
proxy assertions; they are not independent endpoint acknowledgements
and cannot expose a proxy that deliberately fabricates both. A
counterparty binding supplies independent evidence only to the extent
that the peer's independently authenticated signature and scope
support it. Bypassed traffic and unsupported methods remain outside
the measured coverage.
C.6. Passive Telemetry Ingestion
A passive ingestion pipeline reads structured records the originating
application or its runtime has already emitted (for example,
OpenTelemetry spans, application access logs, vendor-managed
observability exports, or batch CSV drops) and synthesises a
Compliance Receipt for each record after the fact. The synthesiser
holds the signing key, applies the receipt-format wire profile, and
emits the receipt to the same downstream sink that the in-process SDK
and network-proxy paths feed. Vocabulary value: passive_telemetry.
Trust boundary: the telemetry pipeline operator's signing key plus
the integrity of the upstream observability source; the receipt binds
the producer of the telemetry, not the originating application's per-
request principal. Threat-model note: captures whatever the upstream
telemetry source preserved (typically a subset of the action's bytes
and metadata, often without request or response payload) plus the
wall-clock and counterparty identifiers visible in the telemetry
record; does NOT capture data the upstream source dropped, sampled
out, or never emitted, and inherits any tampering risk the upstream
source carries between emission and ingestion.
Useful when the in-process SDK, network proxy, browser extension,
eBPF observer, and MCP proxy topologies are all operationally
infeasible (legacy applications without instrumentation hooks, third-
party SaaS with read-only export, fleet migrations where the producer
has only logs to work from) but the operator still needs a signed
evidence artefact tied to the historical action. Reference
implementation hint: any OpenTelemetry collector exporter feeding a
conformant receipt-emitting signer; the upstream telemetry source is
out of scope of this profile.
Gomes Marques Expires 25 March 2027 [Page 138]
Internet-Draft Compliance Receipts Profile September 2026
C.7. capture_topology Vocabulary and Considerations for a Future IANA
Registry
The six values defined in this appendix (in_process_sdk,
network_proxy, browser_extension, ebpf_observer, mcp_proxy,
passive_telemetry) form the closed initial vocabulary for the
capture_topology attribute. The attribute is optional at the wire
layer and, where present, appears only in the Audit Pack manifest
entry for the receipt, never inside the signed payload object, so
that the topology declaration is producer-side metadata that does not
alter the receipt's signed bytes. A verifier must not treat the
absence of a capture_topology attribute as a non-conformance
condition: absence simply means the producer did not declare a
topology, and neither Section 11.2 nor Section 11.3 lists the
attribute among the verifier's checks.
This Independent Stream document requests no IANA action for
capture_topology. RFC 8726 generally prohibits new IANA registries
for this stream, with a narrow exception for subcode registries tied
to an allocated code point. That exception does not establish
authority for the standalone tables here. These are externally
maintained profile tables. Any future IANA request must satisfy the
applicable registration policy and publication procedure. See
[RFC8726].
C.8. Regulatory Currency and Verification Dates
This appendix is informative. Sources and their applicability must
be checked when this draft is revised and before a deployment selects
a legal mapping. A successful link check is not a legal review, and
an inaccessible page is not evidence that the law has not changed.
The local audit preserves a separate reference inventory with
retrieval results and source hashes; this draft makes no claim that a
scheduled source-monitoring service has been implemented.
The 12 September 2026 review checked official EU AI Act and amendment
text, the Commission's Article 50 guidance, DORA, official Texas
legislation, the NYDFS amended rule, the SEC 2022 adopting release,
HHS Security Rule guidance, RFC publications and current native
integration documentation. Some sources required an alternate
official access path. ISO catalog pages establish publication
metadata, not a reading of the full paid standards. During that 12
September review, eCFR access was restricted; the SEC release and HHS
guidance do not establish the absence of later amendments.
CIRCIA remains provisional in this draft because this review did not
verify an operative final rule. Colorado's implementing rules and
effective-date conditions require a final check before the mapping is
Gomes Marques Expires 25 March 2027 [Page 139]
Internet-Draft Compliance Receipts Profile September 2026
used. The current legal text and applicable exceptions control over
any summary here. This is a bounded review of named mappings, not a
catalogue of every law worldwide.
A bounded follow-up on 13 September 2026 read DORA Articles 2 and 64,
current eCFR Sections 164.302, 164.304 and 164.316, the official SB
26-189 session law, and 6 U.S.C. 681b through [CIRCIA-681B]. Current
eCFR access succeeded for those sections. The corresponding House
U.S. Code section (https://uscode.house.gov/
view.xhtml?req=granuleid:USC-prelim-
title6-section681b&num=0&edition=prelim) was attempted but timed out;
this review used the official GPO alternative and does not claim a
successful House reread. The official CIRCIA agenda entry
(https://www.reginfo.gov/public/do/
eAgendaViewRule?RIN=1670-AA04&pubId=202510) listed a September 2026
target; the review did not establish an operative final rule.
For every legal mapping, maintain a record of the official source,
exact provision and version, publication and applicability dates,
verification date, reviewer, pending changes, and any retrieval gap.
Do not label a claim verified solely because a URL is reachable. A
changed source or unresolved legal conflict requires review of the
mapping and its conformance examples.
Author's Address
Joao Andre Gomes Marques
Asqav
Portugal
Email: info@asqav.com
Gomes Marques Expires 25 March 2027 [Page 140]