Résumé

  • Publié le 28 septembre, le premier projet AAuth Budgets propose un plafond de consommation par jeton d’autorisation, appliqué par la ressource qui facture l’usage.
  • Ce plafond ne devient pas, à lui seul, une limite globale pour une personne : les autorisations simultanées doivent être additionnées et rapprochées par le serveur qui les délivre.

Le cas difficile n’est pas celui d’un service qui oublie de vérifier un plafond. C’est celui d’un service qui respecte chacun des plafonds qu’on lui présente. Deux agents, ou deux missions d’un même agent, peuvent recevoir chacun une autorisation de dix unités — montant purement illustratif. Si les deux jetons restent valides, vingt unités peuvent être consommées sans qu’aucun jeton n’ait dépassé sa propre limite. Celui qui voulait limiter la personne à dix unités devait retenir cette somme au moment de l’émission, avant de promettre une deuxième fois la même capacité.

Cette séparation est au cœur du texte déposé le 28 septembre 2026 par Dick Hardt. AAuth Budgets est un Internet-Draft individuel, qualifié d’exploratoire par son auteur. Son statut visé est « Standards Track », mais la fiche du Datatracker n’indique qu’un projet existant, sans filière RFC définie. Rien n’autorise à parler d’une norme approuvée, d’un accord du groupe de travail ou d’un déploiement généralisé. Le document se greffe sur un autre projet, le protocole AAuth : l’agent demande un montant, la ressource annonce l’unité et l’offre possible, le serveur de la personne — éventuellement avec un serveur d’accès — peut réduire la demande, puis le jeton signé transporte le montant accordé. La ressource mesure et arrête la consommation; le serveur de la personne conserve pour lui seul le plafond général qu’il s’est engagé à tenir.

À la ressource revient une obligation locale exigeante dans le projet. Le total déjà facturable et les réservations des requêtes encore en cours, pour un même jeton, ne doivent pas franchir le montant accordé. Or une réponse de modèle peut coûter plus ou moins selon ce qui est produit. Avant de servir une requête payante, il faut donc en fixer un coût maximal fini, à partir d’une borne annoncée ou d’une valeur par défaut documentée. La ressource réserve ce maximum, réalise l’opération, inscrit le coût réel et libère le reste. Une requête peut être refusée alors que son coût final hypothétique aurait tenu dans le solde; l’agent peut ensuite proposer une borne plus petite. C’est le prix d’un plafond dur, différent d’une alerte envoyée une fois la dépense déjà faite.

La ressource tient aussi des compteurs rattachés à la personne. Ils ne lui donnent pas le droit d’inventer un deuxième plafond global : elle ne connaît pas celui que le serveur de la personne garde en privé. Ce serveur doit dimensionner l’ensemble des allocations vivantes, et non seulement chaque jeton pris isolément. Le projet l’exprime sans détour : n jetons simultanés de montant X exposent à nX pendant leur durée de validité. Il ne s’agit pas d’un dépassement constaté, mais d’un risque conditionnel résultant des droits effectivement délivrés.

Le rapprochement est moins immédiat qu’un simple « annuler ». Un agent peut abandonner un jeton ou se bloquer; le serveur sait ce qu’il a autorisé, pas nécessairement ce qui a été utilisé. Le projet lui impose de compter provisoirement l’allocation inconnue comme entièrement consommée. Un relevé de consommation attaché à un nouveau défi ne donne qu’une photographie d’un jeton qui peut encore servir. La lecture des compteurs de la ressource, complète jusqu’à un instant as_of, permet de solder les allocations expirées avant cet instant. Une révocation effectivement enregistrée peut avancer la fin de l’exposition. Si la ressource ne prend pas la révocation en charge ou n’est pas joignable, la réserve ne peut pas être rendue tout de suite; une requête déjà partie peut aussi se terminer. Un arrêt demandé par l’utilisateur n’est donc ni un remboursement ni, sans réponse vérifiée, la preuve que toute dépense a cessé.

Le texte distingue également le prix de l’action permise. Un budget borne une quantité, pas la nature de ce que l’agent peut faire : une opération irréversible à faible coût reste possible si ses permissions l’autorisent. Un jeton ne désigne pas automatiquement le compte de facturation lorsque la personne en possède plusieurs auprès de la ressource. Une délégation à un sous-agent ne prélève pas un « sous-budget » sur le jeton parent; chaque nouveau jeton doit recevoir sa propre allocation auprès du serveur de la personne.

Enfin, l’en-tête AAuth-Budget proposé renseigne l’agent sur le coût et le solde de son jeton. Non signé par défaut, il aide à régler le rythme des requêtes; il ne constitue pas l’autorisation. La signature d’une réponse de compteur est recommandée, pas obligatoire, et prouve ce que la ressource a déclaré, non l’honnêteté de son compteur. Les exemples de mise en œuvre du projet viennent de leurs auteurs et n’ont pas été vérifiés indépendamment ici. L’inférence payée directement par le fournisseur de l’agent, sans serveur de la personne dans ce circuit, reste hors du champ de cette extension.

La véritable question de gouvernance est alors visible : qui garde la liste des jetons encore vivants, la somme réservée pour chacun, la date du dernier relevé complet et le résultat effectif d’une révocation? Un plafond impeccable affiché à l’écran ne répond pas à ces quatre questions.

Sources