Résumé

  • Le dossier stratégique 568 du W3C a ouvert le 19 août 2026 un projet de nouvelle charte pour le Security Interest Group existant ; aucune date de fin de l’affinement n’est annoncée.
  • Le texte place le développement technique des normes hors mandat et prévoit le transfert des travaux de la voie Recommendation vers un Working Group, Community Group ou Business Group approprié.
  • Il demande néanmoins la présence d’implémenteurs de « cette spécification », d’éditeurs et de responsables des tests pour chaque spécification, puis évoque des Working Drafts et Editor’s Drafts élaborés publiquement.
  • Les deux livrables actuels cités dans la charte sont des Group Note Drafts : leur statut ne vaut ni approbation du W3C ou de ses membres, ni engagement de licence propre à la voie Recommendation.
  • Un reçu de livrable et de transfert devrait relier chaque rôle à une classe de document, un groupe propriétaire, un état de brevet et une acceptation explicite par le destinataire.

Deux vocabulaires d’autorité dans le même texte

Le Security Interest Group exerce une fonction horizontale identifiable. Il aide les groupes qui élaborent des normes à repérer et à atténuer les risques, examine des travaux et structure l’analyse des menaces. Sa charte actuelle court jusqu’au 18 novembre 2026. Le 19 août, le Strategy Funnel du W3C a ouvert le dossier 568 afin de renouveler ce mandat. Le dossier indique que la mission, le périmètre et les critères de réussite sont maintenus, tandis que les livrables renvoient désormais aux versions actuelles du modèle de menace et du guide de modélisation.

Le projet n’est manifestement pas achevé. Les dates de début et de fin sont encore des champs modèles. La phrase sur les téléconférences se termine par une formule provisoire. Le délai d’une demande de consensus est grammaticalement incomplet. Le tableau historique attribue à la charte initiale la même date de début et de fin, alors que la charte en vigueur couvre deux ans. Ces traces ne démontrent aucune mauvaise foi. Elles fixent le bon niveau de preuve : nous lisons un instrument en cours de correction.

La frontière de fond mérite toutefois d’être clarifiée dès maintenant. La rubrique Out of Scope exclut explicitement le développement technique des normes. Toute possibilité destinée à la voie Recommendation doit être remise à un Working Group approprié ou, si une incubation est nécessaire, à un Community Group ou à un Business Group.

Cette première grammaire parle donc de conseil, d’examen, d’incubation et de transfert.

La rubrique Participation en emploie une autre. Elle attend des représentants des principaux implémenteurs de « cette spécification », ainsi que des éditeurs et des responsables des tests actifs pour chaque spécification. Elle prévoit aussi une demi-journée hebdomadaire pour les présidents, éditeurs de spécification et responsables des tests. La rubrique Communication annonce que des Working Drafts et des Editor’s Drafts de spécifications seront développés dans des dépôts publics.

Le mot « spécification » n’est pas interdit à un Interest Group. Un tel groupe peut produire des documents techniques précis. L’ambiguïté naît lorsque le titre du rôle circule sans préciser la voie de publication, le propriétaire et l’état du transfert.

Une Note, un prototype et une Recommendation ne sont pas le même objet

La liste des livrables montre pourquoi une règle simpliste serait contre-productive. Le Security IG peut publier des analyses, des principes de sécurité, des modèles de menace, des lignes directrices et des spécifications prototypes compatibles avec son mandat. Un éditeur ou un responsable des tests peut apporter une contribution décisive à ces travaux sans que ceux-ci deviennent des Recommendations du W3C.

Les deux documents désormais reliés à la charte rendent cette différence vérifiable. Threat Model for the Web, daté du 21 juillet, est un W3C Group Note Draft. Threat Modeling Guide, daté du 23 juin, porte le même statut. Les deux pages disent que le Security IG approuve le document, mais pas le W3C ni ses membres. Elles le présentent comme un travail en cours sur la voie Note et indiquent qu’aucun engagement de licence n’en découle au titre de la Patent Policy.

Ce statut ne diminue pas leur utilité. Une Note peut fournir une méthode commune. Un prototype peut révéler la faisabilité d’une solution. Un examen horizontal peut identifier un risque. Aucun de ces actes n’emporte automatiquement la décision d’un Working Group sur le texte normatif.

Si tous ces objets sont seulement appelés « spécifications », le lecteur doit chercher ailleurs s’il consulte un avis, un prototype, un Group Note Draft, un Working Draft de la voie Recommendation ou le brouillon de travail d’un éditeur. Un même intitulé finit alors par porter des attentes incompatibles en matière d’autorité, d’approbation et de brevets.

Un transfert est un événement à deux faces

Le projet contient déjà le bon principe : les possibilités relevant de la voie Recommendation sont remises à un autre groupe. Mais la phrase « seront transférées » ne produit pas, à elle seule, un changement d’état public.

Le Security IG peut identifier un problème, décrire la menace et proposer un destinataire. Le groupe destinataire doit encore décider si le sujet entre dans sa charte, s’il faut une incubation, quel document il assumera, quel régime de brevet s’applique et s’il dispose d’éditeurs, d’implémenteurs et de tests. Le silence n’est pas une acceptation. Un lien entre dépôts n’est pas une adoption. La présence d’un même éditeur dans deux groupes ne transfère pas l’autorité institutionnelle.

Cette précision est particulièrement importante pour l’examen horizontal. Le guide du W3C explique que les groupes horizontaux apportent leur expertise aux propositions, spécifications et chartes élaborées ailleurs. Leur capacité de contrôle intellectuel dépend en partie de la distinction avec la propriété du document. Le Security IG peut demander qu’un risque soit traité ; le groupe propriétaire doit décider de la modification normative et rendre visible la suite donnée.

Sans trace de cette jonction, un conseil non retenu peut sembler n’avoir jamais été reçu. Un prototype peut continuer à évoluer parallèlement au texte repris par le Working Group. Deux documents portant le même nom fonctionnel peuvent alors présenter des états d’approbation et de brevet différents.

L’affinement offre une fenêtre de réparation propre

Puisque le projet est ouvert et que la fin de l’affinement reste inconnue, trois corrections modestes suffiraient à lever l’essentiel de l’ambiguïté.

La rubrique Participation devrait d’abord nommer les classes de livrables. Si les éditeurs et responsables des tests entretiennent des Group Notes, questionnaires, modèles de menace ou prototypes du Security IG, la charte devrait le dire. Si les implémenteurs participent à l’examen de spécifications détenues par d’autres groupes, leur contribution relève de la preuve d’examen, non d’un pouvoir d’édition implicite.

La rubrique Communication devrait ensuite séparer les brouillons produits par le Security IG des spécifications seulement examinées par lui. Dans l’écosystème du W3C, Working Draft n’est pas une expression neutre. Le texte doit associer chaque brouillon à sa voie et à son groupe propriétaire.

Enfin, la clause de transfert devrait désigner un registre de réception : proposition source, destinataire, date, décision et propriétaire actuel. Si le destinataire refuse ou ne possède pas le mandat nécessaire, l’état doit rester ouvert plutôt que de laisser le document du Security IG acquérir une autorité par défaut.

Un reçu de livrable et de transfert

Le registre public nécessaire peut rester léger. Pour chaque travail durable ou possibilité transférée, il devrait consigner :

  • un identifiant stable et la révision exacte du document ;
  • la classe du livrable : examen, questionnaire, Group Note Draft, prototype, rapport d’incubation ou document de la voie Recommendation ;
  • le groupe propriétaire et la clause de charte qui autorise le travail ;
  • les éditeurs, responsables des tests et implémenteurs, avec la portée de leur rôle ;
  • les états actuels d’approbation, de publication et de brevet ;
  • la spécification examinée et la recommandation de sécurité concernée ;
  • le déclencheur, le destinataire et la date du transfert ;
  • l’acceptation, le refus, le report ou la demande d’incubation du destinataire ;
  • l’identité du nouveau document et du nouveau propriétaire en cas d’acceptation ;
  • l’historique des corrections, remplacements et clôtures.

Il ne s’agit pas d’ajouter une instance d’autorisation. La discipline de Minimum Initial Specification décrite par Heng Lu demande au contraire de limiter la couche commune aux informations nécessaires pour ne pas confondre validation, adoption et déclaration. Ici, le reçu n’a pas à décider si une idée de sécurité est bonne. Il doit empêcher qu’une classe de document ou un rôle se fasse passer silencieusement pour un autre.

Le Security IG doit pouvoir publier des avis solides, maintenir des Notes précises et construire des prototypes utiles sans être pris pour un Working Group de la voie Recommendation. Un Working Group doit pouvoir reprendre ce travail sans effacer son origine. La clause Out of Scope énonce déjà la frontière constitutionnelle ; l’affinement doit faire en sorte que chaque rôle d’éditeur, de test et chaque titre de brouillon la respecte.

Sources

  1. W3C Strategy — dossier 568 sur la charte du Security Interest Group
  2. W3C — projet 2026 de charte du Security Interest Group
  3. W3C — charte 2024–2026 en vigueur
  4. W3C — comparaison avec la charte en vigueur
  5. W3C — Threat Model for the Web
  6. W3C — Threat Modeling Guide
  7. W3C — Process Document
  8. W3C — page du Security Interest Group
  9. Guide du W3C — Horizontal Groups
  10. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption