Specification v0.1

Status: Draft, pending technical review Version: 0.1 Date: 2026-07-17 This is the normative specification. The overview page orients and links, and does not repeat this content. Initiator and first maintainer: mintBlue (see Section 7, Governance). The initiator is not the owner.

Abstract

The base protocol defines how organisations share, address, and verifiably record encrypted data directly with one another. It fixes a minimal normative core: the shape of a record, how parties are addressed, how each field is encrypted, how every exchange is anchored to a shared public audit layer, and how any party reconstructs and verifies state from the recorded log. On top of that core sits a forkable, source-available reference implementation, including the state machines that run the protocol, which is one way to satisfy the rules and not the standard itself. No single organisation owns the base protocol. The protocol is designed so that anyone holding this specification can build an interoperable implementation in any language. Full independent interoperability in this version depends on the published test-vector suites and on resolution of the settlement layer the audit layer resolves to (PROV-1); Section 6 sets out what an implementation can build against before those are pinned. This document carries the normative rules, the register-and-discovery chapter, the conformance requirements, the governance model, and the version history.

---

1. Introduction and scope

1.1 What the base protocol is

The base protocol is the base layer for cross-organisational data sharing. It specifies how organisations exchange encrypted data: how a record is structured, how parties are addressed and discovered, how records are signed, how each field is encrypted, and how the fact of an exchange is recorded so that no participant can retrospectively alter it. It is deliberately minimal. It fixes only what two independent implementations MUST agree on to interoperate, and nothing more.

1.2 What the base protocol is not

The base protocol does not prescribe what data is shared or with whom. It carries no domain schema and no business rule. Two concerns sit outside this document and are referenced, not restated, here:

• Domain taxonomies define which data a field of work shares and what it means. They sit above the base layer as light, per-domain agreements. They are documented under /protocols, not here.
• Exchange patterns are reusable configuration templates for using the base protocol (one-to-many, broadcast, on-demand, request-response, cross-sector). They configure this protocol; they are not a layer of their own and carry no layer number. They are documented under /patterns, and each pattern descends by link to this specification.

A domain adding or changing a rule does not change the base layer, and a change to the base layer does not require a domain to change its taxonomy. This separation is what lets a single expensive-to-standardise layer carry many light agreements above it.

1.3 The organising principle: rebuildable by design

Neutrality is a checkable property. The normative core in Section 3 states what an interoperable implementation MUST do. The reference implementation in Section 5 is one way to satisfy that core. Conformance in Section 6 is defined against the published rules and test-vector suites, never against the reference implementation. Because every mechanism is drawn from open, published cryptographic primitives and open, numbered standards, any party can inspect the algorithms, implement them independently, and verify each record for itself. An organisation that wants to leave any particular implementation can build its own against these rules. In this version the same-network guarantee is a design guarantee; see Section 6 for what an implementation can build against before the settlement layer (PROV-1) and the test-vector suites are pinned.

1.4 External context

The design follows the position that shared infrastructure is better governed as an open protocol than as a platform a single party can withdraw (Masnick, "Protocols, Not Platforms", 2019). That reference is cited as context, not as a claim about this specification.

---

2. Terminology and conventions

2.1 Normative key words

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174, and only when they appear in capital letters.

2.2 Citation of open standards

Open, published standards are cited the way one cites an RFC: neutrally, as the published standard on which a mechanism rests and which any party may implement. This includes the open overlay standards for submit-and-lookup, topic naming and discovery, and mutual authentication; an open key-derivation standard; canonical binary encoding (RFC 8949); and the open identity standards (W3C DID, W3C Verifiable Credentials, SD-JWT, OpenID4VP, OpenID4VCI, eIDAS). Where such a standard is cited, an implementer may follow the public standard directly; this document does not restate it.

2.3 Glossary

---

3. Normative core

This section carries the rules an interoperable implementation MUST satisfy. Each subsection ends with its explicit conformance rules. Technical detail that is either not required for interoperability or is provisional pending technical review sits inside a collapsed technical-detail block, so that the normative body reads cleanly and a reviewer sees every provisional item at a glance. Provisional items are tagged inline as [PROV-n] and collected in Section 9.

3.1 Data envelope and wire format

A record is a versioned envelope of typed tiers, canonically encoded. The canonical encoding MUST be deterministic: the same logical record MUST produce the same bytes on any conforming implementation, so that two parties compute identical commitments and identical proofs. Canonical binary encoding follows RFC 8949.

A recorded action has a fixed shape. It carries:

1. an identifier for the action,
2. the method name it invokes,
3. the arguments to that method,
4. the actor identifier that signed it,
5. the time carried in the action itself, and
6. the anchor reference to its position on the public audit layer.

Method bodies read the time from the recorded action, never from a local clock, so that replay is deterministic (Section 3.5).

Rules.

• An implementation MUST encode records with the deterministic canonical encoding, such that two conforming encoders produce byte-identical output for the same logical record.
• An implementation MUST include an explicit version field in every record.
• An implementation MUST use the fixed recorded-action shape above, so that any party can reconstruct and replay an action it did not originate.
• An implementation MUST preserve canonical ordering of map and set structures on encode, and MUST NOT rely on any type distinction that the canonical encoding does not preserve.

Technical detail

The canonical-encoding profile is fixed by the cbor-det-v1 test-vector suite (Section 6). The suite defines map-key ordering, the erasure of type distinctions the encoding does not preserve, and the byte-exact output an encoder MUST match. A rebuilder validates its encoder against the vectors, which will be published alongside the reference implementation (Section 6), rather than against any prose here.

3.2 Addressing and discovery

Parties are addressed, and records are discovered, through the open overlay standards. Addressing rests on the open overlay submit-and-lookup standard; topic naming and discovery rest on the open overlay naming-and-discovery standards. Mutual authentication between parties rests on the open mutual-authentication standards. These are open, published standards; an implementation follows them directly.

The overlay is a routing fabric. It admits records into named topics and answers lookup queries. It does not hold state for the parties and does not need to be trusted for the integrity of a record, because integrity is established by the record's own signatures and its anchor (Sections 3.4 and 3.6). An overlay instance MAY be self-hosted, third-party operated, or both.

Rules.

• An implementation MUST address records and admit them to topics using the open overlay submit-and-lookup standard.
• An implementation MUST support topic naming and discovery per the open overlay naming-and-discovery standards.
• An implementation MUST authenticate peers using the open mutual-authentication standards.
• An implementation MUST NOT require any party to trust a specific overlay operator for the integrity of a record.

Technical detail (provisional, pending technical review)

[PROV-3 (1 of 2)] Membership of any specific consortium overlay network, and the ownership boundary of a given overlay instance, are operator-tier configuration. They are out of scope for this specification: the base protocol fixes how addressing and discovery work over the open standards, not who operates a particular network or on what commercial terms. The consortium-membership and instance-ownership arrangements are proprietary and are not normative here.

3.3 Encryption principles

Encryption is on by default and applied per field. Each field is encrypted independently and carries its own receivers, so that different parties can be granted access to different fields of the same record. Selective disclosure is achieved by granting a counterparty only the field keys it is entitled to. A field carries a placement descriptor stating where its encrypted content lives: inside the anchored record, in overlay storage, or in external storage. In every case the record carries a cryptographic commitment to the field, so a party can verify a field exists and is unchanged even without holding the key to read it.

Keys are derived, not stored. Every key an implementation needs, for a party's account, for a running instance, for a single record, for a single field, is derived on demand from a single master input plus a labelled context, through a five-level hierarchy. Derivation follows an open, published key-derivation standard. The hierarchy is built over two curves: secp256k1, which binds a runtime to the public audit layer, and P-256, which signs payloads in the formats that EU digital identity wallets and web identity systems already use. Both curves derive from the same master input, so an implementation covers audit-layer binding and EU wallet and web-identity signing without a second secret.

Keys retire per epoch. On rotation a new epoch begins, the transition is marked publicly and anchored, and data encrypted under a prior epoch stays decryptable to any party that held a key in that epoch. There is no re-encrypt-everything event.

The open cryptographic primitives on which these principles rest are HKDF, PBKDF2, AES-256-GCM, ECDH, and ES256. They are cited as the open basis; an implementer uses the published primitives.

Rules.

• An implementation MUST encrypt field content by default and MUST encrypt each field independently.
• An implementation MUST record a placement descriptor per field and MUST carry a cryptographic commitment to each field regardless of placement.
• An implementation MUST derive keys according to the open key-derivation standard, through the five-level hierarchy, over both curves.
• An implementation MUST mark and anchor epoch transitions so that any party can determine which epoch a record belongs to, and MUST keep prior-epoch data decryptable to prior-epoch key holders.
• An implementation MUST grant field access by wrapping only the keys for the fields a counterparty is entitled to, and MUST NOT require disclosure of a whole record to disclose one field.

Technical detail (provisional, pending technical review)

The exact construction (the derivation contexts, the parameters of the key-stretching and authenticated-encryption primitives, and the per-field content-key scheme) is fixed by the dual-curve and docv2-envelope test-vector suites (Section 6). A rebuilder matches the vectors once they are published (Section 6); the parameter values are not restated in this prose. Only the interop-load-bearing shape is normative here: five levels, two curves, open-standard key derivation, per-field independent encryption, per-epoch rotation.

[PROV-2] Forward-secrecy trade-off. The per-field content-encryption key is derived deterministically from the field's own content. This is what lets any party that legitimately holds a field's content rederive the key and verify the field independently, without contacting the party that recorded it. A deliberate consequence is that the scheme does not provide classical forward secrecy in the way an ephemeral-key transport does: determinism and independent verifiability are chosen over ephemerality. This is an engineering trade-off in favour of auditability and self-contained verification, not an oversight. The framing of this trade-off is subject to technical review.

[PROV-3 (2 of 2)] Placement-channel ownership. The placement descriptor semantics (selecting whether a field's content sits in the anchored record, in overlay storage, or in external storage) are normative and stated in the body above. The ownership boundary of overlay-versus-external storage, and who operates each store, are operator-tier configuration and are out of scope for this specification. This boundary is subject to technical review.

3.4 Anchoring to the public audit layer

Every exchange is anchored to the public audit layer: a shared, append-only, tamper-evident record that no single party controls or can rewrite. The public audit layer is a shared, public network that any party may anchor to directly; no participant owns it or can gate access to it, which is what lets an anchored proof be verified by anyone and keeps the layer free of network-level lock-in. The anchor fixes an ordered, chained position for each recorded action, so that the sequence of a party's actions is unbroken and any gap or reordering is detectable.

Rules.

• An implementation MUST anchor every recorded action to the public audit layer as a chained, ordered entry.
• The anchor MUST carry a cryptographic commitment to the record's fields.
• A proof of anchoring MUST be independently verifiable, without trusting the operator that submitted the anchor.
• A cross-domain reference MUST carry its proof with it, so a party in another domain can verify the referenced record without access to the originating domain's storage.
• Each recorded action MUST derive a unique commitment key, so that no two actions collide on the audit layer.

Technical detail (provisional, pending technical review)

[PROV-1] Settlement-layer naming and anchoring mechanics. This specification names the settlement layer only as "the public audit layer". The concrete script-level mechanics (carrying encrypted field bytes and commitments in spendable output data rather than in metadata-only outputs, the chaining container that links each action to the previous one, the self-verifiable inclusion proofs, and the per-action commitment-key derivation) are the interop-load-bearing detail and are fixed by the utxo-chaining and cross-domain-refs test-vector suites (Section 6). The naming of the underlying settlement layer, and the framing of the standards citations for these mechanics, are subject to technical review. A rebuilder verifies against the suites once they are published (Section 6).

3.5 Verification and replay semantics

An implementation reconstructs state by applying recorded actions in log order, and any two implementations applying the same actions in the same order MUST arrive at identical state. There is no master copy of state to be trusted; the log is the source of truth.

Method bodies are pure functions of state and the recorded action. They contain no clock read, no random draw, and no network call, so that replay is reproducible by construction.

An implementation checks itself. It replays recently applied actions and confirms that the result matches the state it holds. A disagreement (drift) signals tampering, a non-deterministic method body, or a corrupt storage layer, any one of which is grounds to stop.

Method bodies evolve by version. Each recorded action carries the method version it was recorded with, and replay applies that version. A migration is itself a recorded action, so schema evolution happens by explicit cutover and never silently changes the meaning of a past action.

The runtime contract is expressed as three roles: a reader that admits recorded actions from the audit layer and replays them, a writer that encodes, signs, and submits actions, and a recorder that persists canonical state and verifies replay determinism.

Rules.

• An implementation MUST reconstruct state deterministically by applying recorded actions in log order.
• Method bodies MUST be pure functions of (state, recorded action) and MUST NOT read a clock, draw randomness, or make a network call.
• An implementation MUST detect drift between reconstructed and stored state and MUST halt or raise on drift.
• Each recorded action MUST carry the method version it was recorded with, and replay MUST apply that version.
• A schema change MUST be introduced as a recorded cutover action, not as an untracked change.

3.6 Identity and delegation

Authority binds through a verifiable chain of grants: a legal entity to a runtime account, an account to a mandated actor, and an actor to each signed recorded action. Every link is verifiable, and none of them requires a network call at the moment an action is recorded.

A mandate grants a natural person or a service scoped, time-bounded authority to sign actions on an account's behalf. The actor's public key is pinned at the moment the mandate is granted. Verification is therefore local: an action's signature verifies against the key pinned at grant time, with no lookup on the critical path. A delegation and its revocation are themselves recorded actions on the audit layer, so the authority history is auditable.

Because every key in the chain is a distinct per-context derivation, compromise at one link does not cascade: a leaked action-signing key reveals nothing about the mandate, and a compromised mandate can be revoked in its own scope without touching the account.

Identity binds to the open standards. Accounts and mandates bind to W3C DID and W3C Verifiable Credentials; citizen-facing mandates MAY be issued as portable, selectively disclosable credentials using SD-JWT and presented over OpenID4VP and OpenID4VCI; binding aligns with eIDAS. The credential is optional; organisational flows work without it.

Rules.

• An implementation MUST verify each recorded action's signature against the actor public key pinned at grant time, locally, with no network call at the moment of recording.
• A mandate MUST be scoped, time-bounded, and revocable.
• A delegation and its revocation MUST each be recorded actions anchored to the public audit layer.
• An implementation MUST reject an action from an actor without an active, in-scope mandate for the method invoked.
• An implementation SHOULD bind accounts and mandates to the open W3C DID and Verifiable Credentials standards, and MAY accept portable credentials per SD-JWT and OpenID4VP/OpenID4VCI for citizen-facing flows.

Technical detail (provisional, pending technical review)

[PROV-4] Data-protection erasable-mandate pattern. An append-only record cannot delete a past entry, which appears to conflict with a data-subject erasure request. The protocol resolves this with a separable identity link: the runtime operates on a pseudonymous actor identifier, and the mapping from that pseudonymous identifier to a natural person is held as a separate, erasable link. Erasing the link renders the person no longer identifiable from the append-only record, honouring an erasure request without rewriting history. The pattern is normative; the concrete operator-owned identity-link mechanism that stores and erases the link is proprietary operator configuration and is out of scope for this specification. The split is subject to technical review.

---

4. Register and discovery standard

The register lets any organisation publish verifiable claims about itself to a known address, so that any counterparty can look those claims up directly and verify their origin and integrity for itself, with no central gatekeeper. A claim is a signed, anchored recorded action; the signature is checkable by anyone. Publishing is one-to-many; verifying is many-to-one.

The register is itself an application of the base protocol, not a new layer. It reuses the identity and delegation rules of Section 3.6 to bind a claim to its issuer, the anchoring rules of Section 3.4 to make a claim tamper-evident, and the addressing rules of Section 3.2 to make a claim discoverable. A continuous stream of verifiable updates replaces a periodic manual exercise: a party publishes an update, and counterparties verify it independently whenever they need it.

Rules.

• A claim MUST be a signed recorded action anchored to the public audit layer.
• A claim MUST carry its issuer binding, so that any party can verify the claim's origin against the issuer's pinned key.
• Verification of a claim MUST be independent of any central party.
• A published claim MUST be discoverable through the open addressing and discovery standards of Section 3.2.

Scope of this version. The register is specified here as a concept and specification. This version defines no live lookup service, no directory user interface, and no adopter list. No branded instance of the register is named or implied by this specification; any party may operate its own instance over the same rules and the same public audit layer.

---

5. Reference implementation

A reference implementation, including the state machines that run the protocol, will be published source-available under a licence now being finalised, with each version scheduled to convert to the Apache-2.0 open-source licence two years after its release; it is designed to be free to fork and free to run. It exists to demonstrate one working way to satisfy the normative core, and it is explicitly not the standard: conformance (Section 6) is defined against the public rules and the published test-vector suites, and any language may implement the standard.

The reference architecture expresses the runtime contract of Section 3.5 as replaceable adapters: a reader, a writer, and a recorder, around locally owned state and pure method bodies. A topology is an adapter swap over the same code path:

• Full: reads and writes; a normal runtime that both submits and consumes.
• Query replica: reads only; a read-only mirror that scales out queries.
• Ingest-only: writes only; a submit-only worker.
• Observer: neither reads nor writes into state; an audit-only viewer that sees only what it has been keyed for.

Selecting a topology is a configuration of the same reference architecture, not a different protocol.

Rules.

• An implementation MAY reuse, fork, or replace the reference implementation in whole or in part.
• An implementation MUST NOT depend on the reference implementation to claim conformance; conformance is against the rules and suites only.
• An implementation MAY adopt any topology above, since a topology is an adapter configuration and does not change the wire behaviour other parties observe.

Operator-infrastructure detail (provisioning, hosting, key-management-service or hardware-module setup, funding, custody topology, and runbooks) is out of scope for this specification. A topology is an adapter swap; how an operator runs and scales it is not part of the base protocol.

---

6. Conformance

An implementation is interoperable when it demonstrates the following. Each item maps to a rule in Sections 3 and 4 and to a published test-vector suite where one applies. The suites are named here; their vector values are not embedded in this document. A rebuilder fetches the vector suites, which will be published alongside the reference implementation (see "How to build against this specification" below), and validates against them.

Items 8 and 9 are behavioural: an implementation demonstrates them by exhibiting the required behaviour, not by matching a fixed byte vector. Item 10 requires implementing the published port-contract interfaces (the MUST interfaces of the reader, writer, and recorder roles of Sections 3.5 and 5, defined in the glossary) that define the interoperability surface.

Interoperability test. Two independent implementations are interoperable when they:

1. reconstruct identical state from the same ordered log,
2. verify each other's records without trusting the other's storage, and
3. anchor to the same public audit layer.

Conformance levels. A MUST rule is required for core interoperability. A SHOULD rule is recommended and its absence must be justified. A MAY rule is optional. An implementation states which SHOULD and MAY provisions it supports.

How to build against this specification. The test-vector suites named above and the port-contract interfaces of item 10 will be published alongside the reference implementation: the suites at /protocols/data-sharing/v0.1/vectors and the port-contract interfaces at /protocols/data-sharing/v0.1/interfaces. A rebuilder starts there: fetch the suites, implement the MUST interfaces of the reader, writer, and recorder roles, and validate byte-exact output against the vectors. Until they are published, this specification fixes the shape an implementation must match; the vectors pin the bytes.

---

7. Governance

No single party owns this standard, can change its normative core, or can withdraw it. Four mechanisms are designed to make that true and verifiable; the licence that anchors them is being finalised and will be linked here.

Licence. The protocol and its specifications will be published under an open, royalty-free licence; the reference implementation, including its state machines, will be published source-available under a licence now being finalised that converts to the Apache-2.0 open-source licence two years after each version's release. There is no registration requirement and no fee. Anyone is free to implement, fork, and run them. The licence exists to make neutrality verifiable in practice rather than dependent on a commercial relationship.

Public working group. The standard is developed in public, and anyone can join the working group: organisations, implementers, and domain experts who review the specification, propose changes, or help define taxonomies. The normative core cannot be changed unilaterally, and there is no central gatekeeper.

Separation of specification from implementation. The normative core is separate from any reference implementation. The specification cannot be changed by one party acting alone, and no implementation is privileged in defining conformance.

Hand-over clause. Stewardship passes to the working group once at least three parties are actively implementing the protocol, participating in working-group discussions, and ratifying taxonomy changes. That clause was part of the governance model from the start, not added afterwards. This version does not claim an independent foundation, committee, or not-for-profit body; neutrality in this version rests on the open working group, the specification-implementation separation, the built-in transfer clause, and the open royalty-free licence being finalised.

Initiator and first maintainer. mintBlue initiated this standard and wrote the first specifications. The initiator is not the owner: the maintainer role is temporary and transferable, and the credit records origin, not control. The current role is practical stewardship, keeping the first version coherent and preparing the work for transfer as participation grows.

Versions and forks. Versions are explicit, so parties always know which agreement an exchange follows, and nobody is upgraded on someone else's timetable. Because everything is open, anyone who disagrees with a choice can fork a taxonomy or the specification itself, and a fork carries exactly as far as others choose to adopt it. A fork has one natural boundary: the public audit layer. As long as every party keeps anchoring to the same audit layer, every exchange stays verifiable across versions and forks. Splitting the record itself is the one move that breaks this.

Open and paid. Everything needed to build, host, and operate an interoperable implementation is source-available and free to self-host. An organisation can run the full stack itself, commission an implementation from another party, or test compatibility against the public rules, with no licence fee and no required integration with any managed service. The paid route is managed provisioning: a provider operates an implementation for organisations that do not want to run the infrastructure themselves, with one-click set-up, operational scale, and service-level commitments. Any conforming provider can offer this; the initiator is simply the first to do so. Paying for provisioning buys no control over the specification and no permission to participate. The full governance model, licence, and hand-over conditions are documented at /governance.

---

8. Versioning and changelog

This is version 0.1, status Draft, pending technical review. The base layer is deliberately minimal and is versioned explicitly.

Future versions are proposed and ratified through the public working group. The normative core cannot change unilaterally: a change to a MUST rule requires working-group ratification, and versions remain explicit so that adopters choose when to move.

Changelog

• v0.1 (2026-07-17) Initial specification. Establishes the normative core (envelope and wire format, addressing and discovery, encryption principles, anchoring to the public audit layer, verification and replay, identity and delegation), the register-and-discovery chapter, the reference-implementation reference, the conformance requirements, and the governance model. Four items are marked provisional pending technical review (Section 9).

---

9. Provisional-items register

The following four items are the only content in this specification pending technical review. Each is written inside a collapsed technical-detail block at its point of use and tagged inline. Content from the internal threat model and the internal privacy analysis is excluded from this version, not deferred: it does not appear here in any form.