Summary

  • La revisión 01 transporta un JWT firmado por su emisor en Authorization: DPoP y conserva el ath, la clave confirmada y los controles de solicitud de RFC 9449.
  • El servidor no puede deducir por el aspecto del mensaje si recibió un token de acceso o una credencial. Debe seleccionar la semántica mediante iss y typ previamente admitidos.
  • La posesión de clave para una solicitud no reemplaza aud, estado vigente, protección de claims, autorización local ni comprobación del resultado.

La misma tubería admite otro objeto

La propuesta evita inventar un protocolo de presentación para llamadas entre programas. El Holder envía la credencial completa en el lugar del token y firma un DPoP separado con htu, htm, iat, jti, nonce cuando se exige y ath. Este último sigue siendo el hash SHA-256 de los bytes US-ASCII de la credencial recibida. El verificador compara además la clave de la prueba con cnf.jkt o con la huella de cnf.jwk.

Nada de eso identifica la clase del objeto. RFC 9068 exige audiencia y at+jwt en su perfil de token JWT. El borrador exige para la credencial un typ definido por el despliegue y distinto de at+jwt y de los tipos de ID Token. Si el servidor acepta ambas cosas, un iss confiable y un typ admitido deben abrir ramas diferentes. Validar la criptografía antes de hacer esa distinción puede ejecutar la política equivocada con datos perfectamente formados.

Destino de la solicitud y audiencia no son sinónimos

htu y htm vinculan la prueba con una URI y un método. Esa evidencia demuestra uso de la clave en esta solicitud; no registra a qué conjunto de servidores quiso limitar el Emisor una identidad reutilizable.

La credencial puede no llevar aud. En tal caso se puede presentar a cualquier servidor de recursos que confíe en el mismo Emisor. El Holder elige adónde enviarla, pero no puede crear retrospectivamente una audiencia. Si existe aud, lo fijó el Emisor durante la emisión y el servidor debe encontrar en él su identificador configurado.

Por eso, una relación de confianza compartida con un proveedor de identidad no equivale a una política común. Un servicio de nómina y una herramienta de desarrollo pueden confiar en las mismas claves, pero no necesariamente deben aceptar la misma credencial ni interpretar sus claims del mismo modo. La autorización local sigue siendo la barrera que decide la operación.

El estado hereda el problema del tiempo

Una credencial puede durar mucho más que un token de acceso. El borrador recomienda status para compensar ese horizonte. Cuando está presente, el verificador debe consultarlo y rechazar un resultado inválido; también puede rechazar por política una credencial larga sin mecanismo de estado.

La caché importa. Su tiempo de vida se convierte en la demora antes de que una revocación surta efecto. Firma del Emisor, prueba DPoP reciente y estado descargado ayer son recibos de relojes distintos. La ausencia del Emisor en el camino de cada llamada mejora latencia y reduce observación directa, pero una consulta de estado puede revelar patrones de uso.

Mostrar todo también es una decisión

No hay selección de claims. Cada servidor recibe el JWT completo, y una firma estable permite correlacionarlo entre verificadores. Los encabezados pueden terminar en registros de acceso o proxys. TLS no corrige una claim innecesaria ni retira copias ya guardadas.

Cuando hace falta descubrir credenciales, mostrar solo un subconjunto o obtener consentimiento humano, OpenID4VP sigue resolviendo otro problema. Este perfil sirve cuando el software ya conoce servidor y credencial. Incluso un SD-JWT VC se presenta aquí únicamente como JWT firmado, sin disclosures.

La doctrina de Lu Heng ayuda a no confundir la reutilización con una constitución total. Una especificación inicial mínima puede compartir el transporte; el código en ejecución todavía debe producir recibos separados de tipo, Emisor, audiencia, frescura de estado, versión de política y efecto observado.

Sources and limits

Estas fuentes no demuestran adopción por el grupo OAuth, consenso IETF, RFC, implementación, interoperabilidad, despliegue de agentes, emisión o revocación real, autorización ni resultado del servicio. El artículo existente sobre RFC 9449 conserva la tesis general de sender constraint; este cubre solo el cambio semántico dentro de un formato idéntico.