Resumen

  • client_attesters permitiría al editor de un cliente OAuth publicar los atestadores que avala, pero el servidor de autorización conservaría la decisión independiente de aceptarlos.
  • La retirada solo impide autenticaciones futuras con el aval eliminado cuando el servidor ve el cambio. Los permisos y tokens anteriores necesitan una revocación aparte.

Un administrador elimina hoy un atestador de la lista autorizada de un cliente. ¿En qué momento dejó de poder abrir una puerta? La respuesta no está en el instante de edición. Hay al menos dos relojes: el de los metadatos que conserva el servidor de autorización y el de las credenciales de acceso que ya circulan ante los servidores de recursos. El nuevo borrador de K. McGuinness es valioso precisamente porque no confunde esos relojes.

Se trata de una versión individual -00, fechada el 28 de septiembre de 2026 y con intención de llegar a Standards Track. La ficha oficial indica que el Internet-Draft existe; no acredita que sea un RFC, que el grupo OAuth lo haya adoptado, que haya interoperabilidad probada o que haya ocurrido una emergencia real. El texto complementa el trabajo de autenticación de clientes basada en atestación. No introduce una credencial distinta. Propone expresar en los metadatos una relación que aquel trabajo dejaba fuera: qué entidad puede atestiguar instancias de este cliente.

El editor autorizado del cliente añadiría client_attesters en un registro o en un Client ID Metadata Document. La entrada identifica al atestador y dónde encontrar sus claves de verificación. Sin embargo, avalar no equivale a confiar. Para aceptar una atestación dentro de este perfil, el servidor de autorización debe hallar un aval vigente para el emisor y, por separado, permitirlo conforme a su propia política y selección de claves. Una política de servidor no puede incorporar un atestador que el cliente no avaló; una lista del cliente no puede imponerle confianza al servidor. Tampoco cualquiera de las dos decisiones concede por sí misma permiso de acceso a un recurso.

El primer reloj es de caché. El borrador exige máximos finitos configurados para copias de metadatos de aval y conjuntos JWK; las entradas caducadas deben renovarse o rechazarse. Pero no fija un máximo idéntico para todos los despliegues. Mientras una copia anterior siga vigente, el servidor puede no haber observado la eliminación. Una vez que obtiene o almacena el cambio, debe aplicarlo a la siguiente presentación. En cambio, una prohibición fijada directamente por la política del servidor rige para las solicitudes posteriores sin esperar a que expire esa copia. Las reglas de caché no describen los registros de cliente autoritativos.

Por eso un editor que necesita un límite de propagación previsible tiene que pactarlo con el operador, no deducirlo del número de versión del proyecto.

El segundo reloj empieza con lo que ya fue emitido. El apartado 6.3 declara expresamente que retirar un aval impide autenticaciones futuras bajo ese aval, pero no revoca concesiones ni tokens de acceso existentes. Las solicitudes de renovación que requieren una atestación pasan otra vez por el control. Para cerrar una relación de acceso, hay que revocar por separado las concesiones y tokens afectados e impedir nuevas renovaciones. La introspección definida por RFC 7662 puede declarar inactivos los tokens revocados; un servidor de recursos que valida localmente necesita otra vía de revocación o esperar su vencimiento. Una lista de atestadores corregida no sustituye a ese trabajo.

Hay además una pregunta sobre independencia. Si el editor puede escoger al atestador y sus claves, puede ser él mismo quien opera el atestador; tal prueba no aporta garantía independiente del editor. Si otra forma de autenticar al cliente sigue permitida y la atestación es opcional, publicar la lista tampoco obliga a usarla. El proyecto advierte incluso que la toma del sitio de metadatos puede alterar avales dentro de la política del servidor sin dejar una señal independiente de mala intención. Son límites hipotéticos del diseño, no acusaciones contra un servicio concreto.

Como práctica de supervisión, convendría conservar una secuencia verificable: edición autorizada, conjunto anterior y nuevo de avales, fuente de claves y política del servidor, duración real de las copias, primera autenticación rechazada, concesiones afectadas, fin de la renovación y resultado de validación en cada servidor de recursos. Esa secuencia es una propuesta periodística de control, no un artefacto exigido por el borrador. Evita que un cambio en un documento se presente como la extinción demostrada de una capacidad que ya salió del documento.

Fuentes