Sekretess and privacy: a committed pillar

Status: committed (v1 design); cryptographic hardening is v2. Secrecy is not a bolt-on. It is orthogonal to the other properties: a contract can be perfectly deterministic, evaluatable, ported, standards-native, and receipted, and still leak everything. The v1 mechanics below are committed; cryptographic selective disclosure is the v2 hardening. The reconciliation with append-only replay is the crux, and it is tested against bit-for-bit replay rather than asserted.

12.1 Why this bites harder for us than for a PDF

A mechanical contract is more exposing than a paper one by default, on four fronts: the contract is structured (a rate is a queryable field, not a needle in 40 pages); execution distributes state (buyer, supplier, platform each hold the log); receipts quote the contract (a rejection diff citing rates.senior = 895 × index leaks the rate card to whoever holds the receipt); and escalation summons outsiders (steering group, mediator, court - level 3 hands contract internals to third parties).

And Swedish law makes this concrete, not theoretical. Public-sector contracts are allmänna handlingar with a presumption of publicness - but OSL 31 kap 16 § seals a supplier’s business/operational circumstances on a harm test, and in practice detailed price information - hourly and unit prices - is the typically-sealed material (Upphandlingsmyndigheten’s guidance; contract-term secrecy runs max 2 years, supplier-protection up to 20). Read that against §2: the rate card - the exact field our rules cite in every receipt - is the exact field most often under sekretess. Anbudssekretess (absolute until award) adds a second regime for the pre-signature phase. So field-level secrecy is not a nice-to-have; it is the legal shape of the domain.

The inversion worth noticing: a PDF can only be disclosed in full or redacted by hand with a marker pen. A structured contract can do minimal disclosure by construction - publish the port manifest (capabilities are rarely secret), seal the parameters (rates), disclose per audience. Done right, the mechanical contract is the first contract form that can comply with OSL precisely - clause by clause, field by field, with the sekretessprövning documented as a disclosure policy instead of improvised per begäran.

12.2 The prior art to read (each solves one layer)

Approach	What it gives us	Read	Maturity
Salted-hash selective disclosure (SD-JWT)	Replace each field with hash(salt + value); sign the digests; disclose only chosen fields + salts, verifier checks against the signature. THE fit for “contract public in structure, sealed in parameters”	IETF SD-JWT (RFC 9901 track) · walt.id explainer	Standardized, production - the EUDI wallet stack uses it
BBS+ signatures	Selective disclosure with unlinkability + predicate proofs (“rate < X” without revealing rate); constant-size proofs	BBS+ vs SD-JWT comparison	Standardizing (W3C VC ecosystem)
Canton/Daml sub-transaction privacy	Need-to-know distribution at the protocol level: each party receives ONLY their slice of a transaction (bank sees cash leg, custodian sees securities leg)	Canton protocol · need-to-know deep-dive · Daml identity & privacy	Production (regulated finance)
Zero-knowledge compliance proofs	Prove “this invoice complies with the sealed contract” revealing NOTHING - even the referee needn’t see terms	zk-Agreements (arXiv 2025) · Hawk (IEEE S&P 2016)	Research-grade; heavy; watch, don’t build
Confidential computing (TEE)	The literal black box: the machine evaluates inside an attested enclave (SGX/Nitro); parties get receipts + attestation, operator sees nothing	vendor docs (Intel SGX, AWS Nitro Enclaves)	Production tech, adds ops + trust-in-vendor cost
Ricardian hash-only publication	The degenerate baseline we already have: publish hashes, hold contents	§1	Built-in

12.3 The committed design (v1 mechanics, v2 hardening)

Secrecy is not a new subsystem - it is the promotion of primitives that already exist, now made load-bearing and enforced. The envelope and body split is the detachable container; personal data lives only in detachable bodies, so erasure = body detachment + salt destruction, chain intact. The closed field list is what makes “what could this contract possibly reveal” answerable by reading the state block. A disclosure scope is a borrow of fields - read-access by reference; the value actually revealed to another party is a receipted copy (both then hold it), the scope is the borrow - not a new primitive. And SD-JWT salted selective disclosure is the cryptographic form: hash(salt + value) per field, sign the digests, disclose chosen fields and salts.

Two linter rules make the reconciliation with replay bit-for-bit hold, and both are exercised by an executable golden fixture (sealing and erasure against replay):

• Rule A - salts are fixed at signing. Each sealed field’s digest uses a salt minted once and bound into the signed genesis. Re-rolling a salt breaks the signature - which is why sealing cannot reach for fresh randomness per replay; the salt is a signed constant.
• Rule B - erasable implies non-computational. A field a rule branches on is accumulator state; purging it breaks replay by construction. So such a field may be sealed (hidden from a viewer while the evaluator keeps the value) but never purged. Erasure is honored only on fields no rule computes over (identity data), and the linter enforces it. Where the law demands erasing a computed value, the contract must be restructured so it no longer computes on it - a real boundary, not papered over.

The reconciliation in one line: “replay” splits into evaluate and verify. The full-state evaluator, holding the values in the detachable bodies, reproduces state bit-for-bit - determinism lives here. A digest-only holder cannot re-evaluate a sealed computation but can verify the receipt and the signed commitment. Evaluate needs the value; verify needs only the digest. Sealing separates the two; it breaks neither.

The mechanics that ride those rules:

1. v1 = access control + OSL-aligned redaction views. The platform is already the referee holding full state; per-audience views (public/allmän handling view, counterparty view, mediator view, court view) with field-level redaction driven by a disclosure policy block in the contract itself - the sekretessprövning, pre-declared and signed. No cryptography beyond what we have; legally sufficient because OSL compliance is exactly field-level redaction with a documented basis.
2. Receipts get scoped from day one (cheap now, hard to retrofit): a receipt names the clause IDs it applied; the full diff with values goes only to the parties; third-party/escalation variants carry digests instead of values, resolvable via disclosure. This keeps the hash chain intact while quoting nothing.
3. v2 = cryptographic selective disclosure (SD-JWT-style salted digests per field - conveniently the same primitive the EUDI wallet rails already deploy), so a disclosed subset is verifiable against the signature without trusting our platform. Escalation then means: level 3 discloses the disputed branch + its receipt sub-chain, mathematically bound to the signed whole, nothing else.
4. ZK and TEE stay on the watchlist, adopted only if a real buyer (defense procurement, regions with patient-adjacent contracts) demands referee-blind validation.

The escalation question that started this has a crisp answer under that model: escalating never widens disclosure automatically - each level has a declared disclosure scope (level 1: parties only; level 2: + steering group, digested receipts; level 3: + mediator, disputed branch disclosed; level 4/court: per court order, with the Merkle/salt structure letting us comply exactly and no further). Who-saw-what is itself receipted.

Surfaced by the medical scenario (scenario 1) and adopted as v-next: receipted READS - access itself as an event through a read port, so “who looked at the sealed fields, when” is a fold over access receipts (patientdatalagen’s loggutdrag, generalized to OSL 31:16’s rate cards). Today no contract system can answer that question; this design can make it a query.