Résumé

  • Publiée le 2 octobre 2026, la révision 01 de Using KYAPay Tokens remplace « verifier » par « recipient » et sépare explicitement identification et admission. Après validation, le destinataire conserve le choix d’accepter, de ralentir, d’exiger une authentification supplémentaire ou de refuser.
  • Une validation réussie n’établit pas tout le reste : un bearer token ne prouve pas la possession d’une clé privée, l’autorisation au moment de l’émission ne prouve pas un contrôle humain continu et un contexte de paiement ne prouve pas le règlement final.

Le mot le plus important de draft-skyfire-oauth-using-kyapay-tokens-01 n’est pas un nouvel algorithme. C’est « recipient ». La partie qui consomme le jeton n’est plus décrite comme un simple vérificateur, mais comme le lieu où une décision doit encore être prise.

Ce déplacement lexical restaure une frontière d’autorité. Un serveur de ressources, un opérateur de périphérie, un système antifraude ou une protection contre la prise de contrôle de comptes peuvent vérifier la même signature et ne pas appliquer la même conséquence. Le risque, la valeur de l’action et la relation avec l’utilisateur leur appartiennent encore.

Le jeton KYA peut relier trois coordonnées : la personne, la plateforme d’agent et l’instance d’agent. PAY ajoute un contexte de transaction. Si l’émetteur est accepté, que la signature est correcte et que les claims enregistrés passent leurs contrôles, le destinataire sait mieux ce que l’émetteur affirme. Il ne reçoit pas pour autant un ordre d’ouvrir son service.

La révision 01 le formule sans détour : identification et admission sont distinctes. Le jeton alimente un moteur de politique configuré localement. Une lecture publique peut être admise avec une assurance modeste ; une récupération de compte, une exportation ou un achat engageant peuvent nécessiter une étape humaine fraîche. Une unique pastille « agent vérifié » détruirait cette gradation.

Le statut institutionnel doit rester tout aussi précis. Les deux textes KYAPay sont des Internet-Drafts individuels. Les fiches Datatracker gelées ne leur attribuent ni stream, ni niveau de standard, ni adoption par un groupe de travail. La liste OAuth fournit un lieu de discussion, pas une preuve de consensus. Les champs HTTP et claims JWT demandés ne sont pas des allocations IANA tant que les registres vivants ne les affichent pas.

La chaîne de traitement révèle ensuite plusieurs tests indépendants. Le destinataire choisit d’abord les émetteurs auxquels il fait confiance. Il vérifie l’en-tête JOSE, la signature, exp, iat, jti, aud et l’environnement annoncé. Il distingue le type de jeton et les niveaux d’assurance attachés à l’humain, à la plateforme et à l’agent. La seule présence de KYAPay-Token n’est jamais une preuve de présence humaine.

Le mode de présentation est une autre couche. Le profil décrit par défaut un bearer token : celui qui le copie peut tenter de le présenter pendant sa validité. TLS, durée courte, audience étroite et mémoire de rejeu réduisent cette fenêtre. Ils ne démontrent pas que l’appelant possède une clé privée contrôlée par l’agent.

Le format compagnon permet un claim cnf. Il peut désigner une clé de confirmation et participer à une contrainte d’émetteur, mais seulement si le protocole environnant exige une preuve et si le destinataire la contrôle effectivement. Une référence à une clé dans un objet signé n’est pas l’acte cryptographique. Identité et preuve de possession restent donc deux résultats séparés.

Le temps limite aussi la portée de l’attestation. Le projet dit qu’un jeton valide reflète l’autorisation du principal au moment de son émission. Entre-temps, l’hôte peut être compromis, la plateforme radiée ou le mandat humain retiré. La révision 01 ne définit pas de mécanisme de révocation. Plus l’action tolère mal une autorité vieillissante, plus un défi récent devient nécessaire.

La confiance envers l’émetteur ne vient pas de la signature elle-même. Celle-ci établit qu’une clé a signé. Elle ne mesure ni la qualité de la vérification d’identité, ni les contrôles de la plateforme, ni la solidité des preuves sous-jacentes. Le projet reconnaît que la confiance à grande échelle reste ouverte et repose aujourd’hui sur des accords hors bande. La version de la liste de confiance doit donc figurer dans le reçu.

PAY ne ferme pas davantage la chaîne financière. Le format peut lier une cible, un montant et une devise, et transporter un identifiant de paiement limité à une transaction avec cryptogramme à usage unique. Cela aide à détecter une réutilisation ou un écart de paramètres. Cela ne prouve ni l’acceptation par le marchand, ni l’autorisation du réseau, ni la compensation, ni le règlement irrévocable, ni la livraison.

Un reçu exploitable conserve donc le profil et la révision exacts, l’émetteur et son jeu de clés, l’assurance déclarée, le hash du jeton, les résultats de signature et de claims, l’audience et l’environnement, la décision anti-rejeu, le mode bearer ou la preuve de clé, la version de politique, l’éventuel step-up et le résultat applicatif. Pour un paiement, les références d’autorisation, de compensation, de règlement et d’annulation restent séparées.

La doctrine de Heng Lu donne une règle de conception : une spécification initiale minimale partage les claims et invariants nécessaires, sans centraliser les conséquences. La primauté du code en exécution oblige à regarder ce que l’application a vraiment fait. Les couches de réalité empêchent de fusionner assertion de l’émetteur, validation cryptographique, possession de clé, décision locale et résultat visible sous le mot commode « autorisé ».

« Recipient » est donc une correction de gouvernance. L’émetteur atteste, le jeton transporte, le validateur contrôle. Le destinataire garde sa porte et doit produire le reçu de l’action réellement exécutée.

Sources