]> 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), and the verification algorithm, including bidirectional claim grounding. 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 naturally by treating the handoff itself as a material action: a future revision of this document defines an optional claim binding the handoff's canonical action identifier and authorization-receipt hash into the succession evidence, connecting the exact human-approved handoff to the exact transfer event without conflating the two formats. 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": [ "", ... ] }, "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. 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. A conforming verifier MUST accept every golden vector and MUST reject every tamper case of the published conformance corpus at the named check.

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.

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. 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. 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 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 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, 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. 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; this revision incorporates it.

Change Log -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.