DaWN-Dokumentation · Identität und Zugriff

Ein Kreis, viele Schlüssel

Eine Identität ohne Registrierungsstelle muss drei Verluste überstehen: den Diebstahl eines Schlüssels, das Abschalten einer Domain und den Verlust sämtlicher Geräte. Rechte müssen offline prüfbar bleiben, weitergegeben und dabei eingeschränkt werden können — ohne Rückfrage bei einem Dienst, der dann ja auch entscheiden könnte. Diese Seite zeigt, wie das gelöst ist und welche Alternativen aus welchem Grund ausgeschieden sind.

did:webvh Biscuit-Capabilities Losverfahren Stand September 2026

Reifegrad dieser Seite

Alles auf dieser Seite ist entschieden und dokumentiert — und nichts davon ist gebaut. Weder die Prüfung der Identität noch die der Berechtigungen existiert als Code; die zuständigen Bausteine haben null Zeilen. Was hier steht, beschreibt Festlegungen, nicht laufende Software.

Problem 1

Ein gestohlener Schlüssel darf keine Übernahme erlauben

Wer einen Signaturschlüssel erbeutet, kann in fremdem Namen sprechen — das ist unvermeidlich. Unvermeidlich ist aber nicht, dass er damit auch die Identität an sich reisst, indem er einen eigenen Schlüssel als neuen gültigen einträgt. Genau das verhindert die Vorab-Rotation: Jeder Eintrag im Änderungsprotokoll benennt bereits den Hashwert des nächsten Schlüssels. Eine Rotation ist nur gültig, wenn der neue Schlüssel zu diesem vorab hinterlegten Wert passt — und dieser Nachfolger war nie im Umlauf, von ihm existiert nur der Fingerabdruck.

Geprüft und verworfen wurden mehrere Alternativen. KERI versprach genau das und noch Zeugen dazu, löste das Zeugenproblem aber nicht protokollseitig. Eine verwandte Methode drückt dasselbe über eine Web-Adresse aus und bringt dieselbe Komplexität mit. Reine Schlüssel-Bezeichner ohne Historie können nicht rotieren; ein nacktes Schlüsselpaar erst recht nicht. Ein Kompromiss wird offen benannt: Für die Verkettungs-Fingerabdrücke schreibt das gewählte Verfahren SHA-256 zwingend vor, obwohl im übrigen System eine andere Hashfunktion bevorzugt wird — hingenommen, weil dort nichts signiert wird.

Die Domain darf kein Abschaltpunkt sein

Eine web-basierte Identität hängt normalerweise an ihrer Domain. Wer sie abschaltet, löscht die Identität. Drei Vorkehrungen lösen das: Portabilität ab dem Gründungseintrag, Verteilung der Protokolldatei über die Abgleichschicht, und unabhängige Beobachter, die den letzten gültigen Stand vorhalten. Weil alles signiert und verkettet ist, kann ein bösartiger Beobachter nicht fälschen, sondern nur schweigen oder veralten — deshalb fragt man mehrere und nimmt die längste gültige Kette.

Auch der Verlust aller Geräte darf nicht das Ende sein

Die Wiederherstellung läuft nicht als Neuanfang, sondern als gewöhnliche Rotation auf einen Schlüssel, der längst vorab festgelegt war. Er entsteht deterministisch aus einer Saat, die per Aufteilung auf fünf Vertrauenskontakte gesichert ist, von denen drei genügen — und die auf keinem eigenen Gerät liegt. Die Identität behält dabei ihre Kennung und ihre gesamte Geschichte. Verworfen wurden ein Neustart bei null, der alle Beziehungen gekostet hätte, und das Anzeigen einer Merkwortliste, die Nutzer erfahrungsgemäss verlieren.

Durchgespielt

Das Telefon ist weg, das Notebook auch

Ausgangslage. Beide Geräte sind verloren. Auf keinem lag die Wiederherstellungs-Saat; verteilt sind fünf Anteile bei fünf Kontakten.
Drei Kontakte genügen. Sie geben ihre Anteile heraus, daraus wird die Saat rekonstruiert. Aus zwei Anteilen lässt sich nichts gewinnen.
Der Nachfolgeschlüssel entsteht. Er wird aus der Saat berechnet — und passt zu dem Fingerabdruck, der seit dem letzten Eintrag im Protokoll steht.
Die Rotation wird eingetragen. Ein gewöhnlicher Eintrag, kein Sonderfall. Wer die Kette prüft, sieht eine reguläre Rotation.
Ergebnis. Dieselbe Kennung, dieselbe Geschichte, dieselben Beziehungen. Für Gegenstellen hat sich nichts geändert ausser dem aktuellen Schlüssel.

Was der Angreifer davon hat: Wer eines der verlorenen Geräte findet und dessen Schlüssel ausliest, kann Nachrichten fälschen, bis die Rotation durch ist — die Identität übernehmen kann er nicht, weil der Nachfolger nie auf dem Gerät lag.

Problem 2

Zeugen, die sich niemand selbst aussucht

Sobald Zeugen eine feindliche Übernahme verhindern sollen, taucht ein bekanntes Problem auf: Benennt der Inhaber seine Zeugen selbst, schützen sie gegen jeden ausser gegen ihn. Die Lösung ist ein Losverfahren mit überprüfbarer Zufallsfunktion — jeder Kandidat zieht selbst, nachprüfbar für alle, vorhersehbar für niemanden.

Die Vorbehalte, die dazugehören

Der Zufall, aus dem gezogen wird, entsteht in einem kuratierten Kreis von Betreibern. Solange nicht genug unabhängige Instanzen existieren, ist es ein einzelner Gründungsserver — ein Zustand, den die Architektur ausdrücklich als reduzierte Sicherheitsstufe zu benennen verlangt. Die Konstruktion ist eigen und unerprobt, die verwendeten Bibliotheken sind nicht auditiert, und Kreisgrösse, Schwelle und Zeitabschnitt sind bewusst noch nicht festgelegt. Zeugen gehören ohnehin nicht zur ersten Auslieferung. Geprüft und verworfen wurden vier fremde Zufallsquellen — die eine wegen fremder Kryptografie, die anderen wegen Konsensbedarf oder Beeinflussbarkeit durch den letzten Teilnehmer.

Problem 3

Rechte, die nur schrumpfen

Rechte müssen weitergereicht werden können, ohne dass der Empfänger mehr bekommt als der Absender hatte — und die Prüfung muss ohne Rückfrage auskommen, sonst ist das System offline wertlos. Die gewählte Form ist eine anfügbare Blockkette: Jeder Weitergabeschritt hängt einen Block mit zusätzlichen Bedingungen an, der Umfang kann nur kleiner werden. Bedingungen stehen in einer eingebetteten Regelsprache, sodass ein Prüfer sie auswerten kann, ohne die Anwendungslogik zu kennen.

UCAN schied aus, weil es eine im Projekt nicht bevorzugte Hashfunktion zwingend vorschreibt und weil ein alternativer, nicht widerrufener Beweispfad einen Widerruf umgehen kann. Verworfen wurden ausserdem ein älteres Fähigkeitsformat ohne Regelsprache und der Gedanke, Berechtigungen als Bescheinigungen über Personen auszudrücken — hier geht es um konkrete Rechte an konkreten Objekten, nicht um Eigenschaften von Menschen. Einordnung, die das Projekt selbst vornimmt: Berechtigungen sind die zweite Verteidigungslinie. Die erste ist und bleibt, dass ohne Schlüssel nichts zu lesen ist.

Zwei Modelle, weil eines nicht beides kann

Unwiderrufliche Veröffentlichung und verkaufter, entziehbarer Zugang schliessen einander aus. Statt einen faulen Kompromiss zu bauen, gibt es beides, und der Eigentümer wählt je Objekt. Gruppen laufen über dieselbe Kette eine Ebene höher statt über ein zweites Rechtesystem.

Durchgespielt

Ein Kurs wird gekauft — und der Zugang später entzogen

Kauf. Die Käuferin weist sich mit ihrem Schlüssel aus. Der ausgebende Knoten prüft Berechtigung und Zahlung und gibt den Inhaltsschlüssel heraus, verpackt für genau ihren Schlüssel.
Nutzung. Sie lädt die Inhalte und liest sie offline, ohne dass irgendjemand das mitbekommt — der Schlüssel liegt bei ihr, nicht bei einem Dienst.
Weitergabe an ihre Lerngruppe. Sie hängt einen Block an ihr Berechtigungsdokument: nur Lesen, nur dieses eine Kapitel, nur bis Monatsende. Mehr als sie selbst hat, kann sie nicht weitergeben.
Entzug. Die Zahlung platzt. Der Ursprung wird auf die Sperrliste gesetzt — und weil jedes abgeleitete Dokument die Kennung des Ursprungs mitträgt, verfallen die Weitergaben an die Lerngruppe automatisch mit.
Was der Entzug nicht kann. Wer den Inhaltsschlüssel schon zwischengespeichert hat, liest weiter, bis dessen Gültigkeit abläuft. Bereits heruntergeladene Inhalte werden nicht unlesbar.

Die Lücke, die bleibt: Ein Entzug ist selbst nur eine Nachricht im Netz. Bis sie ein bestimmtes Gerät erreicht, gilt dort die alte Berechtigung — die Frischelücke ist der Preis dafür, dass das System offline funktioniert. Im souveränen Modus gibt es den Entzug ohnehin nicht.

Der Satz, der das Offline-Modell trägt

Der Netzzustand ist niemals ein Eingang in eine Autorisierungsentscheidung, und es gibt keinen Codepfad nach dem Muster „wenn offline, dann erlauben". Autorität entsteht aus Schlüsselbesitz, nicht aus Erreichbarkeit; fehlt eine Information, wird abgelehnt. Gegen zurückgedrehte Uhren schützt eine nur vorwärts laufende Zeituntergrenze.

Problem 4

Ein zweites Gerät, ohne den Hauptschlüssel zu kopieren

Zweitgeräte bekommen einen eigenen Schlüssel mit eng zugeschnittenen Rechten statt einer Kopie des Wurzelschlüssels. Geht ein Gerät verloren, wird dessen Dokument gesperrt — die Identität bleibt unberührt. Zwei bequemere Wege wurden ausdrücklich verworfen, weil beide die Leitung prüfen statt den Schlüssel: sich darauf zu verlassen, dass eine Anfrage von der eigenen Maschine stammt, und eine Liste erlaubter Herkunftsadressen.

Wie dieselbe Frage auf der Gegenseite gelöst ist — wenn ein Browser mit einem lokalen Knoten sprechen will —, steht auf der Seite zum Veröffentlichungs-Frontend. Wie Rechte und Identität im Netz transportiert werden, auf der Seite zum Netz.