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 liegt auf der Blockchain – und was nicht?
Die häufigste Frage, die wir bekommen: "Ihr speichert sensible Daten auf einer Blockchain?"
Nein. Die Blockchain speichert ausschließlich Metadaten:
| Auf der Blockchain (on-chain) | NICHT auf der Blockchain |
|---|
| 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 |
Die Blockchain ist das Regelregister – sie dokumentiert kryptografisch verifizierbar, dass eine Regel existiert und wann sie erstellt wurde. Nicht was drinsteht. Genau deshalb braucht es eine Blockchain: Wer garantiert über 30 Jahre hinweg, dass diese Regeln nicht manipuliert wurden? Die kryptografische Verkettung der Blockchain – nicht das Versprechen einer Organisation.