Summary

  • Publié le 29 septembre, draft-saha-aadp-bound-permit-00 décrit un permis de courte durée qui transporte une décision AADP avec état au-delà d'une frontière de confiance, en la liant à un destinataire, une clé de présentation, une requête HTTP et une instance d'action.
  • Le permis ne commande pas le destinataire. Le mandat référencé doit encore permettre l'opération, la politique locale peut la refuser et la fraîcheur de la décision doit être établie. Ces contrôles s'additionnent ; aucun n'élargit les autres.
  • Le destinataire ne consomme (iss, jti) qu'après les autres vérifications. Le mécanisme maîtrise les répétitions, mais ne garantit pas un effet externe exactement une fois : un résultat inconnu exige une réconciliation, pas un nouveau permis.

Le calcul que le destinataire ne peut pas refaire

Un agent propose un virement de 40 euros. Dans le domaine de l'émetteur, le point de décision sait que le plafond quotidien n'est pas atteint, qu'une réservation de 40 euros est disponible, qu'une validation humaine est encore active et que le coupe-circuit n'a pas été déclenché. Il rend permit.

Le prestataire de paiement ne voit aucun de ces états. Un mandat peut lui indiquer ce que l'agent est délégué pour faire ; une identité de charge peut lui dire qui appelle. Ni l'un ni l'autre ne lui permet de reconstruire le solde du budget au moment de la décision. Si la demande arrive avec 40,01 euros, une signature JWT valide ne répond pas à la question décisive : est-ce la demande qui a été autorisée ?

C'est la lacune précise visée par le premier projet de Shamik Saha sur les action-bound permits. Le document est un Internet-Draft individuel actif, destiné selon son en-tête à la voie Standards Track. Ce n'est ni un RFC, ni un consensus de l'IETF, ni la preuve d'un déploiement.

Son objet est plus modeste qu'un système d'autorisation entre organisations : transporter la preuve d'une seule décision que l'autre côté ne peut pas recalculer.

Un jeton volontairement peu réutilisable

Le permis proposé est un JWT JWS compact dont le type exact est aadp-permit+jwt. aud contient un seul destinataire ; plusieurs audiences provoquent un refus. cnf.jkt désigne l'empreinte de la clé du présentateur. La requête HTTP doit être signée par cette clé. Sans cette preuve de possession, le permis devient un bearer token ; le projet interdit ce mode au-delà d'une frontière de confiance.

La signature HTTP couvre au minimum méthode, autorité, chemin, requête, Content-Digest, Idempotency-Key et le champ qui porte le permis. Le destinataire recalcule Content-Digest sur les octets exacts reçus, avant une décompression non convenue, l'analyse ou une nouvelle sérialisation. Deux objets JSON équivalents peuvent donc différer au niveau du fil et être refusés.

Le sens bénéficie d'une liaison distincte. Le type d'action enregistré indique comment extraire l'objet A du corps, du chemin et de la query. Le destinataire le canonise selon RFC 8785, applique le séparateur de domaine et compare action_digest. Cette seconde comparaison empêche une même enveloppe de légitimer un autre montant, bénéficiaire ou numéro de séquence. Une égalité sémantique ne répare pas des octets modifiés ; une égalité d'octets ne répare pas une dérivation d'action différente.

Le temps ferme encore la portée. exp ne peut dépasser l'obligation AADP execute_within. En l'absence de cette obligation, exp - iat ne dépasse pas 120 secondes, et un type d'action peut imposer moins. La tolérance d'horloge, déclarée et enregistrée, est limitée à 60 secondes et ne prolonge pas le délai de fond.

Un destinataire, une clé, une requête, une action, un intervalle bref : l'incommodité du permis est précisément ce qui empêche sa transformation en pouvoir générique.

Trois refus restent possibles

La règle de composition est une conjonction. Premièrement, la décision et ses liaisons doivent vérifier. Deuxièmement, le mandat référencé, s'il existe, doit être évalué séparément contre la même transaction. Troisièmement, la politique locale du destinataire doit permettre l'effet.

Un Agent Authorization Envelope proposé répond à la question de la délégation. Le permis répond à la question de la décision avec état. Si l'AAE fourni ou récupéré ne correspond pas au digest, rend DENY ou PENDING, la demande est refusée. Le permis ne transforme jamais PENDING en PERMIT. Si un mandat requis ne peut pas être obtenu, l'indisponibilité est un refus sauf règle locale explicite qui rende ce type d'action indépendant du mandat.

Le prestataire conserve ensuite son propre jugement. Il peut reconnaître l'émetteur, valider le montant décidé et néanmoins refuser selon ses règles de fraude, de compte ou de conformité. Accepter la signature d'un autre domaine ne revient pas à lui céder la décision finale.

La confiance dans l'émetteur est elle aussi délimitée. La table proposée associe clés, types d'action, limites par champ, date de fin et niveau minimal de fraîcheur. Un émetteur reconnu pour des virements inférieurs à 1 000 euros ne devient pas automatiquement compétent pour fermer un compte ou autoriser un montant illimité.

Une signature peut déjà être périmée

Entre la décision et la réception, une politique peut être remplacée ou un mandat révoqué. Une durée courte réduit cette fenêtre sans la supprimer. Le projet force donc chaque permis à déclarer son mode de currentness.

En time-bounded, la décision est tenue pour courante jusqu'à exp, avec la limite reconnue que les changements intermédiaires ne seront pas vus. Le destinataire ne peut accepter ce mode que pour les couples émetteur/action configurés à cet effet. En status-checked, il vérifie au moment de la requête que le permis, la version de politique et le mandat ne sont ni révoqués ni dépassés, par une liste d'état ou une attestation fraîche signée par l'émetteur.

Une réponse indisponible, illisible ou trop ancienne aboutit normalement à status-unavailable. Une ouverture en cas de panne n'est permise que si elle est locale, explicite, auditée et limitée à une classe de faible risque. L'exception doit apparaître dans le dossier ; elle ne peut se dissoudre dans l'étiquette « jeton valide ».

La distinction des couches de réalité de Lu Heng évite ici une erreur de catégorie. Le permis représente une conclusion passée. Le contrôle d'état représente une observation ultérieure. L'effet économique ou opérationnel arrive encore après. Les relier est nécessaire ; les confondre fabrique une certitude symbolique.

Consommer en dernier

Le projet impose treize étapes. La structure, l'émetteur, l'audience, le temps, le type d'action, la portée, le digest des octets, la signature du présentateur, l'action sémantique, la fraîcheur, le mandat et la politique locale précèdent tous la consommation atomique de (iss, jti). L'effet n'est tenté qu'ensuite.

Cet ordre évite qu'une présentation mal formée ou adressée au mauvais service brûle un usage valide. Un refus de politique locale ne consomme pas non plus le permis. Si le magasin de consommation est indisponible, l'état est could-not-check, et non un refus de politique que l'on pourrait contourner.

jti n'est pas l'identifiant AADP interne permit_id. Le premier franchit la frontière et devient Idempotency-Key; le second reste dans le cycle décision/rapport du domaine émetteur. L'émetteur conserve une correspondance, sans rendre les deux valeurs dérivables. Un identifiant de gouvernance interne ne doit pas devenir une clé de pouvoir externe par facilité.

La première présentation consomme puis stocke le résultat. La même paire (iss, jti) avec le même digest renvoie ensuite ce résultat sans produire un second effet. Avec un corps différent, elle échoue en idempotency-conflict. Pendant que la première tentative tourne encore, la réponse invite à réessayer plus tard.

Ce dispositif n'abolit pas l'incertitude. Si la réponse se perd, le présentateur ne doit pas demander un nouveau permis et renvoyer. Il déclare un timeout, rapproche les traces au moyen de jti ou de l'identifiant d'action du destinataire et escalade si le rapprochement échoue. L'idempotence discipline la reprise ; elle ne prouve pas l'exactly once.

Une réponse signée dans l'autre sens

Après la consommation et la tentative d'effet, le destinataire renvoie une confirmation signée. Elle nomme le permis, la requête, la base de signature, l'action, le verdict du mandat, le résultat et l'identifiant d'action local. Le présentateur place son digest dans le rapport AADP pour acquitter present_bound.

Chaque signature garde ainsi une fonction. L'émetteur atteste la décision ; le présentateur atteste la requête ; le destinataire atteste ce qu'il en a fait. Un refus signé permet de soutenir failure avec no_effect: true. Une erreur non signée ne démontre pas l'absence d'effet ; sans confirmation, le résultat reste timeout.

La chaîne s'arrête après un saut. Un champ parent doit être refusé. Si B appelle ensuite C, B prend une nouvelle décision dans son domaine. Une référence au saut précédent peut conserver la provenance, jamais autoriser C ni alléger ses contrôles.

La Minimum Initial Specification trouve ici une traduction pratique : rendre interopérables les liaisons et les motifs de refus nécessaires, sans confier à l'émetteur la souveraineté sur le destinataire. Le désaccord devient vérifiable, pas interdit.

Le code de référence ne ferme pas encore toute la boucle

Le projet cite le dépôt public onedoor à un commit immuable. Son manifeste contient 24 vecteurs ; le fichier de traçabilité en marque 22 comme implémentés et deux comme lacunes. V17 concerne une politique devenue obsolète en mode status-checked. V22 concerne une confirmation du destinataire qui nomme le mauvais digest de requête. Le texte annonce aussi 92 tests permit réussis.

C'est une preuve reproductible mais limitée. L'implémentation est liée à l'auteur du projet, le message du commit porte sur une autre maintenance du dépôt et aucune interopérabilité indépendante n'est établie. Running-Code Primacy invite à rejouer les vecteurs et à publier les écarts, surtout sur les deux trous ; il ne transforme pas le dépôt en vote de normalisation.

Sources et limites

Ces sources établissent l'existence d'une proposition individuelle active, de ses dépendances et d'un instantané d'implémentation lié à l'auteur. Elles n'établissent ni consensus IETF, ni RFC, ni interopérabilité indépendante, ni déploiement sûr, ni effet exactement une fois. Cet Article possède seulement la thèse de la révision 00 : une décision AADP avec état transportée comme une tentative unique, liée au destinataire, au présentateur, à la requête et à l'action, puis répondue par une confirmation signée.