RLTP im Universum von Trust over IP und First Person: was es übernimmt, wo es abweicht und warum

Wer aus der Welt von Trust over IP auf das Real Life Trust Protocol schaut, erkennt vieles wieder: W3C-Credentials, Korrelationsbereiche, Trust Tasks, TSP. Und dann stolpert er über Dinge, die es dort nicht gibt. Gruppen ohne Admins. Credentials, die nie widerrufen werden. Nachweise, die nur ein einziger Empfänger prüfen kann.

Die Frage, die sich dann stellt: Ist RLTP eine Variante des Decentralized Trust Graph, ein Konkurrent oder etwas Drittes? Diese Notiz beantwortet das Baustein für Baustein. Die Grundlagen des Protokolls selbst stehen in der ersten Notiz. Ich arbeite im Real-Life-Projekt mit, habe RLTP aber nicht entworfen; wo ich eine eigene Einschätzung gebe, steht das dabei.

Die Kurzfassung liefert das Protokoll selbst: „From the ToIP Decentralized Trust Graph work it takes credentials, Trust Tasks and transport. From local-first software it takes replicated data, group keys and event logs. What is new is the joining: groups that are places, entered through trust between people.”

Die Landkarte

Vier Akteure sind im Spiel. Trust over IP ist das Projekt unter dem Dach der LF Decentralized Trust. Darin arbeitet die DTG-Arbeitsgruppe an drei Spezifikationen: der Credential-Familie mit sieben Typen, der Verifiable Trust Infrastructure für Knoten und Dienste und dem Rahmenwerk der Trust Tasks. Das Trust Spanning Protocol ist die Transportschicht darunter. Das First Person Project hat 2025 ein White Paper veröffentlicht, das den Vertrauensgraphen aus Sicht der Menschen beschreibt und die Standardisierung der DTG-Arbeitsgruppe überlässt. RLTP steht daneben, als eigenständiges Protokoll aus dem Real-Life-Projekt.

Was RLTP übernimmt

RLTP beschreibt sich selbst als bewusst an der DTG-Arbeit ausgerichtet, dort wo sich beide treffen. Die Übernahmen sind konkret:

In der Rollensprache der DTG-Arbeit ist die Web-of-Trust-App, die RLTP trägt, ein Personal Network Manager: lokal zuerst, Schlüssel auf dem Gerät, ohne einen gehosteten Verifiable Trust Agent.

Wo RLTP abweicht, und warum

Die README des Protokolls nennt die Abweichungen selbst und verspricht, die Gründe in den Spezifikationen offenzulegen: „participant recognition rather than third-party witness, per-relationship anchors with blinded continuity rather than a stable identifier per person, and honestly stated correlation properties.” Daraus ergeben sich sieben Stellen, an denen sich die Modelle trennen.

Mitgliedschaft: Platz statt Bescheinigung

In DTG ist Mitgliedschaft eine Kante aus zwei Credentials. Die Community stellt ein Verifiable Membership Credential aus, das Mitglied bestätigt es mit einem zweiten. Erst beide zusammen beweisen die Mitgliedschaft.

RLTP stellt kein Mitgliedschaftscredential aus. Mitglied ist, wer im Zustand der Gruppe steht und den aktuellen Schlüssel hält. Die Begründung steht auf der Begründungsseite des Protokolls: „Being a member means holding a place, not holding a claim.” Wie eine RLTP-Gruppe ihre Mitgliedschaft gegenüber Außenstehenden bescheinigen könnte, ist offen. Die Spezifikation nennt dafür die kurzlebigen Bescheinigungen über einen Verifiable Authority Credential als Vergleichsfall.

Der Raum: Room-Host oder Geräte der Mitglieder

Hier liegt der genaueste Unterschied, und er wird leicht falsch erzählt. Die VTI kennt gemeinsame Räume. Ein „data room” ist dort „a shared space with its own membership”, betrieben auf einem Room-Host. Der Room-Host ist ein Host Service: Infrastruktur, von der ein Knoten abhängt. Rechte wie room-present und room-open regeln, wer im Raum vorzeigen und öffnen darf. Die Vertrauensgrenze zieht die VTI je Betreiber.

RLTP macht den Raum zum Protokollobjekt ohne Betreiber. Die Gruppe ist ein verschlüsseltes Dokument, das auf den Geräten aller Mitglieder liegt. Dienste dürfen beim Abgleich helfen, aber der Replikationsvertrag verspricht ausdrücklich „convergence over entries, never readability of content”. Welcher Eintrag kanonisch ist, berechnet jedes Gerät selbst.

Autorität: Community-Rolle oder Regeln als Daten

Die VTI trennt Schlüsselhoheit und Mitgliedschaft sauber: Der Verifiable Trust Agent ist die Schlüssel- und Kontextautorität, die Verifiable Trust Community die Mitgliedschaftsautorität. „Admission is a decision made under community authority, not the completion of a join exchange.” Verwaltet wird über Rollen und Fähigkeiten, etwa eine eigene Fähigkeit für das Ändern der Community-Regeln.

RLTP kennt diese Rolle nicht. „There are no admins.” Die Gruppe trägt je Operation eine Regel als Daten in ihrem Authority-Log, jedes Gerät setzt sie durch, und ein einzelner Gründer mit allen Rechten ist der Sonderfall k = 1. Die Spezifikation begründet das an den Stellen, wo Macht über andere schaden würde: Ein Austritt darf von niemandem blockiert werden, und das Sperren des eigenen verlorenen Geräts darf nie von anderen abhängen.

Widerruf: Statusliste oder Schlüsselepoche

DTG und VTI arbeiten mit Gültigkeitsfristen und credentialStatus. Delegations- und Autoritätscredentials müssen ein Ablaufdatum tragen, und die VTI verlangt, dass Suspendierung und Entfernung eines Mitglieds im Status seiner Credentials wirken. Die DTG-Spezifikation benennt dabei selbst die Kosten: Eine Statusabfrage verrät dem Betreiber der Liste Ereignisse, deshalb sind kurze Fristen und Neuausstellung der bevorzugte Entzug. Einladungen sollen kurz gelten und nur einmal verwendet werden.

RLTP hat an diesen Stellen keine Statusliste. Ein Encounter-Credential ist unveränderlich und wird nie widerrufen, eine neue Einschätzung ist ein neues Credential. Aus einer Gruppe verschwindet man über eine neue Schlüsselepoche: „Revocation is an epoch.” Eine RLTP-Einladung gilt im Standard 90 Tage und hat ebenfalls keinen Status. Eine Bürgschaft läuft gar nicht ab, sie ist aber an genau eine Zustimmung gebunden und damit nach der Aufnahme verbraucht.

Präsentation: Zero-Knowledge als Ziel, Designated Verifier als Weg

Die DTG-Spezifikation empfiehlt, Credentials per Zero-Knowledge-Proof vorzulegen, und nennt das als Standardverhalten. Sie sagt aber auch ehrlich, dass die nötigen Konstruktionen „requirements on the schemas rather than constructions” sind. Bis sie stehen, werden Credentials offen vorgelegt, und die Kosten trägt der Datenschutz.

RLTP geht einen anderen Weg. Alles, was zwei Kontexte einer Person verbindet, wird als Designated-Verifier-Nachweis gebaut: aus Schlüsselvereinbarung und HMAC, nur für den Empfänger prüfbar und für ihn fälschbar. Die Regel lautet: „a cross-context link MUST NOT exist anywhere as a transferable proof.” Zero-Knowledge-Präsentation führen die RLTP-Spezifikationen als Richtung, nicht als Funktion. Für die Prädikate, die sie bräuchten, verzeichnen sie den Stand „no audited library”.

Identität: did:webvh oder did:key

Die VTI verlangt für die dauerhafte Identität von Agenten, Communities und Diensten did:webvh und erlaubt did:key nur für das erste Einrichten eines Clients. RLTP nutzt ausschließlich did:key, auch dauerhaft, je Kontext ein eigener Anker. Did:webvh und did:peer sind laut Foundations-Seite „not specified”.

Eine Begründung für diese Wahl steht in den RLTP-Spezifikationen nicht. Sie halten fest, dass did:key nicht rotieren kann, und lassen das Nachfolgeformat mit prüfbarer Schlüsselhistorie bewusst offen. Als nächsten Nachbarn nennen sie eine geplante, noch nicht veröffentlichte Arbeit der DTG-Gruppe zu einem Peer-to-Peer-Vertrauensstack.

Netz und Register: VTN und Trust Registry oder nichts

Über den Communities kennt die VTI das Verifiable Trust Network, das Communities listet, und die Trust Registry als Nachschlagewerk für Autorität. RLTP hat oberhalb der Gruppe keine Ebene und kein Register, in dem nachgefragt wird. Die Begründungsseite sagt, was zwischen den Welten bewusst nicht wandert: „What does not cross is the checking itself: no registry, no duty to present, no log of who was checked.”

Kante und Zeuge: Begegnung statt Beobachtung

DTG baut eine Kante aus einem VRC-Paar und hat für die beobachtete Kantenbildung einen eigenen Zeugenbeleg, das Witness-Profil des Statement Credential. RLTP lässt die beiden Beteiligten selbst bestätigen und setzt auf frische Anker je Begegnung, verbunden über verblindetes Wiedererkennen. Die Encounter-Spezifikation nennt das „stricter than the DTG’s one per relationship”. Für Dritte beweist ein Credential-Paar dabei nur Stimmigkeit, nicht, dass ein Treffen stattfand.

First Person: Personsein von zwei Seiten

Das First Person Project fragt, wie ein Mensch online zeigen kann, dass er eine reale, einzigartige Person mit realen Beziehungen ist. Seine Antwort hat zwei Teile. Ein Personhood Credential stellt ein Ökosystem aus, also eine Community, ein Unternehmen, eine Universität oder ein Staat, und zwar höchstens eines je Person. VRCs stellen Menschen einander paarweise aus, per QR-Code, aber auch per Nachricht oder E-Mail. Sie können ablaufen oder widerrufen werden, wenn die Beziehung endet. In der DTG-Spezifikation wird ein PHC zum Membership-Grant einer Community, deren Regeln genau eine Mitgliedschaft je Mensch verlangen, und das First Person Network dient als Beispiel für ein solches Netz.

RLTP hat keinen Aussteller für Personsein. Seine Personhood Predicates sind Messgrößen, die ein Prüfer über vorgelegte Encounter-Credentials selbst berechnet, relativ zu den Ankern, die er schon kennt. Sie beanspruchen ausdrücklich keine Einzigartigkeit: „The predicates here claim no uniqueness and need no issuer.”

Gegen Sybil-Angriffe setzen beide also an verschiedenen Enden an. Das First Person Project verankert Einzigartigkeit bei einem Aussteller und braucht dafür zertifizierte Communities und ein Governance Framework, das laut White Paper noch geschrieben werden muss. RLTP verzichtet auf diese Instanz. Ein Anker ist bei RLTP billig zu erzeugen; teuer ist nur eine Aussage unter einem Schlüssel, den der Prüfer schon kennt. „A verifier without roots learns nothing.”

Die Gemeinsamkeiten sind größer, als die Unterschiede vermuten lassen. Das White Paper warnt vor einem globalen Vertrauensgraphen: „It would be a privacy disaster.” Jeder soll seinen eigenen Teilgraphen halten. Das First Person Network soll „exclusively by invitation” wachsen. Und beide Seiten setzen auf Paare von Credentials zwischen Menschen.

Wo sich die Welten treffen

RLTP versteht sich als Brücke, nicht als Gegenmodell. Die Begründungsseite sagt: „The two worlds meet, and statements cross in both directions.” An vier Stellen ist das heute greifbar:

Lesbare Credentials

Encounter-Credentials, Einladungen und Bürgschaften tragen die DTG-Typen und den DTG-Kontext. Ein DTG-Verifier kann ihre Form lesen.

Gemeinsamer Transport

Der erste Zustelladapter von RLTP läuft über TSP und einen VTI-Mediator. Das Profil dieses Adapters ist noch nicht konvergiert, der Weg läuft aber.

Gemeinsames Nachrichtenmodell

RLTP-Nachrichten sind private Trust-Task-Spezifikationen im Sinn des DTG-Rahmenwerks.

Belege für Fremde

Ein Encounter-Credential „can serve as evidence where a stranger needs it”. Wie das technisch aussieht, beschreiben die Quellen noch nicht; es ist eine erklärte Absicht.

Bewusst nicht über die Brücke geht die Prüfung selbst. Die Gruppe bleibt ein Ort: Was auch immer draußen über sie gesagt wird, ihre Regeln und Daten bleiben bei den Mitgliedern.

Was das für die DTG-Arbeit bedeuten könnte

// Dieser Abschnitt ist meine Einschätzung, keine Aussage der Spezifikationen.

Ein Raumprofil ohne Room-Host. Die VTI hat den Data Room schon als Begriff. RLTP zeigt, wie ein solcher Raum ohne Betreiber aussehen kann, mit Regeln als Daten, Schlüsselepochen und einem Log, das jedes Gerät selbst auswertet. Ich halte das für einen Kandidaten für ein eigenes Profil neben dem Room-Host.

Designated Verifier als Zwischenschritt. Solange die Zero-Knowledge-Konstruktionen der DTG-Spezifikation nicht stehen, werden Credentials offen vorgelegt. Für Verknüpfungen zwischen zwei Kontexten zeigt RLTP mit heute verfügbarer Kryptografie, wie ein Nachweis nur den Empfänger überzeugt.

Die Kante neu denken. Bei der DTG-Arbeitsgruppe läuft die Diskussion, ob ein VRC als Kante zählt, wenn der Verifier den Aussteller schon kennt. RLTP liefert dazu ein durchgearbeitetes Beispiel: frische Anker je Begegnung, verblindetes Wiedererkennen und Zählregeln, die nur eingehende und gegenseitige Kanten werten. Auch der offene Punkt, ob dabei die einzelne Kante oder die verkettete Beziehung zählt, wäre dort gut aufgehoben.

Personsein an den Rändern. RLTP sagt: Prüfstellen gehören an den Rand des sozialen Raums, Einladungen in seine Mitte. Ein Personhood Credential passt genau an diesen Rand, die Personhood Predicates in die Mitte. Ich sehe darin eher eine Arbeitsteilung als eine Konkurrenz.

Versionsstand

RLTP referenziert die DTG-Arbeit auf einem älteren Stand. Das betrifft die Form, nicht das Modell, sollte aber vor jedem Gespräch über Interoperabilität klar sein:

Die RLTP-Quellen nennen den Umzug auf den DTG-Kontext v2 und auf ein StatementCredential mit eigenem Prädikat für die Bürgschaft als geplante gemeinsame Änderung. Auch auf der DTG-Seite ist vieles Entwurf: Keine der drei Spezifikationen ist ratifiziert, Konformanztests fehlen, und das Format des VRC nannte das First-Person-White-Paper 2025 noch eine offene Frage der Arbeitsgruppe.