Resumen

  • El principal firma una Delegation Authorization compacta; en ver=3, esa DA incluye agent_key_binding, la huella de la clave pública del agente, mientras el emisor firma el AIC-JWT exterior que transporta la cadena exacta.
  • El verificador debe comparar la clave de prueba indicada por cnf con el vínculo firmado por el principal. Una firma válida del emisor no legitima una sustitución, y renovar exige otra DA con un nonce nuevo.

La rotación parecía rutinaria. El emisor colocó la nueva clave en cnf, produjo un AIC-JWT con fechas válidas y lo firmó con su clave de confianza. El sistema criptográfico no encontró ningún fallo en ese sobre. La operación se detuvo porque el principal nunca había firmado esa nueva clave.

La revisión 02 de AI Agent Identity Certificate (AIC) JSON Web Token Profile convierte ese desacuerdo en una condición de rechazo. Se publicó el 2 de octubre de 2026 como Internet-Draft individual activo, declara una aspiración Informational y expira el 5 de abril de 2027. No es un RFC ni consenso o aval del IETF, y tampoco prueba adopción o despliegue. El interés del texto reside en cómo reparte la autoridad entre principal, agente, emisor y verificador.

Conservar lo que realmente se firmó

El principal crea una Delegation Authorization, o DA, en forma de JWT compacto y la firma. Después, el agente o el emisor inserta toda esa serialización compacta en la reclamación da del AIC-JWT exterior. La firma exterior cubre por tanto la cadena interior exacta. Cambiar el encabezado JOSE, la carga o la firma interior altera también la carga exterior.

El verificador no puede parsear la DA y fabricar otra representación equivalente antes de comprobarla. Una variación en el orden de miembros, la codificación o la forma base64url produce otros bytes. La firma del principal protege esos bytes, no una reconstrucción posterior. Guardar solamente un objeto normalizado impide demostrar qué mensaje autorizó realmente.

Cada firma tiene un cometido. La del principal declara la delegación. La del emisor responde por la credencial que la transporta. Que el emisor sea fiable no le concede autoridad para reescribir el permiso; que la DA sea auténtica no convierte a cualquier emisor en confiable. Ambas claves deben validarse bajo la política configurada y quedar ancladas en el mismo dominio de confianza admitido.

Los valores explícitos de typ separan también las clases de objeto. La DA interior no es por sí sola un AIC-JWT ni un token de acceso. Sin esa frontera, una autorización firmada para solicitar una credencial podría reutilizarse como si ya fuera la credencial emitida.

La comparación que impide la sustitución

La versión actual de la DA, ver=3, requiere agent_key_binding. Es el hash, con el algoritmo declarado, de la SubjectPublicKeyInfo DER de la clave pública del agente. Como vive dentro de la DA, la firma del principal lo cubre. El token exterior requiere además cnf, que enlaza el token emitido con la clave de prueba de posesión del agente.

El control decisivo consiste en exigir que ambas referencias representen la misma clave. Una DA válida, una firma exterior válida y una prueba de posesión válida pueden coexistir en un conjunto inválido. El emisor puede haber asociado otro dispositivo, un intermediario puede presentar su propia clave o una cuenta comprometida puede pedir una sustitución. La firma exterior sigue siendo correcta; la comparación revela que no es la clave consentida.

La versión 2 solo enlaza agent_id, no una clave. El borrador la considera heredada y la acepta únicamente con las mitigaciones de sustitución que especifica. La versión 1 debe rechazarse y las DA nuevas usan la versión 3. Mezclar las tres bajo una etiqueta de “token válido” borra una diferencia real en la prueba disponible.

Tampoco los encabezados crean confianza. kid selecciona una clave dentro de un conjunto ya confiable y bien delimitado. x5c o x5t no validan por su sola presencia una cadena de certificados o una política. La clave exterior del emisor y la clave interior del firmante de la DA deben tener anclas aceptadas dentro del mismo dominio configurado.

El reloj del principal prevalece

El emisor puede acortar el periodo efectivo, pero no extenderlo. La duración exterior exp - iat no puede superar la solicitada por la DA, ni la caducidad exterior rebasar la de la autorización interior.

El nonce de la DA funciona asimismo como su jti. Se consume cuando ocurre la primera emisión y no puede utilizarse para acuñar un segundo token exterior. Renovar o reemitir requiere que el principal firme una DA nueva con otro nonce. Así, la renovación no es una modificación administrativa del reloj del emisor: vuelve a pedir consentimiento.

Ese nonce no debe confundirse con el control de repetición de cada llamada. El mismo token de acceso puede presentarse legítimamente varias veces mientras esté vigente. El replay de una solicitud pertenece a la prueba de solicitud, como el jti de DPoP. Una contabilidad detecta si una autorización produjo más de una credencial; la otra detecta si se repitió la misma prueba de llamada.

Registrar la huella de la DA compacta, el consumo del nonce, el identificador del token resultante y el identificador de cada prueba evita dos errores: marcar el uso normal como reemisión y perder una verdadera doble emisión entre miles de peticiones.

La criptografía no decide la acción

El perfil completo contrasta principal, capacidades, modo de delegación, restricciones y la posición del sujeto o actor entre las dos capas. Una discrepancia se rechaza. No está permitido recortar en silencio las capacidades y llamar al resultado “lo firmado”. Si las relaciones de subconjunto exigidas no se cumplen, la credencial es incoherente.

Después llega la política local. La autoridad efectiva queda acotada por lo concedido por el principal, las capacidades del agente, las restricciones AIC y las reglas adicionales de la pasarela. La validez del token no demuestra que una compra, un cambio de ruta o una transferencia sea conveniente. Tampoco demuestra ejecución ni el resultado externo.

El perfil de consumidor ligero puede omitir la DA en un modo autorizado y de bajo riesgo. Al hacerlo carece de la atestación criptográfica de autorización del principal que ofrece el perfil completo. Es una opción de riesgo que debe nombrarse, no una equivalencia que deba insinuarse.