Verifiable Trust Agent (VTA)

Verifiable Trust Agent (VTA) ist der Knoten der Verifiable Trust Infrastructure (VTI), der die Schlüsselhierarchie eines Prinzipals verwaltet. Prinzipal kann eine Person, eine Organisation oder ein Software-Agent sein. Die Spezifikation formuliert es knapp: Ein VTA ist die Wurzel von allem anderen, er ist Schlüssel- und Kontextautorität. Ich lese das als Betriebssystem einer Identität, an dem alles hängt, was später Vertrauen tragen soll.

So funktioniert es

Der VTA gliedert die Schlüssel in Vertrauenskontexte (trust contexts). Ein Kontext ist die Isolationsgrenze, innerhalb derer der VTA Schlüssel, Credentials, gespeicherte Daten, Agentenspeicher und Delegationen hält; er ist zugleich die Einheit, in der Autorität vergeben wird. Der VTA entscheidet, wer in welchem Kontext handeln darf, und er hält und präsentiert Credentials stellvertretend für den Prinzipal.

Clients, Geräte und Software-Agenten handeln als Delegierte. Ihre Autorität wird als Eintrag in der Zugriffskontrolle des VTA ausgedrückt und ist immer enger als die des Prinzipals. Eine Verifiable Trust Community (VTC) wird auf einem bestehenden VTA bereitgestellt und leitet ihre Identität von ihm ab, die Abhängigkeit läuft nur in diese Richtung. Verpflichtend sind Ed25519 für Signaturen und X25519 für die Schlüsselvereinbarung. Die dauerhafte Identität eines VTA muss ein did:webvh sein, nur die Bootstrap-Identität eines Clients ist ein did:key.

Im Vergleich

RLTP kennt keinen Knoten dieser Art. Eine Person hält ein einziges Geheimnis, eine BIP-39-Mnemonic, und leitet daraus pro Kontext einen eigenen Anker ab, also ein Schlüsselpaar je Beziehung oder Gruppe. Die Kontexttrennung ähnelt dem VTA-Modell, der Ort der Schlüssel unterscheidet sich: Die RLTP-Dokumentation ordnet die Web-of-Trust-App aus dem Real-Life-Projekt in DTG-Begriffen als Personal Network Manager ein, lokal zuerst, mit Schlüsseln auf dem Gerät und ohne gehosteten Agenten (VTA).

Zwei Punkte bleiben dabei offen. RLTP nutzt ausschliesslich did:key und gibt dafür in den Quellen keine Begründung an. Ein did:key kann nicht rotieren, eine Schlüsselhistorie ist benannte, bewusst unentschiedene Arbeit. Und die Gerätedelegation, die der VTA über seine Zugriffskontrolle löst, steht in RLTP noch aus: Im Seed-Modell sind Geräte Root-Halter, das Entfernen eines Geräts ist dort nicht ausdrückbar.

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://trustoverip.github.io/dtgwg-vti-spec/