La charte DID du W3C doit reprendre l’état exact de la norme

Résumé

La charte DID de 2024 a ajouté DID Resolution aux livrables de la Recommendation Track. Elle a été prolongée jusqu’au 28 octobre 2026 : le travail d’août dispose donc d’une autorité en vigueur.
Le Candidate Recommendation Snapshot du 6 août est un Patent Review Draft. Il a ouvert une opportunité d’exclusion qui se termine le 5 octobre et fixe des critères d’implémentation par fonctionnalité ; il ne constitue ni une Recommendation ni une approbation du W3C.
Le W3C a lancé le 10 août l’affinement d’une charte de continuité. La version publique, y compris le commit de tête fusionné le 27 août, décrit encore DID Resolution comme un Working Draft, donne le 10 juillet comme dernière publication et renvoie au Draft d’exclusion de 2024.
L’historique officiel ajoute ensuite un Candidate Recommendation Draft daté du 28 août. Plus récent pour la lecture technique, ce Draft ne devient pas pour autant un nouveau texte de référence pour les exclusions de brevets.
Avant l’AC Review, une fiche de transmission devrait relier charte active, dernière version lisible, Snapshot de référence, fenêtre d’exclusion, fonctionnalité à risque et preuve d’implémentation datée. Cette fiche documenterait les états sans créer une couche d’autorisation supplémentaire.

Une norme, quatre réponses à la question « où en est-on ? »

La première réponse vient de la page d’historique des publications. Elle place un Candidate Recommendation Snapshot au 6 août, puis un Candidate Recommendation Draft au 28 août. Si l’on veut lire le travail intégré le plus récent, le second document est le bon point d’entrée.

La deuxième vient de la politique de brevets. Le Snapshot du 6 août est le Patent Review Draft qui a déclenché l’appel à exclusions. La date pertinente n’est alors pas celle du document le plus récent, mais la période du 6 août au 5 octobre et le corps de texte auquel elle s’applique.

La troisième réponse vient des essais. Le rapport public indique que ses tests ont été exécutés le 27 mars à 14 h 16 UTC. Il présente plusieurs implémentations et une matrice. Cette date ne se confond ni avec une date de publication ni avec une décision sur la maturité.

La quatrième réponse est institutionnelle. La charte adoptée en avril 2024 reste active jusqu’au 28 octobre. La charte suivante est en discussion publique ; elle n’a encore ni date d’effet ni décision d’adoption.

Ces quatre réponses ne se contredisent pas. Elles répondent à quatre questions. La confusion naît lorsque « dernier », « candidat », « testé » ou « autorisé » devient un résumé universel.

La bonne gouvernance ne consiste pas à soumettre les quatre horloges à une cinquième. Elle consiste à publier leurs correspondances.

La charte actuelle est la provenance, pas un vestige

La charte de 2024 ne sert pas seulement à expliquer l’organigramme du groupe. Elle a fait de DID Resolution un livrable de la filière Recommendation. C’est sous cette autorité, prolongée en avril 2026, que le groupe a atteint le Candidate Recommendation Snapshot.

La nouvelle charte n’a donc pas à valider rétrospectivement le travail. Elle n’est pas davantage déjà en vigueur parce qu’un projet existe sur GitHub. Le Process du W3C sépare l’affinement, l’examen par l’Advisory Committee, la décision et le futur Call for Participation.

L’issue 562 du dépôt Strategy qualifie le projet de recharte d’un groupe existant. Elle indique qu’il n’y a pas de changement substantiel et que le groupe a simplement besoin de plus de temps, le consensus sur DID Resolution ayant pris plus longtemps que prévu.

Une telle continuité semble administrativement simple. Elle exige pourtant une preuve plus précise qu’une réorientation complète. Si le périmètre ne change pas, il faut pouvoir montrer ce qui traverse la frontière : le livrable exact, la charte qui l’a autorisé, le Snapshot qui sert de référence de brevet, les changements intégrés depuis, les questions encore ouvertes et l’état des tests.

Autrement, « même mission, plus de temps » risque de devenir « même nom, mémoire approximative ».

Deux Candidate Recommendations, deux fonctions

Le vocabulaire du W3C demande une lecture attentive. Snapshot et Draft appartiennent tous deux à la phase Candidate Recommendation. Ils ne produisent pas le même effet documentaire.

Le Candidate Recommendation Snapshot du 6 août constitue un point stable. Le Process l’assimile au Patent Review Draft. Sa publication ouvre l’opportunité d’exclusion. La page IPR du groupe en donne aujourd’hui les deux bornes et conserve l’opportunité 2024–2025 dans l’historique.

Le Candidate Recommendation Draft du 28 août est une surface d’intégration. Son propre avis de statut explique qu’il incorpore des changements que le groupe entend proposer dans un futur Snapshot. Il peut être mis à jour, remplacé ou rendu obsolète. Pour la politique de brevets, il ne déclenche pas de nouvelle opportunité d’exclusion.

L’ordre chronologique ne suffit donc pas à déterminer la fonction :

le 28 août est le texte technique intégré le plus récent ;
le 6 août reste le Snapshot qui commande l’opportunité actuelle ;
le 5 octobre est la fin annoncée de cette opportunité ;
un prochain Snapshot ne peut être déduit d’un simple changement du Draft.

Ce découpage évite deux erreurs. La première ferait glisser le corps de référence juridique vers tout texte nouvellement publié. La seconde cacherait aux implémenteurs les changements présents dans le Draft au motif que le Snapshot est plus stable.

Une fiche de transmission doit conserver les deux liens et leur attribuer des rôles explicites. Un champ unique intitulé « dernière version » ne peut pas accomplir ce travail.

La page IPR montre que le mécanisme fonctionne

Dans le projet de charte, la ligne DID Resolution renvoie encore au Working Draft du 28 novembre 2024 comme Exclusion Draft et à la période terminée le 27 avril 2025. Prise isolément, cette ligne n’est plus à jour.

La surface spécialisée du W3C l’est. L’appel du 6 août fixe la fin de la nouvelle opportunité au 5 octobre. Il précise que les exclusions éventuelles portent sur ce qui n’était pas présent ou apparent dans le corps de référence précédent. La page IPR réunit le document, la possibilité de divulgation, l’opportunité actuelle et les précédentes.

Le constat n’est donc pas celui d’une procédure manquante. Le W3C a bien déclenché et publié le nouvel état. Il s’agit d’un défaut de raccordement dans un document en cours d’affinement.

Il faut aussi résister à une dramatisation facile. L’existence d’une fenêtre d’exclusion n’établit pas qu’un brevet gêne la spécification. La page indique qu’aucune divulgation de brevet n’a été faite pour les spécifications du groupe. Une procédure ouverte est une propriété du processus, non une accusation.

La nouvelle charte devrait simplement identifier le Snapshot de référence, les dates, le corps antérieur et le lien IPR. Si une autre opportunité apparaît, elle doit s’ajouter à la suite, sans réécrire la précédente.

Une matrice de tests n’est pas un tableau des médailles

Les critères de sortie du Snapshot sont volontairement plus fins qu’un nombre d’entreprises. Chaque fonctionnalité doit disposer d’au moins deux implémentations indépendantes et interopérables, vérifiées par des tests ouverts. Les énoncés normatifs testables par machine demandent deux implémentations conformes par fonctionnalité ; les autres, deux démonstrations. Les implémentations concernées doivent en outre prendre en charge au moins deux méthodes DID à spécification ouverte, chacune mise en œuvre de façon interopérable par plus d’un acteur.

Le rapport public nomme plusieurs implémenteurs. Cela ne transforme pas le nombre de colonnes en preuve automatique de tous les critères. L’unité de décision est la fonctionnalité, pas la marque située en haut de la matrice.

L’horodatage du 27 mars appelle une question légitime : quelle version du texte et de la suite de tests cette exécution démontre-t-elle ? Il ne justifie pas de conclure que les résultats sont caducs. Une fonction testée en mars peut être inchangée en août. Il ne justifie pas davantage de déclarer le passage acquis ou refusé à partir de quelques cellules visibles.

Le bordereau utile doit relier : version de spécification, commit de la suite, heure d’exécution, assertions normatives regroupées par fonctionnalité, deux preuves qualifiantes, base de l’indépendance, méthodes DID utilisées, éléments non testés et responsable de la mise à jour.

La séquence est importante. La proposition devient code, le code rencontre des vecteurs de test, l’interopérabilité est observée, puis le statut institutionnel décrit cette réalité. Le libellé ne doit pas fabriquer l’implémentation qu’il est censé constater.

« À risque » veut dire que la question reste gouvernée

Le Snapshot signale le déréférencement d’URL DID comme fonctionnalité à risque. Il avertit qu’elle pourrait être modifiée ou retirée et demande aux implémenteurs d’en évaluer l’utilité. Il prévient aussi que des issues ouvertes de classe 1, 2 ou 3 peuvent modifier le texte.

Ce marquage est une qualité de la phase Candidate Recommendation. Elle existe précisément pour confronter le projet à l’implémentation. « À risque » ne veut pas dire « échec ». Cela veut dire que le groupe a délimité une incertitude et nommé l’évidence attendue.

Le passage à une nouvelle charte ne doit ni effacer cette incertitude ni la figer. La fiche de transmission doit préserver l’identifiant de la fonctionnalité, l’issue, la preuve recherchée, le détenteur de la décision et le futur acte de résolution. Le résultat pourra être conservation, modification ou retrait.

Un état binaire—présent ou absent—perdrait la partie la plus utile de la gouvernance : la raison pour laquelle un élément demeure provisoire.

L’affinement est précisément le moment de corriger

Le document public porte le mot DRAFT. Ses dates de début et de fin sont encore des emplacements à compléter, ce qui n’est pas anormal : la date de début dépendra du Call for Participation après approbation. Le W3C a annoncé une phase d’affinement allant approximativement jusqu’au 15 septembre.

Le Process prévoit pendant cette phase la revue large, le traitement formel des issues et une décision de l’Équipe : lancer l’AC Review, prolonger l’affinement ou abandonner le projet. Il serait donc excessif de traiter une donnée ancienne comme la preuve que la charte est invalide. Un projet existe pour être corrigé.

Mais le projet définit lui-même le critère pertinent. Il dit que l’état du livrable doit être celui observé au moment de l’approbation. Or le commit de tête fusionné le 27 août conserve Working Draft, 10 juillet et le corps d’exclusion 2024, bien que le Snapshot du 6 août fût déjà publié. Le CR Draft du 28 août ajoute un état à réconcilier.

Il ne faut ni condamner le document comme final, ni attendre qu’il soit final pour constater que la donnée doit changer.

Un bordereau mince, pas un deuxième système de normes

Les pages spécialisées du W3C savent déjà publier les bons éléments. Il serait inutile de recopier toute la matrice de tests ou toute la politique de brevets dans la charte.

La couche commune peut rester courte :

Autorité

Charte actuelle, période d’effet, commit du projet successeur, état d’affinement et décision d’adoption lorsqu’elle existe.

Texte

Dernier rapport technique lisible et Snapshot de référence, dans deux champs distincts.

Brevets

Patent Review Draft, dates d’ouverture et de fermeture, corps précédent et page IPR.

Implémentation

Version du rapport, exécution, spécification testée, couverture par fonctionnalité, base de l’indépendance et points non résolus.

Revue

Fonctionnalité à risque, issues, revues horizontales, période de wide review et traitement des commentaires.

Garde

Responsable de chaque projection, voie de correction et événement qui remplace un état.

Ce registre peut être lisible par machine tout en restant affiché comme une petite table. Sa force ne vient pas d’un nouveau veto. Elle vient de l’identité stable et de la succession append-only.

Le sujet plus large de l’identité et de la gestion des accès fournit un repère thématique, pas une extension de mandat. La charte exclut les protocoles d’authentification et d’autorisation, les API de navigateur et l’ambition de « résoudre l’identité » sur le Web. W3C normalise un périmètre défini ; il ne certifie pas chaque produit IAM ni chaque méthode DID.

La nouvelle charte DID du W3C doit consigner l’état de la norme qu’elle reprend

Pourquoi c'est important