Home

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).

Content

Content

Einige Zot-Anwendungen bzw. -Implementierungen unterstützen komplexe Inhaltsstrukturen, darunter eingebettete Apps, identitätsbezogene Inhalte und authentifizierte Links. Nicht alle Implementierungen müssen diese Arten von Inhalten unterstützen oder sind dazu in der Lage. Darüber hinaus können die von der jeweiligen Implementierung unterstützten Datenserialisierungsformate die Fähigkeit beeinträchtigen, identitätsbezogene Inhalte in vollem Umfang darzustellen.

ActivityStreams

Eine Implementierung, die ausschließlich ActivityStreams2 unterstützt, erhält „message“-Inhalte vom Typ „Article“, die eine generische HTML-Darstellung des Quellinhalts in den Elementen „content“ oder „contentMap“ enthalten. Diese generische Darstellung ist für jeden Beobachter geeignet; einige HTML-Links sind jedoch aufgrund von Berechtigungs- und Authentifizierungsanforderungen möglicherweise nicht zugänglich. Die Quelle für das gerenderte HTML ist im „source“-Element verfügbar. Implementierungen, die identitätsbezogene Inhalte und authentifizierte Links unterstützen möchten, sollten diesen Quellinhalt (insbesondere wenn er vom Typ „text/x-zot-bbcode“ ist) verwenden, um dynamisch eine HTML-Darstellung zu generieren, die spezifisch für den aktuellen Beobachter ist. Der genaue, von der Implementierung unterstützte Funktionsumfang sowie lokale Sicherheitsfilter KÖNNEN dazu führen, dass der gerenderte Inhalt leer ist. Implementierungen KÖNNEN sich dafür entscheiden, leeren gerenderten Inhalt nicht anzuzeigen, oder sie KÖNNEN dem Betrachter mitteilen, dass der Inhalt nicht erfolgreich gerendert werden konnte. Implementierungen SOLLTEN eine Menüoption „Quelltext anzeigen“ bereitstellen und die Möglichkeit bieten, auf den Originalinhalt zuzugreifen, wenn die Darstellung zu leerem Inhalt führt und es sich um einen MIME-Typ handelt, dessen Anzeige im Quelltextformat als sicher eingestuft wird.

Zot

Die gleichen Überlegungen gelten für Inhalte, die die „zot“-Serialisierung verwenden. In diesem Fall ist die Inhaltsquelle das „body“-Element und hat den Typ „mimetype“. Die beobachterneutrale HTML-Darstellung wird im „html“-Element bereitgestellt.

Messages

Messages

Zot6 ist in erster Linie ein Transport- und Identifikationsformat. Die Semantik des Nachrichteninhalts liegt in vielerlei Hinsicht außerhalb des Geltungsbereichs dieses Dokuments. Websites/Server MÜSSEN in ihrem Site-Discovery-Dokument angeben, welche standardisierten Nachrichtenformate akzeptiert werden.

Die für uns vorrangig relevanten Nachrichtenformate sind

1. ActivityStreams (ActivityStreams JSON-LD) (format=‚activitystreams‘)
2. Zot (format=‚zot‘)

Bei der Verwendung von ActivityStreams JSON-LD wird standardmäßig ein @context von „https://www.w3.org/ns/activitystreams“ angenommen. Aktivitätsobjekte müssen nur dann eine @context-Deklaration angeben oder bereitstellen, wenn Abweichungen vom Standard vorliegen.

Delivery

Die Zustellung erfolgt als POST-Anruf mit Umschlag und Daten an den Zot-Endpunkt. Zur Validierung des Absenders werden HTTP-Signaturen verwendet. Zustellberichte für private Nachrichten SOLLTEN verschlüsselt sein und MÜSSEN Ergebnisse zur Host-Sperrung enthalten. Hier ist ein Beispiel für eine Aktivität…

{
    "type": "activity",
    "encoding": "activitystreams",
    "sender": "wXDz7WR51QHwAORaVR8-0wff06LBtBWvhd_zfDWTYEzaqaPfJ_fsK7nRaM4aVeKPmZklUAgtqs09zUzitwNT2w",
    "site_id": "gcwJ1OzIZbwtfgDcBYVYhwlUmjaxsgPyJezd-F2IS1F3IrlVsyOesNpm3hvoWemIBxoHmgIlMYKkhFeYihsqBQ",
    "recipients": {
         "xxWsqvZp3w-sr3FXrmb6wxmKZx6khMLjBCOafPdRT1lWzYmCPHeaDDBD9KwOqpOAt4lezIFQbyaLt9I3H54M9Q",
         "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
    },
    "version": "6.0",
    "data": {
        "type": "Create",
        "id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
        "published": "2018-06-25T04:14:08Z",
        "actor": "https://example.org/channel/zapper",
        "object": {
            "type": "Article",
            "id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
            "published": "2018-06-25T04:14:08Z",
            "content": "just another Zot6 message",
            "actor": "https://example.org/channel/zapper",
        },
    },
}

Die „sender_id“ ist die „portable_id“ des Absenders. Die „site_id“ ist die „portable_id“ der Website des Absenders. „recipients“ ist ein einfaches Array aus „portable_ids“ der Nachrichtenempfänger. Diese Liste KANN gefiltert werden und nur die Empfänger enthalten, von denen bekannt ist, dass sie auf der empfangenden Website verfügbar sind.

Die „version“ wird angegeben, um mögliche Unterschiede bei der Protokollversion im Laufe der Zeit auszugleichen. „data“ enthält die eigentliche Nutzlast von ActivityStreams (in diesem Fall).

Empfangende Websites MÜSSEN die bereitgestellte HTTP-Signatur überprüfen und Beiträge ohne Signatur oder mit ungültigen Signaturen ablehnen (Fehler 400). Während des Überprüfungsprozesses wird „Discovery“ verwendet, wodurch eine lokal gespeicherte „portable_id“ generiert wird. Stimmt die „portable_id“ nicht mit der „portable_id“ des verifizierten Unterzeichners überein, MUSS die Nachricht abgelehnt werden (Fehler 400).

Wenn das Feld „recipients“ nicht vorhanden oder leer ist, gilt der Beitrag als öffentlich und darf an jeden Kanal zugestellt werden, der dem Absender folgt. Wenn das Feld „recipients“ Inhalte enthält, DARF die Nachricht an niemanden außer den aufgeführten Empfängern zugestellt werden.

Nach erfolgreicher Zustellung wird ein Zustellbericht erstellt und an die sendende Seite zurückgesendet.

 {
    "success": true,
    "delivery_report": [
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "xxWsqvZp3w-sr3FXrmb6wxmKZx6khMLjBCOafPdRT1lWzYmCPHeaDDBD9KwOqpOAt4lezIFQbyaLt9I3H54M9Q",
            "name": "System ",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "posted",
            "date": "2018-06-26 05:19:48"
        },
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "wXDz7WR51QHwAORaVR8-0wff06LBtBWvhd_zfDWTYEzaqaPfJ_fsK7nRaM4aVeKPmZklUAgtqs09zUzitwNT2w",
            "name": "Zapper ",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "posted",
            "date": "2018-06-26 05:19:48"
        },
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "name": "Bopper ",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "update ignored",
            "date": "2018-06-26 05:19:48"
        }
    ]
}

Followups

Alle Folgeaktivitäten zu einem Beitrag (Antworten, Likes, Reaktionen usw.) MÜSSEN als private Aktivität (einzelner Empfänger) an den Absender des Originals mit dem Nachrichtentyp „response“ gesendet werden. Dies wird als „Upstream-Zustellung“ bezeichnet.

Darüber hinaus MÜSSEN diese Aktivitäten ein „inReplyTo“-Element enthalten, das auf die ID der Aktivität gesetzt ist, auf die sich die Antwort bezieht. Implementierungen SOLLTEN mehrstufige Likes unterstützen. Server KÖNNEN mehrstufige Kommentare unterstützen.

Der ursprüngliche Absender MUSS die Folgeaktivitäten unter Verwendung des Nachrichtentyps „activity“ an alle Empfänger der ursprünglichen Nachricht erneut senden. Dies wird als „Downstream-Übermittlung“ bezeichnet.

Dieser Mechanismus mit einer einzigen Quelle stellt sicher, dass die Datenschutzeinstellungen des ursprünglichen Absenders respektiert werden und die Konversationen für alle Empfänger der ursprünglichen Nachricht intakt bleiben.

Multi-level support

Wenn mehrstufige Kommentare nicht unterstützt werden, MUSS der Empfänger den mehrstufigen Kommentar dem ursprünglichen Konversationskopf zuordnen und die Konversation dabei auf eine Ebene vereinfachen. Der empfangende Server SOLLTE die korrekte Ziel-ID speichern, auch wenn der Kommentar neu zugeordnet wird.

Wenn mehrstufige „Likes“ nicht unterstützt werden, DARF die eingehende „Like“-Aktivität für einen nicht übergeordneten Konversationsknoten verworfen oder abgelehnt werden, anstatt sie einem möglicherweise nicht beabsichtigten, nicht verwandten Aktivitätsknoten zuzuordnen.

Portable IDs

Portable IDs dienen dazu, ortsunabhängige Identifikatoren im gesamten Netzwerk bereitzustellen. Eine portable ID ist nur dann vertrauenswürdig, wenn sie verifiziert wurde oder auf dieser Website generiert wurde. Die Verifizierung erfolgt im Rahmen des [[Discovery]]-Prozesses.

Die portable ID verwendet einen bereitgestellten öffentlichen Schlüssel. Um sicherzustellen, dass die Berechnung der portablen ID portabel ist, MUSS die Berechnung anhand eines öffentlichen Schlüssels im PKCS#8-Format erfolgen. Wird der Quellschlüssel in einem anderen Format bereitgestellt (z. B. als Salmon-Schlüssel [Modulus/Exponent] oder im PKCS#1-Format), MUSS der Schlüssel vor der Berechnung der portablen ID in das PKCS#8-Format konvertiert werden.

Im Folgenden werden die Schritte zur Generierung einer „portable_id“ beschrieben.

1. Rufen Sie über [[Discovery]] das „zot-info“-Paket für eine Netzwerk-URI ab. Die Netzwerk-URI wird häufig als „signer keyID“ in einer signierten Nachricht angegeben, kann aber auch als „acct:“-URI bereitgestellt werden, die von Nutzern der Website übermittelt wird.
2. Das „zot-info“-Paket enthält alle notwendigen Informationen zur Überprüfung einer Identitätsangabe.
3. Überprüfen Sie mit dem „public_key“ die „id_sig“ anhand der „id“ (angegebene Identität).
4. Überprüfen Sie mit dem public_key die location->url_sig anhand der location->url für die Discovery-Website.
5. Überprüfen Sie mit site->sitekey die site->site_sig anhand der site->url.
6. Verketten Sie die id und den public_key. Wenden Sie auf diese verkettete Zeichenfolge eine Whirlpool-Hashfunktion an und führen Sie eine Base64-URL-Kodierung des Ergebnisses durch.
7. Dies ist die Kanal-portable_id.
8. Verknüpfen Sie die URL und site->sitekey. Wenden Sie auf diese verkettete Zeichenfolge eine Whirlpool-Hash-Funktion an und kodieren Sie das Ergebnis mit base64_url.
9. Dies ist die portable site_id. Überprüfen Sie, ob sie mit der location->site_id im Discovery-Paket übereinstimmt.
10. Wenn ein Verifizierungsschritt fehlschlägt, verwerfen Sie die Ergebnisse und geben Sie einen Fehler zurück.

Diese Berechnung gilt allgemein als rechenintensiv; daher sollten die Ergebnisse als Paar aus Kanal und Ort gespeichert werden.

Wenn Sie eine Zot-Nachricht erhalten, verwenden Sie bei der Überprüfung der HTTP-Signatur die gespeicherten Ergebnisse (sofern vorhanden) für die keyID des Unterzeichners. Wenn die HTTP-Signatur gültig ist, die keyID mit der location->id_url für diesen Standort übereinstimmt und die portable_id des Absenders mit der berechneten/gespeicherten portable_id für dieses Kanal-Standort-Paar übereinstimmt, wurde der nomadische Absender validiert.

Falls für die keyID keine gespeicherten Ergebnisse vorliegen, führen Sie [[Discovery]] wie beschrieben durch.

Message types

Message Types

purge

Dieser Nachrichtentyp enthält weder Nutzdaten noch eine Kodierung. Wenn die Nachricht Empfänger hat, gilt sie als „Unfriend“-Aktion. Die Beziehung des Absenders zu den Empfängern wird beendet. Die genauen Maßnahmen, die daraufhin ergriffen werden, sind implementierungsspezifisch. Im Allgemeinen werden die Berechtigungen des Absenders gegenüber dem Empfänger widerrufen. Die dem Absender vom Empfänger gewährten Berechtigungen KÖNNEN unverändert bleiben.

Hat die Nachricht keine Empfänger, gilt sie als Benachrichtigung, dass die Identität des Absenders nicht mehr existiert. Empfangende Seiten MÜSSEN den Kanal als nicht verfügbar kennzeichnen und die weitere Kommunikation einstellen. Sie SOLLTEN alle dem Absender zugeordneten öffentlichen Inhalte löschen und KÖNNEN die Verbindung sowie private Inhalte aus verbundenen Kanälen entfernen.

Die Antwort auf diese Nachricht lautet

{
  'success': true
}

oder

{
  'success': false,
  'message': 'optional error message or reason'
}

Server SOLLTEN bei der Verwendung einer zielgerichteten Nachricht nur einen einzigen Empfänger angeben, da die einzelne Rückantwort mehrdeutig sein könnte.

refresh

Diese Nachricht enthält weder Nutzdaten noch eine Kodierung. Sie dient dazu, dem empfangenden Server mitzuteilen, dass sich wichtige Kanalinformationen geändert haben. Der empfangende Server MUSS einen „Zot Discovery“-Vorgang durchführen und alle lokal gespeicherten Informationen, die sich geändert haben, aktualisieren. Falls die Nachricht Empfänger enthält, sollte diese Aktion vom Empfänger mithilfe eines signierten „Discovery Fetch“ durchgeführt werden, der vom Empfänger signiert ist. Die Antwort entspricht der einer „Purge“-Nachricht.

Eine gezielte Aktualisierungsnachricht (die z. B. Empfänger enthält) wird üblicherweise verwendet, um eine Änderung der Berechtigungen anzuzeigen, die der Absender dem Empfänger gewährt hat. Wenn diesem Absender zuvor keine Berechtigungen zugewiesen wurden, gilt dies als „Freundschaftsanfrage“, was bedeutet, dass bestimmte Berechtigungen verfügbar sind, die zuvor möglicherweise nicht verfügbar waren. Der empfangende Kanal SOLLTE die aktualisierten Berechtigungen speichern und den Absender zu den bekannten Verbindungen des Empfängers hinzufügen. Er KANN den Empfänger darüber benachrichtigen, dass ein neuer Freund vorliegt, und die Verbindung in den Status „ausstehend“ versetzen, bis die Anfrage vom Empfänger geprüft, angenommen oder abgelehnt wurde.

rekey

Die „rekey“-Nachricht wird ohne Empfänger gesendet. Die Nachricht gibt an, dass der Absender seinen öffentlichen Schlüssel geändert hat. Die Schlüsseländerung MUSS sowohl mit dem alten als auch mit dem neuen privaten Schlüssel signiert sein, und diese Signaturen MÜSSEN gültig sein, andernfalls MUSS der Vorgang fehlschlagen. Das boolesche Flag „update“ (sofern vorhanden) gibt an, dass die mit diesem Schlüssel verknüpfte alte „portable_id“ geändert und die alte „portable_id“ verworfen werden soll. Ist „update“ falsch, wird eine neue „portable_id“ generiert und die alte sowie die neue Identität werden miteinander verknüpft. Das bedeutet, dass beide „portable_id“s gültige nomadische Identifikatoren für denselben Kanal sind. Die Antwort entspricht der für die „purge“-Nachricht.

activity

Nachrichtenkodierung: activitystreams

Dieser Nachrichtentyp wird für die normale Kommunikation verwendet. Sind Empfänger angegeben, handelt es sich um eine private Nachricht. Sind keine Empfänger angegeben, ist die Nachricht öffentlich. Die Empfängerliste KANN gefiltert werden und nur diejenigen Empfänger enthalten, von denen bekannt ist, dass sie auf der empfangenden Website verfügbar sind. Der Absender DARF eine Nachricht NICHT versenden, wenn es sich um eine private Nachricht handelt und die Empfängerliste für eine bestimmte empfangende Website leer ist.

{
    "type": "Create",
    "id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
    "published": "2018-06-25T04:14:08Z",
    "actor": "https://example.org/channel/zapper",
    "object": {
        "type": "Article",
        "id": "https://example.org/item/e8a20a21dd7e0d8d2207a5df62d2168d65db7db08f1a91ca",
        "published": "2018-06-25T04:14:08Z",
        "content": "just another Zot6 message",
        "actor": "https://example.org/channel/zapper",
    },
}

Bei der Zustellung wird ein Zustellbericht erstellt und an den Absender zurückgesendet.

{
    "success": true,
    "delivery_report": [
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "xxWsqvZp3w-sr3FXrmb6wxmKZx6khMLjBCOafPdRT1lWzYmCPHeaDDBD9KwOqpOAt4lezIFQbyaLt9I3H54M9Q",
            "name": "System",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "posted",
            "date": "2018-06-26 05:19:48"
        },
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "wXDz7WR51QHwAORaVR8-0wff06LBtBWvhd_zfDWTYEzaqaPfJ_fsK7nRaM4aVeKPmZklUAgtqs09zUzitwNT2w",
            "name": "Zapper",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "posted",
            "date": "2018-06-26 05:19:48"
        },
        {
            "location": "https://zap.macgirvin.com",
            "sender": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "recipient": "T5ni0wUAlYmyqlibiTQiS54PqLKXCL7XAJhOSKeJMqEXeKn46AkDPdCJZ4JUA05Vlhux25OLTkBPyV7L60JmyQ",
            "name": "Bopper",
            "message_id": "https://zap.macgirvin.com/item/ebaa483a2e8331a21a68b9d9e4a72a079c260162d2e37edc",
            "status": "update ignored",
            "date": "2018-06-26 05:19:48"
        }
    ]
}

response

Die Antwortnachricht dient dazu, einen Kommentar oder eine Antwort „stromaufwärts“ an den Absender zu senden. Der Absender leitet die Nachricht anschließend an alle nachgelagerten Empfänger weiter. Sie entspricht dem Nachrichtentyp „Aktivität“, mit dem Unterschied, dass sie genau einen Empfänger haben MUSS – nämlich den Absender der Aktivität, auf die sich diese Aktivität bezieht. Diese gesamte Aktivität SOLLTE vom Absender der Antwort signiert und als JSON-Salmon-Magic-Envelope gekapselt werden, wie in Encryption+Signatures beschrieben.

sync

Zwischen nomadischen Klonen werden Synchronisationsnachrichten verwendet, um geänderte Datenstrukturen zu synchronisieren. Diese Nachrichten werden als private Nachrichten an die nomadischen Instanzen des Absenders gesendet und SOLLTEN zusätzlich zur HTTPS-Transportverschlüsselung weiter verschlüsselt werden, da die Nachrichten private Schlüssel enthalten können.

Implementierungen KÖNNEN Synchronisationsnachrichten bereitstellen und KÖNNEN versuchen, mit Synchronisationspaketen koexistieren, die von anderen Implementierungen erstellt wurden. Wenn ihre Anforderungen an die Datensynchronisation nicht auf die von anderen bereitgestellten Synchronisationsstrukturen abgebildet werden können, MÜSSEN sie einen eindeutigen Kodierungstyp bereitstellen (es wird empfohlen, den Namen der Implementierung unter ausschließlicher Verwendung der Buchstaben [a–z] des US-ASCII-Zeichensatzes zu wählen). Wenn eine Stelle eine Synchronisationsnachricht mit unbekannter Kodierung und unbekanntem Datenformat empfängt, MUSS diese ignoriert werden.

Zu den grundlegenden Synchronisierungsinformationen gehören alle lokalen Änderungen an persönlichen Einstellungen, Profileinstellungen sowie Änderungen im sozialen Netzwerk. Implementierungen KÖNNEN die Synchronisierung aller verfügbaren Informationen unterstützen, einschließlich hochgeladener Dateien und Fotos, Ereignisse sowie anderer anwendungsspezifischer Datenstrukturen.

Discovery

Discovery

Die Kanalsuche erfolgt in erster Linie über Webfinger (RFC 7033). Sie suchen nach einem Eintrag mit

rel: http://purl.org/zot/protocol/6.0
type: application/x-zot+json
href: (discovery rhef)

Lade die URL aus dem href-Attribut unter Verwendung eines HTTP-Accept-Headers mit dem Wert

Accept: application/x-zot+json;

Dadurch wird ein Dokument zur Kanalerkennung bereitgestellt. Es enthält außerdem einen Abschnitt zur Standorterkennung.

Sie können das Paket zur Standorterkennung separat laden, indem Sie auf die oberste Domäne zugreifen unter

Accept: application/x-zot+json;

Beispiel für ein Dokument zur Kanalermittlung

{
    "id": "XSWtrP_U65k9ZXeBxoYbcBgy6cVteo3yLwmLy4ppkjXqAryky0pYBq8YWnj7rApoTSdgy-QeciQG7Yhz7QYt4g",
    "id_sig": "sha256.yG_Biu8pTpV0DlKPzoZHi0PbpM3okDYB7v5z2UuB___6J85gSOiOdes1tLwSmFkjbYMZbL2oksIe2tmD32lJWxpycSWJlDNbK8oggAtMx1sfVwyZOX_O0QBde2SxWCp0EIrRTRacIyKBzJhPRxCsGkc0uWin6XesXVZuYEVCxESr0KMT35Y79keOXGjJGv822C-Z2Nb4vphpbpftllGjxXOV70PxTNF0uZTWeVSmv2O0FGhkqBeBvBZU0FaWdYZqZZbd2AN_bto-8P95KMw6Fdfl2NIeL6vpD3xSu59Qhztl8L5npU13S3yvywzSvNg8DVgpNqcRmMiebaspfcjttCEAKtB2H-uiPkeuvDUk_iMXGtSUulcsNt1VFtSTnLEG371O6kj3dsczCV4QrpKBdIWNF3_41xHhrLi4Pug5JQg_wncyBSXu6Uj9pkCiD-JPVfI0ViCPccJcCKB-kXpP2EQIoPMhjV5x3bruI0TFLxrJqKWuoY6m8KUYrlGRdewaPYJ7pOY2NSNeLb9z6PO3UHT0bnr3DLyNxypxiUo5Pg4BxnHeuVKmiTxULF06KSwLmPDGsscrBSX1wIbHP6rhcmh0vDP0af2ixluLJbcLbptI2d137tFDVT4lTWBZ8PRNPWi1rfSl_x-dzevF8Dd3vi0iWd7D-aK89rqmRfUKsWk",
    "aliases": [
        "acct:zapper@zap.macgirvin.com",
        "https://zap.macgirvin.com/channel/zapper"
    ],
    "primary_location": {
        "address": "zapper@zap.macgirvin.com",
        "url": "https://zap.macgirvin.com/channel/zapper",
        "connections_url": "https://zap.macgirvin.com/poco/zapper",
        "follow_url": "https://zap.macgirvin.com/follow?f=&url=%s"
    },
    "public_key": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA154VVJChRzsdm1Aba4su\nMLhhnuTELsQCIuDGB07lxTlHmJeeD9eImLXzQPDTNlLcCYVQkKH1uPhfhwnBFITu\noG7hr9QklhFZxfe9IFiAfr7w1+IRFXCYEwfe/eAaYDoprNqtMxonniOiVvnAdNs+\nRi1/Bfasd9d4BRBSj2KwuAeTke7gvHlACRKmauhFmhfG2fzj53AL2ixsraBzdccR\nFseICC99eldgWk2Jg16J1Euh51HV56jUWoz4ZYb1Kxri8zf55R2GiQJCHvSCLlgl\noFaiHLPS+yBIlCkNZ+47ee6DL7ePJ6kip6+ukAP5/1vOM0ahTPANoqaWmg19RsOu\n2q0LPyotWyLX1JX13rtLC7qFlSST31gxY082G8QIJfEbWgYoci0g2XOCDjAZ3JjI\neK/+tZwLzrV5l5Tcorf35Kbc/lHbMSm+wuyc6eQV14tj542nUftZAgpkPOImHsRm\nLqwiG6uxpfIW0TFuUse45F/faYbV4pbcaGm7Hwp/MbXl8vNiE0LpV9eqZu5ryVjZ\nT+Vt32ISWuTeyLqB1Wb/lWP9lGsMFDtsiZ5Wst1W8omrAgYfYo4RxOr14TUiJg3T\nmgTg10fBrcTC210Kl0lKNkHGi0qK8LaB2QwuWy7FKgx5I7yhgWKSWLVFhIOlca/X\nFo0mxCf8NPqOrhxRdS6UeucCAwEAAQ==\n-----END PUBLIC KEY-----\n",
    "name": "Zapper",
    "name_updated": "2018-06-04 03:22:19",
    "username": "zapper",
    "photo": {
        "url": "https://zap.macgirvin.com/photo/profile/l/2",
        "type": "image/png",
        "updated": "2018-06-04 03:22:19"
    },
    "channel_role": "social",
    "searchable": true,
    "adult_content": false,
    "public_forum": false,
    "profile": {
        "description": "",
        "birthday": "",
        "gender": "",
        "marital": "",
        "sexual": "",
        "locale": "",
        "region": "",
        "postcode": "",
        "country": "",
        "about": "",
        "homepage": "",
        "hometown": ""
    },
    "permissions": "view_stream,view_profile,view_contacts,view_storage,view_pages,view_wiki",
    "permissions_for": "",
    "locations": [
        {
            "host": "zap.macgirvin.com",
            "address": "zapper@zap.macgirvin.com",
            "id_url": "https://zap.macgirvin.com/channel/zapper",
            "primary": true,
            "url": "https://zap.macgirvin.com",
            "url_sig": "sha256.qBKZU6tReyUkVcNgGldRfdINiPoBneN9wWc-RHN7CFj8z9GgRW26LDUgmWL6kNoobYvHO6VIdZLxJb6CGdTLs7pjYGMZeTxpHHTgo3uHdBBIJdWPAwyEoppKGR3qT3S5iYWW9P0dsMtGjQ_q2VdaiqguoG8Z3lnTWikT7ujPI4NXZP2R0PVzEmaefN4SXqTO22XhXO-SuK4EOHylGcusQCfO6hXji9KItfwH1rnPx588YNRQ9WvBkV95ArZYSELRoFuJfHWh4ABqqAwQ4BqTO4-Pv1LiN1bWoNwVTki79Lx2GhQlw-_7HcHtVpqW_TQ04G4iPXvWHLzKfErfbGnQ575sbsF1gc2MYOINCofOmTq8eU_HOWaGK8D10HxpCVMMZXK37i8b6QEk3wpCoGiStGe5nsytVepZwNhsdnmW5msyO2ew_jZo3t_lP7U3oRvJHyJ7JpZBZg4E-MkLa-00KtiVGIosCesmFbZ042OwwTH3iJeSgz-yxrOsg3xdCj3e7rx4E93ra91OdN-mL-x8K4iYjcPQ6UpjInx2qsc_B8qwiw7L4jqJan7SYRDlxSiAb3yd1NFqL5gEMBg7RkS9s9a92hU3R6_K6CPpP9fb4mzRAzxpgRMpzhmBKnzlWF_Uz6c0urQpJLqJxfV4OzFThyxuqi3UyPg_R59DY3JfDUI",
            "site_id": "gcwJ1OzIZbwtfgDcBYVYhwlUmjaxsgPyJezd-F2IS1F3IrlVsyOesNpm3hvoWemIBxoHmgIlMYKkhFeYihsqBQ",
            "callback": "https://zap.macgirvin.com/zot",
            "sitekey": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuOkQslfq9EjZJLVniWP1\n3anzfdASnlgUKUYK1zyxy/HbwxAXl0GupYpJEVNIpkrGtTUMWY7ppxH7y/EAiSTJ\nsMIFIy1AnHgS/ecx6N/tH6rzZ68jD8yJQxjZBUk7MfhfYOK8KUti/qmp859Pr3cA\n1K1woCtSLRx2HNzHED8LDTUCGSwneHA2m7Ffc1MNfII8Ia/VtoF7pBwOixayws2N\nlY5syuDqOO3LtMJnDMBRN5WbtTw5jobyaoK6o4+Kg7Kln0nymloD3knFFsPvIdJd\nl493ItBi6k5QR0PV8NtElZMWRy8gZjzI5c4yukXku0WK1lVJBpjl4/LfjulWSMaR\nzj+YZKTjw7G56EEB2drNUVn/ZYLYwvMn6Bv/8lYu4VwL873UbupITNGX/Wh7+EU3\ntJqvXvdh8scIAKR3+sS/SrNI6OMn34HKewaX8iMf6NgW5lrskr9dhOYuZVr63huc\nhXxdGv+6b5+ARYEOpTn5QQd89WSL4Vui+1VaO4FARt9oRiC9s3sd0swyTxFqJSY4\nYJcpuVMUKY54jOGpsT0+1DlYFZf+lOk7pRpuYY1Vv/AhWCpkt6Uamf5d11rnVikA\nuPFgFqaObFenM1u1EKF1xrNaQqy3NbhOb0yRatVPcnAwOlesHbM7tgKmyZSopJTW\nJ2ug8isS+vNI0q+4IwET5FMCAwEAAQ==\n-----END PUBLIC KEY-----\n",
            "deleted": false
        }
    ],
    "site": {
        "url": "https://zap.macgirvin.com",
        "site_sig": "sha256.OWCNR-OocRwk2Y4RwSHtE-y_bcWPkXYPQetvRO-8VjO_b0eqwKDjvB52WPKKl43UQRHRn0CN6Xc487zPY7bVqIaLcsE23R0JOacl9IO3_9k-RbeH6H8KV8E_GynM-6cucPI1Dh7s3rgcqk-GXwoRaFaraurYDHvoGEVHOa1jHpv75lT2COCi1sDGhDR3-KPJbug61y58CUu3bJj2VRAqBaoiMz5TwbUIY9Sb22d205X_UzoIF_TlPDMoZv-Mbrkcxn9kgIfatgVyKGKKyoAnvyJeFzjHm1xCY4sZtt4C_em0a5wpcVPl31KbI5BodKn910ChErHXMCedBPeYWhRA0a-9Y_vYGonun3jXqJZ33WxzG9P1Gllp4bhxK6tm9X1iRpUnB7j8g8RHSH4PukQKSl2ErZ2vPLdHMIkczX9YEhhCbeZIvcX6T_5s82Ua75rlVktJGHsh8yLw3iqCdWljpCVhTWpEK0NmhJB6TcadE9qlRN9Gun7keEV4Ov6Dl5O7I-0ssoWbhv7lHU6JcjhAuf2TDLod_Izka32ZZk_8s8ZmqFzEEG6g6pRyuzvqk4XNK6cTL6dvBGIua5D0bRTBn4XTELx8u4B3yK7_MArr_m5Z5KfXOm_ngGMCN-lIZuKhxAQpCVDD5jcHmnCzjcDiR5m5LvOfvBSxwtpgHZUr3AU",
        "post": "https://zap.macgirvin.com/zot",
        "openWebAuth": "https://zap.macgirvin.com/owa",
        "authRedirect": "https://zap.macgirvin.com/magic",
        "sitekey": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuOkQslfq9EjZJLVniWP1\n3anzfdASnlgUKUYK1zyxy/HbwxAXl0GupYpJEVNIpkrGtTUMWY7ppxH7y/EAiSTJ\nsMIFIy1AnHgS/ecx6N/tH6rzZ68jD8yJQxjZBUk7MfhfYOK8KUti/qmp859Pr3cA\n1K1woCtSLRx2HNzHED8LDTUCGSwneHA2m7Ffc1MNfII8Ia/VtoF7pBwOixayws2N\nlY5syuDqOO3LtMJnDMBRN5WbtTw5jobyaoK6o4+Kg7Kln0nymloD3knFFsPvIdJd\nl493ItBi6k5QR0PV8NtElZMWRy8gZjzI5c4yukXku0WK1lVJBpjl4/LfjulWSMaR\nzj+YZKTjw7G56EEB2drNUVn/ZYLYwvMn6Bv/8lYu4VwL873UbupITNGX/Wh7+EU3\ntJqvXvdh8scIAKR3+sS/SrNI6OMn34HKewaX8iMf6NgW5lrskr9dhOYuZVr63huc\nhXxdGv+6b5+ARYEOpTn5QQd89WSL4Vui+1VaO4FARt9oRiC9s3sd0swyTxFqJSY4\nYJcpuVMUKY54jOGpsT0+1DlYFZf+lOk7pRpuYY1Vv/AhWCpkt6Uamf5d11rnVikA\nuPFgFqaObFenM1u1EKF1xrNaQqy3NbhOb0yRatVPcnAwOlesHbM7tgKmyZSopJTW\nJ2ug8isS+vNI0q+4IwET5FMCAwEAAQ==\n-----END PUBLIC KEY-----\n",
        "directory_mode": "normal",
        "encryption": [
            "aes256ctr.oaep",
            "camellia256cfb.oaep",
            "cast5cfb.oaep"
        ],
        "zot": "6.1",
        "register_policy": "closed",
        "access_policy": "private",
        "accounts": 1,
        "channels": 3,
        "admin": "mike@macgirvin.com",
        "plugins": [],
        "sitehash": "c89e5a2b5059d04cc05078899c2083d4b89c190e6d6b247300256bfc66a930b3",
        "sitename": "Zap Development",
        "sellpage": "",
        "location": "",
        "realm": "RED_GLOBAL",
        "project": "zap",
        "version": "6.6"
    }
}

Encryption+Signatures

Encryption

Standorte geben in ihrem Site-Discovery-Dokument ein Array an, das 0 oder mehr Verschlüsselungsalgorithmen enthält, die sie in der Reihenfolge ihrer Präferenz akzeptieren. Standorte, die verschlüsselte Dokumente versenden, MÜSSEN diese Liste verwenden, um den für beide Seiten am besten geeigneten Algorithmus zu ermitteln. Kann kein geeigneter Algorithmus ausgehandelt werden, DARF die Website auf Klartext (unverschlüsselte Daten) zurückgreifen; ist der Kommunikationskanal jedoch nicht mit SSL gesichert, DARF die sendende Website KEINEN Klartext verwenden, und eine empfangende Website DARF die Kommunikation ignorieren oder ablehnen, wenn sie private oder sensible Informationen enthält.

Unterstützt die empfangende Website den bereitgestellten Algorithmus nicht, MUSS sie den Fehler 400 zurückgeben.

Verschlüsselte Informationen werden in ein JSON-Array/Objekt mit den folgenden Komponenten gekapselt:

'encrypted' => true
'key'       => The encryption key, base64urlencoded
'iv'        => The encryption initialisation vector, base64urlencoded
'alg'       => The encryption algorithm used
'data'      => The encrypted payload, base64urlencoded

Das boolesche Flag „encrypted“ gibt an, dass es sich um eine kryptografische Struktur handelt, die entschlüsselt werden muss, um die Informationen zu extrahieren. „alg“ ist erforderlich. Andere Elemente können bei Bedarf angepasst werden, um verschiedene Mechanismen/Algorithmen zu unterstützen. Beispielsweise benötigen manche Mechanismen möglicherweise ein „hmac“-Feld. Die aufgeführten Elemente unterstützen eine Vielzahl von Standard-Verschlüsselungsalgorithmen.

Der Schlüssel und der IV sind pseudozufällige Byte-Sequenzen, die vor der Base64-URL-Kodierung mit dem öffentlichen RSA-Schlüssel des Empfängers verschlüsselt werden. Der in den meisten Fällen (standardmäßig) verwendete Empfängerschlüssel ist der öffentliche Schlüssel der Remote-Site. Unter bestimmten Umständen (sofern angegeben) ist der öffentliche RSA-Schlüssel der des Zielkanals oder des Empfängers.

Sowohl „key“ als auch „iv“ KÖNNEN auf 255 Zeichen aufgefüllt werden. Der Umfang der erforderlichen Auffüllung hängt vom Verschlüsselungsalgorithmus ab. Die empfangende Seite MUSS zusätzliche Auffüllung bei beiden Parametern entfernen, um die vom gewählten Algorithmus unterstützte maximale Länge einzuhalten. Der Algorithmus „aes256cbc“ (nicht empfohlen) verwendet beispielsweise eine Schlüssellänge von 32 Byte und einen IV von 16 Byte.

Die Bezeichnungen für gängige Algorithmen entsprechen den von der OpenSSL-Bibliothek verwendeten Algorithmusnamen in Kleinbuchstaben ohne Satzzeichen. Der OpenSSL-Algorithmus „aes-256-ctr“ wird beispielsweise als „aes256ctr“ bezeichnet.

Ungewöhnliche Algorithmen, die von OpenSSL nicht unterstützt werden, dürfen verwendet werden, doch die genauen Algorithmusnamen sind in diesem Dokument nicht definiert.

Signatures

Die Herkunftsnachweis der Identität erfolgt mithilfe von HTTP-Signaturen (derzeit gilt die Spezifikation „draft-cavage-http-signatures-10“ als maßgeblich). Bei Verwendung eines verschlüsselten Transports KANN die HTTP-Signatur mit demselben ausgehandelten Algorithmus verschlüsselt werden, der auch in der Nachricht zum Schutz des Umschlags verwendet wird. Siehe HTTP-Signaturen. Wenn eine Website die im vorangegangenen Abschnitt beschriebene ausgehandelte Verschlüsselung verwendet, MUSS sie in der Lage sein, die HTTP-Signaturen zu entschlüsseln.

An mehreren Stellen in den Kommunikationsprotokollen, an denen die Verifizierung mit einem Dritten erfolgt, der nicht der Absender des betreffenden HTTP-Pakets ist, werden signierte Daten/Objekte festgelegt bzw. vorgeschrieben. Je nachdem, ob es sich bei den signierten Daten um einen Einzelwert oder ein JSON-Objekt handelt, können zwei Signaturverfahren zum Einsatz kommen. Das für Einzelwerte verwendete Verfahren wird hier als „SimpleSignatures“ bezeichnet. Das für Objekte verwendete Signaturverfahren ist traditionell als „Salmon Magic Signatures“ bekannt und nutzt die JSON-Serialisierung.

Simple Signatures

Ein Datenwert wird mit einer geeigneten RSA-Methode und einem Hash-Algorithmus signiert; beispielsweise „sha256“, was eine Signatur mit einem RSA-Schlüsselpaar unter Verwendung des dafür vorgesehenen privaten RSA-Schlüssels und des Hash-Algorithmus „sha256“ bezeichnet. Das Ergebnis wird Base64URL-kodiert, mit dem Algorithmusnamen und einem Punkt (0x2e) vorangestellt und, sofern angegeben, als zusätzliches Datenelement gesendet.

"foo_sig": "sha256.EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe..."

Zur Überprüfung wird der Inhalt des Elements am ersten Punkt getrennt, um den Algorithmus und die Signatur zu extrahieren. Die Signatur wird mit „base64urldecode“ dekodiert und unter Verwendung der entsprechenden Methode und des entsprechenden Hash-Algorithmus sowie des dafür vorgesehenen öffentlichen RSA-Schlüssels (im Falle von RSA-Signaturen) überprüft. Der zu verwendende Schlüssel ist an anderer Stelle im Zot-Protokoll in Abhängigkeit vom Kontext der Signatur definiert.

Implementierungen MÜSSEN RSA-SHA256-Signaturen unterstützen. Sie KÖNNEN zusätzliche Signaturmethoden unterstützen.

Salmon “magic envelope” Signatures mit JSON-Serialisierung.

{
  "signed": true,
  "data": "PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGl...",
  "data_type": "application/x-zot+json",
  "encoding": "base64url",
  "alg": "RSA-SHA256",
  "sigs": [
    {
    "value": "EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe...",
    "key_id": "4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI"
    }
  ]
}

Das boolesche Element „signed“ ist in der Spezifikation des Magic Envelope nicht definiert. Es handelt sich hierbei um ein boolesches Flag, das angibt, dass es sich bei dem aktuellen Element um ein vorzeichenbehaftetes Objekt handelt, das einer Überprüfung und Entpackung bedarf, um den tatsächlichen Inhalt des Elements abzurufen.

Die signierten Daten werden durch Entpacken der „data“-Komponente der Magic-Signatur abgerufen. Das Entpacken erfolgt durch Entfernen aller Leerzeichen (0x0d, 0x0a, 0x20 und 0x09) und anschließende Base64-„URL“-Dekodierung.

Die „key_id“ ist die Base64-URL-kodierte Kennung des Unterzeichners, die im Rahmen des Zot-„Discovery“-Prozesses zur Ermittlung des öffentlichen Schlüssels führt. Dabei handelt es sich in der Regel um die Basis-URL des Servers oder die „Home“-URL des Kanals. Webfinger-Kennungen (acct:user@domain) KÖNNEN ebenfalls verwendet werden, wenn das resultierende Webfinger-Dokument einen auffindbaren öffentlichen Schlüssel (Salmon-Public-Key oder WebID-Schlüssel) enthält.

Die Überprüfung erfolgt mithilfe der „Magic Envelope“-Verifizierungsmethode. Entfernen Sie zunächst alle Leerzeichen aus dem Wert „data“. Fügen Sie die folgenden Felder durch einen Punkt (0x2e) getrennt aneinander.

data . data_type . encoding . algorithm

Dies sind die „signierten Daten“. Die Überprüfung erfolgt mithilfe der RSA-Verifizierungsfunktion unter Verwendung der signierten Daten, des Base64-URL-dekodierten Werts „sigs.value“, des in „alg“ angegebenen Algorithmus und des öffentlichen Schlüssels, der durch Ausführen der Zot-Erkennung für die Base64-URL-dekodierte „sigs.key_id“ ermittelt wurde.

Bei der Durchführung einer Zot-Abfrage nach Schlüsseln ist es wichtig, zu überprüfen, ob der in der Abfrageantwort zurückgegebene Principal mit dem Principal in der „key_id“ übereinstimmt und ob die Abfrageantwort ebenfalls signiert und validiert ist.

Einige historische Varianten von „Magic Signatures“ geben eine Base64-URL-Kodierung mit oder ohne Auffüllung aus.

In dieser Spezifikation MUSS die Kodierung die Zeichenkette „base64url“ lauten, was die URL-sichere Base64-Kodierung gemäß RFC 4648 bezeichnet, ohne abschließende Auffüllung mit Gleichheitszeichen (=).

Die entpackten Daten (nach der Überprüfung) können einen einzelnen Wert oder ein zusammengesetztes Objekt enthalten. Enthalten sie einen einzelnen Wert, wird dieser zum Wert des übergeordneten Elements. Andernfalls werden sie wieder als zusammengesetztes Objekt zusammengeführt.

Beispiel: Quelldokument

{ 
    "guid": {
      "signed": true,
      "data": "PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGl...",
      "data_type": "application/x-zot+json",
      "encoding": "base64url",
      "alg": "RSA-SHA256",
      "sigs": [
        {
        "value": "EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe...",
        "key_id": "4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI"
        }
      ]
    },
    "address": "foo@bar"
}

Die Dekodierung des Datenparameters (unter der Annahme einer erfolgreichen Signaturprüfung) ergibt

"abc12345"

Durch das Zusammenführen mit dem Originaldokument entsteht

{
    "guid": "abc12345",
    "address": "foo@bar"
}

Beispiel mit einem signierten Objekt, das mehrere Elemente enthält: Die Dekodierung des Datenparameters (unter der Annahme einer erfolgreichen Signaturprüfung) ergibt

{
    "guid": "abc12345",
    "name": "Barbara Jenkins"
}

Wenn man dies mit dem Originaldokument zusammenführt, ergibt sich

{
    "guid": {
        "guid": "abc12345",
        "name": "Barbara Jenkins"
    },
    "address": "foo@bar"
}

Nomadic Identity

Nomadic Identity

Einer der grundlegenden Unterschiede zwischen Zot und anderen Messaging-Systemen bzw. -Protokollen ist die Unterstützung der „nomadischen Identität“. Das bedeutet ganz einfach, dass Ihre Identität (wer Sie sind) unabhängig von dem Server ist, von dem aus Sie Beiträge veröffentlichen (wo Sie sich befinden).

Folglich kann eine Person eine beliebige Anzahl aktiver Standorte haben. Implementierungen, die nomadische Identitäten unterstützen, MÜSSEN eine Kopie aller für diese Identität bestimmten Nachrichten an alle bekannten aktiven Standorte senden. Wenn Standorte eine Nachricht von der angegebenen Identität von einem beliebigen Standort erhalten, MÜSSEN sie überprüfen, ob die Identität diesen Standort autorisiert hat, und (bei erfolgreicher Überprüfung) die Nachricht ordnungsgemäß zustellen. Sie SOLLTEN den neu verifizierten Standort speichern und KÖNNEN anschließend die gespeicherten Informationen verwenden, anstatt eine erneute Überprüfung durchzuführen.

Wenn eine Identität ihre Standortdaten ändert, MUSS sie ein „Refresh“-Paket an alle bekannten Standorte senden, zu denen sie eine Verbindung unterhält und die für den nomadischen Betrieb ausgelegt sind. Die „Refresh“-Nachricht weist den anderen Standort an, eine Netzwerkerkennung durchzuführen und alle gespeicherten Informationen zu dieser Identität zu aktualisieren, die sich möglicherweise geändert haben.

OpenWebAuth

OpenWebAuth

OpenWebAuth provides a light-weight form of cross-domain authentication between websites on the open web. The principals involved in the authentication may or may not have any pre-existing relationship.

OpenWebAuth utilises webfinger (RFC7033) and HTTP Signatures (draft-cavage-http-signatures-09) with a simple token generation service to provide seamless and interaction free authentication between diverse websites.

For example, on website podunk.edu a member has made a video available privately to bob@example.com. In order for bob@example.com to verify his identity and view the protected video, he must establish proof of his identity to podunk.edu.

At a high level, for an actor to visit another site as an authenticated viewer, he/she first redirects to a service which can create digital signatures on their behalf and which is provided a destination URL. This service must have access to their private signing key.

The public key is stored on a webfinger compatible service or provided directly as a webfinger property. The webfinger resource is provided as the keyID of an HTTP Signature ‘Authorization’ header.

There is very little concensus on providing public keys in webfinger except for the salmon magic-public-key. For those that prefer a higher level key format a property name of ‘https://w3id.org/security/v1#publicKeyPem’ MAY be used and although unofficial, aligns with JSON-LD and ActivityPub. Servers MAY look at other webfinger resources if there is no usable public key found in the webfinger JRD document. These discovery mechanisms are outside the scope of this document.

A webfinger request to the baseurl of the destination URL returns an entry for an OpenWebAuth service endpoint. For example:

rel: https://purl.org/openwebauth/v1
type: application/json
href: https://example.com/openwebauth

The redirector signs an HTTPS GET request to the OpenWebAuth endpoint using HTTP Signatures, which returns a json document:

{
  'success': true,
  'encrypted_token': 'bgU50kUhtlMV5gKo1ce'
}

The ‘token’ is a single use access token; generally a unique hash value of 16 to 56 chars in length (this is consistent with RSA OAEP encryption using a 1024-bit RSA key). The resulting token will very likely be used in a URL, so the characters MUST be in the range of [a-zA-Z0-9]. To generate the ‘encrypted_token’ this token is first encrypted with the actor’s public key using RSA encryption, and the result base64_url encoded.

If the Signature cannot be validated, the OpenWebAuth service returns

{
    'success': false,
    'message': 'Reason'
}

‘message’ is not required.

If an encrypted_token is returned, this token is decrypted:

base64_url decode the ‘encrypted_token’ decrypt this result with the RSA private key belonging to the original actor, which results in a plaintext ‘token’.

added to the destination URL as a query parameter ‘owt’ (OpenWebToken).

303 https://example.com/some/url?owt=abc123

The user’s browser session is now redirected to the destination URL (with the token provided) and is authenticated and allowed access to various web resources depending on the permissions granted to their webfinger identity.

Notes: All interactions MUST take place over https: transport with valid certificates. HTTP Signatures offer no protection against replay attacks. The OpenWebAuth token service MUST discard tokens after first use and SHOULD discard unused tokens within a few minutes of generation.

Encrypted HTTP Signatures

Encrypted HTTP Signatures

draft-cavage-http-signatures-09 describes a method for providing public key signatures and authentication for HTTP requests.

A fundamental limitation (flaw) of HTTP signatures is the fact that they often leak metadata of the originator of a communication via the ‘keyId’.

Encrypted HTTP signatures corrects this by encrypting the signature header.

Encryption uses the public key of the receiving site. The content of the Signature or Authorization header after creating an HTTP signature is passed through an encryption function f(header,key,algorithm) with the public key of the remote site and a mutually agreed encryption algorithm which returns an encrypted structure containing

key: a “random” string encrypted with the RSA public key of the remote site and base64_url encoded iv: a “random” string encrypted with the RSA public key of the remote site and base64_url encoded (optional) alg: the encryption algorithm used data: the encrypted data, base64_url encoded hmac: base64_url encoded hmac (optional)

The header is generated by applying each field name followed by ‘=’ followed by the double-quoted field value and fields separated by commas (the same as draft-cavage-http-signatures)

The encryption is performed by encrypting the header string with the chosen algorithm using key and iv. Key and iv may be of a greater length than the specified algorithm permits. These strings are truncated to the desired key length and initialisation vector length prior to encryption, but transmitted in their entirety. Typically the random string is of length 256 octets and the key and iv are generally restricted to 16 or 32 octets (depending on the encryption algorithm used). There are no restrictions on the characters of the “random” octet string.

Resulting header:

Signature: iv="d-uqkRoeXCoL1T5DU74ywizSM2RgsI9ZXWREKVg3_Qjd-mUWTJVGLq2hOQi3XKaa9Q7R6uB6UzlRmLfxBMZhVIxHjdNgfSRQ_oXafiSv8bZzMVKLZCjw6PfxBcljFs5gaQ7vEGuOVZ5nUaNEU7QX7WFr7BQKlev_6GFruv7HOsehGCokpyHHkKwrQ_4WJxUZp7o1ZhS1masPqMrEtUxDGfKwHfiHILuMdWDBvv2Xk4iHzlCi9fRVUEvzzFvv1rXsanjbaypZMIfSNj31kvsGfs6IyHpIaKbFqRs_iCxfujKDYh-2Dsg02bJTF1qx9BHJqLKNpfc0iReVe_xV2Qom3-SrJe1K8mRzYQJuOyyDuQk04GBlw7ken698JcwuS0G0OMfvGh5okq_0wM_O09iYumnJlEZT2a5nJ8ifc-kZfu8zdIPyAjJvS3a3KGEsytLxuUekFPVIpEoV2rmgOWz0TzDg-mIgwFffcx3kDa_WWhPGCFwVOzGU9um0KKStThKNXrbjYEAHVxD0gYXPgwmL8KayCo2A2s4bE2W8FfSURGu4Noqr9VsZ69Bcygzitv3aWCeIAk0y7kjJ0yQDfuIOjK1GP4HECq5NJIf8L3LJKw8QIBKm_0nx4gV9rLSAKCe3S63-D1tp9hafeiKQvGSwR0ybhxTJrhkcxd2nieVAyoA",key="Ca14lvjZua-ED8kXbedNLmrk6mRMHZm9NugcphyBMKEBo8MXLLnTsZchkAP-auWa0iJFKRwtdYUW_IGO-WX_qKZ8VNOslViveTYY-ybLTjQUj--YCFuURLYUWYTEmDcOImPWc8cQYGjTL_PN5X7vo7t3cm6rdV2W4tio2Rrmg3-cjhXBBRElr3GQKQ7i9ljBPs2YffoRsJ7f8DycKeyTv1T9xwr5lDklWOcOMTD4_39cZN2BI-b3AcGhBG4oYabUavW3BLGX7-SnezUcbTP3RyCVGI0ylVS8FmHSBZmW0oWfrVmz0oc0UcZYQMk8rb2WL_2ZdnzV_yZsjbBTFHG1ytIYyMeJsUU-pv4b4TodZmuDKT5UGtXPhm8Lsh-JpFo8xj5Yl15T9H6yLVHMR7Wzx_r2SvlJUsyqzBpaZE8DMd0zzrNZwgHQZ08wVHieKKO-TIqdypZHkxGGM68u2NPPW8-mXHgd_w9fUNM5fZRKPL9GxoVqoe9hx2f6CXPD95GAwjer9hbJcOmvxA1veXpIQzlkd-kEc8EuECaC50aUZJZbUIghYFo9NAA-UgNb26TyuY1OwE55MstPA6OO1sFki2u1G1T5JGWWgIOAziCcZbDYl1NPFWD2I1sV__rYeZ6XaaW4GXIVqD3wyBpmBRIoFx43gVDTISyUjhjUjjVHbZE",alg="aes256ctr",data="CLBNNE-tR1lRm0QL5gS86HyfwMs_16xKSSHTBP7MUEmRhGR00s0cdOfLC-PCZKlpG3ZRvc_lxnd53GGycNiTskisAb1mTbTrUBvk7hpDGNciUEB_7-hehjRiztmfi_oR-H0sCsVK9qDJdYepr4BYIgznVcB0uEN-POm97H4cTTVD8xCxLeEX0ArgDzgv_-Bq-nMcyht2LdGFl4Ej3bhEOhzvd-Xs1m6Z3E55dw0Bx7QDtkorvoetgMJrhgPKjYkIUWGoyVqa8MssvYIT8w9mpPDm4_QuVSNiPLIrKwQ3vob_hxcvENY-l0vXihdnpMzg81Sdk0E4FS4uQ9HtYSWsjOaFDSWRlxc-C5RhIvnHST4uEy3tjI--OHYQo2mFG2fWM3h8bYPq6r41W79qxsfmdSydmV1G5rFIqaz7gOa2JGOtW19WPJ8FTNFLVDehrFD6FJUy185gYyXosonp2EF3qlC8k_fzmazrzUrx0YmQ941870LJAwtEC7P-XiHV3dj-tZRYPgiSp7m8cMm7Z8WGgN8lLb61t5di5XS8zAv3FU1EAvvyL7PQhDi1U-s2cQXk3hXTNhOIymUYRhSV8NZrk80EsOrbPevSNQyYKXWCeUbnyhUznZQ3Lwq-UWAufcwrVY5uIJKeNu2lZ42xzSHWW3hn0ymcXzBOz7_wip9pSPY1nsTwApqTaIjURMEHhPvgaKRzNmuKbWP-d5Ihjeqw6JGXoAw0beWPJ4rqOlpQtn63deyBR5ylcRe4Ok2n03fZBnzJAobfZuHkiW93Yvc_byF-rpMJ3C8BSFYhGNDzYeRea3d9BEsqz_sr2HNpJyLhPssiZlZdjGRfqQ5UvCIJgT_NY57FoRCx4RHRpSxkjyF5XaKXW0_uNK7Oxk30qOCbIsLkQJqB2JIVrFFDBPITZIQVq2OamcBVk09OPuIMvsNBUTt2sxcZ7LVAA61ubv0jU39TcYO_OCs2eL7WaH7zDs9wHmxlwvzrPclduY5Gx2pwkrI_nb42j4Nc5imUkvzkIAhbYOB-XBClNVjFdEqYH35lziqEl9I6_w"

Decrypting the header reverses this process.

• base64url_decode the key and iv and data fields and if used, the hmac field.
• use the site private key to decrypt key and iv
• apply decryption algorithm ‘alg’ to ‘data’ using ‘key’ and ‘iv’, truncating ‘key’ and ‘iv’ if necessary for the chosen algorithm.
• The end result is an HTTP Signature as sepcified in draft-cavage-http-signatures, process according to that document.

Discovery of site public keys and algorithm negotiation is outside the scope of this document.