Summary

  • Le projet propose /.well-known/agent-capabilities pour publier les parcours, les serveurs d’autorisation et les points d’appel accessibles aux agents.
  • Une opération absente de tous les parcours publiés est fermée. Le serveur de ressources ne doit pas l’exécuter, même si une autorisation déjà approuvée la mentionne.

Le dossier d’autorisation porte encore le tampon « approuvé ». À l’entrée du service, cela ne suffit plus. Dans le projet publié le 2 novembre, l’application affiche ses parcours pour agents dans un document JSON sous /.well-known/agent-capabilities. Aucun parcours ne cite l’opération demandée ? Le serveur de ressources doit la refuser ; le serveur d’autorisation devrait également refuser une instance qui l’inclut. La liste diffusée par l’origine devient donc une partie de la décision exécutable.

Ce dispositif permet de fermer un parcours proprement. Il donne aussi un poids inhabituel au droit d’écrire un fichier statique. La section 8.6 décrit un adversaire capable de remplacer le document sur l’origine : les agents qui découvrent ensuite le service peuvent être dirigés vers des surfaces d’appel choisies par lui, ou détournés des parcours véritables. Aucune modification du code de l’application n’apparaît nécessaire. Les auteurs demandent de placer ce document dans le contrôle des changements de version. La RFC 8615 signalait déjà que les administrateurs oublient parfois les chemins .well-known ; ici, l’oubli touche la frontière d’exécution des agents.

Le cas des applications natives rend l’arbitrage visible. Une copie intégrée au paquet sert à la découverte hors ligne, mais elle n’est qu’un cache. Avant la première opération distante d’une session, l’application consulte la version servie par son origine associée et l’adopte en cas de divergence. Une opération retirée de cette version ne peut plus être exécutée au prétexte qu’un ancien paquet l’affiche encore.

Le nom et le logo du service ne prouvent aucune identité : le projet fonde l’association sur l’origine et la transmission authentifiée. Si l’application diffuse aussi les métadonnées OAuth de ressource protégée, les listes de serveurs d’autorisation doivent coïncider. Le registre de l’IETF classe le texte comme projet individuel. Il manque l’historique d’un déploiement réel et les refus enregistrés par son serveur pour savoir si cette porte a effectivement bougé.