Prüfstelle oder Einladung: das Real Life Trust Protocol entlang einer Beziehung

Alice und Bob stehen nach einem Nachbarschaftstreffen am Fahrradständer. Sie haben den Abend über die Gemeinschaftsgärten am Kanal geredet und wollen in Kontakt bleiben. Bob hält sein Handy hoch, Alice scannt den Code. Zwei Sekunden später steht auf beiden Bildschirmen der Name des anderen, und beide tippen auf „bestätigen”.

Was ist in diesen zwei Sekunden passiert? Niemand hat einen Ausweis gezeigt. Keine Behörde, kein Plattformbetreiber und kein Register war beteiligt. Trotzdem halten beide jetzt etwas in der Hand, das sich kryptografisch prüfen lässt.

Dass die beiden dabei nebeneinander standen, gehört zur Idee des Protokolls, aber nicht zu dem, was es beweist. Ein Code lässt sich auch über eine Videoverbindung weiterreichen, und RLTP verbietet jeder Implementierung ausdrücklich, Anwesenheit zu behaupten. Was zählt, ist der Moment, in dem Alice bewusst bestätigt: Das ist Bob, ich erkenne ihn.

Diese Szene ist der Kern des Real Life Trust Protocol, kurz RLTP. Ich arbeite im Real-Life-Projekt am Stack mit, für den es gedacht ist, und habe es selbst nicht entworfen. Weil es eine andere Frage stellt als die meisten Identitätssysteme, gehe ich es hier einmal von vorne durch, entlang einer einzigen Beziehung. Die Einordnung in die Arbeit von Trust over IP und des First Person Project folgt in der zweiten Notiz.

// Der Leitsatz des Protokolls lautet: „Cryptography proves freshness and authorship; only a human can witness a human.”

Was du aus SSI kennst, und was hier anders ist

Wer mit Self-Sovereign Identity gearbeitet hat, kennt das Dreieck: Ein Aussteller signiert einen Nachweis, der Inhaber trägt ihn in seiner Wallet, ein Prüfer verlangt ihn und entscheidet. Das Muster ist die Prüfstelle. Ein Fremder will wissen, ob du etwas bist oder darfst, und du legst ein Verifiable Credential vor.

RLTP stellt eine andere Frage an den Anfang: Für wen ist die Vertrauensaussage gedacht? Die Antwort des Protokolls heißt Einladung statt Prüfstelle. Wer dich kennt, lädt dich ein. Was ihr teilt, bleibt eine Beziehung zwischen euch. Geprüft wird auf euren Geräten, und niemand draußen schreibt mit.

Das ist keine Absage an Nachweise. Die Begründungsseite des Protokolls formuliert es so: „Checkpoints belong at the edges of social space; invitations belong inside it.” Grenzübertritt, Altersnachweis und Zulassung unter Fremden bleiben Prüfstellen. Ein Nachbarschaftsgarten, ein Verein oder ein Freundeskreis brauchen keine. Eine Prüfstelle gehört dorthin, wo es keinen gemeinsamen Ort gibt.

Ein Schlüssel, viele Gesichter

Bevor Alice und Bob einander scannen konnten, hat jede ihrer Apps einmal etwas angelegt: zwölf oder vierundzwanzig Merkwörter nach BIP-39. Aus diesen Wörtern entsteht ein Seed, und aus dem Seed leitet die App für jeden Kontext eigene Schlüssel ab. Diese Schlüssel heißen Anker.

Jeder Anker ist ein did:key, also ein Decentralized Identifier, der nichts anderes ist als ein öffentlicher Ed25519-Schlüssel. Dazu gehört ein X25519-Schlüssel für die Verschlüsselung. Nachgeschlagen wird dabei nichts: Wer den Identifier hat, hat den Schlüssel. Kein Netz, kein Register, keine Domain.

Das hat eine Folge, die früh klar sein sollte: Alice hat im Netz kein einzelnes Gesicht. Bob kennt sie unter einem Paar-Anker, ihre Gartengruppe unter einem Mitglieds-Anker, und niemand kann diese beiden ohne Alices Zutun verbinden. Das Protokoll ordnet die Anker den drei Korrelationsbereichen der DTG-Spezifikation zu: pairwise, directed und public.

Der Preis ist ebenso klar benannt. Ein did:key kann nicht rotieren. Wird ein privater Schlüssel kompromittiert, ist der Anker verloren. Die Merkwörter stellen Schlüssel wieder her, aber keinen Zustand: Welche Gruppen und Beziehungen es gibt, steht im verschlüsselten Zustand der Person. Wer die Wörter verliert, verliert die Identität endgültig, es sei denn, die Nachfolge ist eingerichtet. Die ist allerdings bewusst geparkt. Ein Nachfolgeformat mit prüfbarer Schlüsselhistorie ist als offene Arbeit benannt, das Format „deliberately not chosen”.

Die Begegnung

Zurück zum Fahrradständer. Bobs Code war seine Kontaktkarte: eine signierte Selbstbeschreibung mit seinem frischen Paar-Anker, seinem Verschlüsselungsschlüssel, einem Anzeigenamen und einer Zufallszahl, der Challenge. Die Karte ist kein Credential. Den Namen hat Bob selbst eingetragen, und niemand bürgt dafür.

Alice scannt. Ihre App erzeugt eine eigene Karte, adressiert an Bob, mit Bezug auf Bobs Challenge und mit einer neuen Challenge von Alice. Dann fragt sie Alice, ob sie bestätigen will. Erst danach stellt Alices App ein Encounter-Credential aus: ein W3C-Credential, signiert mit einem Data Integrity Proof, das Bobs Challenge bindet. Karte und Credential gehen an Bob. Bob bestätigt seinerseits und stellt ein Credential aus, das Alices Challenge bindet.

Die Challenges sind das, was die Begegnung frisch macht. Sie verfallen nach Minuten, das Fenster für die Ausstellung schließt nach 24 Stunden. Ein Credential, das vor dem Bestätigen oder ohne die Challenge der Gegenseite entstanden ist, gibt es nach den Regeln des Protokolls nicht.

Aus Alices Sicht entsteht so eine Kante zu Bob. Solange nur ihr Credential unterwegs ist, ist sie ausgehend. Kommt Bobs zurück, wird sie gegenseitig. Zählt eine Anwendung später Kontakte, zählen nur eingehende und gegenseitige Kanten.

Wer den Ablauf einmal selbst durchspielen will: Das RLTP-Projekt hat dafür einen Simulator gebaut, der auf der echten Bibliothek läuft. Zwei simulierte Geräte zeigen ihre Codes, ein Knopf ersetzt die Kamera, und jeder Umschlag zwischen den beiden Geräten wird sichtbar.

Ein Encounter-Credential läuft nicht ab und wird nie widerrufen. Ändert sich Alices Einschätzung von Bob, stellt sie ein neues aus. Es gibt kein Verzeichnis, aus dem es sich streichen ließe, und kein Signal an Alice, ob Bob es angenommen hat. Die Begegnung ist ein Ereignis, das stattgefunden hat.

Wiedererkennen ist nicht Vertrauen

Drei Wochen später treffen sich Alice und Bob auf dem Gartenfest wieder und scannen erneut. Weil jede Begegnung frische Paar-Anker erzeugt, wissen die Apps zunächst nicht, dass sie sich kennen. Hier greift das Wiedererkennen über eine Continuity Probe: Beide Apps schicken einander verblindete Werte ihrer bisherigen Beziehungsanker, aufgefüllt mit Zufallswerten. Gibt es einen Treffer, verketten sie die neue Begegnung mit der alten. Auf dem Bildschirm steht nach einem Hin und Her „re-verified”, ohne Dialog. Ein Gegenüber, das seine Daten verloren hat, kann nicht antworten und gilt ehrlich als neuer Kontakt.

Für alles, was zwei Kontexte einer Person verbindet, nutzt das Protokoll keine Signatur, sondern einen Designated-Verifier-Nachweis. Ein Beispiel ist die Anker-Zuordnung: Alice zeigt Bob, dass ihr Paar-Anker und ihr Community-Anker zusammengehören. Bob kann das prüfen. Er hätte es aber auch selbst erzeugen können, also kann er es niemandem beweisen. Dritte können es nicht einmal prüfen. Die Spezifikation sagt dazu: „a cross-context link MUST NOT exist anywhere as a transferable proof.”

Diese Regel ist systematisch angelegt. Das Protokoll teilt jedes Artefakt in eine von drei Zielgruppenklassen ein, nach zwei Fragen: Wen muss die Aussage überzeugen, und muss der Empfänger sie weitergeben können?

Die Standardform ist abstreitbar. Eine übertragbare Signatur ist die Ausnahme, die begründet werden muss. „Provability MUST be the smallest set the purpose demands.”

Am deutlichsten wird das beim Stern. Bob möchte wissen, welche seiner Kontakte Alice auch kennt. Alice schickt ihm einen Stern: für jeden ihrer Kontakte entweder nur einen Beitrag zur Gesamtzahl oder einen verblindeten Wert, den Bob nur mit seinen eigenen Kontakten abgleichen kann. Welche Form gilt, entscheidet der betroffene Kontakt selbst. Ein Stern wird nie signiert. Wäre er signiert, könnte Bob einem Dritten beweisen, wer zu Alices Kreis gehört. Die Spezifikation hält fest: „Forgeability is a requirement, not a defect.” Die Kehrseite: Alice kann im Stern weglassen oder erfinden, und niemand darf ihn als Beleg ihrer Beziehungen werten.

Einladung in einen Ort

Alice und Bob gehören zur Gartengruppe am Kanal. Bei RLTP ist so eine Gruppe kein Eintrag bei einem Anbieter und kein Mitgliedsausweis in einer Wallet. Sie ist eine Gruppe als Ort: ein verschlüsseltes Dokument, das auf den Geräten aller Mitglieder repliziert wird, mit einem eigenen Log darüber, wer beigetreten ist, wer gegangen ist und welche Regeln gelten. Mitglied sein heißt, im Gruppenzustand zu stehen und den aktuellen Schlüssel zu halten. „Being a member means holding a place, not holding a claim.”

Admins gibt es nicht. Die Gruppe trägt ihre Regeln als Daten, und zwar je Operation: Wer darf aufnehmen, wer entfernen, wer den Schlüssel erneuern, wer die Regeln ändern? Eine Regel kann lauten „irgendein Mitglied”, „k Mitglieder”, „bestimmte Mitglieder” oder „n Bürgschaften”. Jedes Gerät eines Mitglieds setzt sie durch. Ein einzelner Gründer mit allen Rechten ist nur der Sonderfall k = 1.

Jetzt will Carol dazukommen. Bob kennt sie aus der Begegnung am Fahrradständer der Vorwoche. Die Aufnahme läuft in fünf Schritten:

Anker übergeben

Carols App leitet ihren Mitglieds-Anker für diese Gruppe ab und gibt ihn Bob. Ab hier kennt die Gruppe Carol unter diesem Anker, nicht unter dem Paar-Anker vom Fahrradständer.

Einladung

Bob schickt eine Einladung. Sie ist ein Verifiable Invitation Credential aus der DTG-Familie, nennt Carols Anker und den Genesis-Digest der Gruppe. Sie trägt keinen Schlüssel und keine Operation.

Zustimmung

Carol signiert eine Zustimmung, die an genau diese Einladung gebunden ist und ihre eigene Karte enthält. Unter dem Schlüssel dieser Karte reist später das Welcome.

Aufnahme

Ein Mitglied, das nach den Regeln aufnehmen darf, schreibt die Aufnahme ins Log. Sie enthält Einladung und Zustimmung als vollständige signierte Dokumente, nicht nur deren Hashes. Damit kann jedes Gerät die Aufnahme ohne Vorwissen prüfen.

Welcome

Carol erhält, an sie versiegelt, das Material des aktuellen Schlüsselzustands und nichts mehr. Die Geschichte der Gruppe öffnet sich über die Kette, die die Gruppe in ihrem Replikat führt.

Verlangt die Gruppe mehr als eine Einladung, steht in ihren Regeln zum Beispiel vouch(2). Dann braucht Carol zwei Mitglieder, die für genau diese Aufnahme bürgen. Eine solche Aufnahme-Bürgschaft nennt Carols Anker, die Gruppe und die konkrete Zustimmung, auf die sie sich bezieht. Sie läuft nicht ab, gilt aber nur für diese eine Aufnahme. Ob die Bürgin Carol getroffen hat oder ihr vorgestellt wurde, schreibt sie als eigene Angabe hinein. Geprüft wird diese Angabe nie.

Wenn jemand geht

Ein Jahr später zieht Carol weg und verlässt die Gruppe. Bob verliert im selben Monat sein Handy. Beide Ereignisse beginnen eine neue Schlüsselepoche.

Der Grundsatz heißt „Revocation is an epoch”. Jede Operation, die Rechte entzieht, trägt ihre Schlüsselerneuerung im selben signierten Umschlag. Ein Austritt braucht nur Carols eigene Signatur und darf von niemandem blockiert werden. Das Sperren des eigenen verlorenen Geräts darf ebenfalls nie von anderen abhängen. Und die Spezifikation ist ehrlich, was das kann: Entfernen ist kein Löschen. „No protocol revokes knowledge.”

Alle diese Operationen stehen im Authority-Log der Gruppe. Es ist ein kausal verketteter Graph einzeln signierter Einträge, der mit der Gründung beginnt. Der Hash dieser Gründung ist die Identität der Gruppe. Der Gruppenzustand wird aus dem Log berechnet, und kein Schlüssel verleiht dauerhafte Macht.

Was passiert, wenn zwei Mitglieder gleichzeitig handeln, während sie offline sind? Für fast alle Kombinationen gibt es eine feste Regel. Entfernen zwei Mitglieder einander gleichzeitig, wirken beide Entfernungen. Genau ein Fall lässt sich nicht automatisch auflösen: Ändert jemand die Regeln, während ein anderer gleichzeitig jemanden entfernt oder den Schlüssel erneuert. Dann geht die Gruppe in einen sichtbaren Gabelzustand, in dem jede Berechtigungsanfrage abgelehnt wird, bis eine neue Regeländerung beide Zweige zusammenführt. Die Foundations-Seite fasst es so: „Only a change of the rules made at the same time as a removal stops the group, visibly.”

Wiedersehen und Vorstellen

Dave möchte in die Gartengruppe, kennt dort aber niemanden außer Bob, und Alice kennt Dave nicht. Bob kann die beiden einander vorstellen. Dafür laufen fünf versiegelte Nachrichten: Alice fragt Bob, Bob reicht die Anfrage unverändert an Dave weiter, Dave antwortet, Bob bestätigt, und beide Seiten erhalten von Bob einen Beleg. Bob überträgt dabei Nachrichten, nie die Anker seiner eigenen Beziehungen. Alice und Dave legen für ihre neue Beziehung frische Anker an.

Eine vorgestellte Beziehung ist schwächer als eine Begegnung, und das Protokoll sagt das offen. Bob könnte den Akt fabrizieren und Dave selbst spielen. Dagegen gibt es ohne vorherige Beziehung keine kryptografische Abhilfe. Deshalb trägt jede Beziehung ihre Herkunft: „vorgestellt” oder „begegnet”. Erst ein echtes Treffen hebt sie auf „begegnet”, nie geht es abwärts.

Brief und Tisch

Bis hierher kam kein Server vor, und das ist Absicht. RLTP nennt weder einen Transport noch eine Datenbank. Es definiert zwei Verträge, die Ports, und jedes Substrat, das einen Vertrag hält, kann das Protokoll tragen.

Der Zustellvertrag ist der Brief. Er bringt ein Dokument zu genau einem Empfänger und ist bei Ankunft erledigt: „Eventually, at least once, never silently lost.” Jede Nachricht ist dabei ein Trust-Task-Dokument in einem versiegelten Umschlag. Der erste und bisher einzige Adapter bindet das Trust Spanning Protocol über einen Mediator der Verifiable Trust Infrastructure an. Er läuft, das Profil des VTI-Mediator-Adapters ist aber noch nicht konvergiert.

Der Replikationsvertrag ist der Tisch, an dem die Gruppe sitzt. Er hält das Dokument einer Gruppe auf jedem Gerät gleich, solange die Gruppe besteht. Er verspricht „convergence over entries, never readability of content”: Der Dienst hinter dem Port gleicht Einträge ab, lesen kann er sie nicht. Welcher Eintrag kanonisch ist, bestätigt kein Dienst, jedes Gerät berechnet es selbst. Damit passt der Vertrag zum Gedanken von Local-first-Software, ohne sich auf ein bestimmtes CRDT festzulegen. Die Spezifikation prüft bekannte Kandidaten wie p2panda, Keyhive, SECSYNC, NextGraph und Automerge Baustein für Baustein und kommt zu einem klaren Urteil: „None is a conformant adapter today.”

Und wer ist ein Mensch?

Eine Frage bleibt, die jeder stellt, der an Sybil-Angriffe denkt: Woher weiß das Netz, dass hinter einem Anker ein Mensch steht? RLTP gibt darauf keine Ausstellerantwort. Die Personhood Predicates sind Messgrößen, die ein Prüfer selbst über vorgelegte Encounter-Credentials berechnet, relativ zu den Ankern, die er schon kennt. Etwa: Wie viele mir bekannte Anker haben diesen Anker erkannt? Die Spezifikation sagt deutlich, was sie nicht leisten: „No predicate here says ‘this is a human’”. Und: „A verifier without roots learns nothing.” Wie sich das zu den Personhood Credentials des First Person Project verhält, steht in der zweiten Notiz.

Offene Punkte

Das Bild ist schlüssig, und ein Teil davon läuft schon in einer App. Vieles ist aber noch Spezifikation. Diese Grenzen nennen die Quellen selbst:

Wer RLTP aus der Welt der Verifiable Credentials kennenlernt, findet viele vertraute Bausteine wieder: W3C-Credentials, DIDs, Trust Tasks, TSP. Neu ist, wofür sie eingesetzt werden. Die Credentials sind Belege zwischen zwei Menschen, und die Gruppe ist ein Ort, den ihre Mitglieder selbst tragen. Wo genau das Protokoll von Trust over IP abweicht, und warum, zeigt die zweite Notiz.