Resumen

  • La revisión 01 de draft-wei-aic-jwt apareció el 8 de septiembre de 2026. Es un Internet-Draft individual activo, no un documento adoptado por la IETF, un estándar aprobado ni evidencia de uso real; Experimental es solo el destino declarado por su autor.
  • El perfil completo encierra un JWT de DelegationAuthorization firmado por el principal dentro de un AIC-JWT firmado por el emisor. La firma interna protege agent_id y los límites de la autorización; la externa protege ese DA exacto y el claim cnf.
  • En esta revisión, el DA vincula la delegación con la identidad del agente, no con su clave pública. Un vínculo de clave dentro del DA queda para una futura versión; la clave actual se identifica mediante cnf y debe probarse al presentar el token.
  • Una auditoría debería guardar un recibo del enlace identidad-clave que diga qué afirmó cada firmante. Es una recomendación editorial de Daniel Kade, no un requisito del borrador.

Una revisión grande que aún no es una decisión de la IETF

El anuncio oficial sitúa la versión 01 a las 14:48 UTC del 8 de septiembre. Su ficha de Datatracker la coloca entre las Individual Submissions y muestra el estado I-D Exists, sin stream de RFC, Area Director responsable ni telechat. Cualquiera puede presentar un Internet-Draft. El encabezado propone el destino Experimental, pero ese rótulo no acredita adopción, consenso, aprobación ni despliegue.

El alcance declarado también limita la noticia. AIC-JWT no se propone como un modelo nuevo de autorización. Lleva al nivel de aplicación, mediante JWT y JWS, el modelo de otra especificación AIC basada en X.509. Así puede consumirse en entornos web, HTTP u OAuth donde el certificado no viaja en la capa de transporte. Los derechos siguen dependiendo del modelo AIC, de los esquemas de capacidades y de la política local.

La comparación con la versión 00 muestra más que cambios editoriales. El conjunto de claims del DA sube de la versión 1 a la 2, incorpora campos para presentarse como grant conforme a RFC 7523 y debe fallar de forma cerrada ante el formato antiguo. La revisión nueva también expone una unión que antes era fácil suponer: autorizar el identificador de un agente no equivale a firmar la clave pública que ese agente presentará.

La firma interna cierra el texto de la delegación

En el flujo PKI descrito, el agente crea un par de claves y prepara una solicitud con capacidades, modalidad, restricciones y un nonce. El principal revisa la solicitud, firma el DA y lo devuelve. Después, el agente lleva ese DA a la CA. En la modalidad de authorization server, el DA firmado se entrega en el token endpoint como grant JWT bearer de RFC 7523.

El DA contiene las piezas que permiten acotar la autorización: iss, sub, aud, exp, jti, agent_id, la referencia al principal, motivo, capacidades, modalidad, restricciones, vida solicitada, marca temporal y nonce. La clave que verifica la firma debe coincidir con el anclaje del principal. jti y nonce han de ser iguales. El tipo aic+da+jwt impide tratar el DA aislado como si fuera el AIC-JWT final.

El valor da del token exterior conserva la serialización compacta exacta. No se permite reconstruir el JWT interno antes de comprobarlo. Si el emisor intentara cambiar una capacidad, el sujeto, la audiencia o agent_id, rompería la firma del principal. Y si el principal tratara de producir por sí solo el token exterior, faltaría la firma del emisor.

La conclusión probatoria es concreta: una firma interna válida dice que el principal autorizó ese contenido para la identidad de agente nombrada. No dice todavía que la huella de la clave de presentación estuviera dentro de los bytes firmados por el principal.

El claim exterior asigna la clave a otro nivel

La clave vive en cnf, claim obligatorio del AIC-JWT exterior. RFC 7800 define esa clase de confirmación; el borrador recomienda la huella JWK jkt. Si un despliegue usa DPoP, la huella debe ser la de la clave que firma la prueba. Con mTLS, también puede compararse la clave del certificado cliente.

La revisión 01 evita la ambigüedad. Afirma que el DA firmado por el principal vincula la autorización con agent_id. Para vincular también la clave en el propio DA habrá que esperar a otro conjunto de claims. Mientras tanto, la clave presentada queda ligada por cnf al consumir la credencial. Como ese claim forma parte del payload exterior, la firma del emisor es la que lo cubre.

No se desprende de ello que el emisor tenga permiso para escoger cualquier clave. El flujo descrito empieza con la generación de la clave por el agente, y el principal revisa la solicitud. Tampoco puede el emisor ampliar la delegación. Debe validar la firma, la clave del principal, la audiencia, la caducidad, la unicidad del nonce y las restricciones. El token exterior no puede durar más que el grant firmado.

Sí se desprende una obligación para la trazabilidad. Si años después solo quedan los dos resultados criptográficos, el auditor puede probar qué DA firmó el principal y qué cnf firmó el emisor. No puede convertir la primera prueba en una firma de la segunda. Si el principal vio y confirmó la clave en la interfaz, el expediente de emisión debe retener ese hecho con su propia evidencia.

Tampoco basta con que exista cnf. El apartado de seguridad advierte que AIC-JWT no queda automáticamente restringido al remitente. Sin una verificación real de posesión, quien roba el token puede seguir usándolo como bearer hasta que caduque. El claim señala la clave esperada; la comprobación de DPoP o un mecanismo equivalente demuestra que la presentación la posee.

Un recibo para reconstruir la transferencia de responsabilidad

Mi propuesta es registrar el hash y la versión exactos del DA, el identificador de la clave del principal, agent_id, el emisor, el hash del token exterior, el método y la huella de cnf, la política de emisión, el resultado de consumo del nonce, la caducidad efectiva, el método de prueba de posesión y la decisión del verificador. Si hubo una confirmación humana de la clave, debe aparecer como un evento separado.

Las protecciones contra replay requieren dos líneas. El emisor consume el nonce del DA en la primera emisión y no debe producir un segundo token exterior con él. Eso no convierte cada presentación del token ya emitido en un uso único. El control por petición corresponde al jti de DPoP u otro mecanismo. Un registro que mezcle ambos relojes puede declarar protegido el acceso cuando solo estaba protegida la emisión.

No todo el recibo debe ser público. Las huellas persistentes pueden correlacionar agentes, principales y servicios. La divulgación puede limitarse a compromisos criptográficos, resultados de política o referencias accesibles a un auditor autorizado. La minimización protege a los sujetos sin borrar la asignación de decisiones.

El espejo de política de Heng Lu ordena la pregunta: el principal decide identidad y capacidades; el emisor acepta el DA y firma el vínculo actual de clave; el verificador exige o no la prueba; el propietario del recurso recibe el efecto. La utilidad de dos firmas está precisamente en no fingir que esos cuatro actos son uno solo.

Fuentes