Summary

  • draft-liu-oauth-authorization-evidence-01 exige que as_signature cubra el id y todo user_confirmation, pero excluye expresamente los campos de extensión.
  • La audit_trail excluida es la que identifica el nivel de expansión y remite a la propuesta original. En una reproducción local, una versión de 50 dólares y otra de 500 produjeron la misma entrada de firma interna.
  • La firma exterior de un JWT intacto sí protege el conjunto. En el recorrido de un token opaco, TLS protege la recuperación, no convierte la traza extraída en una afirmación firmada independiente.

El precio no estaba en la frase

El ejemplo “auriculares baratos” es útil porque no permite esconder la decisión semántica. “Barato” no es un importe. Antes de que un agente pueda comprar, alguien o algo debe fijar moneda, límite, categoría, cantidad, vendedor y condiciones. El nivel de expansión medium del borrador reconoce que hubo una interpretación significativa, pero la etiqueta no contiene ese cálculo.

La revisión 01 propone un objeto authorization_evidence dentro de Rich Authorization Requests. Su núcleo contiene un identificador, una confirmación del usuario y una JWS separada del contenido. La confirmación conserva el texto exacto mostrado, la acción con la que se confirmó y una marca temporal.

La sección 3.6 no deja ambiguo el alcance: se crea un objeto JSON nuevo con solo id y user_confirmation, se canoniza mediante JCS de RFC 8785 y se firman esos bytes. Todo campo de extensión queda fuera. audit_trail no está accidentalmente olvidado; el algoritmo normativo ordena excluirlo.

Así, una firma válida puede probar que el servidor de autorización registró la aprobación de “auriculares baratos”. No prueba de manera independiente que la persona consintió, porque el servidor controla la interacción y su clave. Tampoco prueba que 50 dólares era la interpretación mostrada, que el servidor de recursos la aceptó, que la compra se envió o que hubo entrega.

La traza explica justo lo que la firma omite

El borrador describe audit_trail como trazabilidad semántica para analizar cómo la intención se interpretó y se tradujo en operaciones autorizadas. Puede contener evidence_ref, semantic_expansion_level y proposal_ref. Esa última referencia identifica la propuesta anterior a la evaluación de políticas, la reducción de alcance o el cambio durante el consentimiento.

Pero proposal_ref es una URI opaca asignada por el servidor. No existe aquí un protocolo de recuperación, una huella obligatoria del contenido, un plazo de retención o una política de autorización para leerlo. Una referencia puede seguir siendo sintácticamente válida cuando el objeto ya no está disponible, ha cambiado o no es accesible al auditor que recibe la evidencia.

Eso no demuestra manipulación. Describe una dependencia que todavía no tiene contrato portátil. La implementación puede resolverla con almacenamiento inmutable, hashes, una respuesta firmada o una envoltura mayor. La revisión 01 no impone esa solución.

La reproducción separó 50 de 500 sin mover la firma

Construimos dos objetos con igual id, texto, acción y hora. Uno usó expansión medium y una referencia terminada en «50»; el otro, expansión high y una referencia terminada en «500». Los objetos completos y sus hashes cambiaron. La proyección prescrita para as_signature no cambió: ambos casos produjeron aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512.

La prueba es deliberadamente limitada. No comprueba la firma abreviada del documento, no rompe JWS ni JCS, no examina un producto desplegado y no prueba que alguien compró nada. Solo hace visible la frontera de bytes que el propio texto define.

JWT y token opaco no dejan la misma evidencia portátil

Si el objeto viaja dentro de un token de acceso JWT firmado según RFC 9068, la firma exterior protege todo el contenido incorporado, incluida audit_trail, mientras el token permanezca íntegro. No sería correcto afirmar que la traza puede cambiar dentro de ese JWT sin detección.

Con un token opaco, el servidor de recursos obtiene la evidencia por introspección RFC 7662 o por un endpoint dedicado. El borrador llama a as_signature la única protección de integridad del registro en ese caso y exige TLS. TLS protege el canal y la respuesta durante la consulta. Cuando el objeto se guarda o se reenvía, esa sesión TLS no acompaña a la traza como firma verificable por terceros.

La introspección tampoco es un recibo histórico por defecto. El significado de active depende del servidor, una respuesta puede variar según el recurso y el caché introduce una decisión explícita sobre frescura.

Por qué y qué siguen siendo objetos distintos

El borrador compañero de políticas Rego distingue la evidencia que registra por qué se autorizó una operación de la política que define qué puede hacer el agente. En el ejemplo completo, authorization_evidence y rego_policy son objetos hermanos. La firma interna de la confirmación no cubre el URI de la política, su punto de entrada ni sus entradas.

Un JWT exterior puede ligar ambos mientras se conserve entero. Fuera de él, el sistema necesita un diseño de recuperación y conservación que permita demostrar qué versión de política convirtió la frase en un límite y qué decisión tomó el servidor de recursos.

Es una cuestión de capas de realidad. Pantalla, confirmación registrada, interpretación, política, autorización del recurso, solicitud despachada, ejecución y resultado externo no son sinónimos. Si una organización los resume en “el usuario autorizó”, el componente que rellena los saltos recibe poder sin dejar necesariamente una prueba equivalente.

El pasaporte que debe acompañar a la interpretación

Para acciones de alto impacto, un pasaporte de interpretación podría enlazar la sesión y la evidencia, el hash y el idioma de la pantalla, la propuesta original o su hash inmutable, la operación normalizada, el diferencial semántico, el componente que lo generó, la política y sus entradas, emisor y audiencia, sujeto y agente, decisión del recurso, hash de la solicitud ejecutada, recibo de ejecución y resultado observado por separado.

Es una propuesta analítica de Daniel Kade, no un requisito del borrador. Los datos sensibles pueden permanecer en depósitos controlados. Lo esencial es que los hashes e identificadores permitan a una parte autorizada rehacer el camino de “barato” a 50 dólares sin depender de la memoria del sistema que tomó la decisión.

Sources and limits

Las observaciones se cerraron el 30 de septiembre de 2026, zona Asia/Shanghai. La revisión 01 es un Internet-Draft individual activo, no un RFC, consenso del grupo OAuth ni prueba de adopción. La reproducción local solo confirma la construcción del alcance. No demuestra criptografía rota, un servidor malicioso, alteración durante TLS, fallo de implementación, pérdida real ni acción completada. El texto puede cambiar, ser sustituido o caducar.