Résumé

  • Le 24 septembre 2026, le groupe Verifiable Credentials du W3C a publié le premier projet d'une note distincte sur les menaces du modèle de données v2.1. Le projet de modèle du 20 septembre en donnait déjà un résumé non normatif.
  • Les 25 menaces sont réparties entre cible de la spécification, réalisation logicielle, déploiement, risques externes et dépendances. Cette répartition ne vaut ni audit ni classement de gravité.
  • Une signature valide peut accompagner une mauvaise identification initiale, un contenu dangereux à afficher ou un usage inadapté. La note est un projet non approuvé, pas une recommandation ni une certification.

Le premier maillon ne ressemble pas à un problème de cryptographie. Une personne trompe l'organisme émetteur au moment où celui-ci établit son identité. L'organisme délivre alors un justificatif authentique qui désigne la mauvaise personne. Plus tard, le portefeuille le présente, la signature est correcte et toutes les vérifications techniques réussissent. La menace T25 de la nouvelle note du W3C décrit précisément cette rupture entre l'identification réelle et la validité ultérieure du document. Aucun vérificateur ne peut déduire d'une signature seule la qualité de l'entretien ou des pièces examinées au départ.

Cette note, publiée le 24 septembre comme Group Note Draft, donne davantage de corps à une liste qui figurait déjà dans l'annexe non normative du projet Verifiable Credentials Data Model v2.1 daté du 20 septembre. Elle explique les scénarios, les réponses envisagées et les composants concernés. Son apport public n'est donc pas d'avoir découvert cette semaine toutes les menaces. Il est de rendre visibles les lieux où une réponse doit être décidée. L'émetteur fixe la rigueur du contrôle d'identité; le vérificateur apprécie le niveau d'assurance avant de se fier au justificatif.

La répartition est éclairante si on la lit avec prudence : deux menaces visées par la spécification, sept relevant de la mise en œuvre, onze du déploiement, quatre externes et une liée aux dépendances. On ne peut pas transformer ces nombres en taux d'incident. Surtout, « visée » ne signifie pas « résolue ». La mauvaise identification est classée parmi les menaces cibles, alors que son analyse reconnaît que le modèle de données ne peut imposer à l'émetteur sa procédure d'identification. Le dictionnaire du document qualifie encore certaines définitions de points de départ à revoir.

La menace T1 ajoute une deuxième séparation. Une modification de données protégées peut être détectée en vérifiant le mécanisme de sécurité. En revanche, si un attaquant supprime entièrement la preuve, la cryptographie n'a plus rien à contrôler. Il faut une règle du vérificateur exigeant cette preuve lorsque la décision réclame une affirmation attribuable à l'émetteur. Cela n'interdit pas tous les justificatifs dépourvus de preuve : le modèle admet des déclarations de la personne elle-même ou des données intermédiaires. Leur origine ne doit simplement pas être présentée comme authentifiée par un émetteur.

Autre angle mort : la menace T2 concerne le code incorporé dans un contenu que la signature protège effectivement. L'intégrité du contenu ne rend pas son affichage sûr dans une application ou un portefeuille. Le traitement des données non fiables, l'encodage ou l'isolation sont des choix des équipes logicielles. La menace T24, elle, apparaît au moment de décider : signature et statut valides ne disent pas si l'émetteur et la nature des affirmations conviennent à l'usage précis envisagé. Cette adéquation relève de la politique du vérificateur.

Une grille de responsabilité pourrait associer à chaque risque un acteur, le moment de décision, la mesure retenue et la preuve de son fonctionnement. C'est une proposition éditoriale, non un formulaire prescrit par le W3C. Elle servirait à demander qui répond de l'identification, qui sécurise l'affichage, et qui refuse un justificatif authentique mais impropre au contexte. La note mentionne également les fuites possibles lors de consultations de statut; le présent dossier ne reprend pas le débat distinct sur le pointeur abrégé et statusPurpose de Bitstring v1.1.

Enfin, les statuts des textes ne sont pas interchangeables. Le modèle v2.0 est une recommandation W3C depuis mai 2025. Le modèle v2.1 de septembre est un Working Draft; son analyse séparée est un Group Note Draft non approuvé. Leurs listes ne prouvent l'efficacité d'aucun produit et ne constatent aucun incident chez un opérateur nommé. Elles donnent aux acteurs une question vérifiable à poser, pas une attestation déjà remplie.

Sources