]> Continuity Laboratories

hello@continuitylaboratories.com

Security Individual Submission authority succession signed receipts AI agents offline verification Ed25519 JSON canonicalization Autonomous agents are upgraded, replaced, suspended, and restored while holding real operational authority. A Succession Receipt is a portable, signed JSON document that proves one completed, policy-gated transfer of authority between two agents: which agent held the authority, which agent holds it now, under what legitimacy determination the transfer ran, and which obligations carried forward, with every claim grounded in signed evidence events embedded in the receipt itself. Receipts are verifiable offline by parties who do not operate the issuing system, using only the issuer's public key. This document specifies the receipt wire format, its canonicalization and signature scheme (JSON Canonicalization Scheme with Ed25519), the verification algorithm including bidirectional claim grounding, and an optional claim that binds a pre-execution authorization of the handoff to the succession evidence. Where decision receipts prove what an agent did, and delegation receipts prove what an agent may do, Succession Receipts prove that an agent legitimately became the holder of an authority.

Introduction Deployed autonomous agents hold credentials, approve transactions, and act under delegated authority. When such an agent is upgraded, replaced, suspended, or restored, its successor inherits real power. Existing identity and authorization infrastructure answers "who is the successor?" and "may this request proceed?"; it does not produce portable evidence that authority, obligations, and accountability were legitimately carried from predecessor to successor. A Succession Receipt closes that gap. It is a self-contained JSON document, issued by the system of record that governed the transfer, carrying: the parties (predecessor and successor agents, called stewards); the authorities revoked from the predecessor and derived for the successor, with their recorded bases; the legitimacy evaluation the transfer was approved under; the obligation and commitment lineage carried forward; and the evidence: the signed, hash-chained events the issuing system recorded, embedded verbatim, so that every claim above is checkable against them. A relying party — an auditor, a counterparty, a regulator — verifies a receipt offline with only the issuer's Ed25519 public key: no API call, no access to the issuing system, no trust in its operator's infrastructure. Verification recomputes every hash from the document's own bytes and enforces claim grounding in both directions (), so a receipt can neither invent nor conceal an effect of the transfer. This document is companion to adjacent work on signed agent evidence: decision receipts attest individual machine-to-machine authorization decisions, and delegation receipts attest grants of permission to act. Per-hop delegation-chain identity, as in PEDIGREE , attests how authority flows downward through live delegation from a root; Succession Receipts attest a different event class again — the transfer of the authority of record itself between agent generations, with obligation lineage — and are complementary to all three. The formats share primitives (Ed25519 , JSON Canonicalization Scheme ) deliberately. Pre-execution authorization of individual material actions is a fourth adjacent class: an authorization receipt establishes that a named human authorized an exact action before it ran, where a Succession Receipt establishes that the authority of record itself moved legitimately between agent generations. The two compose by treating the handoff itself as a material action: this document defines an OPTIONAL authorization_binding claim () that binds the handoff's canonical action identifier and the hash of the authorization receipt that approved it into the succession evidence, connecting the exact human-approved handoff to the exact transfer event without conflating the two formats. The claim is additive — a receipt that omits it verifies exactly as one that predates it — and a cross-format conformance vector, contributed by the authorization-receipt format's author, pins the binding in the published corpus . A wider set of agent-evidence formats has grown up alongside these, and nearly all of it records what an agent did: hash-chained action receipts , SCITT statement profiles for agent actions and their selective-disclosure form , AI-agent receipts , execution profiles , and existence-time anchoring . An architecture for the layer they occupy is developing in , whose Authorization Transition Record work item asks for a record carrying previous state, new state, triggering event and responsible actor, replayable to reconstruct the authorization in force. This document instantiates that shape for one consequential class of transition — the handoff of the authority of record between agent generations — and is complementary to the action-level formats rather than an alternative to any of them. The wire format specified here is implemented and published with a machine-readable conformance corpus (golden vectors plus tamper cases that MUST fail at named checks) , against which independent verifier implementations can validate; the format steward additionally maintains a reference verifier, including a no-install in-browser verifier. The same repository publishes companion evidence formats under the same corpus discipline — ledger exports, capability credentials, external anchoring checkpoints, a refusal-transparency digest attesting transitions an agent system refused to perform, and selective-disclosure projections of the receipts specified here (partial views that verify against the one issuer signature) — which are outside the scope of this document.

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 when, and only when, they appear in all capitals, as shown here.

Steward:

An agent (or agent generation) that can hold authority and carry obligations in the issuing system's registry.

Succession:

The governed process by which authority of record transfers from a predecessor steward to a successor steward. Only completed successions yield receipts.

Issuer:

The system of record that governed the succession, recorded its events, and signs the receipt.

Relying party:

Any holder of the receipt verifying it against the issuer's public keys.

Evidence event:

One event envelope from the issuer's append-only ledger, embedded verbatim in the receipt.

The Receipt Document A Succession Receipt is a UTF-8 JSON object shaped after the W3C Verifiable Credentials data model as plain JSON: the @context member is carried for interoperability, and JSON-LD processing is NOT REQUIRED. The complete normative member catalog, with types and constraints, is the AHR specification , which publishes version 0.1 (frozen) and version 0.2 (current); this section summarizes the structure a verifier depends on and shows a version 0.2 receipt.

", "succession_id": "", "predecessor": { "steward_id": "", "revoked_authorities": [ ... ], "replaced": true }, "successor": { "steward_id": "", "authority_id": "", "authority_scope": "...", "accountability_chain_id": "", "authority_status": "granted" | "active" }, "legitimacy": { "legitimacy_id": "" }, "constitution": { "genesis_event_hash": "", "amendments_ratified": , "amendment_head_hash": "" }, "ledger_binding": { "height": , "event_hash": "" }, "obligations_carried": [ "", ... ], "commitments_carried": [ "", ... ], "authorization_binding": { // OPTIONAL (see below) "caid": "", "receipt_hash": "<64 lowercase hex, authorization receipt>", "format": "EP-AUTHORIZATION-RECEIPT-v1" } }, "evidence": [ , ... ], "proof": { "type": "CSSEd25519Signature", "created": "", "verification_method": "", "receipt_hash": "", "signature": "ed25519::" } } ]]>

The constitution and ledger_binding members are REQUIRED at version 0.2 and absent at version 0.1. constitution records the constitutional lineage the transfer ran under: genesis_event_hash (the hash of the genesis event that roots the lineage), amendments_ratified (the count of ratified amendments in force at completion), and amendment_head_hash (the hash of the latest such amendment, omitted when the count is zero). ledger_binding records the receipt's evidence horizon: height (the 1-based position of the receipt's final evidence event in the issuer's ordered event stream) and event_hash (that event's hash). Both are grounded in the embedded evidence (), so a verifier recomputes them from the receipt alone. A version 0.1 receipt names urn:css:ahr:v0.1 in @context, sets spec_version to 0.1, and omits both members; a conforming verifier accepts either version. The authorization_binding member is OPTIONAL and additive. A receipt that omits it verifies exactly as a receipt that predates the claim, and its presence does not change spec_version. When present, it binds the succession to a pre-execution authorization of the handoff; its members and verification are specified in . Each evidence event envelope carries event_id, event_type, aggregate_type, aggregate_id, optional causation_id / correlation_id / previous_event_id / actor_id, timestamp (), event_version, payload, event_hash, and an optional signature. Envelopes are embedded exactly as recorded — stored bytes, not re-derived ones.

Canonicalization and Signatures

Canonical Form The canonical bytes of a receipt are its JSON serialization with the proof member absent, object member names sorted lexicographically, no insignificant whitespace, and no HTML escaping. For the receipt's value domain (strings, integers, arrays, objects; no floating-point numbers) this coincides with the JSON Canonicalization Scheme .

Hash-Then-Sign The proof signs the lowercase hexadecimal SHA-256 digest of the canonical bytes (the digest string is the signed message). receipt_hash records that digest; signature is the canonical signature string:

":" ":" base64url(signature-bytes) ]]>

ed25519 (, deterministic signatures) is the sole algorithm registered at spec versions 0.1 and 0.2. key_id is an issuer-managed label, deliberately NOT derived from the key: a verifier holds a map from key_id to public key, so key rotation adds a mapping without invalidating already-issued receipts. An unrecognized <alg> prefix MUST be rejected; new algorithms (including post-quantum schemes) are additive prefixes registered by a new spec version, never a mutation of an existing one.

Evidence Event Integrity Every evidence event's event_hash is the lowercase hexadecimal SHA-256 of the concatenation of: event_id, event_type, aggregate_type, aggregate_id, the timestamp in UTC with trailing fractional-second zeros omitted, the decimal event_version, the payload's JSON serialization in document member order (the producer's serialization order, preserved by the receipt), and previous_event_id (empty string when absent). An event's optional signature is the canonical signature string over its event_hash.

Verification A verifier is given the receipt document and the issuer's public keys, pinned out of band. Verification MUST perform, in order: Proof. Recompute the canonical hash () from the document. It MUST equal proof.receipt_hash, and proof.signature MUST verify against it under the key named by its key_id. A missing proof, an unknown key_id, a hash mismatch, or a failed signature check is fatal. Verifying against the recomputed hash ensures any content tampering — including of receipt_hash itself — fails here. Evidence integrity. Every evidence event's hash MUST recompute to its stored event_hash per . Evidence authenticity. Every present evidence signature MUST verify. An absent signature is reported, not fatal (deployments that sign no events still produce receipts whose proof covers the evidence bytes); a present-but-invalid signature is fatal. Claim grounding, both directions. Every credentialSubject claim MUST be supported by a matching evidence event: the completion event anchors succession_id and validFrom; the proposal names both parties; the approval names the legitimacy evaluation; the successor's authority grant matches steward, scope, and accountability chain and is correlated with the completion; a claimed replaced predecessor has its replacement event; every claimed revocation has its revocation event with the claimed basis. Conversely, every lineage effect in evidence MUST be declared by the claims: an inherited obligation or commitment absent from the carried lists, or a revocation absent from revoked_authorities, is fatal. A receipt can therefore neither invent nor conceal an effect of the transfer. For version 0.2 receipts, two further claims are grounded. constitution MUST be supported by exactly one GenesisInitialized event in the evidence whose hash equals genesis_event_hash; when amendments_ratified is greater than zero, amendment_head_hash MUST equal the hash of the latest AmendmentRatified event in evidence and the count MUST match. ledger_binding.event_hash MUST equal the hash of the receipt's final evidence event, and height states that event's position in the issuer's ordered stream; against a ledger export or an anchored checkpoint a relying party can additionally confirm that no event at or below height was omitted — a completeness cross-check a single receipt cannot provide alone. Authorization binding (optional). If credentialSubject.authorization_binding is present, perform the cross-format check of ; if it is absent, the receipt asserts no cross-format binding and this step is satisfied. A conforming verifier MUST accept every golden vector and MUST reject every tamper case of the published conformance corpus at the named check.

Optional Authorization Binding credentialSubject.authorization_binding is an OPTIONAL claim binding a succession to a separately verifiable authorization artifact for the handoff. It contains three string members: caid — the canonical action identifier obtained from the natively verified authorization artifact under a mapping profile independently pinned by the relying party. Where the format carries a native identifier, its specification determines that identifier. A derived identifier is a composition value, not an additional member of the native artifact. For the EMILIA Protocol formats the derivation is specified in . receipt_hash — exactly 64 lowercase hexadecimal characters, encoding SHA-256 of the complete native authorization artifact under the canonicalization specified for the named format. For EP-AUTHORIZATION-RECEIPT-v1 this is SHA-256 of the JCS canonicalization of the complete, unchanged Trust Receipt, including log_proof and approver_key_proofs (). No member is added or removed. This is not the action hash, not a Merkle leaf hash, and not the succession receipt's own proof.receipt_hash. format — a non-empty identifier naming the native artifact format and its verification procedure. For the Trust Receipt of Section 7.2 the identifier is EP-AUTHORIZATION-RECEIPT-v1. EP-RECEIPT-v1 names a different generic envelope and MUST NOT dispatch to that verifier. EP-QUORUM-v1 names the quorum reference suite of ; it does not by itself identify a complete receipt carrier, a canonicalization, or a native receipt-verification procedure. A multi-approver binding MUST identify an applicable carrier format and independently authenticate its quorum policy and member mapping. Unknown additional members of authorization_binding are ignored. This does not permit unknown members to be inserted into an authorization artifact whose native schema is closed. A verifier that implements this claim processes it as follows. If the claim is absent, report that no authorization binding is asserted. Absence does not invalidate the succession receipt. If present, check its well-formedness as above. A malformed claim invalidates the succession receipt. If the native artifact, its supported format definition, or the inputs required for native verification are unavailable, report that the binding is not verified. Successful well-formedness checking and the succession issuer's proof do not establish the binding. This incomplete result is not a demonstrated hash or identifier mismatch, and a relying party requiring a verified binding MUST NOT accept it as satisfied. With the artifact and required inputs available, verify the unchanged artifact using its native verification procedure and independently selected trust inputs. An artifact that fails native verification cannot establish the binding. For an EP Trust Receipt, follow Section 7.3; the succession issuer's signature is not a substitute for that verification. Recompute the complete artifact digest and require equality with receipt_hash. A mismatch invalidates the binding and the succession receipt under this claim's verification rule. Obtain the artifact's action identifier as its format defines. For the EMILIA Protocol formats, project the verified Action Object under the exact relying-party-pinned CAID mapping of . Do not add the derived identifier to the native receipt and do not change any native signature input. A missing, failed, lossy, or unpinned mapping is indeterminate, not an action match. Where derivation succeeds, require byte-for-byte equality with caid; a mismatch invalidates the binding and the succession receipt. The digest comparison precedes the identifier comparison. Native-verification failure, incomplete verification, and demonstrated binding mismatch are three distinct results; the descriptive names used here add no wire members to either format. The binding preserves each format's scope. A Trust Receipt records approval evidence and terminal consumption under its native profile; it does not itself grant authority or prove external execution. Succession verification establishes the succession issuer's recorded transfer, subject to this document's trust model. Cross-format equality does not strengthen either guarantee — and neither format speaks for the other. The published corpus pins this rule and its evaluation order. Corpus revision ahr-v0.2/r2 pinned the earlier composition contract and remains unchanged as historical evidence of it: its bytes, hashes and expected results are not edited, and a corpus revision alone must never silently reinterpret an existing format identifier. The corrected native-artifact example is therefore published as a new revision, ahr-v0.2/r3, once the native artifacts contributed by the authorization-receipt format's author are integrated.

Versioning and Stability spec_version identifies the wire format. Published versions are never mutated: format changes only ever add a new version with new golden vectors, and verifiers SHOULD continue to verify every published version. Versions 0.1 (frozen) and 0.2 (current) are drafts on a stated stability ladder toward a stable 1.0 ; 0.2 adds the constitution and ledger_binding claims additively, and a conforming verifier accepts both versions. New OPTIONAL claims are additive and do NOT bump spec_version: a verifier that does not implement such a claim ignores it while still verifying the receipt. The authorization_binding claim () is introduced under exactly this rule — it is version-independent and changes no existing receipt's bytes.

Security Considerations A receipt proves what the issuer recorded, not that the issuer is honest. Verification establishes internal consistency under the issuer's key, not tamper evidence against the issuer. A lying issuer gains the least possible ground: re-signing altered content with an untrusted key fails at the proof; altering embedded evidence while re-signing the receipt without recomputing event hashes fails at evidence integrity; hiding or inventing lineage fails at claim grounding. A malicious or compromised issuer that additionally recomputes event hashes and re-signs both the events and the receipt, however, can produce an internally consistent receipt for a history its ledger never recorded. Relying parties requiring stronger-than-issuer guarantees SHOULD pin the event-signing key independently of the receipt-signing key where the deployment separates them, and SHOULD rely on the externally anchored ledger-head commitments discussed below, against which such a fabrication becomes detectable. The conformance corpus encodes these attacks as executable cases, including re-signed variants. The event-hash input of concatenates adjacent variable-length fields without length framing, so distinct field tuples can in principle produce identical hash input: event_type and aggregate_type are adjacent, individually unconstrained strings, and a shifted boundary between them yields the same bytes. Within a single receipt every evidence byte is additionally covered by the issuer proof, but an event signature is a signature over the hash string alone and is therefore reusable wherever the same hash input can be reproduced. Verifiers SHOULD reject events whose event_type or aggregate_type fall outside the vocabulary the issuing format publishes (the conformance corpus pins the reference vocabulary, in which no two event types stand in a prefix relation), and a future format version will adopt length-prefixed hash components; published versions are never mutated and continue to verify under the current rule. The authorization binding does not extend trust to the other format. When authorization_binding is verified against a held authorization receipt, the guarantee is a byte-exact correspondence between this succession and that pre-execution approval, no stronger than the authorization receipt's own proof under the keys a relying party trusts for it. The binding neither vouches for the authorization issuer nor lets either issuer speak for the other; a verifier lacking the authorization receipt learns only that the claim is well-formed. Relying parties apply the same key-pinning discipline to the authorization format's issuer as to this one. Key pinning is the trust root. Verification binds evidence to the holder of a named key. Relying parties MUST obtain issuer keys through a channel they trust and SHOULD pin them; fetching keys from the issuer's own origin proves only self-consistency. Key rotation adds a key_id; it MUST NOT invalidate previously issued receipts. Omission and rollback are out of a single receipt's scope. A receipt proves one completed succession; it cannot prove that no other events exist. Whole-ledger claims are the companion ledger-export format's job, and resistance to retroactive truncation or rollback requires externally anchored commitments to the ledger head (in the style of transparency logs ), both published alongside this format . The anchoring extension point is designed to register ledger-head commitments with a SCITT transparency service , so anchoring composes with the emerging standard rather than inventing a parallel witness ecosystem. A version 0.2 ledger_binding claim states the evidence horizon (height) at which such a completeness cross-check applies. Deterministic serialization is load-bearing. Implementations MUST reproduce the canonical form and the payload's document-order serialization exactly; the corpus exists to make divergence detectable. Implementations SHOULD reject documents whose numbers fall outside the integer value domain rather than guess at float formatting.

IANA Considerations This document has no IANA actions. The signature-algorithm registry is internal to the format's spec-version ladder (); a future version of this specification may propose a formal registry if the format is adopted for standards-track work.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. EMILIA Protocol, Inc. This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. EMILIA Protocol, Inc. Authorization, delegation, execution, and audit artifacts often identify an action using format-local content and digests. Those digests are not directly comparable when the formats select or encode material action fields differently. This document defines the Canonical Action IDentifier (CAID): a typed action object, a canonicalization and digest suite, a compact identifier string, and immutable action-type definitions with required material fields. It also defines an Action-Mapping Profile for projecting independently verified native artifacts into a common action type, with the closed results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, and INDETERMINATE. CAID carries no trust semantics. It does not establish identity, authority, authorization, execution, safety, or legal reliance. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. ScopeBlind (Veritas Acta) This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp. All of these are signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. Authproof This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol reduces reliance on the operator as a trusted intermediary by making the user's private key the sole signing authority over the delegation record. Glyphzero Labs Inc. This document defines PEDIGREE (Per-Agent Delegation Identity with Governance-Enforced Execution), an identity and delegation framework for AI agents that extends the workload-identity model of SPIFFE (RFC 9542 / draft-ietf-wimse) with cryptographic per-hop delegation, monotonic scope attenuation enforced at mint and at verify, and dual- layer authority enforcement combining an operator-controlled ceiling with per-parent mandate narrowing. PEDIGREE complements AAuth (draft-hardt-aauth-protocol) and AIP (draft-prakash-aip) by providing: (a) dual-enforcement semantics absent from both, (b) Cedar-policy mandates with static-analysis proofs of narrowing, (c) strict cryptographic parent-token re- verification that catches parent-swap attacks missed by append-only token chains, and (d) a native bridge to existing SPIFFE deployments. EMILIA Protocol, Inc. This document defines a multi-party approval predicate over action- bound human signoffs: valid signatures, admitted roles, distinct approvers and keys, threshold, and an optional ordered trail. The relying party pins the governing policy and approver directory independently. Passing the predicate is approval evidence, not a complete authorization decision, proof of execution, or proof of unused authority. This revision repairs the strong ordered profile. A successor signs a digest of the completed predecessor signoff, including its signature, rather than a precomputable context. The versioned profile establishes causal dependence on a completed prior proof under the cryptographic assumptions; it does not establish trusted wall-clock time or human comprehension. Legacy context-only chains cannot satisfy it. JavaScript, Python, and Go reference verifiers share a corpus in one repository. Agreement is a same-team consistency check, not independent interoperability evidence or a formal proof of the new construction. kriya native This document specifies a format for action receipts: compact, individually signed JSON records that state that a specific AI agent attempted a specific action at a specific time, under a specific policy decision, and what the outcome was. Receipts are linked into an append-only hash chain so that deletion, insertion, reordering, or modification of any previously recorded receipt is detectable by a verifier that holds only the records and the signer's public key. The format is deliberately small and self-contained. Verification requires no network access, no service operated by the producer of the receipts, and no state beyond the records themselves and a trust anchor obtained out of band. This document specifies the record fields, the canonical byte sequence that is signed, the chain linkage rule, the verification procedure, and test vectors. Action State Group, Inc. This document defines a SCITT statement profile for recording what an AI agent did: the Agent Action Capsule. A Capsule is a digest- committed record of one agent action carrying its verdict-level disposition (executed, blocked, denied, errored, timed out), the deterministic constraints that were evaluated, the effect that was committed together with a confirmed-effect binding that distinguishes a dispatched attempt from an observed result, and an honest human-in- the-loop flag. Capsules are identified independently of signing and MAY be authenticated by one or more COSE_Sign1 Producer Envelopes. Its Capsule ID can separately be made transparent by registration in a SCITT Transparency Service. A Capsule is recorded on every verdict, including refusals: a blocked or denied Capsule is the auditor-grade evidence that a gate worked. Action State Group, Inc. This document normatively profiles the per-field selective-disclosure extension point reserved in draft-mih-scitt-agent-action-capsule-01 Section 9.2 (Selective Disclosure). It defines the salted-hash commitment encoding, decoy-digest construction, disclosure format, producer requirements, and verifier checks for selectively disclosable fields in Agent Action Capsule payloads. The mechanism follows the SD-JWT selective-disclosure model (RFC 9901) — salted- hash commitments, decoy digests, and disclosed [salt, name, value] triples — using JCS (RFC 8785) canonicalization, which is already the base Capsule profile's canonical form. SD-JWT (RFC 9901) is the JSON form; SD-CWT (draft-ietf-spice-sd-cwt) is the CBOR/dCBOR sibling. Because the Capsule payload is JSON, this profile uses the SD-JWT (JSON) construction, cited alongside the SPICE WG's SD-CWT work for SCITT-ecosystem consistency. Verifier checks are deterministic and reproducible from the Capsule bytes plus a provided disclosure set alone; no clock, network access, model invocation, or external lookup beyond the provided disclosures is required. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. VERIDIC Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. Umarise This document defines a mechanism for temporal anchoring of digital artifacts by committing cryptographic hashes to the Bitcoin blockchain via the OpenTimestamps protocol. The resulting proof is independently verifiable by any party with access to independently validated Bitcoin chain data, without contacting the anchoring service. The SCITT Architecture is used as the primary integration example. No changes to the SCITT architecture are required. Ericsson Fraunhofer SIT This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements.

Acknowledgments The format was extracted from a production authority-succession system of record and hardened against its red-team findings; the conformance corpus packages those findings as executable verification cases. Iman Schrock provided detailed external review of the -00 revision, and contributed the cross-format conformance vector that pins the authorization binding of ; this document incorporates both. The -02 review identified that 's cross-check could not be implemented from the documents this specification cited, which -03 corrects. For -04 the same reviewer supplied the complete native authorization artifacts and executable checks on which the corrected is based, and identified that the illustrative r2 cross-format vector carried the claim at a path the normative text does not use. The -04 review identified that the illustrative receipt in still carried the format value forbids dispatching on, which -05 corrects.

Change Log -05: Corrected the illustrative receipt in , whose authorization_binding.format still read EP-RECEIPT-v1. -04 removed that value from the normative text of and stated that it names a different generic envelope which MUST NOT dispatch to the detailed verifier, but left it standing in the one place a reader copies from. The example now reads EP-AUTHORIZATION-RECEIPT-v1, agreeing with and with the ahr-v0.2 corpus. Editorial only: no normative statement changed, no wire-format change, no change to spec_version, and the published corpus bytes, hashes and expected results are untouched. -04: Corrected against the native authorization-receipt format. The -02 and -03 text derived the action identifier, embedded it, and then hashed; it also offered EP-RECEIPT-v1 and EP-QUORUM-v1 as example format values. Both were wrong. EP-RECEIPT-v1 names a generic envelope that forbids dispatching to the detailed verifier, EP-QUORUM-v1 names the reference conformance suite of rather than a receipt carrier, and the correct identifier for the Trust Receipt is EP-AUTHORIZATION-RECEIPT-v1. The verification order is now: verify the unchanged native artifact, recompute the digest over the complete artifact including its proof members, and only then derive and compare the identifier under a separately pinned lossless mapping — the derived identifier is never inserted into the native artifact. Named incomplete verification as a third result distinct from native failure and from demonstrated mismatch, so an unavailable input can neither pass nor be reported as a mismatch. is cited informatively: no conforming implementation needs it, and a normative reference would add a publication dependency this document does not require. Added informative references situating this format among the agent-evidence work published since -00. No wire-format change and no change to spec_version: a receipt that omits the claim is unaffected, and the existing ahr-v0.2/r2 bytes, hashes and expected results are untouched. -03: Moved to Normative References and added there, and cited both at each point in where the cross-check delegates to the named format. The -02 revision stated the cross-check as a MUST while citing the authorization-receipt format informatively and the canonical-action-identifier specification not at all, so the mandatory branch could not be implemented from the cited documents; this revision closes that gap. Because this document is Informational, the normative references introduce no downward reference (RFC 3967 applies to standards-track documents). Also stated explicitly that a verifier lacking the named format's specification falls back to the well-formedness-only check rather than accepting the binding unverified. No wire-format change, no change to spec_version, and no change to any claim, proof, canonicalization, or event-hash rule. -02: Defined the OPTIONAL authorization_binding claim (), which binds a pre-execution authorization receipt's canonical action identifier and canonical hash to the succession, with its verification rule and evaluation order (recomputed hash before identifier; a derived identifier is part of the hashed canonical representation — derive, embed, then hash). The claim is additive and version-independent: it does not change spec_version and does not alter the wire format of any receipt that omits it. Added the cross-format conformance vector (corpus revision ahr-v0.2/r2) to the published corpus. No change to any existing claim or to the proof, canonicalization, or event-hash rules. -01: Added the pre-execution authorization composition note and the reference; restated the trusted-issuer security consideration as internal consistency under the issuer's key; added the event-hash framing consideration. No wire-format change.