Résumé

  • La version -01 du projet individuel « Wallet State Attestation » a été publiée le 27 septembre 2026 ; il ne s'agit ni d'une RFC, ni d'un texte adopté par un groupe de travail de l'IETF.
  • En JSON, la signature couvre quatre membres principaux, dont le résultat et l'heure d'observation. Elle ne désigne pas nécessairement le portefeuille interrogé ; expiresAt est un champ voisin non signé.
  • Le JWT facultatif signe sub et exp, mais sa présence à côté du JSON ne dispense pas le destinataire de vérifier ce second objet et leur concordance.

Le minuteur posé sur la table

Le texte révisé imagine un émetteur qui lit l'état public d'une chaîne pour une adresse, évalue des conditions choisies par l'opérateur et signe une réponse booléenne. Un tiers peut vérifier la signature hors ligne à l'aide de l'ensemble de clés publié. Ce tiers n'a pas besoin de recevoir le solde exact pour savoir qu'une condition a été satisfaite. La promesse est utile, mais elle n'efface pas la question de la durée pendant laquelle cette observation peut gouverner un accès.

Dans la réponse JSON, attestedAt et les références de bloc propres à chaque résultat sont inclus dans le périmètre signé. expiresAt, en revanche, est transmis à côté. Un destinataire qui accepte cette date sans contrôle permet qu'un indice de durée non protégé joue le rôle d'une limite cryptographique. Le projet conseille de la comparer à l'heure signée et à la fenêtre de validité publiée par l'émetteur. Une politique plus stricte peut refuser toute observation dont l'âge dépasse un seuil local, indépendamment de la date affichée. Cette politique appartient à celui qui décide, pas à la seule opération de vérification de signature.

La version -01 ne crée pas ce périmètre ; sa liste des changements indique que les signatures émises sous la version -00 restent vérifiables. Elle expose plus clairement les octets reconstruits, propose un deuxième schéma de signature JSON séparé par domaine et rassemble les vérifications dans une procédure à sept étapes. Les quatre premières étapes y sont requises : choix de la clé et du schéma, reconstruction, vérification de la signature et recalcul de conditionHash. La fraîcheur et l'expiration sont recommandées, non rendues universellement obligatoires. Présenter la date d'expiration comme une garantie appliquée partout serait donc plus affirmatif que le document.

Le portefeuille n'est pas toujours dans l'enveloppe

Le problème du temps accompagne celui du sujet. Le JSON signé a exactement quatre membres principaux : id, pass, results et attestedAt. L'adresse peut figurer à l'intérieur d'une condition évaluée, elle-même protégée dans results. Elle n'y figure toutefois pas par nécessité générale du format. Le demandeur initial connaît l'adresse qu'il a envoyée ; un second service qui reçoit seulement l'attestation peut ne pas la connaître. Une réponse authentique n'établit alors pas, à elle seule, quelle personne ou quel compte doit bénéficier du « oui ».

Le hachage de la condition ne résout pas magiquement cette absence. La version -01 exige que le vérificateur recalcule conditionHash et rejette une discordance. Cela protège la condition transmise contre une modification non détectée. Si cette condition ne porte pas l'adresse, sa parfaite intégrité ne crée pas le lien manquant. La séparation est importante : authenticité du résultat, rattachement au portefeuille et permission d'agir ne sont pas trois noms pour le même contrôle.

La sélection de clé a également été précisée. Un kid absent ou inconnu rend la signature invérifiable ; il n'autorise pas à essayer la première clé du JWKS. Une signature qui échoue sous la clé désignée est réfutée. Ces deux issues interdisent l'acceptation, mais elles appellent des diagnostics différents. Une copie ancienne des clés peut être rafraîchie avant un nouvel essai ; deviner une autre clé par commodité détruirait la traçabilité du choix.

Le JWT n'est pas un sceau apposé au JSON

Lorsque le client demande aussi le format JWT, le jeton comporte une signature distincte. Son sub désigne le portefeuille effectivement évalué ; exp rend l'expiration signée et son en-tête protégé couvre kid. Le projet demande au destinataire qui lit ces déclarations de vérifier le JWT lui-même. Si les deux formats arrivent ensemble, il prévoit en outre un contrôle de correspondance : un JWT invalide ou contradictoire fait rejeter la réponse. Il ne faut pas attribuer rétrospectivement au JSON les champs signés du jeton voisin.

Une preuve de Merkle facultative peut réduire la dépendance à l'évaluation de l'émetteur lorsque la chaîne et la condition s'y prêtent. Le texte reconnaît qu'elle n'est pas toujours disponible ; là où elle l'est, elle peut révéler un solde brut que la réponse booléenne cachait. Le choix de preuve change donc aussi la confidentialité. Aucun de ces choix ne dispense l'opérateur de savoir à quel portefeuille la décision se rapporte.

Le suivi de l'IETF classe ce document comme projet individuel actif, sans flux RFC et à l'état I-D Exists. Un dépôt d'Internet-Draft ne vaut pas approbation de l'IETF. Les références à des usages ou émetteurs de production contenues dans le texte de l'auteur ne constituent pas ici une vérification indépendante de déploiement. Le fait neuf est documentaire : une révision rend vérifiables les limites de son propre format, sans prouver qu'un système les respecte déjà.

Sources