Resumen

  • draft-ietf-oauth-transaction-tokens-11 propone un JWT firmado y de vida breve para transportar identidad y contexto transaccional dentro del Trust Domain indicado por aud. Es un Internet-Draft activo en Standards Track, con estado WG Consensus: Waiting for Write-Up, no un RFC ni una aprobación final del IETF.
  • El receptor debe validar firma JWS, audiencia y caducidad. Esas comprobaciones prueban la integridad y el ámbito del contenedor, pero no revelan por sí solas si cada valor de rctx o tctx fue aportado, observado, derivado o acreditado de forma independiente.
  • Daniel Kade propone conservar junto a la decisión un sobre de origen por afirmación: fuente, validación realizada, observador, fecha, transformación, versión de política, vigencia, uso permitido, contradicciones y resultado. Puede guardar hashes o referencias, no el token completo ni datos personales innecesarios. No es un requisito del IETF.

El equipo de fraude revisaba por qué una operación había superado el control. El expediente contenía un Transaction Token con firma correcta y risk_level: low. Eso parecía cerrar la discusión hasta que alguien preguntó quién había calculado el nivel. La respuesta podía ser el propio TTS, un servicio externo, la pasarela de entrada o incluso un atributo entregado por el solicitante. El registro ya no lo decía.

La firma seguía siendo verificable. Lo que se había perdido era la genealogía del dato.

En un sistema distribuido es tentador convertir una certeza criptográfica en una certeza semántica. JWS permite determinar que una clave firmó unos bytes y que los bytes permanecen intactos. El TTS decide qué afirmaciones aparecen. Ninguna de esas propiedades describe automáticamente cómo llegó al sistema cada hecho, cuál de sus fuentes fue contrastada, cuándo ocurrió la observación o para qué decisión se consideraba suficiente.

El estado actual exige precisión institucional

La ficha de Datatracker registra la revisión 11, fechada el 30 de julio de 2026, como Internet-Draft activo del OAuth Working Group y destinado a Standards Track. En el corte de esta investigación, el grupo mostraba WG Consensus: Waiting for Write-Up y el IESG I-D Exists. No figuraban un Area Director responsable ni una fecha de telechat. El avance importa, pero aún no equivale a RFC o aprobación definitiva.

El historial y la comparación oficial 10→11 muestran que esta revisión corrige una errata en la historia del documento. El modelo operativo analizado aquí ya estaba en la versión 10. El anuncio del I-D confirma la publicación de la revisión, no una decisión final del IETF.

El mecanismo responde a un problema reconocible. Una petición atraviesa una cadena de llamadas, y cada servicio necesita suficiente contexto sobre identidad, propósito, alcance y transacción. Reenviar el credencial externo original obliga a cada salto a entenderlo y puede exponerlo más de lo necesario. El borrador usa un Transaction Token, JWT firmado de duración corta, para transportar un contexto común dentro del Trust Domain definido por aud.

Cada dominio tiene exactamente un TTS lógico, aunque pueda desplegar varias instancias. Así se centralizan las reglas de emisión sin imponer una sola máquina. El servicio autentica al workload solicitante, comprueba su autoridad para obtener el token, forma las afirmaciones y firma el resultado. JWT define la estructura, JWS la protección firmada y el grupo OAuth conduce la especificación.

Aceptar el token no delega la autorización

Un workload receptor debe validar la firma JWS, confirmar que aud identifica su Trust Domain y rechazar el token expirado. Son requisitos claros. Si pasan, el receptor sabe que ha recibido, dentro de la ventana temporal, el objeto firmado destinado a su dominio.

Después puede emplear los datos para su autorización local. El borrador deja fuera de alcance el método concreto. La frontera asigna responsabilidades: el TTS emite contexto; cada servicio decide qué consecuencia permite y debe comprender la calidad de los campos que consume.

El texto recalca que un Transaction Token no es una credencial de autenticación ni debe usarse como token de acceso OAuth. En OAuth 2.0, el access token representa una concesión de autoridad. Aquí el objeto representa contexto transaccional. Confundirlos haría que una descripción firmada otorgase permisos que nunca recibió.

Tampoco hay resistencia automática al replay. txn, identificador único de la transacción, puede ayudar a detectar repeticiones o imponer consumo único. Sin embargo, una garantía estricta entre servicios distribuidos puede requerir estado compartido y no siempre es viable. Verificar la firma dos veces no hace que la segunda presentación desaparezca.

El contenido firmado admite procedencias distintas

scope es obligatorio y lo determina el TTS. No puede ampliar el scope que representaba el subject token inicial. Si no entiende ese scope, debe rechazarlo, no interpretarlo como permiso abierto. Aquí la especificación sí fija una relación de no ampliación entre autoridad de entrada y resultado.

La cuestión de origen aparece con rctx, contexto recomendado de la petición o del entorno. Cuando el solicitante aporta valores, el TTS debería evaluarlos. Los valores que finalmente publica pueden coincidir exactamente con la entrada, derivarse de ella o ser afirmaciones independientes del TTS. El servicio es autoridad sobre el conjunto disponible. Esa selección deliberada no significa que todas las piezas del conjunto compartan fuente y verificación.

tctx, también recomendado, contiene detalles que deberían permanecer inmutables durante la cadena. Puede reproducir datos de la petición, transformarlos o incorporar afirmaciones adicionales del TTS. La inmutabilidad protege la versión emitida. No contesta quién observó el dato original.

Supongamos un token con tres campos. client_network procede de una pasarela autenticada; order_total se copió del cuerpo que envió el cliente; fraud_score lo calculó un motor bajo el modelo 2026.08, usando una credencial verificada y señales de esa mañana. La firma cubre los tres. Para permitir una descarga de bajo riesgo quizá baste con el primero; para liberar dinero, los demás necesitan una explicación más específica.

No hay que etiquetar rctx o tctx como no fiables. Un valor puede tener garantía alta, incluso mejor que el dato inicial. La regla correcta es más exigente: su confianza depende de fuente, validación, transformación, tiempo y uso. El contenedor no vuelve homogénea esa combinación.

Validar subject tokens no es una operación uniforme

El TTS puede recibir como subject token un token OAuth o SAML, un JWT autofirmado, un objeto JSON sin firma u otro formato que comprenda. Debe validarlo, incluida la firma cuando exista. La palabra “validar” abarca controles distintos según el tipo: emisor, clave, algoritmo, audiencia, plazo, esquema, canal o autoridad del workload.

Las buenas prácticas JWT advierten contra aceptar algoritmos y claves por inferencia insegura. OAuth Token Exchange ofrece el marco de intercambio de tokens, mientras esta propuesta se concentra en contexto interno. Un JSON sin firma puede ser una entrada legítima bajo un contrato protegido; no aporta la misma evidencia criptográfica que un JWT validado.

Además, el TTS autentica al workload solicitante y determina si puede obtener el token pedido. Las políticas de emisión y la lógica empresarial dependen del despliegue y quedan fuera del documento. Dos TTS conformes pueden aplicar comprobaciones diferentes a un campo del mismo nombre. Por eso la interoperabilidad sintáctica no elimina la necesidad de un recibo local.

La frescura tiene más dimensiones que exp

Los Transaction Tokens deben durar minutos o menos y únicamente el tiempo previsto para la invocación. Aun así, el borrador admite que el token sobreviva al subject token presentado, según la política del TTS, que debería evaluar el riesgo. Puede ser útil para completar una cadena ya iniciada. También demuestra que la expiración del nuevo token no certifica automáticamente la vigencia de toda su evidencia de origen.

Un access token puede invalidarse antes de su fecha. De acuerdo con el riesgo, el TTS puede consultar el estado actual mediante introspección o mecanismo similar. No hay una obligación universal de hacerlo en vivo. “No expirado” y “no revocado a las 14:02” son proposiciones distintas y conviene registrarlas como tales.

En la sustitución, el nuevo token no puede ampliar acciones ni cambiar txn, sub o aud. Puede reducir scope, añadir afirmaciones y, bajo política, extender la vida. Debe preservar la cadena de workloads solicitantes, aunque el mecanismo queda fuera del borrador. Si no se identifica qué salto agregó una afirmación, el último token presenta como simultánea una historia que se construyó por etapas.

El límite del Trust Domain tampoco es decorativo. La validez está acotada por aud. Para continuar entre dominios, el documento remite al trabajo separado de encadenamiento de identidad y autorización OAuth. Poder verificar una firma extranjera no incorpora su política local a la propia.

Una advertencia de revisión debe conservar su escala

En un correo WGLC del 8 de agosto de 2026, un revisor apoyó el avance sin objeción bloqueante y pidió más claridad para auditar cadenas de sustitución. También advirtió que los implementadores pueden confundir información transportada en un token firmado con información acreditada de manera independiente por el emisor.

Es una observación relevante, no un censo. Procede de un revisor y de la experiencia que este declara. No es consenso del grupo, incidente confirmado, explotación conocida ni prueba de que la versión 11 esté mal diseñada. Sirve para identificar una lectura posible que la operación debe evitar.

Un sobre de origen fuera del bearer token

Daniel Kade propone adjuntar a la decisión un sobre de origen sólo para los valores utilizados. Debe identificar clase y referencia de la fuente, validación realmente ejecutada, observador y momento, transformación y versión de política, emisor, clave y frontera de confianza cuando correspondan, comprobación de vigencia o invalidación, uso permitido, sensibilidad, contradicciones, decisión aguas abajo, expiración y cierre.

No se trata de imponer nuevas claims universales. El sobre puede vivir en un recibo de emisión o decisión, conservar un hash del token o apuntar a una prueba con datos minimizados. El borrador prohíbe registrar tokens completos de forma literal por el riesgo de replay y exposición. Permite usar un hash para correlacionar con registros del TTS o guardar el payload JWS sin firma; aun así, ese payload puede contener información personal. Una dirección IP puede ser dato personal según jurisdicción. Este texto no determina obligaciones legales.

La disciplina documental consiste en poder reconstruir el fundamento sin fabricar una copia peligrosa del credencial. Se retiene la explicación, no el bearer token.

Fuentes