Sekretess and privacy: the open problem

Status: OPEN PROBLEM, flagged honestly. Nothing below is committed design; it is the map of the territory and the prior art to read. The v1 posture is stated at the end.

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 v1 posture (until v2 solves it properly)

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.