]> Continuity Laboratories

hello@continuitylaboratories.com

Security Individual Submission selective disclosure authority succession signed receipts salted commitments offline verification Ed25519 A Succession Receipt proves one completed, policy-gated transfer of authority between autonomous agents, and it is all-or-nothing: whoever holds the receipt holds every claim and every evidence event in it. In regulated deployments the parties entitled to verify a transfer are not all entitled to read it in full — a regulator, a counterparty, and the public each warrant a different view. This document specifies a selective-disclosure form of the receipt: the issuer signs salted commitments to each claim unit and each evidence event, disclosures travel outside the signature, and a projection — the signed envelope plus any subset of the disclosures — still verifies against the one issuer signature. Withholding never breaks the proof, disclosing never re-signs, withheld content remains visibly committed, and a projection that opens every commitment is verifiable to exactly the strength of the underlying receipt. The disclosure mechanism deliberately follows the salted-digest analysis of SD-JWT, restated for plain-JSON documents canonicalized with the JSON Canonicalization Scheme.

Introduction Succession Receipts make one completed transfer of authority between agents verifiable offline: the claims, the legitimacy determination, the obligation lineage, and the signed evidence events grounding all of it travel in one signed document. That completeness is the format's strength and its disclosure problem. The evidence names parties, scopes, and lineage; a receipt handed to a regulator to prove this transfer was approved under that legitimacy evaluation also hands over every business-identifying detail it carries. A Selective-Disclosure Receipt (SDR) is the receipt rebuilt for that reality. The issuer signs, once, an envelope containing salted commitments — one per claim unit, one per evidence event. The values themselves travel as disclosures outside the signed content. A projection is the envelope plus any subset of the disclosures, and it verifies against the one issuer signature: each disclosure reopens its commitment or the projection fails; nothing about withholding a disclosure disturbs the proof; and producing a narrower view for a new audience is dropping disclosures, never re-signing. Three properties distinguish the design: Withholding is visible, never silent. The commitment arrays are inside the signed envelope, so a verifier of any projection knows exactly how many claims and evidence events exist and which it is not seeing. An undisclosed claim is known-withheld, never deniable. "Verified" and "grounded" are separate statements. Verification reports each claim unit as grounded (its supporting evidence was disclosed and checks out), disclosed (bound to the issuer's signature, supporting evidence withheld), or undisclosed. A projection cannot misrepresent; what it proves is exactly what its report says. Complete projections escalate. A projection that opens every commitment MUST be verified under the full Succession Receipts claim semantics , including the bidirectional completeness rules no partial view can enforce. This is both the issuance gate and the holder's acceptance check: a lying issuer is caught at acceptance, not discovered by a regulator later. The mechanism is deliberately that of SD-JWT and its credential profile — salted digests of the hidden values inside the signed body, disclosures shipped alongside, projection by omission — and this document inherits that work's analysis. What it contributes is the mechanism's application to the succession claim set, and an encoding for plain-JSON documents under the JSON Canonicalization Scheme with the Succession Receipts signature discipline, where SD-JWT is JWS-based. It composes with SD-JWT rather than competing with it: a deployment already carrying SD-JWT credentials can treat an SDR as the same discipline applied to a different document class. The format is published with a machine-readable conformance corpus (golden vectors — a complete SDR and a reference projection — plus tamper cases that MUST fail at named checks) . The underlying receipt format composes with adjacent evidence classes, including pre-execution authorization receipts ; that composition is defined at the receipt layer as an OPTIONAL authorization_binding claim and carries no selective-disclosure semantics of its own. Its relationship to the version 0.1 disclosure-unit set is stated in .

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.

Envelope:

The signed part of the document: everything except proof and disclosures.

Commitment:

The salted digest of one disclosure, carried in the envelope's sd member.

Disclosure:

One {salt, path, value} object that reopens a commitment.

Disclosure unit:

The granularity at which content may be disclosed: one of seven fixed claim units, or one evidence event ().

Projection:

The envelope plus any subset of the disclosures — the form a relying party receives.

Complete projection:

A projection in which every commitment is opened by a disclosure.

Profile:

A named, published subset stating which units a projection disclosed for a given audience. Profiles add no cryptography.

The Document An SDR is a UTF-8 JSON object. The complete normative member catalog is the published SDR specification ; this section summarizes the structure a verifier depends on.

", "credentialSubject": { "id": "urn:uuid:", "succession_id": "" }, "sd": { "alg": "sha-256", "claims": [ "", ...exactly seven... ], "evidence": [ "", ...one per evidence event... ] }, "proof": { "type": "CSSEd25519Signature", "created": "", "verification_method": "", "receipt_hash": "", "signature": "ed25519::" }, "disclosures": [ { "salt": "<64 lowercase hex characters>", "path": "credentialSubject/legitimacy", "value": { ... } }, { "salt": "<64 lowercase hex characters>", "path": "evidence/", "value": { } }, ... ] } ]]>

Only the subject pointer and validFrom (an UTC instant) stay in clear: a receipt no one can address answers nothing, and the timestamp anchors when the attested state held. Every other claim, and every evidence event, lives behind a commitment. The document keeps the shape of the W3C Verifiable Credentials data model as plain JSON, with the same caveats as the underlying receipt format .

Commitments The commitment digest of a disclosure is the lowercase hexadecimal SHA-256 of the canonical bytes of the three-element array [salt, path, value], serialized under the canonical form of . Salts are 32 bytes, carried as 64 lowercase hexadecimal characters, generated from a cryptographically secure random source, fresh per disclosure per issuance, and never reused — see . The commitment arrays in sd are sorted lexicographically and unique; the wire order carries no information. sd.alg is "sha-256", the sole registered value at version 0.1.

The Version 0.1 Disclosure Units Disclosure granularity is pinned as data. The claim units are exactly seven, carrying the underlying receipt's claim members verbatim :

Every issued SDR commits to exactly these seven, so the claim-commitment count itself reveals nothing about the handoff. The lineage arrays disclose as whole units, and commitments_carried is always a unit even when empty: under salted commitments the empty set is committed to, never omitted, or absence would be distinguishable from withholding. Each evidence event is one unit at path evidence/<event_id>, its value the event envelope verbatim as recorded. The evidence set is exactly the set the equivalent plain receipt would carry. The underlying receipt's OPTIONAL authorization_binding claim is deliberately NOT among the version 0.1 disclosure units. An SDR projects the seven standard claim units and their evidence; within version 0.1 it does not represent whether the source receipt carried an authorization binding, and it neither commits to nor discloses that claim. A deployment that must selectively disclose the binding uses a future spec_version that adds it as an eighth unit. Because the binding is an optional additive receipt claim outside this set, its existence does not change the constant claim-commitment count of seven or the metadata analysis of . Finer granularity (per-element lineage disclosure) is a recorded evolution of the published specification, arriving only with a new spec_version; it changes the commitment-counting analysis of and MUST NOT be improvised within version 0.1.

Canonicalization and Signatures The canonical bytes of an SDR are its JSON serialization with the proof and disclosures members absent, object member names sorted lexicographically, no insignificant whitespace, and no HTML escaping — coinciding with the JSON Canonicalization Scheme for the format's value domain (no floating-point numbers). Excluding disclosures from the signed content is the projection mechanism: dropping entries never touches the signature. The proof is the Succession Receipts proof unchanged : hash-then-sign over the lowercase hexadecimal SHA-256 of the canonical bytes, ed25519 () as the sole registered algorithm at version 0.1, the canonical <alg>:<key_id>:base64url(signature-bytes) signature string, and proof.created outside the signed content. The same canonical rules serialize the [salt, path, value] commitment input.

Verification A verifier is given a projection and the issuer's public keys, pinned out of band. Verification MUST perform, in order: Structure. The @context, type, and spec_version members match exactly; sd.alg is "sha-256"; sd.claims holds exactly seven digests and sd.evidence at least one, each 64 lowercase hexadecimal characters, sorted, unique; credentialSubject.id encodes succession_id; every disclosure is well-formed with a path from , and no path appears twice. Proof. Recompute the canonical hash () from the received document with proof and disclosures removed. It MUST equal proof.receipt_hash, and proof.signature MUST verify against it under the key named by its key_id. Disclosure binding. For every disclosure, recompute the commitment digest. It MUST appear in sd.claims (claim-unit paths) or sd.evidence (evidence paths); no two disclosures may bind the same digest; an evidence disclosure's path MUST name its own event's event_id. Evidence integrity and authenticity. Every disclosed evidence event's hash MUST recompute to its stored value under the event-hash rule of ; a present event signature MUST verify (absent signatures are reported, not fatal). Disclosed-claim grounding. The underlying receipt's claim- grounding rules are applied over the disclosed subset, and each disclosed claim unit is assigned a status: grounded (every rule for it had its required evidence disclosed, and all passed), disclosed (at least one rule could not run for lack of disclosed evidence; nothing failed), or undisclosed. A disclosed claim contradicted by disclosed evidence is fatal — including the partial completeness checks a concealing holder would need to survive: a disclosed revocation absent from a disclosed revoked_authorities list, or a disclosed inheritance event for the disclosed successor absent from a disclosed lineage array, invalidates the projection. The exact per-unit rule table is normative in the published specification . Completeness escalation. If every digest in both commitment arrays is opened, the projection is complete, and the verifier MUST reconstruct the full claim set and enforce the entirety of the underlying receipt's verification semantics — both directions of the lineage and revocation rules, the constitution recount, and the ledger binding. Any failure is fatal. A complete projection is exactly as strong as the equivalent plain receipt over the seven standard claim units (the optional authorization binding, being outside the version 0.1 unit set per , is not part of an SDR and is neither reconstructed nor required here). The pass yields a report: the envelope hash, each unit's status, disclosed and undisclosed evidence counts, signed and unsigned counts, and the complete flag. What a relying party may rely on is the per-unit status, never the mere fact of verification: a projection can verify while grounding almost nothing, and the report says so. A conforming verifier MUST accept every golden vector and MUST reject every tamper case of the published conformance corpus (tree sdr-v0.1) at the named check .

Projection Profiles A profile is a named, published statement of which units a projection disclosed for a given audience — an agreement about what to disclose, adding no cryptography. Version 0.1 pins one reference profile: regulator — the projection for an auditor entitled to the governance facts but not the business surface. Disclosed: the legitimacy, constitution, and ledger_binding claim units, plus the evidence events grounding them (the succession's completion and approval, the legitimacy determination, the genesis event, and the ratified amendments — all of whose payloads carry only opaque identifiers). Withheld, but visibly committed: the parties, the authority scope, the revocation bases, and the lineage identifiers. The regulator verifies that the named succession completed at validFrom, was approved under the named legitimacy evaluation at its determined state, and ran under the committed constitutional lineage — without receiving a single business-identifying string. Other profiles (counterparty, public existence proof) are sketched informatively in the published specification ; a deployment tunes profiles to its own payload content.

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. Version 0.1 is the current draft on the format family's stated stability ladder toward a stable 1.0 .

Security Considerations The design inherits SD-JWT's salted-digest analysis ; the considerations below restate the consequences for this document class and add the receipt-specific ones. Forgery and splicing fail at the commitment. Altering a disclosed value, salt, or path changes the commitment digest, which no longer appears in the signed arrays. Commitment membership is per-envelope and salts are fresh per issuance, so a disclosure lifted from another receipt — even one committing an identical value — cannot bind. Salt entropy is what protects withheld values. Several claim values are low-entropy (booleans, two-value enums, short scope strings); an unsalted or salt-reused commitment would be trivially confirmable by dictionary. Salts MUST be 32 bytes from a cryptographically secure random source, fresh per disclosure per issuance, never reused, and never derived from content. Test vectors use published fixed salts; production issuance MUST NOT. Projections of one SDR are mutually linkable, by design. They share the envelope hash, the signature, and the digest sets. Unlinkability across audiences requires issuing multiple salt-fresh SDRs over the same facts (batch issuance) — a recorded evolution, out of scope for version 0.1. State this plainly to deploying parties; do not imply otherwise. Commitment counts are public metadata. The claim-commitment count is a constant seven and reveals nothing. The evidence-commitment count reveals the evidence-set size (roughly, lineage volume). Decoy digests would hide it but are deliberately not part of version 0.1: an unopenable commitment would make the complete projection — the escalation gate this design's issuer-honesty story rests on — undecidable. Any future decoy mechanism arrives with explicit signaling and its own version. Possession is not entitlement. Version 0.1 defines no holder binding: anyone holding a projection can forward it. A recipient-bound presentation (in the style of SD-JWT key binding ) is a recorded evolution. Profiles are access decisions made at disclosure time; treat projections accordingly. A lying issuer is caught at acceptance. An issuer could commit to claims the record does not ground, counting on partial projections to hide it. The complete-projection escalation is the countermeasure placed where it works: issuance MUST verify the complete projection before release, and a holder SHOULD verify it at acceptance — after which every projection the holder makes is a pure subset of a fully grounded, issuer-signed record. A relying party receiving only a partial projection relies on the reported per-unit statuses, not on trust. Key pinning is the trust root, exactly as for the underlying receipts : relying parties MUST obtain issuer keys through a channel they trust and SHOULD pin them.

IANA Considerations This document has no IANA actions. The signature-algorithm and sd.alg registries are internal to the format's spec-version ladder (), shared with Succession Receipts .

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 specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. MATTR Authlete Inc. Ping Identity This specification describes data formats as well as validation and processing rules to express Verifiable Digital Credentials with JSON payloads with and without selective disclosure based on the SD-JWT format. 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.

Acknowledgments The disclosure mechanism follows the analysis of SD-JWT deliberately; the contribution here is its application to an existing plain-JSON receipt format without changing that format's proof discipline. The format was extracted from a production authority-succession system of record; the conformance corpus packages its threat model — forging, splicing, concealing, and complicit-issuer re-signing attacks — as executable verification cases. Iman Schrock provided detailed external review of the -00 document family; this revision incorporates it.

Change Log -02: Updated the composition reference now that the receipt-layer authorization_binding claim is normatively defined , and stated its relationship to the version 0.1 disclosure-unit set ( and step 6): the optional binding is outside the seven standard units, is neither committed nor disclosed by an SDR, and making it selectively disclosable is a recorded evolution requiring a new spec_version. No wire-format change. -01: Added the composition note and the reference. No wire-format change.