Resumen

  • draft-li-oauth-delegated-authorization-03 propone una cadena en la que el servidor de autorización firma la raíz y un cliente puede firmar para otro un token hijo más estrecho. Es un Internet-Draft individual con intención Standards Track, no un RFC ni prueba de consenso o despliegue.
  • La firma del hijo demuestra continuidad con la clave enlazada por el padre inmediato. No demuestra por sí sola una raíz confiable, contención de permisos, consentimiento para delegar ni autorización actual del recurso.
  • La solicitud presenta la cadena completa, ordenada y exacta junto con DPoP de la clave hoja. El servidor aún valida todos los ancestros, restricciones y estados antes de tomar su decisión local.

Imaginemos que un agente financiero recibe un JWT firmado por otro agente. El token limita la tarea a leer facturas, dura diez minutos y está ligado a una clave que el receptor controla. Todo parece correcto. Sin embargo, falta la pregunta decisiva: ¿de dónde obtuvo el firmante poder para nombrar a ese agente y qué límites heredó?

El borrador draft-li-oauth-delegated-authorization-03 responde con una cadena. El servidor de autorización crea el token raíz y vincula su autoridad a la clave del cliente A mediante cnf.jkt. A puede usarla o firmar un hijo para B si todavía conserva profundidad de delegación. Cada nuevo nivel debe reducir, nunca ampliar, los derechos acumulados.

El servidor de autorización no participa en cada emisión. Esa propiedad sirve a agentes y servicios que operan con autonomía y poca conectividad. Pero también elimina un punto de observación y aprobación. La legitimidad del hijo no nace de la ausencia del servidor; nace de una capacidad de delegar que ya estaba limitada en la raíz y que el servidor de recursos reconstruirá después.

La revisión 03 fue subida el 24 de julio de 2026 y expira el 25 de enero de 2027. El encabezado dice Standards Track, mientras el registro API no muestra todavía stream ni nivel de estándar. Las solicitudes de registro incluidas son propuestas. El artículo no supone adopción del grupo OAuth, asignación IANA ni interoperabilidad real.

Una firma intermedia prueba una relación de claves

La raíz se valida con una clave del servidor de autorización obtenida mediante configuración fiable o metadatos autenticados. El iss no permite que el propio token elija la clave que lo hará confiable. La confianza inicial debe existir fuera del objeto.

El hijo contiene la JWK pública del delegante en su cabecera protegida. Su huella RFC 7638 debe coincidir con cnf.jkt del padre. Solo entonces se verifica la firma. El resultado establece que el poseedor de la clave autorizada por el padre creó ese hijo.

No establece que esa clave pertenecía a la instancia humana, corporativa o técnica que se pretendía nombrar. La entrega de la clave pública de B a A y su asociación con el delegado correcto quedan fuera del borrador. Un runtime o protocolo externo puede equivocarse, ser manipulado o cruzar tenants sin romper ninguna firma de la cadena posterior.

Por eso hacen falta dos evidencias: continuidad criptográfica y asociación operacional. La primera registra huellas, firmas y posición. La segunda registra qué workload, tenant, operador y canal aportaron la clave. Si el producto muestra solo “delegate verified”, oculta precisamente la parte que la especificación no resuelve.

La dirección también es estricta. El primer elemento debe ser la raíz del emisor aceptado. No se permite buscar un token posterior que convierta en confiable un prefijo sin origen. Una firma válida en mitad de la lista no sustituye el comienzo.

La reducción semántica es el núcleo difícil

Decir que un hijo es «más estrecho» no basta. En scope, los valores se tratan como conjunto y el hijo debe ser subconjunto. En authorization_details, cada tipo necesita reglas propias: recursos, acciones, límites, comodines, ausencias y valores predeterminados.

La igualdad del campo type no demuestra contención. Un detalle que omite una cuenta puede significar todas las cuentas. Una lista más corta puede expresar alternativas más amplias. Comparar texto JSON o contar propiedades puede aprobar una expansión escondida.

Si el verificador no implementa la regla semántica, el borrador ordena rechazar. Este fallo cerrado impide que una biblioteca genérica se convierta en autoridad informal sobre significados futuros. La capa común solo debe contener reglas deterministas que cualquier participante pueda aplicar localmente.

La omisión también modifica el poder. Si un hijo omite scope o authorization_details, ese componente se pierde y no puede reaparecer. Si omite aud, conserva el público efectivo del padre; si omite nbf, no añade una nueva frontera temporal. Una extensión debe declarar con precisión cómo se introduce, hereda, reduce o elimina.

Por ello la autorización efectiva se calcula desde la raíz en orden. No se puede verificar cada JWT aisladamente y después leer la hoja. El contexto acumulado, incluida la desaparición irreversible de un componente, forma parte del resultado.

Profundidad no equivale a control del grafo

La raíz debe indicar max_delegation_depth. Con valor efectivo m, un hijo explícito solo puede usar de cero a m-1; si calla, hereda m-1. Valor cero permite usar el token pero prohíbe otro hijo.

El número limita niveles, no cantidad de descendientes. A profundidad dos, un cliente puede producir miles de hijos y cada uno miles de acciones durante su vida. Tampoco mide valor: un único permiso puede liberar un pago irreversible.

La implementación limita además número de tokens, bytes y coste de verificación. La organización debe limitar fan-out, reutilización de claves, duración y capacidad de reconstruir descendientes. Al omitir al servidor de autorización en cada salto, se renuncia también a que ese servidor mantenga automáticamente el inventario.

Un registro de emisiones puede recuperar visibilidad, pero no debe presentarse como si validara la cadena. Es un plano de observación. Su ausencia complica respuesta a incidentes; su presencia no convierte una expansión inválida en válida.

Consentir acceso no es consentir nombramientos posteriores

El borrador exige separar la aprobación de acceso de la capacidad de delegar. Un usuario que permite a A leer documentos no necesariamente permite que A elija a B o C. La pantalla debe explicar permisos, audiencias, vida y profundidad, y aclarar que el servidor no verá cada hijo.

La raíz puede conceder uso y poder de nombramiento. La misma clave privada sirve para DPoP y para firmar hijos cuando queda profundidad. Un compromiso permite entonces presentar solicitudes y emitir nuevos mandatos. La interfaz criptográfica debería distinguir los dos usos para que un oracle de pruebas HTTP no se transforme en emisor.

Tener un token delegado no demuestra que el titular aprobó a un delegado particular. El titular aprobó un perímetro; el delegante seleccionó la contraparte. Ese acto local necesita su propio recibo y responsabilidad.

El servidor de autorización marca el techo. Cada delegante lo reduce y decide a quién incorpora. El servidor de recursos conserva la última palabra sobre la operación actual. Ninguno representa por completo a los demás.

El orden exacto llega hasta DPoP

La propuesta serializa la cadena de raíz a hoja, separada por ~. ath de DPoP cubre esos bytes exactos. No se deben decodificar, ordenar ni volver a serializar antes del hash.

Esto impide que un observador cambie la cadena capturada sin otra prueba de la clave hoja. Pero no hace válidos sus elementos. Todavía se verifican la raíz, todas las firmas, cada continuidad cnf.jkt, profundidad, contención, audiencia y tiempo.

La prueba terminal dice que la hoja controló la clave y autorizó esta solicitud con esta secuencia exacta. No dice que el titular original aprobara al último agente, ni que los permisos se compararon correctamente. El artículo existente sobre RFC 9449 conserva la mecánica general DPoP; esta pieza trata el camino ancestral que DPoP no sustituye.

Un hijo no incluye identificador de padre. Puede caber en otra cadena compatible cuando el padre precedente liga la misma clave y las restricciones efectivas lo contienen. Una clave distinta por token reduce esa reutilización. Una exigencia de padre único necesita una restricción adicional.

Revocar en el emisor no apaga a todos los verificadores

La extensión propuesta de RFC 7009 recibe la cadena exacta y apunta a su último token. El dueño de la clave ligada a la meta o el delegante directo puede demostrar derecho de revocación. Autenticarse como cliente OAuth no basta por sí solo.

Revocar la raíz invalida todas sus ramas. Revocar un hijo invalida todas las cadenas que lo contienen y sus descendientes, pero no el padre, los hermanos ni otros tokens ligados a igual clave.

El endpoint puede responder 200 incluso ante una entrada inválida. Y una revocación válida solo graba estado en el servidor de autorización. El borrador no distribuye ese estado. Un servidor offline puede ignorarlo hasta recibir una actualización externa o hasta expiración.

Hay que medir dos tiempos: registro de revocación y observación por cada punto de efecto. El primero no prueba el segundo. Destruir una clave no prueba cierre de sesiones derivadas; distribuir estado no revierte operaciones ya confirmadas.

La política local no desaparece al validar la cadena

Después de toda la criptografía, el servidor de recursos evalúa operación, tenant, estado, política del propietario y revocación. Puede rechazar una cadena válida. Esa separación no es una excepción; es el límite que impide convertir la raíz histórica en una orden remota permanente.

Cada token reduce un máximo. El servidor local puede reducir más. Una cuenta congelada, un expediente bajo retención o una exportación deshabilitada siguen importando aunque el scope heredado sea correcto.

La ejecución tampoco está garantizada. Una autorización positiva puede terminar en conflicto, timeout o efecto parcial. DPoP controla una forma de replay; no crea semántica exactly-once. La aplicación necesita clave de idempotencia, commit observable y reconciliación.

Recibo Evidencia mínima No demuestra
Consentimiento raíz Acceso, delegación separada, profundidad Aprobación de un hijo nombrado
Emisión raíz Emisor, hash, permisos, público, tiempo, clave Acceso presente
Asociación Instancia, tenant, huella y canal Reducción correcta
Hijo Padre, hash, límites y profundidad Raíz fiable o estado vigente
Cadena Firmas, enlaces, contención y tiempo Posesión hoja
DPoP hoja Método, URI, ath, nonce y replay Ancestros válidos
Estado Revocación y frescura observada Entrega universal
Decisión local Política, operación y resultado Commit
Efecto Transacción y estado duradero Resultado final deseado
Reconciliación Observación y excepciones Autoridad futura

Un hijo correctamente firmado es una pieza. La autorización solo aparece cuando el origen confiable, las reducciones sucesivas, la posesión, el estado y la decisión local convergen.