]> 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 . 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-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 that binds this succession to a pre-execution authorization of the handoff, recorded under an authorization-receipt format such as . It is additive: a receipt that omits it verifies exactly as one that predates the claim, its presence does not change spec_version, and a verifier that does not implement it ignores it while still verifying the receipt. When present, the claim MUST be an object with these string members: caid — the canonical action identifier of the handoff, byte-identical to the authorization receipt's own, whether that is a native member of the receipt or a value derived from the verified receipt under the format's pinned mapping profile, exactly as the named format defines. receipt_hash — exactly 64 lowercase hexadecimal characters, the SHA-256 digest over the canonical representation of the authorization receipt as its format defines. Where the format derives the identifier rather than carrying it natively, the canonical representation covered by this digest includes the derived identifier — the format derives it, embeds it, and hashes the complete representation, in that order. format — a non-empty authorization-format identifier naming the receipt's format, and therefore the canonicalization to apply; for example EP-RECEIPT-v1, or EP-QUORUM-v1 for a multi-party authorization. Members inside the claim that a verifier does not recognize are ignored. A verifier processes the claim as follows. If it does not hold the authorization receipt the claim names, it checks only that the claim is well-formed as above; the binding is then carried, covered by the issuer proof, for a consumer able to complete the cross-check later. If it holds the authorization receipt, it MUST additionally recompute that receipt's canonical hash under the canonicalization its format defines and require it to equal receipt_hash; then require the authorization receipt's canonical action identifier, obtained as format defines, to equal caid, byte for byte. The recomputed hash is checked before the identifier. Any failure invalidates the receipt. The binding introduces no new failure mode for a receipt that omits it, and it leaves each format authoritative for its own semantics — a succession receipt for the transfer, the authorization receipt for the pre-execution approval; neither format speaks for the other. The published corpus pins the rule and its evaluation order with a cross-format vector (corpus revision ahr-v0.2/r2) contributed by the authorization-receipt format's author.

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. 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, and contributed the cross-format conformance vector that pins the authorization binding of ; this document incorporates both.

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