Résumé

  • L’extension remoteClientDataJSON est désactivée par défaut et soumise à une autorisation par origine. Cette autorisation ouvre une capacité locale ; elle n’atteste pas la validation de l’origine distante et du RP ID.
  • Un déploiement devrait conserver un reçu interclients lié au hachage exact des données, sans obliger le navigateur local à reproduire toute la validation qui appartient au client distant.

La nouveauté la plus lourde de conséquences dans le First Public Working Draft de Web Authentication Level 4, publié le 15 septembre 2026, tient moins à la cryptographie qu’au déplacement d’une décision.

Dans le parcours WebAuthn habituel, le navigateur connaît l’origine de la page qui l’appelle. Le RP ID doit normalement être le domaine effectif de cette origine ou l’un de ses suffixes de domaine enregistrables, sous réserve de la procédure spécifique aux origines apparentées. Le navigateur fabrique clientDataJSON, l’authentificateur signe son empreinte et le serveur du relying party vérifie notamment le type de cérémonie, le challenge, l’origine attendue et l’empreinte du RP ID.

Un bureau distant sur le Web sépare ces éléments. Le site qui réclame l’authentification s’exécute sur l’hôte distant, tandis que l’authentificateur se trouve sur le terminal local. Si le navigateur local reconstruit les données à partir de son propre contexte, il inscrit l’origine du client Web de bureau distant, et non celle du site ouvert dans la session distante. Même deux objets JSON de sens identique peuvent avoir des octets différents à cause de l’ordre des champs, d’un champ facultatif ou d’espaces, ce qui suffit à faire diverger le hachage.

remoteClientDataJSON répond à ce problème en permettant au client de bureau distant autorisé de fournir la chaîne complète calculée sur l’hôte distant. Le navigateur local l’analyse, mais ne doit rien y ajouter, supprimer ou modifier. Au moment de sérialiser les données client, il reprend exactement cette chaîne afin que l’authentificateur signe les octets qu’attend la machine distante.

Le projet n’en fait pas une dérogation ouverte. La fonction publickey-credentials-remote-client-data-json est à la fois une fonctionnalité puissante et une fonctionnalité contrôlée par Permissions Policy. Son état de permission par défaut est denied et sa liste d’autorisation par défaut est indiquée comme 'none'. La configuration doit être limitée à une origine ; un bouton autorisant toutes les origines est interdit. Le texte privilégie une politique administrée ou un choix explicite par origine dans les réglages du client, plutôt qu’une sollicitation improvisée au milieu de la cérémonie.

Ces défenses répondent à une question locale : cette origine appelante a-t-elle le droit d’utiliser l’extension ? Elles ne répondent pas à la question distante : le client distant a-t-il présenté l’origine réelle du RP et appliqué correctement les règles liant cette origine au RP ID ?

L’algorithme marque clairement la frontière. Il rejette l’opération si la permission n’est pas granted, exige un RP ID explicite et analyse la chaîne JSON fournie. Il saute ensuite le contrôle habituel entre le RP ID et la valeur origin issue de ces données. Le projet précise que tous les contrôles d’origine liés au RP ID sont délégués au client distant. Dans ses considérations de sécurité, il ajoute qu’un user agent accordant la permission doit faire confiance à l’appelant pour fournir honnêtement l’origine distante, et au client distant pour valider le RP ID de manière exacte.

Le résultat booléen de l’extension ne change pas cette répartition. true signifie seulement que l’extension a été prise en compte. Il ne nomme pas la session distante, ne donne ni la version de la politique ni le résultat de l’algorithme, et n’apporte aucune pièce relative aux origines apparentées. La conservation parfaite des octets est tout aussi précise dans sa portée : elle prouve que le navigateur local n’a pas recomposé les données, pas que l’affirmation d’origine contenue dans ces données était vraie et autorisée.

La signature de l’authentificateur lie le résultat à l’empreinte des données client et aux données de l’authentificateur. Le RP reste tenu de vérifier le type, le challenge et l’origine, puis de comparer rpIdHash au RP ID attendu. Ces contrôles sont indispensables. Ils ne conservent toutefois pas nécessairement l’identité du client distant qui a pris la décision déléguée, la version de politique utilisée ni le canal distant auquel l’opération locale était rattachée.

Il ne s’agit pas d’un constat de faille, d’exploitation ou d’incident. Level 4 n’est à ce stade qu’un premier projet public : ni Recommandation W3C, ni preuve d’implémentation ou de déploiement. Son statut affirme que la publication ne vaut pas approbation et que le document peut encore être modifié, remplacé ou abandonné. Une issue ouverte du dépôt W3C WebAuthn suit aussi une dépendance de vocabulaire : l’intention « désactivé par défaut » est explicite, mais le terme normatif 'none' n’était pas encore défini dans le projet Permissions Policy dont dépend le texte. L’issue ne réclame aucun changement de comportement.

La bonne correction de gouvernance n’est donc pas de supprimer la délégation. Le côté distant possède des informations que le navigateur local n’a pas forcément : document d’origines apparentées, association avec une application native, modèle de déploiement propre à la plateforme. Imposer au navigateur local de refaire l’ensemble de cette analyse créerait deux validateurs susceptibles d’évoluer différemment.

Il faut plutôt produire, au point de passage, un reçu de validation interclients. Ce reçu devrait relier l’origine appelante locale et la permission — sujet, source, version et échéance — à l’identifiant de session distante et au canal authentifié. Il devrait enregistrer l’origine distante déclarée, le RP ID, l’algorithme et sa version, le résultat, ainsi que les références aux preuves d’origine apparentée ou d’association applicative. Une empreinte des octets exacts de remoteClientDataJSON relierait cette décision à ce qui a été signé, puis le résultat de la validation du serveur RP fermerait la chaîne. Exceptions, révocations et corrections seraient ajoutées à l’historique au lieu d’effacer la décision initiale.

Ce reçu est un contrôle de déploiement proposé, non une exigence que cet article attribue à WebAuthn. Il sert à garder séparées cinq réalités : la capacité locale a été autorisée, la validation distante a été exécutée, les octets ont été conservés, l’utilisateur a interagi avec un authentificateur et le RP a accepté ou refusé le résultat. Un voyant vert unique ne prouve pas l’ensemble.

Sources