Resumen

  • La versión -02 de un Internet-Draft individual propone que un verificador rechace todo el token si no puede evaluar alguna entrada authorization_details, en vez de borrarla silenciosamente y declarar éxito.
  • La respuesta externa debería dejar claro que repetir ese mismo token no resolverá la negativa, pero sin identificar la entrada, la ruta de delegación o la concesión que falló. La explicación exacta corresponde al registro privado del operador.

Un agente puede haber recibido una cadena de autorizaciones que atraviesa varias organizaciones. Cuando presenta un token ante el servicio final, este solo ve lo que su verificador sabe interpretar y contrastar. Supongamos que una de las entradas de autorización usa un tipo desconocido. Aceptar las entradas conocidas e ignorar la restante equivaldría a aprobar una versión incompleta de la solicitud. Pero devolver al agente el detalle de cada comprobación tampoco es inocente: una respuesta que señale exactamente qué concesión anterior dejó de valer revela el estado de una red de permisos ajena.

La versión -02 de Verifier-Side Evaluation Semantics for Delegated Authority Chains, presentada por Wes Jackson el 29 de septiembre de 2026, plantea esa doble obligación. El registro de IETF la identifica como Internet-Draft individual, todavía en estado I-D Exists, sin flujo formal de estandarización. No es una adopción del grupo WIMSE ni un RFC. Sus verbos imperativos expresan el diseño propuesto por el autor; no convierten el texto en una norma vigente ni prueban que algún servicio lo haya implantado.

Hay una diferencia textual significativa respecto de la versión -01. La primera regla se llamaba “Process Every Entry or Reject”; ahora es “Process Every Entry or Refuse”. La nueva terminología reserva la negativa del verificador para un token o registro que no puede aceptar, y el rechazo del aprobador para una llamada retenida que una persona decide denegar definitivamente. Si un sistema mezcla esas etiquetas, puede confundir una evaluación técnica de autoridad con la decisión humana sobre una acción concreta. Esta noticia se centra en la primera, no en el ciclo completo de aprobación.

La sección 4.1 de la nueva revisión dice que un tipo authorization_details desconocido obliga a negar el token. Añade una propiedad práctica: para el token ya presentado, la negativa es permanente, porque enviarlo otra vez no hará que el verificador aprenda a evaluar el tipo que desconoce. La palabra «permanente» no debe extenderse a cualquier credencial futura. Otro token, con características diferentes y emitido bajo otra política, es una cuestión aparte.

En la sección de seguridad, Jackson separa resultado y motivo. El emisor de la petición debería poder saber que el mismo token no pasará si lo reenvía, para no generar intentos estériles. No debería recibir, salvo información del verificador ya pública, el nombre del elemento fallido, la ruta concreta ni el estado de una concesión superior. Esos datos transformarían el interfaz de errores en un oráculo de la cadena de delegación. El documento sitúa la causa precisa en el registro de auditoría del verificador, accesible a su operador.

El par «señal externa limitada / diagnóstico interno preciso» es la lectura operativa de Daniel Kade; el borrador no prescribe un formulario de dos campos.

Tampoco conviene juntar códigos de OAuth que nacieron para puntos distintos. El RFC 9396 define invalid_authorization_details en el contexto del servidor de autorización, para los extremos de autorización y token. El RFC 6750 define invalid_token cuando un servidor de recursos recibe un bearer token inválido; permite pedir un token nuevo y repetir la solicitud al recurso. La revisión de Jackson cita ambos, pero no registra un código propio ni especifica un formato universal. De ahí que la decisión de señalización dependa del transporte real y de lo que revelaría en esa frontera.

Nada de esto es prueba de una filtración ya observada. El borrador tampoco mide el coste de reintentos en producción. Según su propio texto, la implementación pública de referencia no procesa entradas authorization_details. La aportación consiste en formular una tensión antes de que una respuesta demasiado útil para depurar se convierta en un canal involuntario de reconocimiento.

Fuentes