Summary

  • Der Grundentwurf für Structured Email beschreibt maschinenlesbare Inhalte als application/ld+json. Der Vertrauensentwurf in Revision 02 behandelt deren Anzeige und Verarbeitung.
  • Abschnitt 4.1 nennt sieben alternative Bedingungen. Ein vertrauenswürdiger Unterzeichner, ein bestehender Gesprächsfaden und die Verbindung zu einer älteren vertrauenswürdigen Nachricht gehören dazu.
  • DKIM kann die gesamte Nachricht signieren; JWS kann den strukturierten Teil abdecken. Ob der Unterzeichner vertrauenswürdig ist, beurteilt die empfangende Anwendung.

Ein und dieselbe Mail kann drei Reisepläne enthalten: einen im Klartext, einen in HTML und einen als strukturierte Daten. Die letzte Fassung kann eine Anwendung zu einer Schaltfläche verarbeiten. Der Grundentwurf liefert das Datenformat. Der Vertrauensentwurf vom 2. November legt Kriterien für den Schritt in die Benutzeroberfläche vor. Dort wird aus einer Behauptung über eine Reise eine Aufforderung zum Handeln.

Der Entwurf unterscheidet Spam, gewöhnliche und vertrauenswürdige Nachrichten. Nur die letzte Klasse erhält in seinem Modell die Verarbeitung strukturierter Daten. Eine gültige Signatur beantwortet eine technische Frage nach der Bindung. Die Anwendung beantwortet die soziale und betriebliche Frage, ob gerade dieser Absender an gerade dieser Stelle einen Knopf erhalten soll.

Die sieben Anzeigebedingungen zeigen die Reichweite dieser Entscheidung. Strukturierte Daten können ohne zusätzliche Angriffsfläche gegenüber HTML auskommen oder wie eine Kalendereinladung behandelt werden. Weitere Wege führen über einen vertrauten Absender mit persönlicher oder Domain-Signatur, denselben Absender mit DKIM, einen vertrauten JWS-Unterzeichner, einen laufenden Faden mit vertrautem Absender oder die Verbindung zu einer früheren vertrauten Mail. Das sind Alternativen des Entwurfs. Zwei Programme können dieselbe signierte Nachricht unterschiedlich darstellen und dabei jeweils ihrer eigenen Regel folgen.

Der alte Faden entscheidet über die neue Aktion

Besonders folgenreich ist die Gesprächshistorie. Ein neues Schreiben kann sich auf eine alte Beziehung stützen. Wird ein Teilnehmerkonto übernommen, kann diese Vorgeschichte einer neuen Aktion Sichtbarkeit verschaffen. Wer das Programm betreibt, muss nachweisen können, welcher Faden als Beleg diente und wann dieses Vertrauen enden soll. Eine grüne Signaturanzeige erklärt die Entscheidung allein nicht.

DKIM und JWS schützen zudem unterschiedliche Bereiche. DKIM signiert die Mail, JWS gegebenenfalls nur den strukturierten Teil. Der Entwurf lässt Fragen zu abgetrennten JWS-Nutzdaten sowie zum Vergleich roher Bytes oder kanonischen JSON offen. Ein Spamfilter kann Klartext prüfen, während die Anwendung aus JSON-LD eine Aktion erzeugt. Weichen die drei Darstellungen voneinander ab, muss die Prüfung beim tatsächlich gezeichneten Knopf beginnen und bis zu den signierten Daten zurückreichen.

Externe Verweise können beim Öffnen Netzabrufe auslösen und damit die Lektüre verraten oder neue Inhalte außerhalb der signierten Nachricht holen. Abschnitt 4.3 empfiehlt eigenständige Daten, wenn eine sinnvolle Interaktion sonst eine Webanfrage benötigt. Ein öffentlicher Vergleich derselben signierten MIME-Nachricht samt verknüpfter Antwort und Fernressource in mehreren Mail-Programmen fehlt. Bildschirmanzeige und Netzwerkprotokoll dieses Versuchs würden die praktische Grenze zeigen.

Entwurf und Versionsgeschichte · Structured Email · DKIM · JWS