Compliance Profile of Signed Action Receipts for AI Agents

1.1. Profile, Not Fork

[ACTA-RECEIPTS] specifies a generic, signed receipt envelope for recording machine-to-machine access control decisions made by AI agents. Section 2.2 of [ACTA-RECEIPTS] defines a common payload field set in which all fields except type, issued_at, and issuer_id are OPTIONAL. Section 5.7 of [ACTA-RECEIPTS] introduces hash chaining (previousReceiptHash) inside an optional Commitment Mode extension. [ACTA-RECEIPTS] does not define receipt retention, does not require timestamping anchors, and does not bind to any regulatory regime.¶

This document is an additive overlay on [ACTA-RECEIPTS]: it constrains fields the upstream draft leaves OPTIONAL, fixes their values where regulation requires, and adds three extension fields with reserved names (risk_class, incident_class, and counterparty_binding). A Compliance Receipt remains a conformant [ACTA-RECEIPTS] receipt. Field references use upstream field names rather than section numbers, to reduce maintenance hazard if upstream re-numbers in a future revision.¶

1.2. Scope

This document fills the regulatory binding gap on two surfaces. Section 5 binds the receipt to European Union obligations: Article 12 (record-keeping) and Article 26 (deployer obligations) of the EU AI Act, and Article 17 (ICT-related incident management) of DORA. Section 6 binds the receipt to United States obligations: the voluntary functions of the NIST AI Risk Management Framework, the deployer obligations of the Colorado AI Act 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 the covered-incident reporting requirements of CIRCIA.¶

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(6) of the Colorado Revised Statutes for Colorado bindings). Where another statute uses a different term (Provider, Financial Entity, Covered Entity 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.¶

A verifier that implements only [ACTA-RECEIPTS] can cryptographically validate a profile receipt but cannot attest the additional compliance bindings of this document.¶

5.1. Common Payload Fields

5.2. Decision Receipt Fields (type protectmcp:decision)

The decision field value MUST be allow, deny, rate_limit, or observation. Implementations using a different internal vocabulary (e.g. permit for allow) MUST normalise on emission and on Audit Pack export. The observation value records that an Action was observed and the receipt was signed without any policy evaluation having taken place; it is the regulator-honest alternative to emitting allow when no policy matched, and MUST NOT appear in a receipt of type protectmcp:decision. A producing system that has not evaluated a policy for an Action MUST either refuse to issue a Compliance Receipt for that Action or MUST emit the receipt with type protectmcp:lifecycle and decision observation; in the latter case the upstream policy_decision internal field, if present in the producing system's internal vocabulary, takes the literal value none, which the emitter MUST map to observation on the wire. Verifiers MUST reject a Compliance Receipt that carries decision observation together with type protectmcp:decision; conversely, a Compliance Receipt of type protectmcp:lifecycle MAY carry decision observation in addition to the other three vocabulary values. The policy_digest requirement of Section 5.2.2 applies to observation receipts in the form of a digest of the producing system's "no policy matched" sentinel policy artefact, which the Deployer MUST retain alongside its other policy artefacts for the applicable retention window.¶

The upstream tool_name field (REQUIRED in [ACTA-RECEIPTS] Section 3.1.1) is REQUIRED for Compliance Receipts of type protectmcp:decision.¶

5.3. Hash-Chain Linkage (OPTIONAL upstream, REQUIRED in this profile)

Upstream Commitment Mode introduces previousReceiptHash as part of an optional extension. This profile makes the linkage REQUIRED. Implementations MUST emit a previousReceiptHash field, populated per the digest-scope rule of Section 5.7 of [ACTA-RECEIPTS]: the lowercase hex encoding of SHA-256 over the canonical signing-input bytes of the immediately prior receipt emitted by the same issuer_id, where the canonical signing-input bytes are the JCS-canonical serialization ([RFC8785]) of the predecessor's signed payload object (the same bytes the predecessor's cryptographic signature covers), NOT the envelope object that additionally includes the signature or anchors top-level keys. The first receipt in a chain MUST set this field to the all-zero SHA-256 value (this profile's stipulation; [ACTA-RECEIPTS] Section 5.7 specifies only the digest scope of subsequent links). JSON key is the literal previousReceiptHash (camelCase, case-sensitive); snake_case aliases MUST NOT appear on the wire.¶

Rationale for the payload-bytes (signing-input) digest scope rather than the envelope-including-signature digest scope: the chain layer's purpose is to make after-the-fact alteration of the predecessor's signed content detectable, and the predecessor's signed content is exactly the bytes its signature covers (the canonical payload object). Digesting those bytes binds the chain to what A actually attested to, is recomputable offline from the predecessor's payload alone, and matches Section 5.7 of [ACTA-RECEIPTS]. The chain does not need to bind the predecessor's signature value directly because the predecessor's signature is verified independently under Section 9.1, and cross-agent envelope integrity (where binding the peer's signature value matters) is the role of counterparty_binding per Section 5.6, which digests at the envelope-including-signature scope precisely because the peer signature is the load-bearing artefact in the cross-agent case. Implementations that previously digested the envelope-including-signature object MUST migrate to the signing-input scope before emitting chained receipts under this profile; verifiers MUST recompute under the signing-input scope when checking previousReceiptHash.¶

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 the SHA-256(JCS(receipt)) of the immediately prior receipt emitted by that same issuer_id, taken in emission order, regardless of which concurrent execution path produced it. Parallel 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 5 and 6 (in particular Section 6.3.2, Section 7.5.1, and Section 7.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.¶

5.4. Anchoring (No Upstream Equivalent)

[ACTA-RECEIPTS] lists Sigstore Rekor in its Implementation Status appendix as an OPTIONAL temporal anchor. This profile imposes a normative anchoring requirement.¶

Compliance Receipts MUST be anchored. An anchor is an [RFC3161] timestamp token covering the signed envelope, an [OPENTIMESTAMPS] commitment covering the envelope, or both; implementations SHOULD emit both forms. For both anchor types, the bytes committed are SHA-256(JCS(envelope_minus_anchors)), where envelope_minus_anchors is the wire envelope object with the anchors top-level key removed prior to canonicalization, leaving the two-key object {payload, signature}. The anchors key MUST be removed from the object, not set to null or to an empty array; these produce different JCS output and break interoperability (mirroring the upstream Section 5.6 stripping rule). The anchor thereby binds payload and signature without being self-referential. The anchor evidence MUST be retained alongside the receipt for the applicable retention window. Verifiers MUST reject Compliance Receipts that lack at least one valid anchor.¶

An anchor MAY be attached after issuance if the receipt is persisted with an unambiguous pending marker and the anchor lands within a documented bound. For [OPENTIMESTAMPS], this profile imposes a 7-day deadline; this is a profile-imposed bound, not a property of the OpenTimestamps protocol, whose calendar-to-block upgrade time depends on the calendar operator's publication interval. [RFC3161] tokens MUST be obtained synchronously. A verifier MUST treat a pending receipt as non-conformant once the bound elapses.¶

The anchor MAY cover an aggregate of receipts (for example, a Merkle root over a batch) rather than each receipt individually, provided that the inclusion proof linking the receipt to the aggregate is retained alongside the receipt and the aggregate anchor.¶

Where the anchor type is [RFC3161], the full TimeStampResp DER bytes MUST be retained, sufficient for offline verification by a holder with access to the TSA's published public key. Time-stamp tokens carrying ESSCertIDv2 per [RFC5816] MUST be accepted by Compliance Verifiers. Where the anchor type is [OPENTIMESTAMPS], the upgrade from the initial calendar attestation to the Bitcoin block attestation MUST be completed within the 7-day profile-imposed bound, and the upgraded proof MUST be retained for the applicable retention window per the second paragraph of this section.¶

Each entry in the top-level anchors array is an object with the following members.¶

type:

REQUIRED string discriminator. MUST be one of rfc3161 or opentimestamps.¶

value:

REQUIRED on every anchor entry. The anchor token bytes, base64-encoded. For rfc3161 the value is the base64 encoding of the full TimeStampResp DER bytes (sufficient for offline cryptographic re-verification by a holder with access to the TSA's published public key). For opentimestamps the value is the base64 encoding of the OpenTimestamps proof blob (the .ots serialization). A verifier MUST cryptographically re-verify the anchor against the signed envelope using these bytes per Section 9.1; anchor entries served without value MUST NOT be reported as anchor_valid_*=true.¶

status:

OPTIONAL informational string. When present, MUST be one of anchored (the anchor has reached its final attestation state: an [RFC3161] token has been obtained, or an [OPENTIMESTAMPS] commitment has upgraded to its Bitcoin block attestation), pending (the anchor has been requested but the final attestation state has not yet been reached, e.g. an OpenTimestamps commitment that has been submitted to a calendar but has not yet upgraded to a Bitcoin block within the 7-day bound of this section), or failed (the anchor submission was attempted and did not produce a usable attestation, e.g. a TSA returned an error response or an OpenTimestamps calendar refused the commitment). status is operational metadata; a verifier MUST NOT derive cryptographic validity from status alone, and MUST always re-verify the value bytes per Section 9.1.¶

bitcoin_block:

OPTIONAL informational string. The Bitcoin block hash at which an [OPENTIMESTAMPS] commitment was anchored. Present only on entries with type=opentimestamps and status=anchored; absent on rfc3161 entries and on pending or failed OpenTimestamps entries. bitcoin_block is operational metadata; a verifier MUST NOT derive cryptographic validity from bitcoin_block alone, and MUST always re-verify the value bytes against the OpenTimestamps proof per Section 9.1.¶

5.5. Extension Fields

This profile defines three extension fields that MAY appear in the signed payload alongside the fields defined by [ACTA-RECEIPTS]. The first two, risk_class and incident_class, are defined in this section. The third, counterparty_binding, is defined in Section 5.6.¶

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-AI-ACT], the documentation is the Section 6-1-1703(2) risk management policy and program.¶

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 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 of [HIPAA-SECURITY]. Implementations MAY refine the set, provided the flattened mapping in the Audit Pack manifest (Section 8) 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 extension fields appear inside the signed payload object and are therefore covered by the upstream Section 5.6 signature scope. Both fields are OPTIONAL at the syntactic level but MAY be REQUIRED by the regime bindings in Sections 5 and 6 of this document.¶

Implementations MAY define additional extension fields. Such fields MUST NOT collide with names defined by [ACTA-RECEIPTS] or by this document. Implementations defining extension fields SHOULD register them in the registry described in Section 11.¶

5.6. 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 full signed envelope 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.3 validate independently regardless of whether B's observed bytes equal A's signed bytes. action_ref is a correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS] Section 2.2); counterparty_binding moves the evidence onto B's own COSE or JWS signature, which the verifier already trusts.¶

"counterparty_binding": {
  "envelope_hash": "bDqg...5PE=",
  "receipt_ref": "asqav-receipt://org/123/agent_A/seq/4811",
  "expect_ack_from": "00000000000000000098",
  "transport_label": "mcp"
}

6.1. EU AI Act Article 12 Binding

Each subsection cites the operative phrase of Article 12 and binds it to the receipt field that satisfies it.¶

6.2. EU AI Act Article 26 Binding

6.3. DORA Article 17 Binding

7.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.¶

7.2. Colorado AI Act (SB 24-205) Binding

[COLORADO-AI-ACT] imposes deployer obligations effective June 30, 2026 (per Senate Bill 25B-004, which postponed the original February 1, 2026 effective date). The Act regulates the deployment of High-Risk AI Systems and the prevention of algorithmic discrimination.¶

7.3. Texas Responsible AI Governance Act (HB 149) Binding

[TEXAS-TRAIGA] takes effect January 1, 2026. The Act adopts an intent-based liability framework for the development and deployment of AI systems and provides a safe harbor at Section 552.105(e)(2)(D) of the Texas Business and Commerce Code for organisations that substantially comply with the most recent version of [NIST-GENAI-PROFILE], or another nationally or internationally recognized risk management framework for AI systems, and operate an internal review process.¶

7.4. HIPAA Security Rule Binding (45 CFR Part 164, Subpart C)

[HIPAA-SECURITY] applies to Covered Entities (HIPAA) that handle electronic protected health information. The bindings below apply only to receipts whose underlying Actions reference electronic protected health information.¶

7.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.¶

7.6. SEC Broker-Dealer Recordkeeping Binding (17 CFR 240.17a-4)

[SEC-17A-4] applies to Broker-Dealers, Security-Based Swap Dealers, and Major Security-Based Swap Participants. The bindings below apply only to receipts produced inside such entities.¶

7.7. CIRCIA Binding (Cyber Incident Reporting for Critical Infrastructure Act of 2022)

[CIRCIA] requires Covered Entities (CIRCIA) to report Covered Cyber Incidents to the Cybersecurity and Infrastructure Security Agency within 72 hours of reasonable belief that the incident has occurred, and to report ransom payments within 24 hours. The reporting obligations take effect upon publication of the final rule. Pending publication, the bindings below apply on a voluntary basis.¶

9.1. Mandatory Checks

A Compliance Verifier MUST perform all of the following checks before treating a receipt as a Compliance Receipt.¶

• Verify the signature using the algorithm declared in signature.alg, in accordance with [ACTA-RECEIPTS].¶
• Resolve the verification key through one of the key-distribution mechanisms described in Section 4.3 of [ACTA-RECEIPTS] (well-known JWK Set or out-of-band distribution), or through Audit Pack trust-anchor metadata. The verifier MUST NOT trust a verification key embedded in the receipt envelope.¶
• Verify that all fields marked REQUIRED by Section 5 are present and well-formed.¶
• Verify the hash-chain linkage by recomputing SHA-256 over the canonical signing-input bytes of the immediately preceding receipt (the JCS-canonical serialization of the predecessor's signed payload object, per Section 5.3) and comparing the lowercase hex encoding to previousReceiptHash.¶
• Verify at least one anchor: an [RFC3161] token, an [OPENTIMESTAMPS] commitment, or both. The anchor MUST cover the signed envelope as it appears in the receipt. The verifier MUST cryptographically re-verify the anchor against the signed envelope; presence of anchor metadata without a successful cryptographic check MUST NOT yield "valid".¶
• Verify the future-skew bound on issued_at per Section 5.1.2. Past skew MUST NOT cause non-conformance when the receipt is within retention.¶
• Verify that policy_digest resolves through Section 8. A digest computed over a nonced or otherwise mixed-input form (for example, SHA-256(nonce || JCS(artefact))) MUST NOT be treated as policy_digest; the digest scope is the canonical form of the artefact alone. The verifier MUST recompute SHA-256 over the canonical form of the resolved artefact as documented in the Audit Pack manifest, and compare; for JSON artefacts the canonical form is JCS per [RFC8785].¶

A receipt that fails any of these checks MUST be reported as non-conformant.¶

9.2. 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 artefact 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.¶

9.3. Reporting

A Compliance Verifier SHOULD produce a structured per-receipt report that names the regime bindings the receipt satisfies and the outcome of the per-axis checks the verifier performed. The following fields SHOULD be emitted; the axes are independent and consumers MUST NOT collapse them into a single boolean before display.¶

regimes_satisfied:

Array of short stable regime identifiers drawn from the regimes listed in Section 8 (for example eu_ai_act, dora, nist_ai_rmf, colorado_ai, texas_traiga, hipaa_security, nydfs_500, sec_17a4a, sec_17a4b, circia). The set is open-ended; consumers MUST treat unknown identifiers as informational. Where this field is inherited from a producer-side mapping in the bundle, the bundle-level regime_mapping_disclaimer of Section 8 applies.¶

anchor_valid_ots:

Boolean. true when an [OPENTIMESTAMPS] anchor is present, has upgraded to the Bitcoin block attestation within the 7-day bound of Section 5.4, and re-verifies cryptographically against the signed envelope; otherwise false (including the case where the only present anchor is RFC 3161).¶

anchor_valid_rfc3161:

Boolean. true when an [RFC3161] token is present, carries an ESSCertIDv2 per [RFC5816] where required, and re-verifies cryptographically against the signed envelope; otherwise false.¶

policy_digest_resolved:

Boolean. true when policy_digest resolved to a retained artefact whose JCS-canonical SHA-256 matches the receipt value, per Section 9.1; false on absence, resolution failure, or digest mismatch.¶

duplicate_emission_candidate:

Boolean. true when at least one other receipt sharing action_ref and issuer_id has been observed in the same Audit Pack or in a verifier-maintained index; otherwise false. The axis is informational; this profile does not require verifiers to maintain a cross-receipt index. An absent index MUST report false rather than omit the axis, so consumers learn "no duplicate" from the value and learn "axis unknown" only from the verifier's documented capability set.¶

A receipt may carry anchor_valid_ots=true and anchor_valid_rfc3161=false (or vice versa) and still satisfy the mandatory anchor check of Section 5.4, which requires only one valid anchor. Where a receipt carries counterparty_binding per Section 5.6, the verifier SHOULD additionally emit the outcome of the check of Section 5.6.3; this profile reserves a stable field identifier for that axis pending implementation experience.¶

10.1. Tamper Resistance

The hash-chain linkage required by Section 5.3 provides tamper-evidence at the chain level. An adversary who removes a receipt from the middle of the chain MUST recompute and re-sign every subsequent envelope. The anchor evidence required by Section 5.4 binds segments of the chain to wall-clock time, raising the cost of a re-signing attack.¶

Implementations SHOULD anchor at intervals no longer than 24 hours. Implementations operating under DORA Article 17, 23 NYCRR 500.17, or [CIRCIA] SHOULD anchor at intervals no longer than one hour, given the four-hour initial-notice deadline (with 72-hour intermediate-report and one-month final-report bounds) per DORA Article 17 and the RTS in [REG-2025-301], the 72-hour notification clock under 23 NYCRR 500.17, and the 72-hour CIRCIA covered-cyber-incident reporting deadline that will apply once the CIRCIA final rule takes effect.¶

A deployment that uses only the signature, without chain linkage and anchoring, can be rolled back by an insider with control of the signing key for the period between the deletion and the next anchor. The MUST clauses of Section 5.3 and Section 5.4 close that window.¶

10.2. Chain Availability Under Single-Linear Per-Agent Serialization

This section is informative. The single-linear per-agent chain requirement of Section 5.3 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.3.¶

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 10.1) and it cannot forge receipts (those are protected by Section 10.3). 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.¶

10.3. Key Compromise

A Compliance Receipt is only as trustworthy as the key that signed it. On suspected compromise of an issuer key, the Deployer MUST publish a revocation notice that names the key, the time of suspected compromise, and the chain head at that time. Receipts signed by the compromised key after the named time MUST NOT be treated as Compliance Receipts.¶

Verifiers MUST consult revocation metadata supplied with the Audit Pack and MUST reject Compliance Receipts whose signing key was revoked at or before issued_at.¶

10.4. Retention and Long-Term Verifiability

The longest retention floor in this profile is 2192 days (six calendar years), set by Section 7.4 and Section 7.6; the EU side has a parallel five-year (1827-day) floor under Section 6.3. Both exceed the typical operational crypto-period of a signing key under recommended key-management practice. Implementations SHOULD use ML-DSA-65 from the [ACTA-RECEIPTS] algorithm registry ([FIPS204]) for receipts expected to be verified after the cryptographic lifetime of classical signature schemes ends. Implementations MUST retain public key material for the entire retention window.¶

10.5. Privacy

[ACTA-RECEIPTS] prohibits the inclusion of raw prompts, tool arguments, and credentials in the signed payload. This profile extends that prohibition to the extension fields defined in this document. The risk_class and incident_class values MUST be drawn from controlled vocabularies and MUST NOT carry free-text personal data.¶

Where the underlying Action references a data subject, the payload_digest field MUST cover the data; the data itself MUST be held in a separate store that respects the data subject's rights under applicable law (including but not limited to the General Data Protection Regulation for EU data subjects, the California Consumer Privacy Act and Virginia Consumer Data Protection Act for the corresponding US states, and the HIPAA Privacy Rule where electronic protected health information is involved). A request for erasure that is granted under applicable data protection law MUST be reflected by deletion of the referenced payload, not by deletion of the receipt; the receipt remains as evidence that an Action occurred and was governed by a named policy at a named time.¶

10.6. Anchor Trust

The trust assumptions of an anchor depend on the anchor type. [RFC3161] timestamp tokens depend on the trust placed in the named Time Stamping Authority. OpenTimestamps commitments depend on the inclusion of the commitment in a public Bitcoin block. A Compliance Verifier SHOULD treat the simultaneous presence of both anchor types as stronger evidence than the presence of only one.¶

10.7. Replay

A Compliance Receipt is bound to a single Action via action_ref. Replay of a Compliance Receipt against a different Action is detectable by action_ref mismatch. The 300-second issued_at skew bound stated in Section 5.1.2 limits the window in which a freshly-replayed receipt can be presented as recent.¶

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.¶

10.8. Cross-Regime Conflict

Where the same Action is in scope of more than one regime addressed by this document, the producing system MUST satisfy the union of the applicable requirements. Where a SHOULD clause in one regime conflicts with a MUST clause in another, the MUST clause prevails. Where two MUST clauses conflict, the producing system MUST refuse to issue the receipt and MUST log the refusal as a protectmcp:lifecycle Compliance Receipt.¶

10.9. Algorithm Agility

This profile inherits its algorithm registry from [ACTA-RECEIPTS]. Implementations MUST treat the verification of a historical receipt according to the algorithm registry that was in force at issued_at, not the registry in force at the time of verification, provided that the signing key was not revoked.¶

10.10. Issuer-Misrepresentation Residual

Per-agent hash chains under Section 5.3 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 is a correlation anchor, not a cryptographic binding ([ACTA-RECEIPTS] Section 2.2). Under -03, a regulator obtains no cryptographic answer to "did the acknowledging agent acknowledge the bytes the originating agent actually sent". This revision introduces counterparty_binding (Section 5.6) as the partial mitigation; the following residuals remain.¶

• 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.6.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.6.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 the full signed bytes including A's signature; 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 10.11 is the appropriate primitive in addition to (not instead of) this profile.¶
• Payload-content semantics. The binding proves byte equality, not semantic equality. An intermediary that re-encodes A's bytes into a different but JCS-equivalent canonical form is detected (the SHA-256 differs); an intermediary that swaps A's bytes for entirely different bytes that B's policy happens to interpret as semantically equivalent is detected too. But an intermediary that swaps A's bytes for an A-signed REPLAY of a prior valid envelope from A is not detected by this binding alone; replay protection requires that the verifier also check action_ref and previousReceiptHash uniqueness within the chain segment.¶

10.11. Cross-Agent Integrity Trust Boundary

This section is informative. It records operator guidance for cases where channel-level protection is the only available defence and counterparty_binding per Section 5.6 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 [RFC8446]; 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 10.10; 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.¶

10.12. 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.3 remains internally valid. Under draft-marques-asqav-compliance-receipts-03 the only available cross-agent primitive was action_ref as a SHA-256 join key per Section 5.1.5; both A's chain and B's chain remained valid in isolation, and divergence was only recoverable through a regulator-driven post-hoc comparison of the two chains.¶

counterparty_binding introduced in Section 5.6 closes the case where M silently swaps bytes between two honest endpoints A and B. In this revision (-04), B's acknowledging receipt is REQUIRED to carry an envelope_hash computed over the exact byte stream B received (SHA-256(A's envelope) under the digest-scope rule of Section 5.6.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 MUST be reported non-conformant per Section 5.6.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 load-bearing.¶

• 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.4, 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 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 full 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.¶

Operators concerned about these residuals in the absence of single-point cryptographic defence SHOULD:¶

• Anchor receipts to multiple independent witnesses. Where both [RFC3161] and [OPENTIMESTAMPS] anchors are present per Section 5.4, 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 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 7.6.1) and the post-market surveillance regime of EU AI Act Articles 12 and 26 (see Section 6.1 and Section 6.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.1.5. 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.¶

The worst-case latency to detection for an M-only compromise (not M-B collusion) is bounded by the anchor interval recommended in Section 10.1: 24 hours by default, one hour for Deployers operating under [DORA] Article 17, 23 NYCRR 500.17, or [CIRCIA]. After the next anchor commits, the divergence between A's anchored chain segment and the digest carried in B's counterparty_binding is permanently recoverable from the anchored evidence alone, without trust in M.¶

11.1. Compliance Receipt Extension Fields Registry

IANA is requested to create a new registry titled "Compliance Receipt Extension Fields" under a new "Compliance Receipts" registry group.¶

This registry covers both signed-payload fields and envelope-level fields (siblings of payload and signature); each entry's Description identifies which.¶

Each entry contains:¶

• Field Name: a JSON object key, lowercase ASCII letters, digits, and underscore.¶
• 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.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the field name does not collide with any field defined by [ACTA-RECEIPTS], that the Reference is a stable, dereferenceable specification, and that the Vocabulary is documented sufficiently for an independent verifier to validate values.¶

Initial registry contents (each entry labelled with Scope to disambiguate signed-payload fields from envelope-level fields per the registry description above):¶

• risk_class - Scope: signed-payload - Risk classification term under the Deployer's risk management documentation - 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, and HIPAA security incident under 45 CFR 164.304 - This document - Audit Pack metadata.¶
• counterparty_binding - Scope: signed-payload - Signed-payload object carrying a base64-encoded SHA-256 digest (envelope_hash) of a peer agent's full signed envelope including signature bytes, a resolvable opaque locator (receipt_ref), an OPTIONAL expected-acknowledger identifier (expect_ack_from), and an OPTIONAL operational transport_label; see Section 5.6 for the full member set and the digest-scope rule - This document - Member vocabulary defined in Section 5.6.1; digest algorithm is SHA-256 per [ACTA-RECEIPTS] with base64 encoding per [RFC4648].¶
• anchors - Scope: envelope-level - Envelope-level array of timestamp / transparency-log anchors covering the signed envelope; entries carry a REQUIRED type discriminator (rfc3161 or opentimestamps) and a REQUIRED value field, plus OPTIONAL informational members status (anchored / pending / failed) and bitcoin_block (string Bitcoin block hash for upgraded OpenTimestamps entries); full schema is defined in Section 5.4 - This document - Anchor type vocabulary: rfc3161 per [RFC3161], opentimestamps per [OPENTIMESTAMPS].¶

This document additionally requests that IANA register counterparty_binding as a new claim in the CBOR Web Token (CWT) Claims registry established by [RFC8392], with this document as the reference and the semantics defined in Section 5.6. The requested CWT claim key is TBD by IANA; this document proposes allocation from the IANA First Come First Served range (claim keys greater than or equal to -65536 and less than -256, or greater than or equal to 65536, per [RFC8392] Section 9.1) so as not to consume Expert Review or Standards Action space. The JSON-form claim name is the literal string counterparty_binding as registered above in the Compliance Receipt Extension Fields Registry.¶

11.2. Compliance Receipt Type Namespaces Registry

IANA is requested to create a new registry titled "Compliance Receipt Type Namespaces" under the same "Compliance Receipts" registry group.¶

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.¶

The registration policy is Specification Required, per [RFC8126]. The Designated Expert(s) SHOULD verify that the namespace does not collide with any namespace already registered or any namespace reserved by [ACTA-RECEIPTS], and that the Reference is a stable specification.¶

Initial registry contents:¶

• protectmcp:acknowledgment - A receipt emitted by the B-party in a counterparty_binding pair, confirming receipt of the A-party action and carrying a digest of the bound envelope per Section 5.6 - 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 per Section 5.2 - This document.¶
• protectmcp:restraint - A receipt recording the application or release of a restraint on an agent (e.g., quota, rate limit, sandbox tightening) - 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.2) - 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 6.1.1); a registered sub-namespace under protectmcp:lifecycle that the reference cloud implementation emits today - This document.¶

draft-marques-asqav-compliance-receipts-04

Cross-agent integrity revision. The threat case is a compromised intermediary that swaps payload bytes between two honest agents while both per-agent hash chains validate independently.¶

• Section 5.3 digest-scope correction. The chain-link digest scope is the canonical signing-input bytes (the JCS-canonical serialization of the predecessor's signed payload object, the same bytes the predecessor's signature covers), NOT the envelope object that additionally includes the signature or anchors top-level keys. The earlier -04 text that said the digest covers "the entire signed receipt object including the signature field" was a Security Considerations over-reach that did not match the reference implementation and would have required every deployed chain to be re-issued. The corrected scope matches both the reference implementation and the upstream [ACTA-RECEIPTS] Section 5.7 rule. The security rationale is updated accordingly: the chain binds the signed-over content of the predecessor (recomputable offline from the predecessor's payload alone), and cross-agent envelope-including-signature integrity is delegated to counterparty_binding (Section 5.6), which IS at the envelope-including-signature scope precisely because the peer signature is the load-bearing artefact in that case. Section 9.1 is updated to match.¶
• New informative Section 10.2 in Security Considerations acknowledges that the single-linear per-agent chain rule of Section 5.3 creates a per-issuer serialization bottleneck: a denial-of-service against the predecessor pointer (database lock, network partition, slow IO) bounds chain throughput. Mitigation: issuers SHOULD use bounded predecessor-lookup timeouts, emit a structured protectmcp:lifecycle audit event with a stable chain_emission_blocked reason code when the timeout fires, and document a chain-head recovery procedure for crashed emitters. Parallel per-issuer throughput beyond a single linear chain remains the existing distinct-issuer_id escape hatch.¶
• Section 10.12 residual list is rewritten for honesty. The M+B collusion residual is downgraded from "M+B alone defeats counterparty_binding" to "M+B+(A's-storage compromise or unavailability) defeats counterparty_binding": the audit-time verifier resolves receipt_ref to A's retained envelope and recomputes the digest, so an honest reachable A's storage defeats M+B collusion alone. A new M+A collusion residual is added: M and A coordinating to produce a fraudulent A-signed envelope is fundamentally outside the receipt model's threat surface because every cryptographic invariant holds; mitigation is separation of duties between issuer and intermediary plus anchor evidence on independent witnesses under different trust roots.¶
• The worked-example appendix carries an explicit disclaimer that the keys are shown in human-readable order (not JCS-canonical lexicographic order), the sig/value/hash bytes are deterministic placeholders, and implementations MUST NOT replay or trust the example as a real receipt. The disclaimer states the JCS-canonical key ordering that an implementer would derive on the wire.¶
• Section 5.6.1 envelope_hash rule is tightened on three axes. First, the base64 alphabet is no longer ambiguous: standard base64 per [RFC4648] Section 4 on emission, OR base64url per Section 5 where the transport requires URL-safe encoding, and verifiers MUST accept both and normalise before comparison. Second, JSON-framed digest scope is now normative and mandatory-to-implement: the JCS-canonical UTF-8 byte sequence of A's signed envelope JSON object per [RFC8785], where the envelope is the three-key object {"payload", "signature", "anchors"} with anchors OPTIONAL and B forbidden from re-canonicalizing or stripping any of the three keys before computing the digest. Third, cross-framing equivalence is explicitly addressed: JCS-canonical JSON, COSE deterministic encoding, and JWS Compact Serialization with JCS-canonical payload produce different byte sequences from the same semantic payload-and-signature, so envelope_hash is framing-specific; a transcoding intermediary that re-frames A's envelope MUST be treated as a tampering event, and verifiers MUST NOT reframe before recomputing.¶
• Section 11.1 entries now carry an explicit Scope tag (signed-payload for risk_class, incident_class, counterparty_binding; envelope-level for anchors). The CWT claim request for counterparty_binding now proposes allocation from the IANA First Come First Served range of [RFC8392] Section 9.1 rather than the unqualified "unassigned integer range" placeholder, so as not to consume Expert Review or Standards Action space.¶
• The [CIRCIA] reference is corrected to cite the statutory authority (Public Law 117-103 Division Y, codified at 6 U.S.C. 681 et seq.) rather than CISA's general topic page; the March 15, 2022 enactment date is retained, and the pending NPRM at 89 FR 23644 (April 4, 2024) is named in the reference annotation.¶
• New normative Section 4.6 (Section 5.6) defines the counterparty_binding extension field, an in-payload object carrying a base64-encoded SHA-256 digest (envelope_hash) over the full signed envelope of a peer agent (including the peer's signature bytes), a resolvable opaque receipt_ref, an OPTIONAL expect_ack_from identifier (kid/issuer_id of the expected acknowledger), and an OPTIONAL operational transport_label. Section 4.6.3 (Section 5.6.3) defines the MUST-reject rule when the bound digest does not resolve, the storage obligation on the Audit Pack production layer, and the pairwise default for N-greater-than-2 chains.¶
• The anchors top-level array schema is now defined inline in Section 5.4: each entry MUST carry type and value (base64-encoded anchor token bytes), with OPTIONAL informational status (anchored / pending / failed) and bitcoin_block (Bitcoin block hash for upgraded OpenTimestamps entries). The IANA Extension Fields Registry entry for anchors is updated to reflect the four-member schema.¶
• The IANA Type Namespaces Registry initial contents now include the registered sub-namespace protectmcp:lifecycle:configuration_change emitted by the reference cloud implementation for configuration-change receipts under Section 6.1.1.¶
• CIRCIA retention floor (Section 7.7.2) is rewritten to measure two years from the submission of the most recently required CIRCIA report per proposed Section 226.13(c) of the CIRCIA NPRM at 89 FR 23644 (April 4, 2024), not from the date of the underlying Action.¶
• HIPAA retention (Section 7.4.2) is rewritten to cite 45 CFR 164.316(b)(2) with the six-year floor expressed as "six years from the date of creation or the date when last in effect, whichever is later" and the analogy basis for applying that floor to audit-log content explicitly named.¶
• EU AI Act Article 26(6) retention (Section 6.1.5) is rewritten to express the six-month floor in calendar-arithmetic terms per [ISO8601-2]; the 184-day day-count figure is retained as an informative anchoring-interval floor, and the previously-endorsed 183-day pick is withdrawn.¶
• Section 5.1.3 now states explicitly that issuer_id values MUST be bare identifiers without a scheme prefix where the scheme is unambiguous (LEI: 20-character alphanumeric self-identifying form), aligning the spec with the reference cloud emitter under the cloud-wire-conformance change.¶
• New informative Section 9.11 (Section 10.12) documents the residual threat that counterparty_binding partially mitigates (M silently swaps bytes between honest A and B) and names three operational mitigations Operators SHOULD adopt: multiple independent anchor witnesses, regulator-driven side-by-side chain comparison under SEC 17a-4 audit-trail workflow, and out-of-band M relay logs.¶
• Section 7 (Section 8) records two manifest-level fields shipped in the reference Audit Pack producer: regime_mapping_disclaimer (when per-receipt regime predicates derive from a producer-side mapping the original signer did not co-sign) and stale_pending (per-entry flag set when anchor evidence remains pending after the bound of Section 5.4).¶
• Section 8.3 (Section 9.3) replaces the prior one-paragraph clause with five SHOULD-emit per-axis fields: regimes_satisfied, anchor_valid_ots, anchor_valid_rfc3161, policy_digest_resolved, duplicate_emission_candidate.¶
• New informative Section 9.9 (Section 10.10) enumerates the residuals counterparty_binding does not solve. New informative Section 9.10 (Section 10.11) records channel-level operator guidance citing [RFC8446], [RFC9266], [RFC5705], and [RFC9421] and disclaims transport-layer security as a substitute for application-layer byte equality.¶
• Section 11 (Section 11) adds counterparty_binding to the Extension Fields Registry and requests registration as a CWT claim per [RFC8392].¶
• New normative references: [RFC9052], [RFC8949], [RFC7515], [RFC8392]. New informative references for channel-level guidance only: [RFC8446], [RFC5705], [RFC9266], [RFC9421].¶
• New normative Section 4 bounds the inputs to which the inherited JCS rule of [RFC8785] is applied: IEEE-754 floating-point numbers MUST NOT appear in the digest-covered canonical form (callers SHOULD serialize numerics as JSON strings or as integer-rational pairs in the IEEE-754 safe range), and tool-version-specific semantic equivalence (SQL case folding, path normalization, locale-aware string collation, numeric tolerance, URL percent-encoding choices) is OUT OF SCOPE for the chain layer. The chain answers byte equality for one agent identity at one wall-clock time only; semantic equivalence belongs in the policy_digest artefact and the Audit Pack manifest.¶
• Section 5.3 now states explicitly that each issuer MUST maintain a single linear per-agent chain and MUST serialize concurrent in-agent emission (parallel tool calls, thread-pool fan-out) through a single predecessor pointer in emission order. Parallel sub-chains within one agent identity (a per-receipt chain_id discriminator) 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, signing key, and chain rooted at the all-zero genesis value.¶
• Wire tightenings introduced in this revision (additive at the message level, restrictive at the verifier level): (a) the anchors entry value member is now REQUIRED where the upstream profile leaves it OPTIONAL; (b) issuer chains are normatively single-linear per issuer (no parallel chain_id discriminator), so a -03 producer that ran parallel sub-chains under one issuer_id emits non-conformant -04 receipts; and (c) IEEE-754 floating-point numbers MUST NOT appear in the canonical form covered by SHA-256 digests. A -03 receipt with a missing anchor value, parallel sub-chains, or a digest-covered float is not a conformant -04 receipt. Implementations targeting -04 SHOULD re-emit -03 receipts under -04 emission rules. The signing algorithms, the canonicalization transformation itself (JCS), the anchor types, and the regime bindings of Sections 5 and 6 are unchanged. A -03 verifier remains conformant for receipts that do not carry counterparty_binding; -03 verifiers encountering the field will ignore it per [ACTA-RECEIPTS] Section 4.2 extension semantics.¶
• Rationale paragraph of Section 4 is rewritten to ground the IEEE-754 float ban on documented divergence between mainstream JSON serializers (Python json.dumps, Go encoding/json, Java Jackson) and the ECMA-262 Number-to-String algorithm referenced by Section 3.2.2.3 of [RFC8785], rather than on a misstated claim that JCS itself fails to specify float serialization outside the safe integer range. The Unicode-normalization bullet of Section 4 is corrected to acknowledge that Section 3.1 of [RFC8785] mandates as-is preservation of Unicode strings (no NFC default).¶
• Security Considerations Section 10.1 is corrected to reflect the tiered DORA deadlines: the four-hour initial-notice clock (with 72-hour intermediate-report and one-month final-report bounds) per DORA Article 17 and the RTS in [REG-2025-301], rather than a flat 72-hour reporting deadline. New informative reference [REG-2025-301] added.¶
• The Annex II field 3.23 (Type of the incident) citation in Section 5.5 and the incident_class initial-registry entry of Section 11.1 no longer reproduces the enumeration verbatim; verifiers MUST resolve the canonical values from [REG-2025-302] directly.¶
• Section 5.2 extends the wire decision vocabulary with observation, a fourth value reserved to type protectmcp:lifecycle for receipts emitted when an Action was signed without any policy evaluation. The new value is the regulator-honest alternative to a misleading allow on the "no policy matched" path; emitters MUST refuse to issue a protectmcp:decision receipt that carries observation, and verifiers MUST reject the combination. The vocabulary-namespace registry entry for protectmcp:decision in Section 11.2 is updated to reflect that observation is reserved to protectmcp:lifecycle.¶
• New informative appendix (Appendix "Appendix - Capture Topologies for Compliance Receipt Emission") catalogues five capture topologies an operator can use to emit conformant Compliance Receipts in environments where the originating application code cannot be modified to call the receipt-emitting SDK directly: in_process_sdk, network_proxy, browser_extension, ebpf_observer, mcp_proxy. The appendix is non-normative; the capture_topology attribute it defines is OPTIONAL at the wire layer and, where present, lives in the Audit Pack manifest entry rather than inside the signed payload object, so the topology declaration does not alter signed bytes. The five values form a closed initial vocabulary at this revision; Appendix "capture_topology Vocabulary and Considerations for a Future IANA Registry" sketches a future "Compliance Receipt Capture Topologies" IANA registry under the "Compliance Receipts" registry group with Specification Required registration policy per [RFC8126] for a follow-on revision, and names reserved-value avoidance guidance for early extenders.¶

draft-marques-asqav-compliance-receipts-03

Multi-jurisdiction consolidation. The European Union profile (formerly the only profile in -02) and the United States profile (formerly the separate draft draft-marques-asqav-us-compliance-receipts-00) are merged into a single document with two regional bindings sections: Section 5 (European Union) and Section 6 (United States). Sections 1 through 4 (Introduction, Conventions, Relationship to upstream, Receipt Field Profile) and Sections 7 through 11 (Audit Pack, Verifier, Security, IANA, Acknowledgements) are shared across both regimes. Conventions terms that differ across regimes are now disambiguated with regime suffixes (Deployer (EU AI Act) vs Deployer (Colorado AI Act); High-Risk AI System (EU AI Act) vs High-Risk AI System (Colorado AI Act)). The incident_class extension field now lists every applicable canonical category in one place: ICT-related incident under [DORA] with the Annex II reporting enumeration, Cybersecurity Event/Incident under [NYDFS-500], Covered Cyber Incident under [CIRCIA], and security incident under [HIPAA-SECURITY]. The issuer_id rule now permits EIN or CIK as alternatives to LEI for US Deployers without an allocated LEI. The Tamper Resistance security consideration extends the one-hour anchoring SHOULD to NYDFS 500.17 and CIRCIA in addition to DORA Article 17. The Privacy security consideration extends to GDPR for EU data subjects and CCPA / VCDPA / HIPAA Privacy Rule for US data subjects. The Worked Example notes that the wire shape applies identically to US bindings, with only the issuer_id identifier and the vocabularies differing. IANA registries are unchanged; the Initial registry contents for incident_class now describe the multi-regime category set. No changes to the wire format, the field profile, the hash chain, the anchoring rules, the Audit Pack contents, or the Verifier checks. Section 4.1.6 (sandbox_state) and Section 4.5 (risk_class) corrected to attribute the EU risk-management documentation requirement to Article 9 of [EU-AI-ACT] (Provider's risk management system) rather than Article 26, with Article 26(1) cited as the deployer's instructions-for-use obligation that links to the Provider's Article 9 documentation. Section 6.5.3 (nydfs-retention) corrected to a single-tier five-year floor under 23 NYCRR 500.6(b) (verified verbatim against LII Cornell); the prior tiered 5-year/3-year split (claimed against the DFS Second Amendment) was incorrect because the Second Amendment does not amend Section 500.6, leaving the 2017 single-tier text in force. The 1096-day three-year audit-trail floor previously stated for NYDFS is removed.¶

draft-marques-asqav-compliance-receipts-02

Submission-ready EU-only profile. Wire-shape alignment with upstream [ACTA-RECEIPTS] (payload/signature/anchors envelope; payload_digest object form; tool_name REQUIRED for protectmcp:decision; issuer_id equals kid). EU AI Act and DORA bindings authored against Official Journal text. Anchor MUST (at least one of RFC 3161 or OpenTimestamps); both RECOMMENDED; 7-day OpenTimestamps upgrade deadline profile-imposed. Six-month AI Act floor expressed as 184 days; DORA-bound default expressed as 1827 days. IANA registries created.¶

draft-marques-asqav-compliance-receipts-01

Initial wire-shape alignment with upstream and addition of dual-anchor, hash-chain, retention, and DORA classification bindings. Subsequent revisions superseded the specific values introduced here.¶

draft-marques-asqav-compliance-receipts-00

Initial version. Defines a profile of [ACTA-RECEIPTS] that binds receipt fields to EU AI Act Article 12, EU AI Act Article 26, and DORA Article 17.¶

In-Process SDK

The originating application links the receipt-emitting SDK directly and calls it inline with the action being recorded. This is the baseline pattern [ACTA-RECEIPTS] and Sections 3 and 4 of this document are written against. The receipt carries a full payload_digest covering the action's request bytes; the SDK has direct access to the application's principal identity, the policy decision, and the request body. Vocabulary value: in_process_sdk. Trust boundary: the application process itself; the SDK runs inside the application's memory space and inherits its principal. Threat-model note: captures the full request and response payloads, the deciding principal, and the policy context; does NOT capture out-of-process side effects or actions taken by sibling processes that do not link the SDK. Reference implementation hint: the Asqav Python and TypeScript SDKs published under the asqav-sdk umbrella (Apache-2.0) implement this pattern; an operator MAY substitute any other conformant [ACTA-RECEIPTS] implementation.¶

Network-Layer Egress Proxy

A customer-owned reverse proxy or egress gateway (Envoy, NGINX, or an equivalent forward proxy) sits in the network path between the application and the downstream LLM provider. The proxy tees the request to a co-located Compliance Signer process, which receives the request bytes, applies the policy evaluation, and emits a receipt via a signer RPC. A DNS-rewrite on-ramp (CoreDNS rewriting the LLM hostname to the proxy address) or a Server Name Indication (SNI) router (SNIProxy at Layer 4) MAY be used to force application traffic onto the proxy without per-application configuration. Vocabulary value: network_proxy. Trust boundary: the customer's network egress; the proxy and signer run under the customer's operational control, and the receipt is signed by a key the customer's signer holds. Threat-model note: captures the request and response bytes that traverse the proxy and the network-layer principal identity (source IP, mTLS client cert if present); does NOT capture traffic that bypasses the proxy (direct outbound from a non-routed host, DNS-over-HTTPS to a hard-coded resolver, or TLS connections to certificate-pinned endpoints that the customer's enterprise CA cannot inspect). The receipt's issuer_id binds the customer's signer, not the originating application; the application's identity, where captured, appears as an attribute resolved through the Audit Pack manifest. Reference implementation hint: CoreDNS (Apache-2.0) for the DNS on-ramp, SNIProxy by dlundquist (BSD-2-Clause) for the SNI router, and Envoy (Apache-2.0) for the Layer-7 reverse proxy plane; none of these are normative requirements.¶

Browser Extension

A managed-browser Manifest V3 (MV3) extension installed on employee workstations via the enterprise MDM intercepts fetch, XMLHttpRequest, and EventSource requests to a configured list of LLM hostnames. The extension POSTs the intercepted request and response bytes to a Compliance Signer endpoint, which emits the receipt. For LLM hosts that pin their TLS certificates, the customer's enterprise root Certificate Authority (CA) MUST be installed in the browser trust store via MDM so that the extension's content-script interception can observe decrypted bytes. Vocabulary value: browser_extension. Trust boundary: the managed browser process on the employee workstation; the extension runs under the browser's sandbox and the employee's interactive session. Threat-model note: captures the full request and response payload for LLM calls initiated from the browser by the human user, and binds the receipt to the browser's principal identity (the user's enterprise single-sign-on subject, where the extension can read it). Does NOT capture LLM calls made by native desktop applications, server-side daemons, or browsers without the extension installed; does NOT capture traffic in incognito or private-window modes unless the extension is explicitly authorised for those contexts. Reference implementation hint: the open-source Chrome MV3 extension scaffolding published by Google under the chrome-extensions-samples repository (Apache-2.0) is a useful starting point; the customer's signer endpoint is the Asqav signer or any conformant [ACTA-RECEIPTS] implementation.¶

eBPF SNI Observer

A kernel-level extended Berkeley Packet Filter (eBPF) probe attached to the host's network stack observes outbound TLS ClientHello records. The probe extracts the SNI hostname, the JA3 client fingerprint, the source and destination addresses and ports, and the connection timestamp, and emits a lower-fidelity receipt that binds the employee, the device, the wall-clock time, and the LLM host without observing payload content. Vocabulary value: ebpf_observer. The receipt SHOULD carry an informational payload_capture attribute set to false in the Audit Pack manifest, so that a verifier or auditor does not assume payload-level evidence is recoverable. Trust boundary: the kernel of the host on which the probe runs; the probe operates below the application's user-space process and observes traffic regardless of application configuration. Threat-model note: captures the existence and counterparty of an LLM call (the "did the call happen" evidence class) and the device-and-employee binding through host attestation; does NOT capture request or response bytes, the prompt content, the model parameters, or the decision-relevant context. Useful when payload capture is operationally infeasible (TLS certificate pinning that the enterprise CA cannot defeat, third-party SaaS that egresses outside the customer's proxy plane) but the operator still needs evidence that a regulated LLM interaction occurred. Reference implementation hint: Inspektor Gadget (Apache-2.0) and Tetragon (Apache-2.0) both expose SNI and connection-metadata events from eBPF probes; neither is a normative requirement.¶

MCP Transparent Proxy

A transparent proxy sits in-path between a Model Context Protocol (MCP) client and one or more downstream MCP servers, terminating the client's stdio, Server-Sent Events (SSE), or streamable-HTTP transport on one side and re-establishing the same transport to each downstream server on the other side. The proxy observes every tools/call and resources/read JSON-RPC method invocation, signs a receipt at the moment the call is forwarded, and emits a second acknowledging receipt carrying a counterparty_binding (see Section 5.6) at the moment the downstream server's response returns. Both sides of the call are therefore bound bilaterally, with the proxy's signing key serving as the integrity anchor for the pair. Vocabulary value: mcp_proxy. The receipt SHOULD carry the invoked MCP method (for example, tools/call or resources/read) as an attribute in the Audit Pack manifest entry, so that a verifier can filter by call type without re-parsing payload bytes. Trust boundary: the proxy process and its signing key; the upstream MCP client and the downstream MCP server are both treated as honest endpoints under the threat model of Section 10.12, with the proxy itself being the named intermediary whose tampering risk counterparty_binding mitigates. Threat-model note: captures the full MCP request and response payload, the method name, and the client and server principal identities visible at the transport boundary; does NOT capture MCP traffic that bypasses the proxy or that uses a transport the proxy does not implement. Reference implementation hint: the Asqav MCP transparent proxy published under the asqav-mcp repository (Apache-2.0) and the upstream FastMCP project (MIT) on which it builds; neither is a normative requirement.¶

capture_topology Vocabulary and Considerations for a Future IANA Registry

The five values defined in this appendix (in_process_sdk, network_proxy, browser_extension, ebpf_observer, mcp_proxy) form the closed initial vocabulary for the capture_topology attribute. The attribute is OPTIONAL at the wire layer and, where present, MUST appear in the Audit Pack manifest entry for the receipt rather than 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.¶

This document is an Independent Submission and does not request IANA action for the capture_topology vocabulary at this revision. A future revision MAY request creation of a "Compliance Receipt Capture Topologies" registry under the same "Compliance Receipts" registry group described in Section 11, with the registration policy of Specification Required per [RFC8126] and an initial set populated from the five values above. Until such a registry exists, implementations that extend the vocabulary SHOULD document the new value in a reference specification and SHOULD avoid colliding with the five reserved values above. The Designated Expert(s) for any future registry SHOULD verify that a candidate value names a distinct topology (a different trust boundary or a materially different payload-fidelity class) rather than a variant of an existing one, and that the candidate's threat-model note states what is captured and what is not, in the form used by the five entries in this appendix.¶