Résumé

  • Le projet de charte du groupe Web Authentication ajoute à son périmètre la signature de données choisies par l’application, sous médiation WebAuthn et avec une clé distincte de la clé d’authentification.
  • L’IA agentique et les justificatifs numériques sont cités comme cas d’usage, mais l’accès de bas niveau aux clés privées et les API cryptographiques généralistes autonomes restent exclus.
  • Le dossier n’a pas atteint la maturité d’une norme : la charte est encore examinée, le niveau 4 n’a pas de FPWD, la modification sign reste un brouillon et son explainer ne rapporte ni recherche utilisateur ni signal des navigateurs.
  • Une fiche publique d’admission de la fonctionnalité doit relier autorité de la charte, version du projet, garanties de consentement, séparation des clés, format signé, examens, tests, implémentations indépendantes et adoption réelle.

La charte autorise une enquête, pas un résultat

La charte actuellement en vigueur donne au groupe une mission centrée sur l’authentification forte. Elle encadre les paires de clés liées à une origine, la preuve de possession, la récupération et la sauvegarde. Elle place hors périmètre l’accès de bas niveau aux opérations cryptographiques ou au matériau de clé.

Le texte proposé ajoute un pont. Son onzième point vise la signature d’autres données que celles de l’authentification WebAuthn classique. La clé de signature serait liée à une clé d’identification, mais différente d’elle. Le navigateur resterait médiateur. La formulation évoque des usages liés aux agents d’IA et aux écosystèmes de justificatifs vérifiables. Les deux points suivants abordent les signaux de confiance fournis par les gestionnaires d’identifiants et la confidentialité des extensions.

Cette modification est majeure au sens du Processus W3C. Elle doit donc passer par l’Advisory Committee et une décision du W3C. La consultation ouverte le 10 août se termine le 7 septembre à 23 h 59 UTC ; l’ancienne charte a été prolongée jusqu’au 30 octobre. Au moment de cette analyse, le nouveau mandat n’est pas adopté.

Même adopté, il ne ferait qu’établir que le groupe peut élaborer une telle fonction. Il ne transformerait pas une pull request en spécification, ne prouverait pas l’interopérabilité et n’imposerait rien à Chrome, Firefox, Safari ou Edge. La charte le montre elle-même : le niveau 4 est annoncé comme livrable normatif, mais aucun First Public Working Draft n’existe encore et l’échéance indicative est le quatrième trimestre 2028.

La signature prouve une opération, pas la compréhension du message

Une assertion WebAuthn ordinaire ne signe pas directement le défi fourni par le site. Elle signe une construction prescrite, qui associe les données de l’authenticator au condensat des données client. Le projet de signature brute vise autre chose : signer, sans le transformer, le contenu fourni par l’application.

Cette propriété permettrait d’utiliser une clé protégée par du matériel dans des protocoles dont les vérificateurs savent déjà contrôler une signature classique. Un portefeuille de justificatifs, un jeton d’autorisation ou un outil de signature logicielle pourrait ainsi rester sur le Web sans exposer la clé privée à JavaScript.

Le projet pose plusieurs digues. La clé de signature doit être cryptographiquement indépendante de la clé WebAuthn parente. Sinon, un site malveillant pourrait tenter de fabriquer une assertion d’authentification à l’aide de l’API générale. La liaison à l’origine doit éviter qu’une même clé serve d’identifiant de suivi entre sites. Les exigences de présence et de vérification de l’utilisateur sont fixées lors de la création. Le niveau exposé aux sites ne doit pas permettre la signature sans présence, même si la couche destinée aux clients natifs peut offrir ce mode.

Ces protections décrivent la cérémonie technique. Elles ne disent pas que la personne a compris le contenu.

L’explainer range explicitement la « transaction confirmation » parmi les non-objectifs. Il accepte que les données soient binaires et opaques, sans exiger qu’une interface fiable les affiche sous une forme intelligible avant la signature. Le signal de vérification peut donc attester que la politique de la clé a été satisfaite. Il ne suffit pas à démontrer qu’un utilisateur a lu un contrat, reconnu l’action préparée par un agent ou accepté la portée juridique attribuée ensuite au résultat.

Cette limite est honnêtement écrite. Le danger naît lorsqu’un produit la remplace par une formule plus ambitieuse. « Utilisateur vérifié », « message compris » et « agent autorisé à choisir ce message » sont trois affirmations différentes.

Les preuves publiques sont encore incomplètes

L’explainer indique qu’aucune recherche utilisateur n’a été menée. Son tableau ne rapporte aucun signal de Chrome, Firefox, Safari ou Edge. Il mentionne un avis favorable côté authenticator et un côté relying party. L’absence de signal n’est pas une opposition : c’est un état non résolu qui doit rester libellé comme tel.

La pull request 2078 est toujours marquée Draft et rattachée au jalon du premier Working Draft public du niveau 4. En septembre 2024, son auteur signalait des prototypes internes rudimentaires et aucune promesse d’implémentation des autres participants à cette date. Des échanges et expériences ultérieurs montrent un travail réel. Ils ne constituent pas, dans le dossier examiné, un rapport ouvert établissant deux implémentations indépendantes et interopérables.

Le Processus W3C donne précisément une succession d’états : décision de charte, proposition concrète, FPWD, examens horizontaux, tests ouverts, expérience d’implémentation, Candidate Recommendation, Recommandation, puis décisions de déploiement. Chaque étape répond à une question différente. Le périmètre dit qui a le droit de travailler ; le FPWD rend un texte standards-track visible ; les tests rendent les propriétés vérifiables ; les implémentations montrent l’interopérabilité ; la Recommandation consacre un texte ; l’adoption fait enfin tourner la fonction.

La distinction de Heng Lu entre publication et réalité opérationnelle s’applique ici de manière limitée. Il ne s’agit pas de transposer son diagnostic des RIR au W3C. Il s’agit de garder une discipline simple : un document qui ouvre une voie ne prouve pas que les systèmes l’ont validée et adoptée.

Une fiche d’admission, mise à jour à chaque seuil

Pour la signature brute, la fiche devrait commencer par la clause de charte et son statut. Elle pointerait ensuite vers la révision exacte de l’explainer et de la spécification. Elle préciserait ce qui est signé—message complet, condensat ou enveloppe—ainsi que l’algorithme et la séparation de domaine. Elle enregistrerait la relation entre clé parente et clé de signature, la liaison à l’origine, la politique de présence et de vérification, ce qui est affiché à l’utilisateur, la portée de l’attestation et les risques de corrélation.

La seconde moitié suivrait les preuves : positions des navigateurs, fabricants d’authenticators et relying parties ; questions des examens horizontaux et réponses ; couverture des tests ; implémentations indépendantes ; objections non résolues ; état W3C courant ; disponibilité effective.

Cette fiche ne publierait ni clés, ni identifiants d’appareil, ni données personnelles, ni détails exploitables. Elle ne créerait pas non plus un nouveau comité de validation. Ce serait un index versionné des pièces existantes.

Son intérêt principal est d’empêcher la réécriture. Si « aucun signal » devient un refus, la date et la source apparaissent. Si la confirmation de transaction entre dans les objectifs, l’ancienne limite reste visible. Si une fonctionnalité est retirée, son état terminal est clair. Une phrase de charte ne flotte plus indéfiniment comme si elle constituait une approbation de produit.

Sources

  1. W3C — appel à examen de la future charte Web Authentication
  2. Projet de charte du groupe Web Authentication
  3. Charte actuelle du groupe Web Authentication
  4. Recommandation Web Authentication niveau 3
  5. Explainer de l’extension de signature brute
  6. Pull request brouillon sign no 2078
  7. Processus W3C du 18 août 2025
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption