Résumé

  • La révision 01 de draft-schrock-ep-presentation-binding limite sa promesse : un rendu déterministe révèle un écart entre l’action signée et le rendu déclaré, mais ne prouve pas ce qu’un écran non fiable a affiché.
  • Le texte ordonne d’évaluer séparément le reçu et la preuve de présentation. La réussite de l’un ou de l’autre ne vaut pas, à elle seule, autorisation.
  • Daniel Kade propose une fiche de décision de présentation reliant ces preuves à l’identité enrôlée, au mandat humain, aux éléments de confiance et au risque résiduel. Cette proposition éditoriale n’est pas une exigence du projet.

Trois voyants verts, trois questions différentes

Le danger ne vient pas d’une signature invalide. Il apparaît précisément quand tout semble fonctionner. Le reçu porte sur le condensat d’une action; un moteur reconstruit une représentation lisible; le terminal signe une affirmation selon laquelle il a affiché cette représentation. Ces trois opérations peuvent être correctes sans démontrer que la personne a vu les mêmes pixels, ni qu’elle disposait du mandat nécessaire.

La révision 01, enregistrée le 12 septembre 2026, clarifie ce point. Le différentiel avec la version 00 abandonne l’idée qu’un vérificateur prouverait ce qui a été montré à l’être humain. Il ne peut établir que la cohérence entre les octets de l’action signée et un rendu soumis à vérification. Un client compromis peut fournir le rendu attendu au vérificateur tout en montrant autre chose à l’utilisateur.

Le changement de vocabulaire est tout aussi important : le reçu n’est plus présenté comme la production d’une « personne nommée », mais comme celle d’une clé enrôlée. La cryptographie connaît une clé. Le rattachement à une personne, l’actualité de son emploi, l’étendue de sa délégation et la validité de son consentement proviennent d’autres autorités.

Selon le Datatracker, il s’agit d’un Internet-Draft individuel actif, sans groupe de travail, filière IETF, responsable de domaine ni statut RFC visé. Sa publication n’est ni une adoption ni une approbation de l’IETF.

Le rendu reproductible constitue une preuve limitée

Le moteur proposé doit être une fonction pure d’une action canonique. Deux actions profondément identiques doivent produire exactement les mêmes octets, quel que soit l’environnement, la date ou la langue active du système. L’heure, le hasard, les entrées-sorties et les paramètres ambiants sont exclus. Le profil fixe l’ordre et la liste des champs matériels, puis calcule un condensat du rendu.

Cette rigueur ferme une faille réelle. Si l’action signée porte sur un virement de 82 000 unités mais que le rendu soumis en annonce une, la reconstruction échoue. Le recours à RFC 8785 fournit la base de canonicalisation JSON. Le texte impose aussi un traitement déterministe des caractères de contrôle, des inversions bidirectionnelles, des graphies trompeuses et des longueurs excessives. En cas d’impossibilité d’afficher sans ambiguïté, le moteur doit refuser.

Ce mécanisme ne regarde pourtant pas l’écran. L’attestation d’affichage reste une déclaration signée du client liant un condensat de rendu à celui de l’action. Vérifier la déclaration ne rend pas le client honnête. La nouvelle section 6.1 sépare donc expressément le résultat du reçu, celui de la présentation et l’autorisation finale; leurs bases de confiance doivent être choisies indépendamment.

Un chemin matériel doit lui aussi être qualifié

Le projet cite Android Protected Confirmation comme exemple possible, tout en précisant qu’il ne définit aucun profil Android. La documentation officielle de ConfirmationPrompt décrit un échange dans lequel le tiers de confiance contrôle la chaîne d’attestation de la clé, un nonce récent et le texte exact de l’invite. Elle avertit que le mécanisme exige un matériel dédié, n’est pas toujours disponible et peut échouer même sur un appareil compatible.

Une politique sérieuse ne peut donc se contenter de la mention « protégé par le matériel ». Elle doit conserver la racine approuvée, le contenu de l’attestation, le texte effectivement lié, les champs matériels absents de l’écran et le parcours de secours utilisé. L’indisponibilité n’est pas un détail : si le logiciel revient silencieusement à une boîte de dialogue ordinaire, le niveau de preuve change.

De même, l’existence annoncée d’une implémentation de référence et de vecteurs négatifs ne prouve ni un déploiement, ni un audit indépendant, ni la sûreté du chemin physique. La révision 01 ne demande aucune action à l’IANA; l’enregistrement d’identifiants est reporté.

Conserver la décision, pas seulement ses pièces

Daniel Kade propose une fiche de décision de présentation tenue par l’organisation qui supporte la conséquence. Elle associe le condensat de l’action et le résultat du reçu; le profil, la version et la langue du moteur; les champs matériels rendus; le condensat et le résultat de l’attestation d’affichage; l’identité du client et ses racines de confiance; la preuve reliant la clé à une personne; le rôle et la limite du mandat; le risque résiduel; la règle d’autorisation; l’issue, l’examinateur, la date, l’expiration et les déclencheurs de révision.

Ce registre ne cherche pas à imposer une décision mondiale. Une opération irréversible peut exiger un écran de confiance et une confirmation hors bande; une maintenance réversible peut accepter une combinaison plus légère. La preuve commune reste portable, tandis que le seuil et la conséquence sont attribués à l’autorité qui les assume.

Cette architecture rejoint la Spécification initiale minimale de Heng Lu : partager un noyau vérifiable sans centraliser les choix futurs. The Policy Mirror invite à préserver la portée exacte de chaque déclaration. Why BTW Media Exists impose enfin de distinguer l’événement observé—une correction substantielle d’un projet individuel—des conclusions d’adoption ou de sécurité qui ne sont pas établies.

Sources

  1. Fiche Datatracker du projet
  2. Historique du projet
  3. Métadonnées Datatracker
  4. Révision 01
  5. Révision 00
  6. Différentiel officiel
  7. Projet sur les reçus d’autorisation
  8. Révision 13 des reçus d’autorisation
  9. RFC 8785
  10. API Android ConfirmationPrompt
  11. Android Protected Confirmation
  12. Attestation de clé Android
  13. The Policy Mirror
  14. Minimum Initial Specification
  15. Why BTW Media Exists