Summary

  • draft-li-oauth-delegated-authorization-03 propone una raíz firmada por el servidor de autorización y tokens hijos ligados a claves; cada cliente firma un permiso más estrecho y el último demuestra posesión mediante DPoP.
  • La validación prueba continuidad criptográfica y reducción de alcance, audiencia, tiempo y profundidad. No prueba qué tarea concreta autorizó una persona, si el servidor conocía una revocación ni qué efecto produjo la solicitud.
  • Daniel Kade propone un recibo de intención de delegación separado, que une mandato inicial, custodia por salto, límite de tarea y efecto, frescura de revocación, decisión del recurso y cierre, sin almacenar credenciales.

Dos estados verdaderos que no llegan al mismo tiempo

La revocación muestra por qué no basta con preguntar si un token “es válido”. La revisión 03 define una semántica clara: revocar la raíz invalida todas sus cadenas; revocar un hijo afecta a toda cadena que lo contenga y a sus descendientes, pero no a su padre ni a sus hermanos. El servidor de autorización debe identificar el objetivo sin ambigüedad, por ejemplo mediante un digest resistente a colisiones de la serialización exacta.

Sin embargo, registrar ese estado no lo distribuye. Un resource server que verifica sin consultar en línea no sabe que la revocación existe hasta recibirla por un mecanismo externo. El borrador no especifica ese canal. Los vencimientos breves reducen la ventana de exposición, pero no acreditan cuándo cada receptor actualizó su vista.

Hay, pues, una hora administrativa y otra operativa. Una auditoría necesita saber cuándo se escribió la revocación y qué versión, con qué antigüedad, tenía el servidor cuando permitió o negó la acción. La firma de la cadena puede seguir siendo correcta durante ese desfase.

Este límite no debilita el diseño; define su unidad de verdad. El error de gobernanza sería borrar la diferencia con una etiqueta verde.

De la raíz a la clave final

El borrador intenta resolver un problema real de sistemas compuestos. Un cliente OAuth con autoridad amplia necesita encargar una parte del trabajo a otro cliente sin entregarle el token original, sin compartir su clave privada y sin volver al servidor de autorización para cada delegación local.

El servidor firma un Delegated Authorization Token raíz y lo vincula, mediante cnf.jkt, a la huella de una clave pública del primer cliente. Para crear un hijo, ese cliente firma con la clave vinculada por el padre, expone la clave pública verificadora en el encabezado protegido del hijo y vincula el nuevo token a la clave del delegado. La operación puede repetirse.

El verificador recorre la secuencia ordenada. Confía en la clave de la raíz porque procede de configuración o metadatos autenticados, no porque el propio token la ofrezca. En cada pareja, la huella RFC 7638 de la clave del hijo debe coincidir con el cnf.jkt del padre. Al acceder al recurso, la clave de la hoja firma una prueba DPoP ligada al método, URI, cadena completa y datos de frescura.

Por eso la posesión de la cadena serializada no basta. El borrador crea el esquema HTTP DA y prohíbe tratar estos objetos como bearer tokens. La evidencia obtenida es concreta: la clave autorizada en cada paso creó el siguiente y el solicitante controla la clave terminal.

La autoridad sólo puede contraerse

Cada hijo debe ser igual o más estrecho en permisos, audiencias, periodo de validez y capacidad de volver a delegar. El alcance OAuth clásico puede compararse como un conjunto. Un término nuevo no puede aparecer si no estaba en el alcance efectivo del padre. La omisión elimina esa componente de permiso.

Los authorization_details de RFC 9396 plantean el reto importante. El significado puede depender de cantidades, acciones, identificadores, arrays, comodines y valores por defecto. Dos JSON con aspecto parecido pueden conceder poderes diferentes; uno más pequeño incluso puede ser más amplio si omite una restricción cuyo default es permisivo.

El proyecto exige reglas deterministas de inclusión para cada tipo. Coincidir en el campo type o comparar texto bruto no es suficiente. Cuando un verificador no implementa la semántica, debe rechazar la cadena. Lo mismo ocurre con claims de extensión que afectan a la autorización: no pueden funcionar como límites invisibles para unos componentes e ignorados para otros.

Esta es una conclusión institucional además de técnica. La monotonía no reside sólo en las firmas; reside también en un vocabulario compartido. La versión de la regla de comparación pasa a formar parte de la evidencia de decisión.

Un contador de saltos no es una escala de autonomía

La raíz incluye max_delegation_depth. Con cero, no puede existir un hijo válido. Con un valor positivo m, el hijo puede escoger entre cero y m-1; si omite el claim, recibe m-1. Además, el servidor impone un máximo configurado y todos los verificadores limitan número, tamaño y coste de las cadenas.

El campo responde cuántos bordes adicionales caben en el grafo. No dice cuánto daño puede causar el último. Un salto puede terminar en un borrado irreversible; cuatro pueden acabar en lectura de un catálogo público. Tampoco expresa si el usuario conocía la identidad del delegado final.

Cuando interviene un resource owner, la decisión original debe cubrir la capacidad de emitir tokens hijos sin otra interacción y la profundidad concedida. Autorizar acceso ordinario no autoriza automáticamente delegación. La negativa a una profundidad solicitada no puede convertirse en una profundidad menor sin consentimiento.

No obstante, el borrador deja fuera cómo se presenta esta decisión. Una interfaz puede explicar mal “dos niveles futuros” aunque el servidor emita exactamente lo pedido. El protocolo registra el límite formal; no conserva lo que la persona entendió, qué categorías de delegados esperaba o qué resultados creía excluir.

La tarea empieza donde termina el formato genérico

La especificación no define descubrimiento de claves entre clientes, negociación fuera de banda, entrega de varias cadenas, vinculación de una cadena recibida a una tarea concreta, reglas semánticas de cada aplicación ni distribución de revocaciones. Estas funciones deben venir de políticas de despliegue o extensiones.

Esa lista describe precisamente el puente entre poder y propósito. Un agente puede recibir lectura sobre una API, una audiencia única, diez minutos de vida y profundidad cero. La cadena no diferencia entre “extraer tres cifras del informe aprobado” y “recorrer todo archivo accesible”. La autorización de aplicación y la solicitud aportan parte de esa decisión. El contexto humano aporta otra.

La revisión 03 recalca que validar la cadena no autoriza por sí solo la petición. El resource server aún comprueba DPoP, binding, audiencia y permisos propios. Después, permitir tampoco equivale a ejecutar correctamente. Una respuesta puede fallar, una acción puede producir un efecto secundario o los datos pueden alimentar otra operación.

Por ello hay cinco preguntas distintas: quién concedió la capacidad raíz; qué claves transmitieron autoridad; qué tarea justificó el salto; qué estado de política y revocación vio el servidor; y qué efecto se observó. Una sola bandera no debe responderlas todas.

Privacidad: el observador cambia de lugar

La emisión local evita que el servidor de autorización vea cada delegado, recurso, hora de acceso y patrón multi-hop. Esa reducción de visibilidad central puede ser una ventaja. También significa que la evidencia de la delegación vive en el cliente firmante.

El servidor de recursos recibe, en cambio, la cadena ordenada completa. Sus claims pueden revelar emisor, sujeto, relaciones entre clientes, audiencias, permisos y forma del workflow. Una huella cnf.jkt estable o un jti persistente pueden correlacionar solicitudes y servicios.

La observabilidad se desplaza, no se evapora. Los registros útiles incluyen emisión de raíz, delegación local, resultado de validación, autoridad efectiva y decisión del recurso. El propio borrador aconseja referenciar la cadena con un digest unidireccional y excluir de logs rutinarios los encabezados Authorization y DPoP. Los detalles y los identificadores de sujeto requieren protección.

El reto consiste en reconciliar pruebas repartidas sin crear un almacén central de credenciales y topologías sensibles.

La doble función de una misma clave

La clave ligada a un token puede demostrar posesión para usarlo y firmar un hijo si queda profundidad. La continuidad resulta elegante; el compromiso de esa clave permite tanto ejercer la autoridad vigente como crear nuevos descendientes dentro de sus límites.

El borrador recomienda claves no exportables y APIs de firma estrechas que distingan la firma de tokens de la prueba DPoP. También aconseja claves distintas por token. La reutilización amplía correlación y radio de impacto.

Hay un matiz adicional: el token hijo no contiene un identificador de padre. Puede ser válido bajo otra cadena cuyo token previo vincule la misma clave y cuyos límites engloben al hijo. Es una propiedad intencional de este formato inicial. Quien necesite exclusividad respecto de una sola cadena debe usar claves de padre distintas o una restricción de aplicación.

La huella identifica una clave, no el proceso, la organización o el propósito que el operador imaginó. El control institucional de esa clave necesita su propia prueba.

Un recibo de intención de delegación

Propongo un recibo de intención de delegación. Es una herramienta de Daniel Kade fuera del protocolo, no un claim nuevo ni una obligación del borrador.

El primer bloque fija un digest seguro del evento raíz y de la versión de la pantalla de consentimiento, el emisor y sus metadatos confiables, la capacidad de delegar, alcance o detalles efectivos, audiencias, expiración y profundidad. No almacena tokens, claves privadas, pruebas DPoP ni encabezados.

Cada salto añade el digest exacto de la cadena, huellas públicas de padre e hijo, restricciones antes y después, regla y versión de inclusión semántica, servicio de firma y evidencia mínima de selección del cliente. Indica si hubo reutilización de clave y si se exigía una única cadena padre.

El bloque operativo incorpora el digest de la tarea, la salida aceptable y el límite de efecto; el responsable; el entorno o valor máximo; y las condiciones que requieren nueva intervención humana. Debe codificar lo mínimo y no copiar datos sensibles.

Al decidir, el servidor registra su versión de política, implementación de containment, estado de revocación recibido y frescura, resultado DPoP, autoridad efectiva y veredicto. El cierre conserva clase de operación, éxito o fallo, efectos materiales y referencia de rollback o incidente.

El conjunto mínimo puede ser pequeño: mandato raíz, digest de salto, digest de tarea y efecto, frescura de revocación y decisión final. Su función no es “probar intención” metafísicamente, sino conservar la evidencia concreta que la cadena no fue diseñada para llevar.

Una afirmación más modesta y más fiable

La revisión 03 es un Internet-Draft individual actualizado el 24 de julio de 2026. No es documento adoptado por el OAuth WG, consenso del IETF, Last Call, aprobación del IESG, RFC ni registro IANA vigente. Tampoco demuestra implementación o adopción.

Dentro de ese límite, ofrece un mecanismo riguroso: atribuye cada salto a una clave, exige que la autoridad disminuya y liga el acceso a la posesión final. También reconoce los puntos donde necesita semántica, política y distribución externa.

La conclusión correcta no es “la cadena demuestra que el usuario quiso la acción”. Es “la cadena demuestra que una secuencia de claves podía delegar y ejercer este subconjunto bajo estas condiciones”. El propósito requiere otro registro.

Cuando una acción ya reveló datos o modificó un sistema, ninguna validación posterior puede recrear una intención ausente. La autoridad puede viajar en la cadena. La intención debe quedar al lado antes de que viaje el efecto.

Fuentes

  1. Lu Heng — The Policy Mirror
  2. Lu Heng — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
  3. Lu Heng — Why BTW Media Exists
  4. OAuth 2.0 Delegated Authorization, revisión 03
  5. Ficha Datatracker del borrador
  6. Historial de OAuth 2.0 Delegated Authorization
  7. Carta del grupo OAuth
  8. RFC 6749: marco de autorización OAuth 2.0
  9. RFC 7009: revocación de tokens OAuth 2.0
  10. RFC 7638: huella de JSON Web Key
  11. RFC 8414: metadatos del servidor de autorización
  12. RFC 8707: indicadores de recurso para OAuth 2.0
  13. RFC 8725: mejores prácticas para JWT
  14. RFC 9396: solicitudes de autorización enriquecidas
  15. RFC 9449: demostración de posesión DPoP
  16. RFC 9700: mejores prácticas de seguridad para OAuth 2.0
  17. RFC 9728: metadatos de recurso protegido OAuth 2.0