Resumen

  • draft-ietf-oauth-rar-metadata-remediation-00 define una respuesta para que un servidor de recursos comunique authorization_details accionables cuando un token válido no basta para una operación.
  • El servidor de recursos propone la condición que considera suficiente; el cliente decide si la tramita, el servidor de autorización aplica política y consentimiento, y el titular puede denegarla o reducirla.
  • Daniel Kade propone un registro de diferencia de autoridad que enlace intento fallido, derechos actuales, propuesta, procedencia del esquema, decisión de consentimiento, detalles concedidos y efecto final. No es un requisito del borrador.

Cuando el error redacta la próxima solicitud

Pensemos en una aplicación que intenta iniciar un pago. El token es auténtico y no ha caducado, pero carece de los detalles de autorización necesarios. Un error genérico obliga a la aplicación a adivinar, consultar documentación privada o abandonar la operación. La remediación propuesta por el grupo OAuth pretende que el servidor de recursos explique la carencia en un formato que el cliente pueda reutilizar.

La respuesta usa HTTP 401 y el código insufficient_authorization. Dentro de authorization_remediation, un objeto JSON codificado con base64url puede transportar authorization_details construidos a partir de la petición fallida. También puede incluir una authorization_reference opaca. El cliente busca primero un token de la misma sesión y origen o, si no sirve, inicia una nueva autorización con los detalles recibidos.

El mecanismo cubre un hueco real. RFC 9396 normalizó las Rich Authorization Requests para describir permisos finos, pero dejó fuera una forma general de descubrir cada tipo y otra de reparar un rechazo en la capa del recurso. El nuevo borrador suma un endpoint de metadatos, esquemas, una señal de error y reglas para reintentar sin acuerdos bilaterales específicos.

Su estado requiere precisión. La revisión 00 se publicó el 23 de agosto de 2026 y el Datatracker la presenta como documento del grupo OAuth que sustituye al borrador individual anterior. Las actas de IETF 126 muestran apoyo al problema, preguntas sobre la solución y una llamada a adopción. No es un RFC, no está en teleconferencia del IESG y sus valores IANA siguen siendo propuestas.

Proponer suficiencia no es otorgar poder

El texto atribuye al servidor de recursos una función concreta: construir los detalles accionables a partir de la operación que negó. Si una nueva concesión incorpora esos detalles, debe satisfacer las condiciones de la recurso. Esa frase hace que el mensaje sea más que una pista de diagnóstico; es la materia prima de una nueva solicitud de autoridad.

Sin embargo, el otorgamiento sigue en otros lugares. El cliente puede no procesar el desafío. El servidor de autorización valida el tipo y comprueba su política. RFC 9396 le exige presentar los permisos solicitados cuando reúne el consentimiento. El titular puede aprobar solo un subconjunto, y la respuesta del token debe indicar los detalles realmente concedidos. El servidor de recursos vuelve a evaluar el token ante la operación.

Por eso sería incorrecto afirmar que la API se concede permiso a sí misma. También sería incorrecto describir toda la secuencia como un simple reintento. Entre ambas llamadas puede haber cambiado el universo de acciones, recursos, límites temporales o efectos recurrentes que el cliente está autorizado a pedir.

Una petición de lectura única y una autorización para acceso continuado no ocupan el mismo lugar normativo. Tampoco lo hacen un pago de una cantidad y un mandato recurrente, aunque ambos usen el mismo tipo. Un cambio de ubicación o postura del dispositivo puede conducir al servidor de recursos a exigir un contexto diferente. La propuesta puede ser más amplia, más estrecha, equivalente o no comparable.

RFC 9396 advierte que no existe una regla estándar para comparar dos objetos arbitrarios porque la semántica corresponde a cada API. Contar campos o bytes no basta. Un campo ausente puede invocar un valor predeterminado más amplio; dos listas pueden unirse; un identificador puede llevar el permiso a otro activo. Validar la forma del JSON no demuestra mínima autoridad.

La referencia encuentra candidatos, no decide equivalencias

La authorization_reference reduce trabajo en el cliente. El servidor debería generar un valor estable para objetos idénticos o semánticamente equivalentes. El cliente lo guarda junto a un token dentro de la sesión del usuario y del origen del servidor de recursos. Cuando reaparece, la comparación de cadenas permite localizar un candidato sin analizar el RAR.

El borrador limita ese valor. Debe ser opaco, no contener información sensible, no viajar entre servidores de recursos y no aparecer cuando los tokens son de un solo uso. Estas condiciones impiden convertirlo en una identidad global o una descripción encubierta de derechos.

Incluso dentro de su ámbito, una coincidencia no garantiza éxito. El consentimiento pudo revocarse; el riesgo contextual pudo cambiar; el servidor de autorización pudo haber emitido un subconjunto. La referencia ayuda a seleccionar; el servidor de recursos conserva la autoridad de aceptar o rechazar.

Una no coincidencia tampoco establece una diferencia ordenada. El propio borrador señala que un token para débitos de hasta 100 puede cubrir uno de 80 aunque las referencias no coincidan. La inclusión es una conclusión semántica del tipo de autorización. La cadena opaca no expresa “mayor”, “menor” ni “igual”.

Esta es una frontera importante para la telemetría. “Token localizado” no equivale a “permiso suficiente”, y “referencia nueva” no prueba que sea razonable solicitar más. Si el producto oculta ambas distinciones, la automatización hereda un poder que el protocolo no le concedió.

Un esquema dice qué objeto es válido, no qué decisión es prudente

El endpoint de metadatos propuesto puede publicar, por tipo, una versión informativa, descripción, documentación, ejemplos y un JSON Schema incorporado o referenciado. El esquema debe validar un objeto único y fijar el identificador de type.

Esto ofrece una gramática común. No ofrece una justificación. La descripción no debe usarse para autorizar o validar, los ejemplos no son normativos y la versión no crea negociación semántica. Un objeto conforme puede pedir algo desproporcionado para el propósito del usuario.

La procedencia sigue siendo parte de la prueba. Si el esquema cambia entre el rechazo y la concesión, una interfaz puede mostrar las mismas etiquetas mientras la política interpreta otro conjunto. El registro operativo debe conservar URI o hash, fecha de obtención y versión del evaluador específico del tipo.

También debe conservar el emisor seleccionado. Cuando el servidor de autorización habitual no admite el tipo, el cliente puede descubrir otro mediante Protected Resource Metadata. Esa posibilidad mejora la interoperabilidad, pero introduce una autoridad institucional diferente. Sus reglas de registro, autenticación, consentimiento y datos no son intercambiables por el mero hecho de hablar OAuth.

El registro de diferencia de autoridad

Propongo un registro de diferencia de autoridad. No se inserta en el token ni modifica el borrador. Su finalidad es mantener visible la transición que el flujo hace cómoda.

La primera parte describe el rechazo: sesión, origen, clase de operación, compromiso criptográfico de la petición y autoridad efectiva del token presentado. Los datos de cuentas, pacientes o transacciones no deben copiarse a un log general; pueden sustituirse por referencias opacas, resúmenes mínimos y hashes salados de corta retención.

La segunda parte fija la propuesta. Incluye el hash del objeto decodificado, una representación comprensible del efecto, la referencia, el tipo, el URI o hash del esquema, su versión informativa y la hora de consulta. Un módulo semántico declara si el cambio es nulo, restrictivo, expansivo, incomparable o desconocido. También identifica la política con la que llegó a esa conclusión.

La tercera parte registra la tramitación. ¿El cliente abandonó, reutilizó un token, abrió un flujo, pidió confirmación o elevó el caso? ¿Qué servidor de autorización eligió? ¿Qué versión de la pantalla vio el titular? ¿Qué aprobó, redujo o rechazó? ¿Qué detalles comunica el token como concedidos?

La última parte sigue el resultado: asociación de referencia y token sin guardar el secreto, número y clase de intentos, decisión final del recurso, resultado de la operación y eventual reversión. Una emisión correcta no demuestra que el pago se ejecutó bien ni que una modificación fue inocua.

Así, cada participante conserva una afirmación limitada. El servidor de recursos prueba su propuesta; el cliente, su conducta; el servidor de autorización, su decisión; el titular, su consentimiento; el sistema protegido, el efecto. La auditoría no necesita fingir que uno observó todo.

No convertir el control en otra fuga

Los objetos RAR pueden describir información financiera o clínica. El borrador recomienda que el servidor de recursos evite datos sensibles y use referencias opacas. También sugiere valorar privacidad y tamaño antes de incluir detalles en JWT, recurriendo a introspección autenticada cuando corresponda.

El registro de diferencia debe aplicar la misma economía. Hashes sin sal sobre cantidades previsibles se pueden adivinar. Resúmenes humanos deben nombrar la clase de efecto sin repetir el identificador protegido. La retención no puede ser indefinida solo porque la palabra “auditoría” aparezca en el propósito.

Además, la fuente de cada dato debe conservarse. Un dato enviado por el recurso no es una afirmación del usuario. Un esquema correcto no prueba consentimiento. Un token emitido no prueba que la pantalla explicara la consecuencia. Mantener estas etiquetas evita que la evidencia técnica se convierta en una narrativa demasiado fuerte.

El límite de reintentos necesita un límite de autoridad

El borrador evita bucles obvios: un intento con token almacenado, una autorización nueva y parada si vuelve la misma referencia. Con otra referencia puede haber una nueva remediación, sometida a un máximo que decide la implementación. Los tokens deben separarse por sesión de usuario.

Pero contar repeticiones idénticas no detecta una escalera de permisos. Referencias sucesivas pueden reflejar contexto legítimo, una política inestable o requisitos crecientes. Además del contador técnico hace falta un presupuesto de cambio: emisor nuevo, recurso nuevo, acción de alto impacto, mayor duración o recurrencia, esquema alterado u objeto no comparable.

Al superar ese presupuesto, el cliente deja de presentar el paso como reparación automática y solicita una decisión explícita. Ese no es un freno a la interoperabilidad. Es la forma de nombrar correctamente lo ocurrido. Reintentar usa la autoridad existente; remediar puede solicitar otra. El protocolo puede transportar la propuesta. La gobernanza debe preservar su diferencia.

Fuentes

  1. Borrador de metadatos y remediación RAR
  2. Historial del borrador
  3. Revisión 00
  4. Repositorio del borrador predecesor
  5. Actas OAuth de IETF 126
  6. Grupo de trabajo OAuth
  7. RFC 9396 — Rich Authorization Requests
  8. RFC 6750 — uso de tokens Bearer
  9. RFC 8414 — metadatos del servidor de autorización
  10. RFC 9728 — metadatos del recurso protegido
  11. RFC 9470 — desafío de autenticación reforzada
  12. RFC 7662 — introspección de tokens
  13. RFC 9068 — perfil JWT de tokens de acceso
  14. RFC 9126 — Pushed Authorization Requests
  15. RFC 9101 — JWT-Secured Authorization Request
  16. Registros OAuth de IANA
  17. Registro API de Datatracker
  18. Texto sin formato de la revisión 00
  19. Fuente XML de la revisión 00
  20. Incidencias del repositorio predecesor