Resumen

  • El borrador individual draft-tulshi-oauth-transactional-access-tokens-00, fechado el 29 de septiembre, plantea un token de acceso OAuth breve, destinado a un solo servidor y sometido a una decisión del servidor de autorización en cada solicitud. Sigue siendo trabajo en curso, no una norma adoptada ni evidencia de uso en producción.
  • Si una tarea visita dos servidores, cada uno recibiría un valor txn diferente; el servidor de autorización mantiene la relación interna. El texto advierte que client_id, otros atributos y la proximidad temporal permiten correlaciones residuales.

El caso práctico puede ser un agente que necesite consultar dos sistemas para una misma tarea. Un permiso OAuth persistente describe una autoridad general; el borrador intenta que cada token entregado al servidor de recursos responda a una decisión más concreta. Propone el tipo txnat+jwt, una audiencia única, un identificador de transacción y contexto afirmado por el servidor de autorización. Aunque menciona agentes de IA, no presenta el diseño como una prueba de seguridad de ningún producto de IA. Datatracker lo registra como Internet-Draft individual en estado I-D Exists, con intención Standards Track, no como RFC.

El detalle decisivo es el reparto de la capacidad de correlación. Al comenzar una transacción, el servidor de autorización crea un identificador interno que no comunica. Entrega un primer token con un txn específico para el primer recurso. Mediante un handle opaco, el cliente puede pedir otro token para la misma transacción y otro recurso; el segundo txn debe ser distinto e imposible de enlazar con el primero para quienes no sean el emisor. La autoridad central sí conoce la unión y puede reconstruirla para auditoría. Dos operadores pueden tener registros localmente coherentes sin poseer, por sí solos, la historia común.

El propio borrador impide convertir esa propiedad en una promesa total de privacidad. En su sección 8 reconoce que client_id se mantiene entre recursos. Recomienda identificadores de sujeto por pareja y no incluir contexto estable innecesario, pero los tiempos de emisión próximos también pueden delatar una misma tarea ante servidores que compartan datos. La protección específica recae sobre el campo txn; los demás campos y la conducta temporal merecen una prueba aparte. Además, el servidor que custodia la unión se convierte en custodio de un rastro sensible.

Hay otra asimetría: los tokens deben durar poco —la propuesta dice que exp menos iat no debería superar 300 segundos—, mientras que un refresh token o una credencial de cliente pueden seguir vigentes. La mejora depende de que el servidor de autorización evalúe cada solicitud y pueda negar una transacción aun con una credencial válida. El documento acepta que un token al portador puede reutilizarse durante su vigencia; recomienda vincularlo al emisor, pero no exige semántica de uso único. Duración corta no significa autorización infalible ni ausencia de reproducción.

La propuesta anterior sobre OAuth Transaction Tokens se ocupa de transportar contexto dentro de un dominio de confianza. BTW ya examinó la procedencia de las afirmaciones dentro de esos tokens firmados. Aquí el punto es distinto: el token de acceso que cruza hacia un servidor de recursos concreto y la posibilidad de unir, o no, los registros de varios destinatarios. Registrar un txn local ayuda al diagnóstico, pero la reconstrucción entre servicios depende de la autoridad que reservó la clave común.

Fuentes