Resumen

  • El Agent Authorization Center propuesto guarda las relaciones entre usuario y agentes y una política de acceso autónomo: aprueba sin consulta a los servicios admitidos, rechaza los prohibidos y pregunta al usuario por los demás.
  • El token debe identificar al usuario, al agente y al centro; indicar si hubo aprobación autónoma o humana es opcional. La sección de seguridad del borrador sigue siendo TBD.

La puerta puede abrirse sin que nadie atienda el timbre porque alguien escribió antes el nombre del visitante en una lista. Esa es la apuesta del borrador de Agent Authorization Center. El texto se ocupa de agentes instalados en el dispositivo personal del usuario, capaces de acudir a terceros en su nombre. La promesa es ahorrar interrupciones. El coste político es trasladar una decisión presente a una regla guardada para el futuro.

El centro, llamado AAC, mantendría la identidad del usuario, la relación con grupos de agentes y agentes concretos, y las políticas personalizadas. El agente llega al servicio con los identificadores del usuario y del AAC. El servicio lo remite al centro. Allí se comparan usuario, agente y servicio con dos listas: la autónoma permite aprobar sin intervención en esa ocasión; la de prohibidos obliga a rechazar; si no aparece en ninguna, el centro solicita confirmación humana.

Tras la aprobación, el AAC entrega un código de autorización de estilo OAuth. El servicio lo cambia por un token, comprueba el token y presta servicio según los derechos del usuario. El borrador dice que deberían viajar en el token los identificadores de cuenta, agente y AAC. La indicación del modo de aprobación, en cambio, puede viajar o no. El receptor puede conocer al agente y seguir sin saber quién tomó la decisión para esta operación.

Una lista resulta cómoda para recados repetidos. El texto de seis páginas no establece límites por tipo de acción para cada servicio incluido, historial de versiones de la política, vencimiento de una entrada ni secuencia para retirarla. «Servicio autorizado» no describe por sí solo una compra, una descarga o un cambio de cuenta. Los derechos del usuario siguen aplicándose en el destino, según el borrador, pero falta precisar cómo se cruza esa frontera con la aprobación general del centro.

La sección de Security Considerations solo dice TBD. El RFC 9700 contiene prácticas de seguridad para OAuth y el RFC 7636 define PKCE para proteger los códigos. El nuevo texto debe explicar qué hace cada actor con esos controles y aportar una prueba piloto de la arquitectura.

El Datatracker lo registra como borrador individual Informational, I-D Exists. La siguiente prueba debería añadir un servicio a la lista, autorizar una tarea concreta, cambiar la entrada y examinar el token siguiente desde el lado del servicio. Si el token solo demuestra que fue emitido, todavía queda por demostrar qué permiso decidió el usuario y cuándo.