Summary

  • The Structured Email draft proposes a machine-readable application/ld+json part. The trust draft, revision 02, sets out when a mail user agent should display or process that data.
  • Section 4.1 offers seven routes to display, including trusted signers, an existing trusted thread and a link to a previously trusted message. These routes turn client history into part of the authorization decision.
  • DKIM can sign the whole message; JWS can cover the structured part. The draft leaves the trust judgment to the receiving application.

The ordinary email has three audiences. Its plain-text part can tell a traveller a flight time. Its HTML part can show a polished itinerary. Its structured part can tell software that there is a reservation, a venue and an action. The core Structured Email draft gives the last part a machine-readable form. The trust draft, dated 2 November, asks when a mail client should promote that data from a passive statement into an interface.

That promotion is the expensive decision. A signature can bind bytes to a signer. It cannot tell the recipient whether the signer should be allowed to put a new control next to a booking, or whether a link behind that control leads to the expected service. The draft describes spam, ordinary and trusted messages as different classes; the trusted class receives structured-data processing. The mail app owns the classification, display and any automation that follows.

Section 4.1 supplies seven possible display conditions. The least adventurous is that structured data creates no extra attack surface compared with HTML. Another treats a calendar invitation or update like its existing equivalent. Other conditions combine a trusted sender with a valid personal or domain signature, or with DKIM; accept a trusted JWS signer for the structured data; use an ongoing thread with a trusted sender; or connect the message to an older trusted one. These are alternatives in a draft, not a seven-step approval checklist.

Their variety is the story: the app may look at cryptography, message type or local conversation history before it draws the same button.

A signature travels; trust stays in the client

The draft distinguishes two signature scopes. DKIM covers the email message. JWS may cover only its structured part. A DKIM pass can say that a domain signed a message containing the itinerary; a JWS pass can say that a signer covered a particular data object. Whether the signer belongs to the airline, the travel agent or a stranger using a familiar brand remains the client's judgment. The draft explicitly assigns the trust decision to the application. Its open questions include detached JWS payloads and whether comparison should use raw bytes or canonical JSON.

Those details matter when the visible message and signed object take different paths through parsers.

The draft also describes a gap between filters and rendering. A spam filter may parse the plain text or HTML differently from the mail app's structured-data parser. A benign-looking body can therefore carry an action the filter never evaluated. Plain text, HTML and structured data can disagree on the booking, destination or requested operation. The result is a plausible screen that asks the reader to act on the wrong representation. An operator needs to compare the representations that reach the user, not just record that a signature verified somewhere in the MIME tree.

Then comes the network fetch. Structured data can point to external resources. Loading them can expose that the reader opened the message, and can retrieve fresh content outside the signed payload. Section 4.3 recommends self-contained data when meaningful interaction would otherwise depend on a web fetch. A mail app can turn a small, signed declaration into an unsupervised request if it treats every external reference as display material.

The public draft supplies no cross-client test corpus showing how the same signed message, linked reply and external resource render in real MUAs. A controlled run with raw MIME, signature results, rendered controls, network traffic and final user action would settle that operational question.

Trust draft and revision history · Structured Email draft · DKIM · JWS