Summary

  • Le projet sur le courriel structuré prévoit une partie application/ld+json exploitable par un logiciel. Le projet sur la confiance, révision 02, traite de son affichage et de son traitement.
  • Sept conditions possibles figurent à la section 4.1, de la signature d'un expéditeur reconnu à la continuité d'une conversation déjà fiable. L'historique local du client entre ainsi dans le choix de montrer une action.
  • DKIM peut signer le message entier ; JWS peut couvrir la seule partie structurée. C'est l'application réceptrice qui juge la confiance accordée au signataire.

Un même courriel peut raconter trois histoires. Le texte brut annonce une heure de départ. Le HTML présente une carte d'embarquement élégante. Les données structurées décrivent une réservation que le logiciel peut interpréter et transformer en action. Le projet central de Structured Email définit cette troisième représentation ; le texte sur la confiance daté du 2 novembre examine le moment où l'application doit la faire entrer dans l'interface.

La frontière est nette : une preuve cryptographique relie des octets à un signataire, tandis que la décision d'afficher un bouton relève du client. Celui-ci classe les messages en indésirables, ordinaires ou fiables dans le modèle du projet. La dernière catégorie ouvre le traitement des données structurées. Le destinataire voit le résultat de ce classement, rarement les éléments qui l'ont produit.

La section 4.1 énumère sept voies vers l'affichage. Une voie estime que les données n'ajoutent aucune surface d'attaque par rapport au HTML. Une autre reprend le traitement d'une invitation ou d'une mise à jour de calendrier. Viennent ensuite l'expéditeur fiable assorti d'une signature personnelle ou de domaine, ou d'une signature DKIM ; un signataire JWS reconnu ; une conversation en cours avec un expéditeur reconnu ; enfin, un lien avec un message antérieur jugé fiable. Ce sont des alternatives proposées par un projet, pas sept validations successives.

Le même objet de réservation pourrait donc produire une commande dans un client et rester du texte dans un autre.

Le fil de discussion devient une pièce d'autorité

La condition fondée sur la conversation mérite un examen particulier. Un message nouveau peut hériter d'un contexte établi avant lui. Une boîte compromise ou un interlocuteur dont la relation a changé peut exploiter ce raccourci : l'application croit reconnaître la scène et lui accorde davantage d'interface. Le projet ne fournit aucun certificat universel de « bon expéditeur ». Il demande au logiciel de définir qui est digne de confiance et dans quelle situation.

La portée des signatures ajoute une seconde différence. DKIM signe le courriel ; JWS peut ne signer que l'objet structuré. Le projet laisse ouvertes les questions du JWS détaché et de la comparaison des octets avec une représentation JSON canonique. Quand le filtre antipourriel, le moteur HTML et le lecteur JSON interprètent différemment le même MIME, une signature valide peut coexister avec des descriptions contradictoires à l'écran. Le contrôle utile consiste à regarder l'action réellement proposée, ainsi que les représentations qui la justifient.

Les références extérieures prolongent cette chaîne. L'application peut charger une image ou une donnée au moment de l'affichage et révéler ainsi l'ouverture du courriel. La section 4.3 recommande des données autonomes lorsque l'interaction aurait autrement besoin d'une requête Web. La pièce manquante est un corpus d'essai public montrant le même message signé, sa réponse liée et une référence distante dans plusieurs clients, avec les contrôles affichés et les requêtes réseau. Ce test établirait où se trouve aujourd'hui la décision effective.

Historique du projet · Projet Structured Email · DKIM · JWS