Resumen

  • La revisión 01 de draft-zehavi-oauth-authz-req-del-chain se anunció el 10 de septiembre de 2026 y sigue siendo una propuesta individual, no un documento adoptado por OAuth ni un RFC.
  • Sus firmas JWS separadas, hashes previos, posiciones y comprobaciones de audiencia protegen la integridad de la cadena visible para el servidor de autorización superior.
  • Cortar el final o sacar un nodo intermedio rompe comprobaciones. Un bróker sí puede crear otra cadena válida poniéndose como primer nodo.
  • La propuesta deja a la política local decidir si ese primer emisor visible es admisible para el cliente, el recurso y el despliegue concretos.

Una cadena perfecta puede llegar con el prólogo ausente

En una autorización intermediada, un cliente inferior no trata directamente con el servidor que finalmente pide consentimiento y emite tokens. La solicitud atraviesa uno o varios brókeres. Cada uno actúa como servidor de autorización hacia abajo y como cliente OAuth hacia arriba. El servidor final quizá solo haya registrado al último intermediario.

El borrador de cadena de delegación propone transportar el contexto en un objeto RAR authorization_details. Cada nodo JSON indica emisor, destinatario, posición e identidad del cliente atestiguado. Una JWS separada firma una representación determinista, mientras p_hash enlaza el nodo con el evento firmado anterior.

El receptor comienza por el final. Comprueba que el último aud lo designa a él y que su iss corresponde al cliente OAuth autenticado que entrega la solicitud. Después recorre firmas, claves, números, espacios de nombres, hashes y la continuidad entre audiencia y emisor.

La secuencia puede superar todas esas pruebas. Lo único que todavía no ha demostrado es que incluya todo lo sucedido antes de su primera entrada.

La criptografía detecta dos cortes, no el tercero

La revisión 01 ordena el problema en tres casos. Si alguien quita la cola, la cadena abreviada termina ante el destinatario equivocado. Si elimina un nodo central, el hash del sucesor y la continuidad entre nodos dejan de coincidir.

En la cabecera no existe ese ancla interna. Un bróker puede desechar contexto previo y crear una cadena nueva donde él ocupa chain[0], con p_hash nulo. Desde ese punto, todas las firmas y relaciones pueden ser genuinas. El texto llama a esto re-origination y reconoce que la validación solo cubre la ruta visible.

No se trata de un ataque observado. Es el límite que el propio documento asigna a su mecanismo. Un encadenamiento de hashes puede impedir que se altere un inicio declarado; no puede aportar un testigo externo de que ese inicio coincide con la historia completa.

Por eso el servidor debe aplicar una regla local: ¿puede este emisor ocupar la primera posición para este cliente, este recurso y este contexto operativo? Una firma correcta tampoco concede autoridad por sí sola. client_roles puede describir al cliente como oauth_broker, pero el borrador prohíbe tratar un rol autoafirmado como prueba de confianza. La autenticación ordinaria del cliente inmediato sigue siendo necesaria.

El permiso para omitir una cadena mira hacia delante

Otra novedad de la revisión 01 es el descubrimiento de soporte mediante los metadatos de servidor del RFC 8414. Cuando el siguiente servidor no entiende el tipo de cadena, un bróker no puede borrarla sin decir nada.

Debe rechazar la operación, conservar el contexto con otro mecanismo fiable o seguir sin cadena únicamente si lo permiten la política local y los nodos firmados. El campo opcional omit_chain admite allowed y forbidden; si falta, cuenta como prohibición. Todos los nodos validados tienen que permitir la omisión antes de que esa degradación sea posible.

La regla conserva una elección importante: hace visible cuándo se pierde evidencia ya conocida. Sin embargo, no demuestra qué se perdió antes de crear el primer nodo. Autorizar una omisión futura y aceptar un origen recién declarado son controles independientes.

La revisión también propone registrar client_roles en IANA. Es una solicitud dentro de un borrador individual. No demuestra asignación, consenso del IETF, adopción del grupo, implementación, despliegue ni incidente.

Fuentes