Résumé

  • Publié le 24 septembre, Bitstring Status List v1.1 est un premier projet public, tandis que la version 1.0 demeure une recommandation du W3C.
  • L’entrée « terse » ajoute une URL de base et un index sur 32 bits ; le motif de l’état est fourni séparément par le vérificateur lors de la reconstitution.
  • La taille théorique d’une liste ne garantit ni l’anonymat d’un petit groupe réel ni la fraîcheur d’un résultat.

Que gagne-t-on à retirer des champs d’un justificatif ? Des octets, certainement. Pas la réponse à la question « qui décide que ce justificatif n’est plus valable ? ». C’est l’intérêt politique du premier projet public de Bitstring Status List v1.1, présenté par le groupe de travail du W3C sur les justificatifs vérifiables le 24 septembre. Le projet introduit TerseBitstringStatusListEntry, une référence condensée aux informations d’état, pensée notamment pour les supports où la place manque.

Le dispositif de listes partagées n’est pas une invention de cette version. La spécification 1.0 a été adoptée comme recommandation en mai 2025. Elle prévoit déjà des listes signées regroupant de nombreux états, pour éviter qu’une consultation individuelle ne révèle à l’émetteur quand et auprès de qui un titulaire présente son justificatif. Le nouveau texte est un projet sur la voie des recommandations, non une nouvelle norme approuvée ; il peut encore être modifié.

La modification identifiable tient à la forme de l’adresse. L’entrée condensée contient terseStatusListBaseUrl et terseStatusListIndex, index entier représentable sur 32 bits. Le projet impose, pour sa conversion, une longueur de 2²⁶ entrées par liste et 2⁶ positions de listes possibles. Il s’agit d’un espace calculé, pas d’un constat selon lequel 64 listes fonctionneraient déjà. Le quotient de l’index désigne la liste ; son reste désigne la case à lire. L’adresse complète ajoute ensuite le motif de l’état entre l’URL de base et le numéro de liste.

Or ce motif, statusPurpose, ne figure pas dans l’entrée abrégée. Le vérificateur doit le donner à l’algorithme. Le projet souligne aussi que c’est normalement l’entrée abrégée qui porte la signature numérique et que sa vérification devrait précéder la conversion. Un logiciel qui calcule le bon quotient mais demande le mauvais motif n’a donc pas réglé la question de confiance. Il faut une règle de l’écosystème ou de l’application indiquant quel état est pertinent pour la décision considérée.

La liste récupérée doit encore avoir des preuves valides. Le titulaire peut joindre une liste signée à sa présentation pour éviter une interrogation directe du serveur, tandis que le vérificateur peut préférer une version plus récente. Le ttl facultatif sert au rythme de rafraîchissement ; il ne prolonge pas la période de validité. Enfin, les nombreuses cases prévues ne remplacent pas une population réelle suffisamment nombreuse : le texte avertit qu’un faible nombre de justificatifs émis peut faciliter la corrélation malgré la longueur de la liste.

Sources