Résumé

  • Le W3C a publié Web Authentication Level 3 comme Recommandation le 25 août 2026, avec un rapport d’implémentation figé au 26 juin.
  • Ce rapport annonce 53 tests et 415 sous-tests exécutés sur des versions nommées de Chrome, Firefox, Safari Preview et Edge, toutes reliées au même commit WPT.
  • Le dossier final dit qu’une partie de Chrome diffère d’Edge, sans préciser quelle partie. Une clé par fonctionnalité rendrait l’indépendance vérifiable sans imposer de formule automatique ni divulguer du code propriétaire.

Une photographie d’exécution particulièrement précise

La Recommandation Web Authentication: An API for accessing Public Key Credentials — Level 3 encadre la création et l’usage d’identifiants à clé publique, limités à une partie utilisatrice, par l’intermédiaire d’un agent utilisateur et d’un authentificateur. Sa version datée du 25 août recommande un large déploiement et indique qu’aucun changement substantiel n’est intervenu depuis le Candidate Recommendation Snapshot du 26 mai.

Son rapport d’implémentation a une qualité rare : il est figé. La page se présente comme une photographie au 26 juin et prévient qu’elle n’est plus maintenue. Le lecteur n’a donc pas à deviner si les résultats ont glissé depuis la décision. Le bandeau annonce 53 tests et 415 sous-tests dans le répertoire WebAuthn de web-platform-tests.

Le contexte d’exécution est également explicite. Chrome 151 et Firefox 154 alpha ont été testés sous Linux le 25 juin. Safari 246 Preview l’a été sous macOS le lendemain, Edge 151 sous Windows. Les quatre environnements citent le commit WPT d41367df1e. La matrice distingue ensuite PASS, FAIL, TIMEOUT, ERROR, NOTRUN et absence de résultat.

Voilà une excellente réponse à la question « quel comportement ce produit précis a-t-il rapporté face à cette révision précise des tests ? ». Mais le Processus du W3C pose aussi une question d’une autre nature : existe-t-il des implémentations indépendantes et interopérables ? Un nom de produit n’est pas, à lui seul, une généalogie technique.

Il serait tout aussi erroné de compter quatre marques que de rabattre systématiquement Chrome et Edge sur une seule implémentation. Un navigateur peut mobiliser son moteur, des services du système d’exploitation, un authentificateur de plateforme et des composants propres au fournisseur. La frontière pertinente peut changer selon la fonctionnalité. L’indépendance doit donc être qualifiée à un niveau donné, et non attribuée une fois pour toutes au logo placé en haut d’une colonne.

Une phrase qui reconnaît le problème sans le résoudre

Le dossier final de transition vers la Recommandation place deux liens sous la rubrique « Implementation » : les résultats WPT vivants et leur photographie fixe. Il ajoute aussitôt qu’une partie de l’implémentation de Chrome est différente de celle d’Edge.

Cette phrase a une vraie utilité. Elle interdit de conclure que les deux colonnes seraient nécessairement le même résultat habillé de deux noms. Elle reconnaît une différence technique. Pourtant, elle ne nomme ni la partie différente, ni la fonctionnalité concernée, ni le groupe de tests, ni la couche de composant. Elle ne renvoie pas non plus à la preuve qui justifie la qualification ou à la proposition de transition pour laquelle cette indépendance a compté.

Le compte rendu du 18 mars montre que la question a bien circulé dans le groupe. Sous le sujet « Testing », un participant évoque des différences techniques d’Edge par rapport au « Chrome normal ». La conversation demande ensuite si Microsoft Authenticator passe par Android ou iOS, puis décrit ces deux chemins comme deux implémentations de la couche WebAuthn pour une extension. Plus tard, le groupe atteint un consensus sans objection pour proposer la Recommandation après résolution des points pendants.

Il ne s’agit donc pas de reprocher au groupe de n’avoir jamais pensé aux couches d’implémentation. Le problème est celui de la compression documentaire. Une discussion attachée à une extension et à une couche devient, dans le reçu public final, « une partie » non localisée. La matrice et l’assurance sont toutes deux publiques, mais aucune clé ne les relie.

La décision, elle, est complète. Le fil de transition consigne l’approbation de l’Équipe le 17 juillet, la clôture de l’examen du Comité consultatif le 18 août avec consensus et sans objection formelle, l’autorisation de publier le 19 août, puis l’adresse de la Recommandation le 25. L’absence d’une clé publique ne permet ni d’annuler ces actes ni d’inférer que le W3C ne disposait pas d’autres éléments.

Le Processus ne transforme pas les navigateurs en bulletins de vote

La section 6.3.2 du Processus refuse justement une règle arithmétique universelle. L’expérience d’implémentation doit montrer que le texte est assez clair, complet et pertinent pour permettre des implémentations indépendantes et interopérables de chaque fonctionnalité. L’Équipe examine notamment la réalisation de chaque fonction, l’indépendance, le fait que des personnes autres que les auteurs aient implémenté le texte, le déploiement public, les différents étages de l’écosystème et les difficultés signalées.

Une cellule PASS répond à l’observation d’un comportement. Elle ne prouve pas simultanément l’indépendance des auteurs ou du chemin logiciel. Un système d’exploitation différent peut être décisif pour une fonction liée à la plateforme et insignifiant pour une autre. Le commit WPT commun rend les mesures comparables ; il ne décrit pas le code testé.

Les résultats hétérogènes ne constituent pas davantage un classement de sécurité. Un échec peut signaler une fonction absente, une divergence à étudier ou un test à revoir. Un délai dépassé ou une case manquante dit encore moins. Le passage en Recommandation n’exige pas que toutes les cases de tous les produits soient vertes, et cet article ne crée pas ce seuil.

Une clé d’indépendance par fonctionnalité

Le complément nécessaire peut rester léger. Pour chaque fonctionnalité ou groupe de tests retenu comme preuve, une ligne nommerait la version fixe de la spécification, le commit des tests, le produit et sa compilation, puis la couche d’implémentation pertinente. Elle formulerait une affirmation limitée d’indépendance et renverrait à une source publique ou à une attestation responsable lorsque l’architecture ne peut être détaillée.

La même ligne indiquerait le résultat d’interopérabilité et dirait s’il a été utilisé pour la transition. Si Chrome et Edge divergent pour une extension, la qualification resterait attachée à cette extension. S’ils empruntent le même chemin pertinent pour une autre fonction, deux colonnes ne deviendraient pas silencieusement deux implémentations. Firefox, Safari, Android, iOS, les authentificateurs et les logiciels de parties utilisatrices recevraient le même traitement fonction par fonction.

Cette clé n’est ni un audit de code source ni une nouvelle autorité d’approbation. L’Équipe du W3C conserve l’appréciation contextuelle que lui donne le Processus. Le registre sépare seulement trois propositions : lieu du test, comportement observé et raison pour laquelle l’implémentation est tenue pour indépendante dans un usage déterminé.

Lu Heng rappelle, dans Minimum Initial Specification, qu’une recommandation reste un artefact de coordination : l’implémentation, la validation, le déploiement et l’adoption demeurent des réalités distinctes. La même modestie s’applique au tableau. Une colonne prouve qu’un produit a été testé ; elle ne raconte pas d’elle-même l’implémentation qui se trouve dessous.

Sources