Résumé

  • La version -02 d'un projet individuel sur l'évaluation des chaînes de délégation remplace « Reject » par « Refuse » pour la décision du vérificateur : une entrée authorization_details incomprise ne doit pas être ignorée au profit d'une approbation partielle.
  • Le demandeur devrait savoir que renvoyer le même jeton ne changera rien, sans recevoir pour autant le nom de l'entrée, du chemin ou du droit dont l'évaluation a échoué. Le diagnostic détaillé reste dans l'audit de l'opérateur.

Le danger ne commence pas toujours par une autorisation accordée à tort. Il peut aussi commencer par une explication trop généreuse d'un refus correct. Une entreprise reçoit le jeton d'un agent venu d'un autre domaine de confiance. Le vérificateur voit qu'un droit transmis dans la chaîne ne peut être évalué. S'il répond « le droit parent X a expiré », il renseigne son interlocuteur sur un état de la chaîne que celui-ci ne pouvait peut-être pas connaître. S'il répond simplement comme pour une panne temporaire, le même jeton risque de revenir aussitôt, sans aucune chance nouvelle de passer.

Wes Jackson aborde cette frontière dans la version -02, datée du 29 septembre 2026, de Verifier-Side Evaluation Semantics for Delegated Authority Chains. Datatracker classe le texte comme Internet-Draft individuel, à l'état I-D Exists, sans courant de normalisation attribué. Son en-tête vise un document informatif ; ni l'adoption par le groupe WIMSE, ni la publication d'un RFC, ni le déploiement d'une solution ne s'en déduisent. Il faut lire ses impératifs comme les prescriptions proposées par leur auteur, non comme un consensus déjà acquis.

La comparaison avec la version -01 explique l'angle nouveau. Le titre de la première règle disait auparavant « Process Every Entry or Reject » ; la version -02 dit « Process Every Entry or Refuse ». Le texte distingue désormais le refus du vérificateur, qui ne peut accepter un jeton ou un enregistrement, du rejet par un approbateur d'un appel suspendu. L'un concerne la vérification d'une preuve de délégation ; l'autre est une décision terminale sur une action soumise à une personne. Confondre les deux obscurcit la responsabilité de chacun.

Dans la règle 4.1 proposée, toutes les entrées authorization_details présentées doivent être traitées. Un type inconnu n'est pas un champ à omettre silencieusement : la réponse honnête est de refuser le jeton. Le document ajoute que ce refus est permanent pour ce jeton tel qu'il a été présenté. Les mêmes octets ne donneront pas au vérificateur une capacité de traitement qu'il ne possède pas. Ce cadrage n'interdit pas une autre demande avec un nouveau jeton adapté ; il évite de faire passer un défaut structurel du jeton pour une panne transitoire.

La section 5 refuse pourtant d'en faire un message explicatif complet pour le demandeur. Elle préconise, selon les possibilités du transport, un signal reconnaissable comme non récupérable avec le même jeton, mais proscrit la divulgation de l'entrée, du chemin de délégation ou de la concession précise en échec, au-delà des capacités déjà publiées par le vérificateur. Une série de messages détaillés pourrait servir de sonde pour cartographier des droits internes. La raison exacte doit rester dans un journal d'audit que l'opérateur du vérificateur peut consulter sous contrôle d'accès.

C'est de cette dissymétrie — issue sommaire dehors, diagnostic précis dedans — que découle la conséquence de gouvernance de l'article.

Les références OAuth montrent aussi qu'il n'existe pas de code à copier indistinctement. Le RFC 9396 définit invalid_authorization_details pour le serveur d'autorisation, aux points d'autorisation et de jeton. Le RFC 6750 définit invalid_token pour le serveur de ressources qui reçoit un bearer token ; le client peut alors demander un nouveau jeton et réessayer. Le projet Jackson cite ces exemples mais ne crée ni code ni format de réponse. Le signal approprié dépendra donc du point de protocole et du risque de divulgation dans chaque échange.

Le texte ne documente ni incident de fuite ni volume réel de tentatives répétées. Son implémentation de référence n'exerce pas la règle sur les entrées authorization_details. La proposition rend néanmoins visible une erreur de conception possible : choisir entre un refus vague et un refus bavard comme si la seule variable était la convivialité, alors que la surface exposée est une frontière de confiance.

Sources