Willkommen in der Zukunft der digitalen Identität. Diese interaktive Demo macht das abstrakte Konzept von Self-Sovereign Identity (SSI) greifbar. Erlebe hands-on, wie digitale Ausweise funktionieren – sicher, dezentral und nutzerzentriert.
Gefällt dir das Projekt?
☕ Spendier mir einen KaffeeDas SSI-Ökosystem basiert auf drei Rollen: Issuer (Aussteller), Holder (Nutzer) und Verifier (Prüfer). Du lernst interaktiv, wie diese Parteien vertrauensvoll zusammenarbeiten, ohne auf zentrale Datenbanken angewiesen zu sein. Zudem kannst du jederzeit neue digitale Identitäten für Personen und Organisationen anlegen und verwalten.
Hier definierst du, welche Art von digitalem Nachweis (Verifiable Credential - VC) erstellt werden soll. Die Auswahl reicht von hoheitlichen Dokumenten wie der E-ID bis hin zu privatwirtschaftlichen Zertifikaten oder Tickets. Damit bestimmst du den Kontext für die nachfolgende Ausstellung und Prüfung.
Dezentrale Register (Base Registry) und Vertrauenslisten (Trust Registry) bilden das technische Fundament für globale Auffindbarkeit. Du erfährst, wie öffentliche Schlüssel (DIDs) hinterlegt werden, ohne personenbezogene Daten zentral zu speichern. Zusätzlich kannst du neue Aussteller (Issuer) konfigurieren und in die Vertrauensliste eintragen.
In diesem Schritt erstellt der gewählte Aussteller (Issuer) einen manipulationssicheren digitalen Nachweis (als Verifiable Credential) für einen Nutzer (Holder). Der fertige Nachweis wird kryptografisch signiert und sicher in der Wallet des Nutzers abgelegt. Dabei wird dir Schritt für Schritt visualisiert, wie ein VC technisch aufgebaut ist.
Wähle einen Geschäftsprozess, der einen spezifischen digitalen Nachweis (VC) erfordert, und lade das entsprechende Wallet eines Holders. Der Prüfer (Verifier) fordert eine Verifiable Presentation (VP) an und validiert deren Echtheit in Echtzeit. Der komplexe mathematische Prüfprozess wird hierbei transparent und verständlich in Einzelschritten dargestellt.
Erstelle die Identitäten (Issuer, Holder, Verifier) und generiere ihre kryptografischen Schlüsselpaare lokal im Browser.
Digitales Vertrauen ist schwer herzustellen. Oft müssen wir uns auf zentrale Vermittler (wie "Login mit Google") verlassen, um Identitäten zu prüfen.
SSI löst das durch kryptografische Schlüsselpaare, die den Nutzern selbst gehören – ohne zentrale Abhängigkeit.
Der Bund agiert als Vertrauensanker ("Trust Root"). Er betreibt eine öffentliche Trust Registry.
Darin steht z.B.: "Der kryptografische Schlüssel XY... gehört dem Kanton Aargau und darf E-IDs ausstellen." So entsteht Vertrauen ohne zentrale Datenspeicherung.
Erstelle die Identitäten für die Simulation.
Wähle die Identitäten für die Simulation aus.
Hier wird ausgewählt, welcher Digitale Nachweis (Verifiable Credential) erstellt werden soll, durch den oben ausgewählten Issuer.
Damit du nicht jedes Datenfeld einzeln definieren musst, nutzen wir hier Vorlagen (Schemas).
Der gewählte Use-Case bestimmt die Struktur des digitalen Nachweises: Welche Datenfelder (Claims) wie Name, AHV-Nummer oder Mitarbeiter-ID enthalten sein sollen.
👉
Wichtig: Deine Auswahl hier dient als aktive Vorlage für den späteren Schritt "Verifiable Credential (VC) ausstellen".
Die technische Basis für Vertrauen: Wo finde ich Schlüssel (Base Registry) und wem darf ich vertrauen (Trust Registry)?
Wie prüfe ich eine digitale Unterschrift, wenn ich den Aussteller gar nicht kenne?
Ohne ein "Telefonbuch" finde ich den öffentlichen Schlüssel nicht. Und ohne eine "Liste vertrauenswürdiger Behörden" könnte jeder behaupten, das Strassenverkehrsamt zu sein. Wir brauchen also einen Ort zum Nachschlagen und Verifizieren.
Bei der Prüfung liest der Verifier zuerst, wer unterschreibt (Base Registry), und dann, ob derjenige diesen Nachweis ausstellen darf (Trust Registry).
Der Bund betreibt die Base- und Trust Registry. Wichtig: Dort sind keine Personendaten gespeichert!
Dort steht nur: "Der Schlüssel mit der ID did:tdw:... gehört dem Kanton Zürich und darf E-IDs ausstellen." Die Daten der Bürger bleiben sicher auf deren Smartphones.
{}
{}
Entfernt Einträge aus der Base Registry.
Entfernt ausgewählte Autorisierungen (pro VC-Typ).
Der Kernprozess: Eine Aussteller (Issuer) signiert Daten digital und "überträgt" sie in die Wallet des Nutzers (Holder).
Herkömmliche Dateien sind manipulierbar. Doch auch qualifiziert signierte PDFs sind keine Lösung für Ausweise:
Während wir in der Demo das generische W3C-Modell nutzen, setzt die Schweiz auf SD-JWT (IETF Standard) ↗.
Der Unterschied:
Das Demo-VC (W3C) hat oft nur eine Signatur über alles.
SD-JWT hingegen verpackt jedes Datenfeld einzeln ("Salt"). Das ermöglicht später die selektive Offenlegung (Datensparsamkeit), ohne die Signatur zu brechen.
Bitte wähle oben im Tab "Registry" einen Issuer und einen Holder aus.
Der Issuer bürgt für die Richtigkeit der Daten. Er nimmt die Fachdaten (Claims), berechnet einen Hash (digitales Einfrieren) und signiert diesen mit seinem Private Key.
Gleichzeitig veröffentlicht er seinen Public Key in der Infrastruktur (Trust Registry), damit andere die Signatur prüfen können.
Einfach gedacht: „Daten schreiben“ + „Einfrieren“ + „Stempeln (Signieren)“ + „Abschicken“ ⇒ VC.
Der Moment der Wahrheit: Der Verifier prüft die kryptografische Echtheit, ohne beim Issuer (Staat) nachfragen zu müssen.
Wie prüft ein Türsteher heute einen Ausweis? Er leuchtet mit einer UV-Lampe darauf. Aber er kann nicht sicher wissen, ob der Ausweis nicht gestohlen oder gestern als ungültig erklärt wurde.
Um sicher zu sein, müsste er theoretisch bei der Behörde anrufen ("Phone-Home"). Das ist langsam, teuer und ein Datenschutz-Albtraum (Überwachung).
Der Staat schaut nicht zu (Unlinkability):
Wenn du dein Alter im Supermarkt prüfst, erfährt das Bundesamt (Issuer) nichts davon. Die Prüfung findet direkt zwischen deinem Handy und der Kasse statt. Es gibt keinen zentralen Server, der Nutzungsprotokolle anlegt ("Kein Phone-Home").
Demo (Vereinfacht): Wir nutzen eine klassische W3C Verifiable Presentation ↗. Das ist ein einfaches JSON-Paket.
Die CH Vertrauensinfrastruktur nutzt für die Übertragung das Protokoll OIDC4VP ↗ (OpenID Connect for Verifiable Presentations).
Warum OIDC4VP?
Es bietet mehr Sicherheit. Der Prüfer (Verifier) muss sich gegenüber dem Wallet authentifizieren. So sieht der Nutzer auf dem Handy genau, wer die Daten anfordert (z.B. "Bundesamt für Informatik"), bevor er zustimmt.
Der Holder verpackt dein VC in eine VP und signiert diese mit seinem Private-Key.
Der Verifier lädt die Schlüssel, bildet den gleichen Hash, prüft die Issuer-Signatur (Inhalt echt) und die Holder-Signatur (Umschlag echt) und schaut in die Statusliste.
Einfach gedacht: „Stempel stimmt“ (Issuer) + „Umschlag echt“ (Holder) + „nicht widerrufen“ (Status) + „berechtigt“ (Registry) ⇒ valid.
Wähle hier, welche Person (Wallet) geprüft werden soll.
Waiting...
Waiting...
Vertiefe dein Wissen: Teste Datensparsamkeit, Widerrufe Nachweise, Manipuliere Daten in einem VC, erkenne böse Verifier und prüfe Wiederherstellung von VCs.
Konfiguriere eine Anfrage und entscheide als Nutzer, was du teilst.
Der Verifier hat deine Daten erhalten und validiert. Unten siehst du genau, welche Informationen tatsächlich das Wallet verlassen haben.
Wir simulieren den Webserver und speichern die Bits im LocalStorage deines Browsers.
demo.statuslist.[DID]bits: [0,0,1,...]Klickst du oben auf "Widerrufen", setzen wir das Bit an der Position (Index) des VCs von 0 auf 1.
Die Statusliste ist eine Datei, die auf einem hochverfügbaren Webserver (HTTPS) liegt.
Die Liste ist selbst ein signiertes VC des Issuers. So kann niemand die Liste fälschen, selbst wenn der Server gehackt wird.
credentialStatus.id die URL zur Liste.statusListIndex == 0?Wir können das VC nicht aus dem Wallet löschen. Stattdessen markieren wir es global als ungültig.
Der Issuer führt eine Bit-Liste. 0=Gültig, 1=Widerrufen. Extrem effizient: 100'000 Ausweise brauchen nur 12kb.
Der Prüfer lädt nur die Bit-Liste. Er sieht "Nr. 45 ist ungültig", weiss aber nicht, wem Nr. 45 gehört.
Nur der Aussteller kann widerrufen.
Visuelle Darstellung der ersten 256 Indizes in der Registry.