Résumé

  • draft-ietf-oauth-status-list-21 place dans chaque Referenced Token une URI et un index vers une liste comprimée. Un Status List Token protégé peut porter, pour beaucoup de jetons, les valeurs VALID, INVALID, SUSPENDED ou des valeurs propres à une application. La révision 21 est un Internet-Draft approuvé dans la file du RFC Editor, pas encore un RFC.
  • Par défaut, la valeur décrit l’état au moment où la liste protégée a été émise. iat, exp et ttl encadrent émission, validité et cache ; ils ne donnent pas automatiquement l’heure de la transition, son auteur, sa cause, sa première mise à disposition ni la décision du relying party.
  • Daniel Kade propose un reçu minimal hors protocole : empreintes du justificatif et de la liste, URI/index, validation de l’émetteur, quatre horloges distinctes, sens décodé, règle locale de fraîcheur, décision et éventuelle correction. Ce n’est pas une exigence de l’IETF ni une invitation à profiler toutes les présentations.

Le dossier arrive en appel. Il contient le statut final, mais pas l’objet signé qui le portait. L’équipe sait qu’une liste a été consultée ; elle ignore si la réponse venait du cache, si ce cache respectait la politique du service, ou si le bit était déjà différent au moment de la contestation. La liste disponible aujourd’hui ne peut pas servir de photographie de ce qui a été vu hier.

Ce manque ne démontre aucune erreur de l’émetteur. Il révèle une confusion de fonction. Une Token Status List est un moyen économique d’affirmer l’état de nombreux jetons sans demander une réponse individualisée pour chacun. Ce choix réduit le trafic et peut empêcher l’émetteur de savoir quel justificatif précis intéresse le vérificateur. Il ne prétend pas devenir le journal causal de chaque révocation.

La gouvernance commence par respecter cette frontière. Elle conserve à part ce dont une décision durable aura besoin, tout en laissant au mécanisme son format compact et sa protection de la vie privée.

Une spécification approuvée qui attend encore son RFC

La fiche Datatracker présente la révision 21 du 21 juin 2026 comme un Internet-Draft Standards Track du groupe OAuth. L’historique enregistre l’approbation de la révision 20 par l’IESG le 4 juin, son entrée dans la file du RFC Editor, la publication de la révision 21 le 21 juin, puis l’état Awaiting First editor du RFC Production Center le 13 août. Le texte est donc approuvé et avancé ; il n’est pas encore un RFC.

La révision 21 annonce une expiration au 23 décembre 2026. Le diff officiel 20→21 fixe le bon périmètre de version. La progression institutionnelle ne mesure ni adoption sur le terrain ni qualité d’un déploiement particulier. Le groupe OAuth produit la spécification ; il n’exploite pas les services imaginaires de cet article.

Le projet couvre des jetons protégés par JOSE ou COSE, notamment JWT, SD-JWT, CWT et certains usages d’ISO mdoc. JWS et JWT donnent la base JSON ; CWT et COSE apportent les formes CBOR. La liste est un objet séparé qui parle d’un Referenced Token après son émission.

L’URI et l’index conduisent à une valeur, pas à un événement

Le Referenced Token porte un champ status. Pour le mécanisme de liste, le membre status_list fournit uri, l’adresse du Status List Token, et idx, entier non négatif désignant l’entrée à lire. Cette paire est un localisateur stable, non une raison de révocation.

Le Status Issuer choisit un, deux, quatre ou huit bits par jeton. Il attribue un index distinct, range les valeurs dans des octets en allant du bit de poids faible vers le bit de poids fort, puis comprime le tableau avec DEFLATE au format ZLIB. Les RFC 1951 et 1950 définissent ces briques. La structure comprimée est intégrée dans un JWT ou un CWT protégé par signature ou MAC.

Trois fonctions entourent cet objet. L’Issuer produit le Referenced Token. Le Status Issuer reçoit l’information d’état et signe ou authentifie la liste. Le Status Provider sert le résultat. Une même organisation peut tout faire, mais le projet autorise aussi un hébergement tiers. La protection cryptographique permet alors de distinguer l’autorité sur les octets de l’infrastructure qui les distribue.

Cette distinction interdit un raccourci fréquent. La signature atteste l’origine et l’intégrité de la liste ; l’horodatage de la réponse HTTP atteste une observation de livraison. Ni l’un ni l’autre ne révèle à lui seul l’instant où un compte a été fermé ou où une suspension a été autorisée. Même sous un seul logo, la décision d’état, l’émission de la liste et sa distribution restent des opérations différentes.

Le registre initial donne des sens précis : 0x00 pour VALID, 0x01 pour INVALID, 0x02 pour SUSPENDED, plus des plages réservées à l’application et à de futurs enregistrements. Si plusieurs bits sont affectés à un jeton, leur ensemble code une seule valeur. On ne peut donc pas lire deux états simultanés dans le même emplacement.

Surtout, le statut n’annule pas les règles du Referenced Token. Un jeton expiré reste expiré même si son entrée indique VALID. La signature du justificatif, ses claims obligatoires et ses limites sont contrôlés avant la liste. Après le décodage, le relying party applique encore ses restrictions et sa politique. Le bit contribue à une décision ; il ne la remplace pas.

Quatre dates demandent quatre noms

La première date appartient au système source. C’est l’instant où la situation administrative ou réelle a changé : révocation, suspension, rétablissement. La révision 21 ne normalise pas le workflow qui a produit cet événement. L’entrée compacte n’en porte ni l’acteur, ni la justification, ni forcément l’heure.

La deuxième date est celle de l’émission de la liste. iat est obligatoire. exp, recommandé, dit après quel instant le Status Issuer ne veut plus que la liste soit tenue pour valide. Ces claims protègent le périmètre temporel de l’affirmation ; ils ne transforment pas iat en heure de révocation.

La troisième date est celle de la distribution et de la récupération. Un Status Provider ou un CDN peut remettre une copie émise plus tôt. Le relying party observe cette copie à l’heure de sa requête. Cette observation est utile, mais différente du temps source comme du temps d’émission.

La quatrième date est celle de la décision. Une file d’attente, un traitement différé ou une révision manuelle peut la décaler. C’est à ce moment que la politique locale juge la fraîcheur suffisante et associe une conséquence au statut.

Le claim ttl relie émission et cache sans les confondre. Il indique combien de secondes le consommateur peut conserver la liste avant de devoir rechercher une version fraîche. Le projet décrit deux pratiques. Compter depuis la récupération répartit la charge ; viser iat + ttl donne une vue plus fraîche pour les cas critiques, avec un petit délai de distribution. Si les en-têtes HTTP et les claims protégés divergent, exp et ttl de la liste l’emportent. RFC 9110 fournit les sémantiques HTTP, mais la décision de fraîcheur reste au profil et au relying party.

Des bornes sont indispensables. Une valeur trop longue peut laisser vieillir l’information ; une valeur trop courte peut provoquer un volume de requêtes déraisonnable et concentrer une charge sur le Provider. Le document avertit qu’un émetteur pourrait même, par erreur ou malveillance, pousser les clients vers un effet de déni de service. La fraîcheur ne se résume donc pas à « respecter le TTL » : elle associe besoin, capacité, limites et conséquence.

Demander le passé ne crée pas une chronologie causale

Le fonctionnement par défaut donne l’état le plus récent. Une extension optionnelle permet d’ajouter time=<timestamp> à la requête. Un serveur compatible peut rendre un Status List Token valable à cet instant ou signaler une erreur. Si un hébergement statique ignore le paramètre et renvoie la liste actuelle, le client doit rejeter la réponse lorsque la date demandée n’entre pas dans la fenêtre iat/exp protégée.

Ce mécanisme peut reconstituer une série de photographies authentifiées. Il ne garantit pas le procès-verbal de l’événement. Deux listes successives peuvent montrer qu’un changement s’est produit entre deux émissions sans dire à quelle seconde, sur ordre de qui ou à partir de quelle preuve. Si l’écosystème possède ces données, elles résident dans un système amont qu’il faut relier explicitement.

Le document recommande de ne pas proposer l’historique sans raison forte. Un relying party qui conserve URI et index et interroge régulièrement peut profiler la vie du justificatif. Un observateur extérieur peut télécharger les listes et estimer volumes ou taux de révocation. Une fonction d’audit utile peut donc devenir une surface de surveillance si elle est activée partout et conservée sans limite.

La confidentialité du troupeau a des bords visibles

Rassembler de nombreux jetons dans la même liste crée ce que le projet appelle la « herd privacy ». L’émetteur voit une demande de liste, pas nécessairement le jeton précis qui l’a motivée. Une liste plus grande augmente l’ensemble d’anonymat, au prix d’un transfert supérieur.

Cette protection n’efface pas les métadonnées. L’adresse du demandeur peut rester visible. Une URI unique par jeton, une liste minuscule ou une taille distinctive réduit le troupeau. Le couple URI/index est lui-même traçable, et plusieurs relying parties qui coopèrent peuvent reconnaître le même justificatif. Le contexte de divulgation sélective est décrit par le RFC 9901 ; le RFC 9458 définit Oblivious HTTP, cité comme exemple de relais masquant le demandeur.

Les réponses possibles sont plurielles : hébergement tiers, indices pseudo-aléatoires, entrées leurres, plusieurs listes, lots à usage unique et nouvelle entrée lors de la réémission. Les états riches posent aussi problème. SUSPENDED révèle davantage qu’un couple binaire valide/invalide ; une valeur métier peut dévoiler encore plus. Le bénéfice opérationnel doit être comparé au risque de profilage.

Un reçu de décision doit respecter la même retenue. Garder l’empreinte du justificatif et de la liste peut suffire ; archiver l’intégralité du credential, l’adresse IP et chaque présentation ne le fait pas. Une requête historique n’est enregistrée que si elle a réellement servi à la décision.

Le décodage fait partie de la preuve

La petitesse d’une valeur n’empêche pas l’erreur. Le projet insiste sur l’ordre des bits, du poids faible au poids fort, et sur l’ordre naturel des octets. Décompresser le mauvais flux, calculer le mauvais emplacement ou tolérer un index hors limites change le sens. Des vecteurs de test accompagnent la spécification.

L’ordre de validation doit rester visible dans le dossier : contrôler d’abord le Referenced Token ; récupérer ensuite la bonne URI ; vérifier type, signature ou MAC et claims de la liste ; confirmer la liaison entre son sujet et l’URI ; appliquer expiration, TTL et politique locale ; décompresser ; lire l’index ; interpréter la valeur enregistrée ; enfin décider.

Un index hors limites signifie qu’aucune affirmation de statut ne peut être faite, et le Referenced Token doit être rejeté. Un échec de validation de la liste mène également à « aucune affirmation », avec une recommandation de rejet. Cette situation n’est pas synonyme d’INVALID. L’une affirme un état ; l’autre constate l’absence de preuve utilisable.

Un reçu réduit, extérieur au protocole

Pour une conséquence durable, Daniel Kade propose un reçu portant deux empreintes et quatre temps. Il conserve un hash ou identifiant minimal du Referenced Token et l’empreinte exacte du Status List Token consulté. Il note URI/index, Status Issuer, Provider observé, résolution de clé, résultat cryptographique et version du décodeur pertinente.

Le temps de transition source est enregistré seulement s’il est connu ; sinon il reste inconnu. Le reçu garde iat, exp, ttl, l’heure de récupération, l’âge du cache et l’heure de décision. Il distingue requête actuelle et historique, valeur numérique, sens du registre, borne locale de fraîcheur, règle métier, action et correction ultérieure.

Ce schéma n’est pas destiné à la Token Status List. C’est un contrôle local et proportionné, fondé sur l’écart entre règle déclarée et décision observable que décrit The Policy Mirror, sur l’attention au système réellement exécuté de Running-Code Primacy, et sur la discipline de l’incertitude de Reality, Not Advocacy. Ces textes orientent l’analyse ; ils ne prouvent aucun incident OAuth.

Sources