Summary

  • El borrador AACP propone un servicio que presenta fuera de la inferencia del modelo cada parámetro marcado para confirmación y firma lo que decide el usuario.
  • Antes de actuar, el verificador compara esa prueba con la operación real, su destinatario, el desafío reciente y la vigencia. Un «no» firmado se trata de forma distinta de una respuesta imposible de obtener.

El «sí» más barato es el que un agente pronuncia en nombre de otra persona. Puede sonar convincente y llegar hasta una API sin dejar rastro de la pantalla que vio el usuario. El borrador Agent Action Confirmation Protocol, publicado el 2 de noviembre, propone cambiar el lugar donde nace esa prueba. El agente que va a ejecutar la acción prepara un descriptor estructurado. Un servicio de confirmación muestra los campos señalados, ofrece aceptar o rechazar y firma la respuesta. El servicio puede estar dentro de la aplicación del usuario, en la infraestructura de autorización de una empresa o en una aplicación dedicada. La decisión ocurre por una interfaz programática, fuera del paso de inferencia del modelo.

El diseño se detiene en un detalle que suele esconderse bajo la palabra «consentimiento»: qué apareció en la pantalla. Cada campo que requiera aprobación lleva la marca confirm=true y una etiqueta legible. El servicio debe mostrar todos esos campos antes de pedir la decisión. Trata las etiquetas y los valores como datos, sin ejecutar enlaces ni instrucciones incrustadas. Así, el agente puede redactar la propuesta, pero el importe, el destinatario y el efecto de una operación quedan fijados como datos que el usuario puede inspeccionar.

La firma del servicio convierte ese momento en una prueba verificable. El sistema que va a actuar recalcula una huella de la operación que tiene delante y la compara con la prueba firmada. También comprueba la clave del servicio según su política, el agente destinatario de la prueba, el desafío recién emitido, el plazo y la reutilización del identificador. Una confirmación para un delegado no abre automáticamente la puerta a otro. Para acciones irreversibles, el borrador recomienda una segunda huella de los campos efectivamente mostrados. Es la diferencia entre registrar un clic y demostrar a qué información respondió ese clic.

El catálogo de resultados evita otra comodidad peligrosa. Denied es una negativa firmada; el agente sólo puede volver a pedir autorización si el usuario inicia la nueva tentativa. Unobtainable indica que no se pudo recoger una respuesta y se comunica sin firma. Una prueba caducada, repetida, dirigida a otro agente o asociada a otros parámetros tiene su propio resultado. El verificador debe cerrar la operación ante cualquiera de esos fallos. Para quien administra pagos o cambios duraderos, convertir el silencio en una negativa, o una negativa en un simple problema de conexión, cambia las reglas del negocio sin pedir permiso.

El registro de la IETF identifica el texto como una presentación individual. Falta una demostración interoperable en la que un verificador rechace un importe alterado, un campo no mostrado y una prueba repetida. Ese ensayo dirá si la firma protege la decisión concreta o sólo añade una ceremonia elegante al mismo botón.