Résumé

  • Le projet d’Agent Authorization Center conserve les associations utilisateur-agent et une politique d’accès autonome. Un service autorisé dans la liste passe automatiquement ; un service interdit est refusé ; un service absent de ces listes exige la confirmation de l’utilisateur.
  • Le jeton doit identifier le compte utilisateur, l’agent et le centre. La mention « approbation automatique ou humaine » reste facultative, alors que la section consacrée à la sécurité est encore TBD.

Le clic supprimé aujourd’hui revient sous une autre forme demain : une ligne dans une liste. Le projet d’Agent Authorization Center s’intéresse aux agents installés sur les appareils personnels. Il promet de les laisser accéder aux services tiers sans interrompre leur utilisateur à chaque demande. La question décisive se pose donc au moment où le service entre dans la liste des accès autonomes, avant même la prochaine requête.

Le centre, ou AAC, garderait l’identité de l’utilisateur, ses liens avec des groupes d’agents et des agents précis, ainsi que ses règles personnalisées. L’agent contacte d’abord le service en présentant l’identifiant de l’utilisateur et celui de l’AAC. Le service l’oriente vers ce centre. L’AAC reçoit les détails de l’utilisateur, de l’agent et du service, puis choisit : passage automatique si le service figure dans la liste autorisée, refus s’il figure dans la liste interdite, demande à la personne dans les autres cas.

Une fois l’accès approuvé, le centre émet un code selon le modèle OAuth. Le service échange ce code contre un jeton, le valide et fournit la prestation dans la limite des droits de l’utilisateur. La proposition prévoit que le jeton contienne les identifiants du compte, de l’agent et de l’AAC. Elle permet, sans l’exiger, d’y ajouter le mode d’autorisation. Un service peut donc vérifier le jeton sans savoir si la personne a consenti à cette demande précise ou si la liste a parlé à sa place.

Une liste préalable a du sens pour les tâches banales. Elle mérite davantage de précision dès qu’un agent achète, modifie un compte ou divulgue des données. Le texte ne fixe ni limite par action pour les services listés, ni version des règles, ni durée d’une entrée, ni procédure de retrait. Il confie au service le respect des droits de l’utilisateur, mais le nom du service sur une liste ne décrit pas l’action qui sera exécutée. Il faut dire qui règle ce deuxième niveau et ce que le destinataire peut contrôler.

La section « Security Considerations » du document contient seulement TBD. Les bonnes pratiques OAuth de RFC 9700 et la protection des codes par PKCE dans RFC 7636 existent déjà. Le projet doit encore décrire comment l’agent, le centre et le service les appliqueront ; il ne fournit aucun essai de déploiement.

Le Datatracker classe ce texte comme projet individuel Informational, I-D Exists. Un essai utile ajouterait un service à la liste automatique, autoriserait une seule opération délimitée, modifierait ensuite l’entrée et demanderait au service quelles pièces le jeton suivant lui présente. La signature peut être correcte pendant que le chemin du consentement reste invisible.