Zot6

Zot/6 aka Zot 2018

Dieses Dokument beschreibt Version 6 des Zot-Protokolls. Es handelt sich um ein fortlaufend aktualisiertes Dokument, das zuletzt am 14.09.2018 geändert wurde.

Zot ist ein WebMTA, der ein dezentrales Identitäts- und Kommunikationsprotokoll unter Verwendung von HTTPS/JSON bereitstellt.

Frühere Versionen des Zot-Protokolls befassten sich mit der Erstellung nomadischer Identitäten und der domänenübergreifenden Authentifizierung, um ein dezentrales Netzwerk zu ermöglichen, dessen Funktionen mit denen großer zentralisierter Anbieter konkurrieren können.

Zot/6 baut auf diesen Konzepten auf und optimiert viele der Interaktionen, wobei die Erfahrungen aus jahrzehntelanger Entwicklung dezentraler Systeme einfließen.

Eine Referenzimplementierung (eine Social-Media-App) ist unter https://framagit.org/mario/zap verfügbar; die Referenzimplementierung ist noch nicht zu 100 % spezifikationskonform oder vollständig, kann jedoch für grundlegende Kompatibilitätstests und Entwicklungszwecke verwendet werden.

Unterschiede zu früheren Zot-Versionen

1. Optimierte Kommunikation durch direkte (Push-)Übertragung. Frühere Versionen verwendeten ein „Notify/Pickup“-Übermittlungsmodell.
2. Die Authentifizierungskomponente (Magic-Auth) wurde in eine separate und eigenständige Spezifikation „OpenWebAuth“ ausgegliedert.
3. Einbindung von ActivityStreams (JSON-LD) als unterstützte (primäre) Serialisierungsform.
4. Aufhebung der Anforderungen an Implementierungen, sekundäre Serialisierungen zu unterstützen.
5. Verlagerung der Dienstermittlung auf „Accept-Header“-basierte Dienstendpunkte, bei denen verschiedene Darstellungen durch Änderung des „Accept“-Headers in der HTTPS-Anfrage ausgewählt werden können.
6. Trennung der „portable-id“ vom verwendeten Signaturalgorithmus.

Unterschiede zwischen Zot und anderen WebMTA-Diensten

Zot unterscheidet sich in seiner Architektur von anderen HTTPS-basierten Protokollen für „soziale Kommunikation“ wie OStatus, ActivityPub und Diaspora. Die wichtigsten Unterschiede sind:

1. Unterstützung für nomadische Identitäten, bei denen eine Identität nicht dauerhaft an einen DNS-Server gebunden ist.
2. Auf Zot aufbauende MUAs sind in der Lage, detaillierte domänenübergreifende Berechtigungen zu nutzen und auszudrücken.
3. Verschlüsselungsverhandlung für zusätzlichen Schutz der Nachrichten über HTTPS hinaus
4. Zot definiert kein absolutes Payload-Format für Inhalte. Implementierungen MÜSSEN ActivityStreams unterstützen. Zusätzliche Nachrichtentypen und Serialisierungsformate KÖNNEN herstellerspezifische Erweiterungen bieten.
5. Die Föderation mit anderen WebMTA-Protokollen wird nicht durch unnötige Einschränkungen bei der Kommunikation mit Drittanbietern behindert. Nachrichten von inkompatiblen Systemen können an andere Standorte weitergeleitet werden, die das Protokoll des Drittanbieters nicht unterstützen.
6. Für Audits und die Fehlerbehebung werden detaillierte Zustellberichte bereitgestellt; dies ist bei einem verteilten Kommunikationsdienst von entscheidender Bedeutung.

Grundlegende Konzepte

Identität

In Zot/6 ist die dezentrale Identität ein Kernmerkmal des Systems. Dies unterscheidet sich in gewisser Weise von (und ist oft unvereinbar mit) typischen dezentralen oder P2P-Kommunikationsprojekten, bei denen der Nachrichtenaustausch die Schlüsselkomponente ist und die Identität lediglich eine Zuordnung zu einer Nachricht darstellt.

Eine Identität besteht aus zwei Hauptkomponenten, die später im Detail beschrieben werden. Eine „gültige“ Identität ist eine Identität, die mithilfe von Kryptografie mit öffentlichen Schlüsseln verifiziert wurde. Bis zur Verifizierung gilt eine Identität als „beansprucht“ (unverifiziert). Eine „ungültige“ Identität ist eine Identität, deren Verifizierung fehlgeschlagen ist oder die widerrufen wurde.

1. Ein Identitäts„Anspruch“, bei dem es sich im Wesentlichen um eine Textzeichenfolge handelt
2. Ein RSA-basierter Schlüssel, mit dem diese Identität verifiziert werden kann

In Zot/6 dürfen beanspruchte (unverifizierte) Identitäten existieren und es KANN ihnen die Berechtigung zur Durchführung von Operationen erteilt werden. Dies ermöglicht die Kommunikation zwischen Zot/6 und anderen Kommunikationssystemen mit unterschiedlichen Identitätskonzepten und unterschiedlichen Validierungsmethoden.

Eine Implementierung KANN sich dafür entscheiden, unbestätigte Identitäten zu blockieren. Dies kann die Fähigkeit zur Interaktion mit fremden Systemen, Protokollen und Netzwerken erheblich einschränken.

Ungültigen Identitäten DÜRFEN KEINE Berechtigungen gewährt werden. Per Definition handelt es sich dabei um Fälschungen oder um widerrufene Identitäten.

Kanäle

Kanäle entsprechen dem, was in anderen Systemen typischerweise als „Benutzer“ bezeichnet wird, obwohl dieser Begriff in Zot/6 abstrahiert ist und andere Bedeutungen annehmen kann. Ein Kanal wird als Identität dargestellt.

Standort und Standortunabhängigkeit

Ein Standort ist eine Identität und unterliegt allen mit einer Identität verbundenen Regeln. Der Identitätsanspruch ist in der Regel die vollqualifizierte „Basis“-URL des Webdienstes, der Zot/6-Dienste bereitstellt, in Kleinbuchstaben und ohne abschließende Schrägstriche. Internationale Domänennamen werden in „Punycode“ umgewandelt.

Eine „standortunabhängige Identität“ ist eine gültige Kanalidentität, die mit einem gültigen Standort gepaart ist, mit der zusätzlichen Eigenschaft, dass das Kanal-Standort-Paar unter Verwendung des Schlüssels der Kanalidentität validiert wurde. Für Laien ausgedrückt: Der Nutzer signiert seine Website mit seinem eigenen Schlüssel.

Das standortunabhängige Modell ermöglicht die Mobilität eines Kanals an verschiedene oder sogar mehrere Standorte, die alle gleichzeitig gültig sein können. Dies wird an anderer Stelle als „nomadische“ Identität bezeichnet.

Für diejenigen, denen dieses Konzept noch neu ist: Im Grunde bedeutet dies, dass ein Kanal jederzeit an jedem beliebigen Standort erscheinen kann, solange die standortunabhängige Identität gültig ist.

Verknüpfte Identitäten

Ein oder mehrere Kanäle/Identitäten können miteinander verknüpft werden. Einfach ausgedrückt ermöglicht dies die Definition eines persistenten Tokens, das auf eine Identität verweist, deren Claim-String oder öffentlicher Schlüssel (oder beides) sich geändert hat oder aus einem anderen System zusammengeführt wird. Um Identitäten zu verknüpfen, MUSS neben der Anforderung, dass beide Identitäten validiert werden MÜSSEN, jede Identität die andere verknüpfte Identität signieren, und alle diese Signaturen MÜSSEN gültig sein.

Im Falle der Bereitstellung eines kontrollierten Zugriffs auf Website-Ressourcen SOLLTEN alle verknüpften Identitäten zu einem gemeinsamen Identifikator zusammengefasst oder reduziert werden, sodass ein Versuch, mit einer beliebigen verknüpften Identität auf eine geschützte Ressource zuzugreifen, für eine Ressource erfolgreich ist, die einer ihrer verknüpften Identitäten zur Verfügung gestellt wurde.

Überlegungen zur Nomadizität

Die ortsunabhängigen Eigenschaften von Zot/6 stellen zusätzliche Anforderungen an Kommunikationssysteme. Bei ausgehenden Nachrichten SOLLTE versucht werden, diese an jeden verknüpften und nomadischen Standort zuzustellen, der mit der Identität, an die die Nachricht gesendet wird, assoziiert ist. Der Dienst KANN einen gültigen verknüpften oder nomadischen Standort aus der Liste der Zustellziele entfernen, wenn der Standort als „tot“ oder „unerreichbar“ markiert ist. Ein Standort KANN aus verschiedenen Gründen als „inaktiv“ oder „unerreichbar“ markiert werden; im Allgemeinen aufgrund fehlender Kommunikation seit mehr als 30 Tagen oder manuell, wenn der Site-Administrator Grund zu der Annahme hat, dass der Standort dauerhaft stillgelegt wurde. Eine Site SOLLTE den Standorteintrag beibehalten und die Kennzeichnung „inaktiv“ oder „unerreichbar“ automatisch entfernen, wenn in Zukunft gültige Kommunikationsvorgänge von diesem Standort aus initiiert werden.

Grundlagen zu Transport und Protokollen

Die Kommunikation mit Zot/6 erfolgt in erster Linie über HTTPS-JSON-Anfragen. Anfragen werden vom „Absender“ mithilfe von HTTP-Signaturen (draft-cavage-http-signatures-xx) signiert. Ist eine Nutzlast vorhanden, MÜSSEN die signierten Header einen Digest-Header enthalten, der SHA-256 oder SHA-512 gemäß RFC 5843 verwendet.

Bei HTTP-Anfragen ohne Nutzdaten können beliebige Header signiert werden, es MUSS jedoch mindestens ein Header signiert sein.

Signierte Anfragen KÖNNEN abgelehnt werden, wenn öffentliche Schlüssel mithilfe von Zot/6 Discovery über die Eigenschaft „keyId“ der Signaturdaten abgerufen und der öffentliche Schlüssel aus diesem Dokument entnommen werden. Zot Discovery wird in einem späteren Kapitel beschrieben.

• Die Digest-Überprüfung schlägt fehl
• Die Anfrage enthält eine JSON-Nutzlast, deren Inhalt nicht signiert ist
• Das Abrufen des öffentlichen Schlüssels schlägt fehl

Empfänger, die diese Anfragen überprüfen, SOLLTEN sicherstellen, dass der Unterzeichner die Berechtigung für die bereitgestellten Daten besitzt – entweder als Urheber oder als Vermittler (Absender).