Szenario 01
Login ohne Passwort – Patientenportal einer Arztpraxis
Situation: Eine Physiotherapie-Praxis betreibt ein kleines Online-Portal, über das Patienten Termine buchen und Befunde einsehen können. Bisher: Benutzername und Passwort, ständig "Passwort vergessen"-Anfragen, Sorge um Datensicherheit.
Mit ROND:
- Die Praxis integriert die ROND-API in ihr Portal (wenige Zeilen Code, wie heute "Sign in with Google")
- Ein Patient öffnet das Portal und klickt "Anmelden mit EUDI"
- Sein Smartphone zeigt eine EUDI-Wallet-Bestätigung – Fingerabdruck oder FaceID
- Die ROND Identity Registry bestätigt dem Portal: "Diese Person ist verifiziert. Hier ist ihre pseudonyme ID für euren Dienst."
- Der Patient ist eingeloggt. Kein Passwort, kein Benutzername, keine E-Mail-Bestätigung.
Was ROND dabei NICHT speichert:
Keine Information darüber, dass sich dieser Patient gerade bei dieser Praxis eingeloggt hat. Keine Login-Historie. Keine Nutzungsprofile. Die Registry kennt nur den Public Key und die Autorisierungsregeln – nicht, wo sie verwendet werden.
Der Unterschied zu "Sign in with Google":
Google weiß danach, dass du dich um 14:37 bei der Praxis eingeloggt hast. ROND weiß das nicht.
Szenario 02
Spam wird strukturell unmöglich – Kommunikation einer Hausärztin
Situation: Eine Hausärztin bekommt täglich Dutzende unerwünschte Mails – Pharma-Werbung, Fortbildungs-Spam, Phishing. Spamfilter helfen, aber lassen auch wichtige Nachrichten durch oder sortieren echte Anfragen aus.
Mit ROND:
- Die Ärztin registriert sich per EUDI Wallet in der Identity Registry
- Sie definiert Autorisierungsregeln: "Kontakt erlaubt von: meinen Patienten, dem Labor Dr. Meier (EUDI-verifiziert), der KV Niedersachsen, meinem Ehemann."
- Ein Pharma-Vertreter will ihr eine Nachricht schicken → Er fragt die Registry nach ihrem Public Key → Die Registry prüft: Ist der Absender autorisiert? Nein. → Die Registry gibt den Public Key nicht heraus. Die Nachricht kann nicht einmal verschlüsselt werden, geschweige denn zugestellt.
Warum das anders ist als ein Spamfilter:
Der Spamfilter entscheidet nach dem Empfang, was Spam ist – und liegt dabei oft falsch. ROND verhindert den Empfang nicht-autorisierter Nachrichten physisch. Der Absender bekommt den Schlüssel gar nicht erst.
Szenario 03
Digitales Vermächtnis – Ein Freelancer sorgt vor
Situation: Ein Freelancer hat 47 Online-Accounts (Banking, SaaS-Tools, Social Media, Krypto-Wallets), eine laufende Lebensversicherung und eine Partnerin, die im Ernstfall an alles rankommen muss. Bisher: ein Zettel im Schreibtisch, der nach drei Monaten veraltet ist.
Mit ROND:
- Der Freelancer hinterlegt eine verschlüsselte Übersicht aller Zugangsdaten in ROND
- Er benennt seine Partnerin als Empfängerin (identifiziert über ihre EUDI-Attribute – kein Krypto-Wissen nötig)
- Er definiert fünf Guardians – Vertrauenspersonen, die seinen Tod bestätigen können
- Trigger-Bedingung: Drei von fünf Guardians bestätigen per EUDI, dass er verstorben ist
- Nach Trigger-Aktivierung: Die Schlüsselfragmente werden rekombiniert, seine Partnerin kann die Übersicht entschlüsseln
Was die Partnerin NICHT braucht:
Keine Krypto-Kenntnisse, kein eigenes ROND-Konto im Voraus, keine technische Einrichtung. Sie identifiziert sich per EUDI Wallet – das genügt.
Was passiert, wenn er die Liste aktualisiert:
Er ändert die verschlüsselte Übersicht jederzeit. Die Trigger-Konfiguration und die Empfänger bleiben unberührt. Er muss nicht jedes Mal alles neu einrichten.
Szenario 04
Ein Verein nutzt alle drei Schichten
Situation: Ein Sportverein mit 200 Mitgliedern hat drei Probleme: ständige Passwort-Resets für den Mitgliederbereich, Spam auf der Vorstands-E-Mail, und die Angst, dass niemand an die Vereinskonten kommt, wenn dem Kassenwart etwas passiert.
Mit ROND:
- Identity Registry: Mitglieder loggen sich per EUDI in den Mitgliederbereich ein. Kein Passwort-Chaos, keine vergessenen Zugangsdaten, keine Nutzerdatenbank.
- Authorization Protocol: Der Vorstand definiert: "Kontakt nur von verifizierten Vereinsmitgliedern." Die Vorstands-Mail-Adresse ist Spam-frei – strukturell, nicht per Filter.
- Legacy Protocol: Die Zugangsdaten zum Vereinskonto, zum Hosting-Account und zum Steuerberater-Portal sind verschlüsselt hinterlegt. Trigger: Drei von fünf Vorstandsmitgliedern bestätigen, dass der Kassenwart sein Amt nicht mehr ausüben kann.
Was öffentlich verankert wird – und was nicht
Die häufigste Frage, die wir bekommen: "Liegen meine sensiblen Daten dann irgendwo öffentlich?"
Nein. Öffentlich verankert werden ausschließlich Metadaten:
| Öffentlich verankert | NICHT verankert |
|---|
| Hashes verschlüsselter Payloads | Die Payloads selbst (verschlüsselt auf föderierten Nodes) |
| Trigger-Konfigurationen | Nachrichteninhalte |
| Public Keys | Private Keys (verlassen nie dein Gerät) |
| Autorisierungsregeln | Login-Historien |
| Schlüsselfragment-Referenzen | Personenbezogene Daten im Klartext |
Der Integritätsanker ist das Regelregister – er dokumentiert kryptografisch überprüfbar, dass eine Regel existiert und wann sie erstellt wurde. Nicht was drinsteht. Gebraucht wird er, weil sonst niemand über 30 Jahre hinweg nachweisen kann, dass diese Regeln nicht manipuliert wurden – das Versprechen einer Organisation genügt dafür nicht. Welche Technologie diesen Anker liefert, ist nicht entschieden; die Architekturentscheidung läuft (ADR-003, Status: Vorgeschlagen).
Stand der Architekturentscheidung →