Vertrauensnetze

Anker-Zuordnung (anchor mapping)

Die Anker-Zuordnung (anchor mapping) ist im Real Life Trust Protocol ein Nachweis, der den Paar-Anker einer Beziehung mit dem Community-Anker derselben Person verknüpft, und zwar für genau einen Adressaten. Sie ist als Designated-Verifier-Konstruktion gebaut: Nur der Adressat kann sie prüfen, und er hätte sie selbst fälschen können.

Aktualisiert:

Die Anker-Zuordnung (anchor mapping, anchor-mapping@2) verknüpft den Paar-Anker einer Beziehung mit dem Community-Anker derselben Person. Sie ist an genau einen Empfänger adressiert. Weil jede Begegnung neue Paar-Anker erzeugt, trägt ein Kontakt zunächst keinen Hinweis darauf, welcher stabile Anker der Person hinter ihm steht. Die Zuordnung liefert diese Auskunft, wenn die Person sie einem Gegenüber geben will, und keinem anderen.

So funktioniert es

Der Inhalt nennt den Typ, den Paar-Anker (pair), den Community-Anker (self), den Adressaten (to), eine Selbstkarte (card), eine Revision und den Ausstellungszeitpunkt. Den Beweis bilden zwei Nachrichtenauthentifizierungscodes (MAC), mac1 und mac2. Sie folgen dem Muster einer doppelten Diffie-Hellman-Berechnung wie im Signal-Protokoll: Der erste Schlüssel entsteht aus dem X25519-Schlüssel des Paar-Kontexts des Absenders und dem des Adressaten, der zweite aus dem Schlüssel des Community-Ankers und dem Paar-Schlüssel des Adressaten. Alles läuft in WebCrypto.

Die Selbstkarte ist mit dem Community-Anker signiert und bindet dessen Ed25519- und X25519-Schlüssel. Der Adressat nimmt die Zuordnung nur an, wenn eine feste Reihe von Bedingungen in dieser Reihenfolge erfüllt ist: Das Schema stimmt, to ist sein aktiver Paar-Anker, pair ist der Paar-Anker der Gegenstelle, die Karte verifiziert, ihr Anker entspricht self, beide MACs passen und die Revision ist neu genug. Fremde Community-Anker lassen sich auf diesem Weg nicht beanspruchen.

Beabsichtigt ist die Abstreitbarkeit. Ein MAC lässt sich nur mit den Geheimnissen des Adressaten prüfen, also könnte er das gesamte Artefakt selbst erzeugt haben (Designated Verifier, siehe Designated-Verifier-Nachweis). Dritte können nichts verifizieren. Die Selbstkarte ist dagegen nicht harmlos: Sie trägt den stabilen Anker, und der Adressat kann sie nach der Offenlegung weitergeben. Zwei bekannte Ketten derselben Person zu einer zu vereinen, bleibt in der Spezifikation ausdrücklich offen.

Im Vergleich

Die DTG-Credentials-Spezifikation (Working Draft 0.6.0) kennt den Korrelationsbereich, den der Halter für einen Identifier erklärt: pairwise, directed oder public. Wer mehrere pairwise-Identifier als dieselbe Partei ausweisen will, braucht dort einen Zero-Knowledge-Beweis gemeinsamer Kontrolle, den bisher keine DTG-Spezifikation definiert. RLTP wählt für denselben Anlass keinen allgemein vorzeigbaren Beweis, sondern einen an den Adressaten gebundenen, den der Adressat auch fälschen könnte. In den DTG-Dokumenten, auf die sich dieser Eintrag stützt, kommt eine solche abstreitbare Verknüpfung nicht vor. Mich überzeugt an der Konstruktion, dass die Fälschbarkeit als Anforderung dasteht und nicht als Mangel.

Einordnung

Diese Erläuterung gehört zu den Fachnotizen über das Real Life Trust Protocol und gibt den Stand der Spezifikationen vom Oktober 2026 wieder.

Quelle

https://trust-protocol.real-life.org/understand/foundations/

https://github.com/real-life-org/trust-protocol

Anker-Zuordnung (anchor mapping) in drei Sätzen

Die Anker-Zuordnung (anchor mapping) ist im Real Life Trust Protocol ein Nachweis, der den Paar-Anker einer Beziehung mit dem Community-Anker derselben Person verknüpft, und zwar für genau einen Adressaten. Sie ist als Designated-Verifier-Konstruktion gebaut: Nur der Adressat kann sie prüfen, und er hätte sie selbst fälschen können.