Resumen

  • La revisión 02 de un Internet-Draft individual permite parámetros opcionales y no nombrados en los permisos de herramientas para agentes. Al omitir uno opcional, la herramienta aplica un valor predeterminado que el verificador no ve.
  • La entrada "*" admite parámetros que el token no enumera, incluso los añadidos en versiones futuras de la herramienta. La firma puede seguir siendo válida mientras cambia el alcance real del permiso.

Un permiso con espacio para escribir después

Una organización firma un permiso para que su agente use una herramienta con ciertos parámetros. Meses después, la herramienta añade un botón. ¿Quién autorizó pulsarlo? La revisión del borrador de Niki Aimable Niyikiza muestra una respuesta incómoda: quizá un asterisco escrito en el permiso original. La firma demuestra quién emitió el token. No demuestra que esa persona estudiara una opción que aún no existía.

El anuncio del 27 de octubre y la ficha de IETF identifican una propuesta individual. Su token AAT permite que el titular derive sin llamar al emisor otro token de igual o menor autoridad. El punto de control comprueba la cadena firmada y contrasta la llamada con las restricciones del token final. Esa operación es precisa para los parámetros que conoce. El problema empieza cuando el catálogo de la herramienta cambia.

La versión 01 rechazaba argumentos no enumerados y exigía los enumerados. La nueva versión reconoce que una implementación independiente encontró un hueco: ese esquema cerrado no podía limitar un argumento verdaderamente opcional. La versión 02 permite marcar como opcional un parámetro nombrado. También reserva "*" para los no nombrados. Ese comodín acepta cualquier valor; incluso un mapa vacío equivale a dejarlo abierto.

El valor por defecto también manda

El propio borrador ofrece una lectura de archivos como ejemplo. El token fija la ruta y limita los recuentos opcionales head y tail. Si el agente declara head, el controlador verifica el número. Si lo omite, decide el valor por defecto de la herramienta, invisible para ese controlador. El texto advierte que la omisión puede hacer que la herramienta devuelva el archivo entero. Quien aprueba la omisión ha aprobado también lo que la herramienta haga cuando nadie indique el número.

El asterisco desplaza el problema al futuro. Acepta todo argumento que no figure en el mapa, incluidos los que aparezcan tras una actualización. El borrador aconseja evitarlo en herramientas con efectos externos y permite a los puntos de control rechazar parámetros que no estén en el esquema publicado. Pero deja esa comprobación como opción y no ata el token antiguo a una versión fija de la interfaz. Un desarrollador puede ampliar la superficie que aquel token deja atravesar sin cambiar una sola firma.

Una verificación criptográfica satisfactoria no zanja la cuestión de autoridad. Puede probar que la cadena es auténtica y que la llamada encaja en el mapa recibido. Para saber quién consintió el comportamiento hay que identificar el esquema, el valor por defecto y la decisión que admitió el comodín. El sello no incluye una lista de los futuros botones de la herramienta.

El apéndice F avisa que la revisión 02 introduce cambios normativos incompatibles con implementaciones de la 01; los argumentos opcionales y no nombrados están entre ellos. El texto de seguridad expone el precio de la flexibilidad: las opciones abiertas facilitan la compatibilidad, pero reducen lo que puede comprobarse sobre el alcance. La pregunta editorial es sencilla: cuando un token viejo sigue funcionando, ¿ha continuado el permiso o ha crecido la herramienta debajo de él?

Documentos originales