Einwilligungsarchitektur
Einwilligung ist mehr als ein Häkchen im Formular.
Die DSGVO verlangt das seit 2018; Artikel 71 des EHDS hat es im vergangenen Jahr durchsetzbar gemacht. Decentralized Key Management ist die einzige Architektur, die ein Opt-out über institutionelle Grenzen hinweg einhalten kann.
30-minütige Überprüfung Ihrer Einwilligungsarchitektur buchenFünf Rechtsregime konvergieren innerhalb von 24 Monaten
Einwilligung ist längst keine organisatorische Kür mehr. In Europa und der Schweiz haben fünf separate Rechtsregime das Opt-out zur harten gesetzlichen Pflicht gemacht, und jedes davon ist unabhängig von den anderen entstanden. Eines haben sie gemeinsam: Sie setzen voraus, dass der Verantwortliche die Nutzung identifizierbarer Daten auf Verlangen stoppen kann, diesen Stopp an jede nachgelagerte Stelle weitergibt und das später nachweist. Zentralisierte Identitätsinfrastruktur ist für keine dieser Garantien ausgelegt.
-
EHDS Artikel 71
In Kraft seit 26. März 2025
Opt-out als gesetzliches Recht; Artikel 71(8) schliesst Re-Identifikationsregister aus; Erwägungsgrund 54 schreibt Reversibilität vor.
-
DSGVO Art. 7(3) + Art. 17(2)
In Kraft seit 25. Mai 2018
Der Widerruf muss so einfach sein wie die Einwilligung; Verantwortliche müssen die Löschung an jeden nachgelagerten Empfänger weitergeben.
-
eIDAS 2.0 Artikel 5a
In Kraft seit 20. Mai 2024; Wallets bis Q4 2026
Identitäts-Wallets unter Kontrolle der Bürgerinnen und Bürger, mit selektiver Offenlegung und Unverknüpfbarkeitspflichten für vertrauende Parteien.
-
Schweizer nDSG / HFG-Revision
nDSG in Kraft seit 1. September 2023; HFG-Änderung in der Vernehmlassung
Widerrufspflicht bei der Einwilligung zur sekundären Forschungsnutzung; ausdrückliches Verbot der Re-Identifikation pseudonymisierter Daten.
-
Deutsches PDSG
In Kraft seit 20. Oktober 2020
Patientenkontrollierter Zugriff auf ePA-Daten; granulares Opt-out je Datenkategorie, durchsetzbar über alle Leistungserbringer hinweg.
Jedes Regime für sich wäre verkraftbar. Zusammen machen sie zentralisierte CA-Architektur unzureichend.
Die fünf nicht verhandelbaren Anforderungen
Aus den fünf juristischen Regimen ergeben sich fünf technische Anforderungen an die umsetzende Infrastruktur. Keine ist optional, keine lässt sich wegbedingen, jede ist mit Artikel und Absatz in primärem Recht benannt.
Für die Begründung auf ein (i) klicken · Zum Vergrössern klicken
-
Personengebundene Identifikatoren
Der Identifikator, den die betroffene Person kontrolliert, muss die Vertrauenswurzel sein, nicht ein Identifikator, den eine vertrauende Partei ausstellt. Erwägungsgrund 54 des EHDS und Artikel 5a von eIDAS 2.0 benennen das direkt: Bürgerinnen und Bürger müssen handeln können, ohne dass der Verantwortliche sie in einem separaten Register nachschlagen muss. Jede Architektur, in der der Verantwortliche den Identifikator erzeugt und speichert, scheitert hier am ersten Tag.
-
Verifizierbares, zeitgestempeltes Opt-out
Der Widerruf muss ein kryptografisch signiertes, zeitgestempeltes Ereignis sein, das die Aufsichtsbehörde (und ein künftiges Gericht) verifizieren kann, ohne den Aufzeichnungen des Verantwortlichen vertrauen zu müssen. Artikel 7(3) der DSGVO sagt es ausdrücklich: Der Verantwortliche trägt die Beweislast. Eine Zeile in einer internen Datenbank ist kein Beweismittel in einem Verfahren, in dem der Verantwortliche der Beklagte ist.
-
Reversibilität ohne Re-Identifikation
Erwägungsgrund 54 des EHDS verlangt, dass das Opt-out reversibel bleibt (die betroffene Person kann wieder einwilligen), ohne dass jemand die zugrunde liegenden Datensätze re-identifizieren muss. Dafür muss das Opt-out gegen ein Credential wirken, das die betroffene Person kontrolliert, nicht gegen eine serverseitige Zuordnungstabelle. Zentralisierte Einwilligungsregister scheitern hier strukturell.
-
Weitergabe über Verantwortliche hinweg
Artikel 17(2) der DSGVO und Artikel 71 des EHDS verlangen beide, dass der Widerruf jeden nachgelagerten Empfänger erreicht. Praktisch heisst das: Der ursprüngliche Verantwortliche kann nicht einfach seinen lokalen Eintrag ändern. Jede Partei, die die Daten je erhalten hat, muss die Autorisierung neu authentifizieren und feststellen, dass sie widerrufen wurde. Föderation schafft das nur, indem sie Identifikatoren teilt, und verletzt damit die nächste Anforderung.
-
Unverknüpfbarkeit
eIDAS 2.0 Artikel 5a verlangt, dass vertrauende Parteien dieselbe Person ohne Einwilligung nicht über getrennte Transaktionen hinweg korrelieren können. Artikel 71(8) des EHDS schliesst den zentralen organisationsübergreifenden Identifikator aus, der die föderierte Weitergabe trivial machen würde. Beide Anforderungen zusammen (weitergeben, aber nicht korrelieren) bringen die konventionellen Architekturen zu Fall.
X.509 erfüllt keine einzige. Föderation erfüllt die Weitergabe, indem sie die Unverknüpfbarkeit verletzt. DKMS erfüllt alle fünf.
Die Falle in Artikel 71(8)
Die intuitive technische Antwort auf «Opt-out im ganzen Netzwerk einhalten» ist eine Liste aller Identifikatoren mit erklärtem Opt-out: ein zentral geführtes Sperrregister, das jedes nachgelagerte System abfragt, bevor es einen Datensatz anfasst. Genau diese Konstruktion verbietet Artikel 71(8) des EHDS. Die Klausel untersagt Dateninhabern, zusätzliche Identifikationsdaten allein zu dem Zweck zu erheben oder zu speichern, Opt-outs einzuhalten.
Die Begründung, in Erwägungsgrund 54 ausdrücklich dargelegt: Das Register selbst wird zur Re-Identifikationsdatenbank, also genau zu dem Schaden, den die Verordnung verhindern soll. Wer eine Liste der «Personen mit erklärtem Opt-out» führt, hat den zentralen Honeypot neu gebaut. Die strukturelle Konsequenz ist unausweichlich: Das Opt-out-Signal muss mit einem Credential wandern, das die betroffene Person kontrolliert, nicht in einer Liste liegen, die der Verantwortliche pflegt.
The DKMS thesis DKMS ist die Antwort
Decentralized Key Management ist die erste strukturell tragfähige Grundlage, um ein Opt-out durchgängig einzuhalten: über Organisationsgrenzen hinweg, nach bereits erfolgter Offenlegung und unter regulatorischer Aufsicht.
(Decentralized Key Management baut auf KERI auf, einer offenen Spezifikation der Trust over IP Foundation.)
So funktioniert es:
- Die AID, die die Person selbst kontrolliert, ist die Vertrauenswurzel. Autorisierungen ketten sich kryptografisch an sie, nicht an ein Konto, das der Verantwortliche ausstellt.
- Jede Autorisierung ist im Key Event Log (KEL) der AID verankert: einem hash-verketteten Protokoll, dem sich Einträge nur anfügen und nicht nachträglich verändern lassen und dessen Zustand die betroffene Person ohne fremde Hilfe nachweisen kann.
- Der Widerruf ist eine Schlüsselrotation, die die betroffene Person selbst durchführt. Der alte Schlüssel wird ungültig; das Rotationsereignis wird im KEL signiert und zeitgestempelt.
- Nachgelagerte Parteien mit veralteten Credentials müssen sich erneut gegen den aktuellen KEL-Zustand authentifizieren. Der Widerruf setzt sich durch, weil die Verifizierung bei jedem nachgelagerten Prüfer fehlschlägt und der Zugriff damit verwehrt bleibt (fail closed).
Nichts im Protokoll erfordert einen zentralen Betreiber. Nichts verlangt, dass vertrauende Parteien Identifikatoren teilen. Nichts verlangt, dass die Aufsichtsbehörde den Aufzeichnungen des Verantwortlichen mehr vertraut als denen der betroffenen Person. Jede der fünf Anforderungen ist durch Konstruktion erfüllt, nicht durch Audits.
Wo DKMS überlegen ist und wo es keinen Nutzen bringt
Ehrlichkeit über den Geltungsbereich macht die These verteidigbar. DKMS ist unter vier Bedingungen überlegen: bei organisationsübergreifenden Datenflüssen, beim Widerruf nach bereits erfolgter Offenlegung, bei Verarbeitung unter regulatorischer Aufsicht und bei adversarialen Gegenparteien. Ausserhalb dieser Bedingungen, etwa bei Single-Tenant-Workloads, bei abgeleiteten Artefakten wie trainierten ML-Modellgewichten, bei Backups aus der Zeit vor dem Widerruf und bei einzelnen unehrlichen Gegenparteien, die allein handeln, liefert DKMS forensische Erkennung, aber keine Prävention.
Ausserhalb der vier Bedingungen, unter denen DKMS überlegen ist, ist zentralisiertes CMK eine vernünftige Wahl. Das offen zu sagen macht die These stärker.
Im Produktivbetrieb bewährt
HIN (Health Info Net) ist das Rückgrat des schweizerischen Gesundheitsinformationsaustauschs und verbindet Spitäler, Kliniken und spezialisierte Leistungserbringer über Kantonsgrenzen hinweg. SEAL, die Schicht für verifizierbare E-Mail-Zustellung, die Vereign innerhalb von HIN bereitstellt, ist heute im Produktiveinsatz und transportiert 800.000+ verifizierte Nachrichten pro Monat: der Nachweis, dass Vereign bereits produktionsreife Infrastruktur im Schweizer Gesundheitswesen betreibt.
Verimesh (früher das Stargate-Projekt), die Decentralized-Key-Management-Laufzeitumgebung, die den oben beschriebenen vierstufigen Opt-out-Mechanismus in den operativen Einsatz bringt, geht Ende Juni 2026 in den frühen Produktiveinsatz.
Die FHIR-Schicht von Verimesh, also dieselben Garantien angewandt auf den Austausch klinischer Dossiers und nicht nur auf Nachrichten, ist heute ein architektonisches Konzept. Der Schritt in den Produktiveinsatz hängt vom Onboarding auf Spitalseite ab; der früheste realistische Zeitpunkt liegt Ende 2026.
Fünf Vorfälle, die das strukturelle Muster belegen
- Kaiser Foundation Health Plan: Vergleich in einer Sammelklage über 47,5 Mio. USD (2026). Daten aus dem Patientenportal sind über eingebettete Tracking-Pixel an Werbeplattformen abgeflossen. Die Architektur hat keinen Mechanismus vorgesehen, mit dem die betroffene Person die nachgelagerte Weitergabe hätte widerrufen können.
- Sutter Health: Vergleich in einer Sammelklage über 21,5 Mio. USD (2026). Dasselbe Muster: Drittanbieter-Tags im Portal, kein von der betroffenen Person kontrollierbares Widerrufsprimitiv, keine Möglichkeit, die Nichtverarbeitung im Nachhinein nachzuweisen.
- NHS National Data Opt-Out (2021): eingestandene Nicht-Rückwirkung. Das GPDPR-Programm hat sich verzögert, weil die Architektur den Widerruf gegenüber Daten, die bereits an nachgelagerte Forschende weitergegeben worden waren, nicht einhalten konnte.
- SingHealth (2018): 1,5 Mio. Datensätze kompromittiert, weil Patientendaten in einer einzigen monolithischen Datenbank ohne patientenseitige kryptografische Grenzen gespeichert waren. Es gab nichts, was die betroffene Person hätte widerrufen können; es gab keinen Schlüssel zu rotieren.
- DigiNotar (2011): Nach der Kompromittierung der Root-CA haben Browser jedem Zertifikat misstraut, das die CA je ausgestellt hatte. Die betroffenen Personen hatten keinerlei architektonische Handlungsmacht: Ihre Identifikatoren und Vertrauensbeziehungen waren vollständig vom Betreiber kontrolliert.
Alle zentralisierten Vorfälle teilen ein Merkmal: Die betroffene Person hatte keinerlei architektonische Handlungsmacht.
Wo Sie ansetzen
Wenn Ihre Organisation identifizierbare Gesundheits-, Finanz- oder andere regulierte Personendaten verarbeitet und einem der fünf genannten Regime unterliegt, ist der nächste Schritt eine 30-minütige Architekturüberprüfung. Wir gleichen Ihren heutigen Einwilligungsfluss mit den fünf Anforderungen ab, benennen die Lücken und sagen Ihnen ehrlich, ob DKMS die richtige Antwort für Ihre Umgebung ist.
Häufige Fragen
- Was verlangt Artikel 71 des EHDS?
- Artikel 71 des EHDS (in Kraft seit 26. März 2025) gibt allen EU-Bürgerinnen und -Bürgern das Recht, der Sekundärnutzung identifizierbarer Gesundheitsdaten zu widersprechen. Artikel 71(8) untersagt Dateninhabern, zusätzliche Identifikationsdaten allein zum Einhalten von Opt-outs zu erheben; damit sind zentralisierte Umsetzungen als «Liste der IDs mit Opt-out» ausgeschlossen, weil die Liste selbst ein verbotenes Re-Identifikationsregister wäre. Erwägungsgrund 54 schreibt vor, dass das Opt-out reversibel und formfrei sein muss.
- Warum kann ein zentralisiertes Einwilligungsregister nicht funktionieren?
- Artikel 71(8) verbietet es ausdrücklich. Das Register selbst wird zum Re-Identifikationsregister, also genau zu dem, was die Verordnung verhindern soll. Die strukturelle Antwort verlangt Identifikatoren, die die betroffene Person kontrolliert, keine zentrale Liste in der Hand eines Betreibers.
- Garantiert DKMS die Durchsetzung der Einwilligung?
- Nein. DKMS ist die erste strukturell tragfähige Grundlage, um ein Opt-out durchgängig einzuhalten: über Organisationsgrenzen hinweg, nach bereits erfolgter Offenlegung und unter regulatorischer Aufsicht. Ausserhalb dieser Bedingungen (Single-Tenant-Workloads, Derivate wie ML-Modellgewichte, bereits erstellte Backups, einzelne unehrliche Gegenparteien) liefert DKMS forensische Erkennung, aber keine Prävention.
- Wie arbeitet DKMS mit X.509- und S/MIME-Gegenparteien zusammen?
- Über KERI-verankerte S/MIME-Brücken, die den Widerruf auch über Parteien hinwegtragen, die X.509 verwenden. Die Brücke verankert das X.509-Zertifikat an einer KERI-AID; der Widerruf der Einwilligung löst eine Schlüsselrotation der AID aus; nachgelagerte X.509-Prüfer müssen das Zertifikat neu abrufen und neu authentifizieren.