Individual Submission J. Sabey Internet-Draft Continuity Laboratories Intended status: Informational 20 July 2026 Expires: 21 January 2027 Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents draft-sabey-succession-receipts-01 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 January 2027. Sabey Expires 21 January 2027 [Page 1] Internet-Draft Succession Receipts July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. The Receipt Document . . . . . . . . . . . . . . . . . . . . 4 4. Canonicalization and Signatures . . . . . . . . . . . . . . . 6 4.1. Canonical Form . . . . . . . . . . . . . . . . . . . . . 6 4.2. Hash-Then-Sign . . . . . . . . . . . . . . . . . . . . . 6 4.3. Evidence Event Integrity . . . . . . . . . . . . . . . . 6 5. Verification . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Versioning and Stability . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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_); Sabey Expires 21 January 2027 [Page 2] Internet-Draft Succession Receipts July 2026 * 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 (Section 5), 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 [I-D.farley-acta-signed-receipts] attest individual machine-to-machine authorization decisions, and delegation receipts [I-D.nelson-agent-delegation-receipts] attest grants of permission to act. Per-hop delegation-chain identity, as in PEDIGREE [I-D.rampalli-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 [RFC8032], JSON Canonicalization Scheme [RFC8785]) deliberately. Pre-execution authorization of individual material actions is a fourth adjacent class: an authorization receipt [I-D.schrock-ep-authorization-receipts] 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) [SR-REPO], against which independent verifier implementations can validate; the format steward Sabey Expires 21 January 2027 [Page 3] Internet-Draft Succession Receipts July 2026 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. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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. 3. The Receipt Document A Succession Receipt is a UTF-8 JSON [RFC8259] object shaped after the W3C Verifiable Credentials data model [VC-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 [SR-AHR], 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. Sabey Expires 21 January 2027 [Page 4] Internet-Draft Succession Receipts July 2026 { "@context": ["https://www.w3.org/ns/credentials/v2", "urn:css:ahr:v0.2"], "type": ["VerifiableCredential", "AuthorityHandoffReceipt"], "spec_version": "0.2", "issuer": { "id": "urn:css:registry" }, "validFrom": "2026-07-04T12:00:14Z", "credentialSubject": { "id": "urn:uuid:", "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 (Section 5), so a verifier recomputes them from the Sabey Expires 21 January 2027 [Page 5] Internet-Draft Succession Receipts July 2026 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 ([RFC3339]), event_version, payload, event_hash, and an optional signature. Envelopes are embedded exactly as recorded — stored bytes, not re-derived ones. 4. Canonicalization and Signatures 4.1. 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 [RFC8785]. 4.2. 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 ([RFC8032], 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 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. 4.3. 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 [RFC3339] 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 Sabey Expires 21 January 2027 [Page 6] Internet-Draft Succession Receipts July 2026 signature is the canonical signature string over its event_hash. 5. Verification A verifier is given the receipt document and the issuer's public keys, pinned out of band. Verification MUST perform, in order: 1. *Proof.* Recompute the canonical hash (Section 4) 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. 2. *Evidence integrity.* Every evidence event's hash MUST recompute to its stored event_hash per Section 4.3. 3. *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. 4. *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. Sabey Expires 21 January 2027 [Page 7] Internet-Draft Succession Receipts July 2026 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 [SR-REPO] 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 [SR-CORPUS] at the named check. 6. 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 [SR-AHR]; 0.2 adds the constitution and ledger_binding claims additively, and a conforming verifier accepts both versions. 7. 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 [SR-CORPUS] encodes these attacks as executable cases, including re-signed variants. Sabey Expires 21 January 2027 [Page 8] Internet-Draft Succession Receipts July 2026 The event-hash input of Section 4.3 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 [RFC9162]), both published alongside this format [SR-REPO]. The anchoring extension point is designed to register ledger-head commitments with a SCITT transparency service [RFC9943], 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. 8. IANA Considerations This document has no IANA actions. The signature-algorithm registry is internal to the format's spec-version ladder (Section 4); a future version of this specification may propose a formal registry if the format is adopted for standards-track work. Sabey Expires 21 January 2027 [Page 9] Internet-Draft Succession Receipts July 2026 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 9.2. Informative References [I-D.farley-acta-signed-receipts] Farley, T., "Signed Decision Receipts for Machine-to- Machine Access Control", Work in Progress, Internet-Draft, draft-farley-acta-signed-receipts-02, 28 June 2026, . [I-D.nelson-agent-delegation-receipts] Nelson, R., "Delegation Receipt Protocol for AI Agent Authorization", Work in Progress, Internet-Draft, draft- nelson-agent-delegation-receipts-10, 13 June 2026, . Sabey Expires 21 January 2027 [Page 10] Internet-Draft Succession Receipts July 2026 [I-D.rampalli-pedigree] Karthik, R., "PEDIGREE: Verifiable Delegation Identity for Agentic AI Systems", Work in Progress, Internet-Draft, draft-rampalli-pedigree-00, 24 April 2026, . [I-D.schrock-ep-authorization-receipts] Schrock, I., "Authorization Receipts for High-Risk Agent Actions", Work in Progress, Internet-Draft, draft-schrock- ep-authorization-receipts-07, 19 July 2026, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [SR-AHR] "CSS Authority-Handoff Receipts (AHR)", 2026, . [SR-CORPUS] "Succession Receipts conformance corpus", 2026, . [SR-REPO] "Succession Receipts: specifications and conformance corpus", 2026, . [VC-DATA-MODEL] "Verifiable Credentials Data Model v2.0", 2025, . 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. Sabey Expires 21 January 2027 [Page 11] Internet-Draft Succession Receipts July 2026 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 [I-D.schrock-ep-authorization-receipts] 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. Author's Address Jaryn Mervin Sabey Continuity Laboratories Email: hello@continuitylaboratories.com Sabey Expires 21 January 2027 [Page 12]