Consent Architecture

Consent isn't a checkbox.

GDPR has required this since 2018; EHDS Article 71 made it enforceable last year. Decentralized Key Management is the only architecture that can honor opt-out across institutional boundaries.

Book a 30-minute consent architecture review

Five regimes converging in a 24-month window

Consent is no longer an organisational nice-to-have. Across Europe and Switzerland, five separate regulatory regimes have made opt-out a hard legal obligation — and each one was drafted independently of the others. They share one feature: they assume the data controller can stop using identifiable data on demand, propagate that stop across every downstream party, and prove it later. Centralized identity infrastructure was never designed for any of those guarantees.

  • EHDS Article 71

    In force 26 March 2025

    Opt-out as legal right; Article 71(8) forecloses re-identification registers; Recital 54 mandates reversibility.

  • GDPR Art 7(3) + Art 17(2)

    In force since 25 May 2018

    Withdrawal must be as easy as giving consent; controllers must propagate erasure to every downstream recipient.

  • eIDAS 2.0 Article 5a

    In force 20 May 2024; wallets by Q4 2026

    Citizen-controlled identity wallets with selective disclosure and unlinkability obligations on relying parties.

  • Swiss FADP / HFG revision

    FADP in force 1 September 2023; HFG amendment in consultation

    Consent withdrawal duty for secondary research use; explicit prohibition of re-identification of pseudonymised data.

  • German PDSG

    In force since 20 October 2020

    Patient-controlled access to ePA records; granular opt-out per data category enforceable across providers.

Each one alone is survivable. Together they make centralized-CA architecture insufficient.

The five engineering invariants

Read the five regimes as one engineer would. Strip out the legal language and what remains is a list of five technical invariants the implementing infrastructure has to satisfy. None of these are optional. None of them are negotiated away by reasonable contractual language. Each is named, by clause, in primary law.

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparison: which architecture satisfies which engineering invariant. X.509 satisfies zero. Federation satisfies zero (propagation only by violating unlinkability). DKMS satisfies all five. Engineering invariant X.509 PKI Federated IAM DKMS Person-scoped identifiers ✗ i ✗ ✓ Verifiable timestamped opt-out ✗ ✗ ✓ Reversibility without re-identification ✗ ✗ ✓ Cross-controller propagation ✗ i ✗ i ✓ i Unlinkability ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Click any (i) for the reasoning · Click to expand diagram

Five engineering invariants: X.509 PKI vs Federated IAM vs DKMS Comparison: which architecture satisfies which engineering invariant. X.509 satisfies zero. Federation satisfies zero (propagation only by violating unlinkability). DKMS satisfies all five. Engineering invariant X.509 PKI Federated IAM DKMS Person-scoped identifiers ✗ i ✗ ✓ Verifiable timestamped opt-out ✗ ✗ ✓ Reversibility without re-identification ✗ ✗ ✓ Cross-controller propagation ✗ i ✗ i ✓ i Unlinkability ✗ i ✗ i ✓ i eIDAS 2.0 Art 5a engineering invariants -- X.509 satisfies 0/5, Federation 0/5, DKMS 5/5 Vereign AG -- Engineering Invariants for Lawful Consent

Why X.509 cannot deliver person-scoped identifiers

X.509 identifies entities through certificates issued by a Certificate Authority, not through keys the subject controls. The citizen has no architectural agency in the trust root — the CA decides who is who. EHDS Recital 54 and eIDAS 2.0 Article 5a require subject-controlled identifiers; X.509 satisfies this only by wrapping the PKI in subject-side ceremony the underlying protocol does not natively support.

Why X.509 cannot propagate withdrawal

X.509 has no native propagation primitive. Revocation cascades through CRLs and OCSP responders that each verifier must opt into checking — and there is no way to push a revocation back to data already shared. Once a certificate has signed authorisation for data flow, withdrawal is at the verifier's discretion.

Why X.509 violates unlinkability

Every X.509 certificate carries a stable serial number and issuer DN that is visible to every verifier. Two relying parties can correlate the same subject across transactions by comparing serials. Pseudonymisation requires re-issuance, which is operationally expensive — linkability is the design, not a bug.

Why federation only partially satisfies propagation

Federated IAM satisfies cross-controller propagation only by violating unlinkability — the identity provider sees every relying-party login, creating a forbidden cross-RP correlation surface (eIDAS 2.0 Art 5a(16)(b)). Propagation through federation is therefore counted as not satisfied.

Why federation cannot deliver unlinkability

A federated identity provider sees every login attempt at every relying party. Even if individual credentials are pseudonymous, the IdP holds the cross-RP correlation graph by construction. eIDAS 2.0 Article 5a(16)(b) forbids exactly this surface.

How DKMS propagates withdrawal

Authorisations chain to the subject's Key Event Log (KEL). When the subject rotates keys, every downstream verifier that re-checks the KEL at processing time sees the rotation and treats stale credentials as invalid. No operator push, no central registry — propagation is verifier-pull at use-time.

How DKMS preserves unlinkability

Subjects can mint a fresh AID for each relying party. The KEL behind each AID is independent — there is no central identity register and no IdP that sees every transaction. Cross-RP correlation requires the subject to deliberately link AIDs.

  1. Person-scoped identifiers

    The identifier the data subject controls must be the trust root, not an identifier issued by a relying party. EHDS Recital 54 and eIDAS 2.0 Article 5a both name this directly: the citizen must be able to act without the controller having to look them up in a separate register. Every architecture that depends on the controller minting and storing the identifier fails here on day one.

  2. Verifiable timestamped opt-out

    Withdrawal must be a cryptographically signed, timestamped event the regulator (and a future court) can verify without trusting the controller's logs. GDPR Article 7(3) makes this explicit: the controller carries the burden of proof. A row in an internal database is not evidence in any forum where the controller is the defendant.

  3. Reversibility without re-identification

    Recital 54 of EHDS demands that opt-out remain reversible — the citizen can opt back in — without anyone having to re-identify the underlying records. That requires the opt-out to operate against a credential the subject controls, not against a server-side mapping table. Centralized consent registries fail here structurally.

  4. Cross-controller propagation

    GDPR Article 17(2) and EHDS Article 71 both require that withdrawal propagate to every downstream recipient. In practice this means the original controller cannot simply update its local row — every party that ever received the data must re-authenticate the authorisation and discover that it has been revoked. Federation can do this only by sharing identifiers, which violates the next invariant.

  5. Unlinkability

    eIDAS 2.0 Article 5a requires relying parties to be unable to correlate the same citizen across separate transactions without consent. Article 71(8) of EHDS forecloses the centralised cross-organisational identifier that would make federated propagation trivial. The two invariants together — propagate, but don't correlate — are what kills the conventional architectures.

X.509 satisfies zero. Federation satisfies propagation by violating unlinkability. DKMS satisfies all five.

The Article 71(8) trap

The intuitive engineering response to "honor opt-out across the network" is to keep a list of opted-out identifiers — a centrally maintained do-not-process register that every downstream system queries before it touches a record. Article 71(8) of EHDS specifically forbids exactly this construction. The clause prohibits data holders from acquiring or storing additional identification data solely for the purpose of honouring opt-outs.

The reasoning, made explicit in Recital 54, is that the register itself becomes a re-identification database — the very harm the regulation was written to prevent. Once you maintain a list of "people who opted out", you have rebuilt the central honeypot. The structural implication is unavoidable: the opt-out signal has to travel with a credential the subject controls, not in a list the controller maintains.

The DKMS thesis DKMS is the answer

Decentralized Key Management is the first structurally sound foundation for honoring opt-out end-to-end in cross-organisational, post-disclosure, regulator-watched conditions.

(Decentralized Key Management is built on KERI, an open Trust over IP Foundation specification.)

How it works:

  1. The user's controlling AID is the trust root. Authorisations chain to it cryptographically, not to a controller-issued account.
  2. Every authorisation is anchored in the AID's Key Event Log (KEL) — an append-only, hash-linked record the subject can prove the state of unilaterally.
  3. Withdrawal is a key rotation the subject performs themselves. The old key is invalidated; the rotation event is signed and timestamped on the KEL.
  4. Downstream parties holding stale credentials must re-authenticate against the latest KEL state. The withdrawal propagates by failing closed at every downstream verifier.

Nothing in the protocol requires a central operator. Nothing requires the relying parties to share identifiers. Nothing requires the regulator to trust the controller's logs over the subject's. Each of the five invariants is satisfied by construction, not by audit.

Where DKMS dominates — and where it offers no benefit

Honesty about scope is what makes the thesis defensible. DKMS dominates four conditions: cross-organisational data flows, post-disclosure withdrawal, regulator-watched processing, and adversarial counterparties. Outside those conditions — single-tenant workloads, derivative artefacts like trained ML model weights, backups already taken before withdrawal, and single dishonest counterparties acting alone — DKMS provides forensic detection but not prevention.

Where DKMS dominates Where DKMS offers no benefit Cross-organisational data flows Click any row for the reasoning Post-disclosure consent persistence Click any row for the reasoning Regulator-determinative custody Click any row for the reasoning Parties compose DKMS end-to-end Click any row for the reasoning Derivatives (analytics, ML weights) Click any row for the reasoning Backups already taken Click any row for the reasoning Single dishonest counterparty Click any row for the reasoning Single-tenant workloads Click any row for the reasoning Where DKMS dominates — and where it offers no benefit. Click any row for the reasoning.

Cross-organisational data flows

Operator-side erasure cannot reach data already shared with downstream parties. DKMS extends holder-controlled keying through the processing chain — every receiver re-checks the KEL at use time. Centralized CMK provides erasure only within the operator's tenancy boundary.

Post-disclosure consent persistence

EUDIW ARF §6.6 explicitly concedes that withdrawal does not retroactively unwind lawful prior processing. DKMS narrows this gap: verifiers re-check the published KEL at processing time, so stale credentials become auditable as such. The architectural primitive is holder-driven, not operator-driven.

Regulator-determinative custody

Schrems II / EDPB Recommendations 01/2020 Use Case 3 require the data importer NOT to hold keys. Centralized CMK fails this test by definition (e.g., US health data in Azure under FISA 702 access). DKMS makes key custody a holder-side property — the importer cannot decrypt without the holder's continued KEL state.

Parties compose DKMS end-to-end

Architecture matters only when all parties enforce it. A verifier that ignores the KEL nullifies the chain. When all parties compose DKMS, withdrawal propagates by simple re-verification — no operator needs to “push” the deletion.

Derivatives (analytics, ML weights)

EDPB Opinion 28/2024 explicitly confirms erasure obligations do not propagate cleanly to model weights once training has occurred. DKMS provides no better coverage than CMK here. Withdrawal cannot retroactively unwind analytics outputs or regulatory reports already filed.

Backups already taken

No architecture can recall data already replicated to offline or immutable backup media. Encryption-at-rest plus key destruction handles retention-window residuals; it does not recover long-term archives. DKMS does not change this fundamental property.

Single dishonest counterparty

DKMS provides forensic detection (signatures past published key rotation are auditable as stale) but not prevention. A fully non-cooperative sub-processor that decrypts plaintext and stores it outside the keyed envelope nullifies the chain — DKMS surfaces the violation rather than blocking it.

Single-tenant workloads

For SaaS under one controller, NIST SP 800-88 §2.5 cryptographic erasure via centralized CMK is adequate and simpler. Switching to DKMS adds operational burden for no architectural benefit when there are no cross-trust-domain boundaries.

Outside the four conditions where DKMS dominates, centralized CMK is rational. Saying so makes the thesis stronger.

Production proof

HIN — Health Info Net — is Switzerland's health-information backbone, connecting hospitals, clinics, and specialist providers across cantonal lines. SEAL, the verifiable email delivery layer Vereign provides inside HIN, is in production today and carries 800,000+ verified messages per month — proof that Vereign already operates production-grade infrastructure inside Swiss healthcare.

Stargate, the Decentralized Key Management runtime that brings the four-step opt-out mechanism described above into operational use, enters early production in June 2026.

Stargate's FHIR layer — the same guarantees applied to clinical record exchange, not just messages — is architectural today. Bringing it to production depends on hospital-side onboarding; the earliest realistic date is September 2026.

Five incidents that prove the structural pattern

  1. Kaiser Foundation Health Plan — USD 47.5M class-action settlement (2026). Patient-portal data leaked to advertising platforms via embedded tracking pixels. The architecture had no mechanism for the subject to withdraw downstream propagation.
  2. Sutter Health — USD 21.5M class-action settlement (2026). Same pattern: portal-side third-party tags, no subject-controlled revocation primitive, no way to prove non-processing after the fact.
  3. NHS National Data Opt-Out (2021) — non-retroactivity admission; the GPDPR programme was delayed because the architecture could not honour withdrawal against data already shared with downstream researchers.
  4. SingHealth (2018) — 1.5M records breached because patient data lived in a single monolithic database with no patient-cryptographic boundaries. There was nothing for the subject to revoke; there was no key to rotate.
  5. DigiNotar (2011) — root CA compromise led browsers to distrust every certificate the CA had ever issued. Subjects had zero architectural agency: their identifiers and trust relationships were entirely operator-controlled.

Every centralized incident shares one feature: the user had no architectural agency.

Where to start

If your organisation processes identifiable health, financial, or regulated personal data and is exposed to any of the five regimes above, the next step is a 30-minute architecture review. We map your current consent flow against the five invariants, identify the gaps, and tell you honestly whether DKMS is the right answer for your environment.

Book a 30-minute consent architecture review Download the consent thesis (PDF, 24 pages)

For your sector

Consent enforcement in healthcare

Read more

Consent enforcement in finance

Read more

Frequently asked

What does EHDS Article 71 require?
EHDS Article 71 (in force 26 March 2025) gives every EU citizen the right to opt out of secondary use of identifiable health data. Article 71(8) forbids data holders from acquiring extra identification data solely to honour opt-out — foreclosing centralized "list of opted-out IDs" implementations because the list itself is a forbidden re-identification record. Recital 54 mandates that opt-out be reversible and free-form.
Why can't a centralized consent registry work?
Article 71(8) explicitly forbids it. The registry itself becomes a re-identification record — exactly what the regulation was designed to prevent. The structural answer requires subject-controlled identifiers, not a central operator-controlled list.
Does DKMS guarantee consent enforcement?
No. DKMS is the first structurally sound foundation for honoring opt-out end-to-end in cross-organisational, post-disclosure, regulator-watched conditions. Outside those conditions — single-tenant workloads, derivatives like ML model weights, backups already taken, single dishonest counterparties — DKMS provides forensic detection but not prevention.
How does DKMS interoperate with X.509 / S/MIME counterparties?
Through KERI-anchored S/MIME bridges that allow withdrawal to propagate across X.509-using parties. The bridge anchors the X.509 certificate to a KERI AID; consent withdrawal triggers AID key rotation; downstream X.509 verifiers must re-fetch and re-authenticate.