Resumen

  • draft-ietf-oauth-status-list-21 permite que un Referenced Token señale una URI y un índice en una lista comprimida. Un Status List Token protegido comunica para muchos tokens estados como VALID, INVALID o SUSPENDED. La revisión 21 está aprobada y en la cola del RFC Editor, pero sigue siendo un Internet-Draft, no un RFC.
  • El valor representa por defecto el estado en el momento de emisión de la lista. iat, exp y ttl delimitan emisión, vigencia y caché; no documentan automáticamente la hora de la transición, su autoridad, la causa, la primera entrega ni la decisión local.
  • Daniel Kade propone un recibo externo y mínimo: huellas del token y de la lista, URI/índice, comprobación del emisor, cuatro relojes, semántica decodificada, límite local de frescura, decisión y rectificación. Es una guía editorial, no una exigencia del IETF ni un registro de vigilancia.

Una universidad revisa la apelación de una credencial suspendida. El verificador muestra una captura con un punto ámbar y la palabra SUSPENDED. El responsable de identidad confirma que hoy la credencial está activa. Falta el objeto intermedio: nadie puede demostrar qué lista protegida recibió el sistema, qué iat llevaba, si el ttl había vencido o a qué hora se ejecutó la regla de acceso.

No hay base para acusar a ninguno de los actores. La lección es documental. Token Status List responde de forma eficiente a «¿qué estado afirmó el Status Issuer en esta lista?». Una apelación pregunta además «¿qué sabía el sistema al decidir y cómo pasó de esa prueba a esta consecuencia?». Son contratos distintos.

La eficiencia del mecanismo depende de no convertir cada entrada en una ficha personal. Muchos tokens comparten una matriz de bits; el verificador descarga una lista, lee un índice y evita preguntar al emisor por una credencial identificable en cada presentación. Pedir al mismo bit que guarde autor, causa, transición y proceso local destruiría buena parte de esa economía.

La cola editorial no cambia el nombre del documento

El registro de Datatracker fecha la revisión 21 el 21 de junio de 2026 y la identifica como Internet-Draft de Standards Track del OAuth Working Group. El historial muestra la aprobación del IESG el 4 de junio sobre la revisión 20, el paso a la cola del RFC Editor, la nueva revisión el 21 de junio y el estado Awaiting First editor el 13 de agosto. Es un texto aprobado y avanzado, pero aún no un RFC.

La revisión 21 expira el 23 de diciembre de 2026. La comparación oficial 20→21 permite no atribuir a la versión equivocada una norma concreta. Tampoco se puede inferir adopción o prevalencia a partir del estado editorial. El OAuth Working Group controla el documento, no las instalaciones hipotéticas utilizadas aquí.

El borrador abarca credenciales y tokens protegidos mediante JOSE o COSE: JWT, SD-JWT, CWT e ISO mdoc, entre otros. JWS y JWT sostienen la variante JSON; CWT y COSE, la variante CBOR. La lista no sustituye al Referenced Token: aporta una afirmación separada sobre un estado que puede cambiar después de emitirlo.

Localizar una celda no explica su procedencia administrativa

En el Referenced Token, el mecanismo usa status_list con dos datos obligatorios. uri identifica el Status List Token. idx es un entero no negativo que selecciona la posición. El localizador permite encontrar la respuesta; no incluye el expediente que la originó.

El Status Issuer elige uno, dos, cuatro u ocho bits por entrada, asigna índices distintos, empaqueta los valores dentro de bytes empezando por el bit menos significativo y comprime el conjunto con DEFLATE en formato ZLIB. Los RFC 1951 y 1950 especifican esas capas. La estructura viaja en un JWT o CWT protegido por firma o MAC.

Hay tres papeles que una misma entidad puede acumular o repartir. El Issuer crea el Referenced Token. El Status Issuer recibe la información de estado y produce la lista autenticada. El Status Provider la entrega. Un CDN puede servir el mismo objeto sin poder modificar sus bytes protegidos. La integridad del contenido y la observación de entrega son pruebas distintas.

El registro inicial delimita la lectura: 0x00 significa VALID, 0x01 INVALID y 0x02 SUSPENDED; otras franjas quedan para la aplicación o futuros registros. Si una entrada tiene varios bits, todos forman un único valor. No es un pequeño conjunto de eventos simultáneos.

Además, VALID no sana el token. Primero deben cumplirse las reglas propias del Referenced Token: formato, claims, firma, vencimiento y cualquier otra restricción pertinente. El ejemplo normativo es claro: un token vencido sigue vencido aunque la lista diga VALID. Tras interpretar el estado, el relying party aún aplica su política de autorización.

Por eso un registro operativo debe distinguir cuatro resultados: token válido o inválido por sus propias reglas; lista validada o no; estado decodificado o imposible de afirmar; acción permitida o rechazada por la aplicación. Un semáforo único borra información esencial.

El tiempo del hecho, el tiempo de la lista y el tiempo del uso

El primer reloj pertenece a la fuente. Un administrador revoca, un motor suspende, una revisión restaura. El borrador no define ese proceso ni obliga a incluir su actor, evidencia o instante en el bit.

El segundo reloj es iat, obligatorio en el Status List Token: cuándo se emitió la afirmación protegida. exp, recomendado, fija el punto a partir del cual el Status Issuer considera caducada la lista. Esta ventana no dice cuándo ocurrió el cambio que afectó a una entrada.

El tercero pertenece al Provider y al cliente. Una lista puede llegar por infraestructura intermedia. El verificador la recupera a una hora concreta, quizá después de haber sido emitida. Esa hora demuestra recepción, no creación ni transición.

El cuarto es la decisión. El sistema puede evaluar enseguida o más tarde, con una caché y una regla local. La consecuencia depende de la edad aceptada, del estado y de otras condiciones del token y de la aplicación.

ttl expresa cuánto puede guardarse una copia antes de buscar otra. El documento contempla volver a consultar después de «hora de recuperación + ttl», útil para distribuir carga, o en iat + ttl para casos que necesitan mayor actualidad. Si las cabeceras HTTP discrepan de los claims protegidos, prevalecen exp y ttl del Status List Token. RFC 9110 aporta la semántica de red, pero el perfil y el relying party deciden qué retraso toleran.

El intervalo no puede elegirse en vacío. Una caché larga amplía la edad de una afirmación; una demasiado corta puede dirigir un caudal absurdo de consultas al Provider. La sección de seguridad exige límites razonables y advierte del potencial de carga accidental o maliciosa. Una prueba completa debe registrar la regla utilizada, no limitarse a copiar el número del ttl.

Las fotografías históricas no son el acta del cambio

El modo normal presenta la información más reciente. De forma opcional, un cliente puede añadir time=<timestamp>. Un servidor compatible devuelve una lista válida para ese instante o un error. Si un hosting estático ignora la consulta y entrega el objeto actual, el cliente ha de rechazarlo salvo que el tiempo solicitado quede dentro de la ventana protegida.

Con varias respuestas históricas se puede acotar una transición. Si a las 10:00 una entrada era VALID y a las 10:15 era INVALID, se sabe algo importante. No se sabe todavía si la orden se emitió a las 10:02, se procesó a las 10:07 o se incorporó a la lista a las 10:14. Tampoco se conoce motivo o responsable. Llamar «línea de tiempo de revocación» a esas dos fotos añade hechos que el formato no contiene.

La cautela protege también a la persona. El borrador recomienda no habilitar la resolución histórica sin una razón fuerte y análisis de privacidad. Un relying party que persiste URI e índice y consulta periódicamente puede construir un perfil del estado. Un tercero que archiva listas puede inferir volúmenes o tasas. La auditabilidad no exige convertir toda presentación en vigilancia perpetua.

La privacidad de rebaño necesita tamaño y disciplina

La lista agrupa muchas credenciales para que una consulta no revele por sí sola cuál interesa. El documento llama a este efecto «herd privacy». Aumentar el tamaño mejora el conjunto de anonimato, pero exige transferir más datos.

La protección se degrada con una URI única por token, una lista por persona, tamaños distintivos o índices que permiten correlación. La solicitud HTTP puede revelar la dirección del relying party. Dos verificadores que comparan el mismo par URI/índice pueden reconocer presentaciones del mismo Referenced Token. El RFC 9901 contextualiza la divulgación selectiva de SD-JWT; Oblivious HTTP ofrece una técnica de relé que puede ocultar al solicitante.

Entre las mitigaciones figuran el hosting de terceros, índices aleatorios o seudoaleatorios, entradas señuelo, varias listas, lotes de un solo uso y un índice nuevo al reemitir. La semántica también filtra: SUSPENDED puede revelar una fase laboral o administrativa que un simple rechazo no haría visible. Cada estado extra necesita una justificación de utilidad y privacidad.

Un índice fuera de rango no equivale a revocado

La decodificación tiene consecuencias. El orden de bits va del menos significativo al más significativo dentro del byte. Leer otro flujo, errar en la posición o manejar mal la compresión puede atribuir a un token el estado de su vecino. El borrador incluye vectores de prueba y recomienda validarlos.

La secuencia correcta conserva la explicación: validar el Referenced Token; resolver la URI; validar tipo, firma/MAC y claims de la lista; comprobar la unión entre sujeto y URI; aplicar caducidad, TTL y política de frescura; descomprimir; extraer el índice; interpretar el valor; aplicar la decisión local.

Cuando el índice está fuera de rango, no se puede afirmar ningún estado y el Referenced Token debe rechazarse. Cuando falla una comprobación de lista, tampoco puede afirmarse el estado y se recomienda el rechazo. Es un resultado de evidencia incompleta, no el valor INVALID. Mezclarlos impide distinguir revocación de fallo de infraestructura o validación.

El recibo que falta no debe convertirse en otra credencial

Daniel Kade propone conservar dos huellas y cuatro relojes. La primera huella identifica de forma mínima el Referenced Token; la segunda fija los bytes exactos del Status List Token. El recibo añade URI/índice, Status Issuer, Provider observado, resolución de clave, comprobación criptográfica, decodificador y significado registrado.

Después separa: hora de transición fuente si se conoce; iat y exp; ttl y hora de recuperación; edad de caché y hora de decisión. Declara si la consulta fue actual o histórica, el timestamp pedido, el límite local de frescura, la regla de aplicación, la acción y cualquier corrección posterior. Un dato desconocido se marca como desconocido; no se rellena con iat.

No es una extensión propuesta al IETF. Es una medida local para consecuencias que sobreviven a la caché. Debe usar hashes, referencias, control de acceso y retención limitada. The Policy Mirror inspira la comparación entre regla declarada y resultado; Running-Code Primacy obliga a mirar el camino ejecutado; Reality, Not Advocacy impide rellenar la incertidumbre. Ninguno prueba un incidente real.

Fuentes