Resumen

  • draft-mcguinness-oauth-client-attesters-00 define metadatos client_attesters con un issuer y un jwks_uri por garante. La revisión 00 es un Internet-Draft individual, no un RFC ni una norma adoptada.
  • El editor del cliente autoriza quién puede atestiguar; el servidor de autorización decide de forma independiente a quién confía y qué fuente de claves acepta.
  • Retirar el aval no invalida grants ni tokens ya emitidos. La terminación exige revocación separada y control de cachés, refresh y validadores directos.

Un equipo puede demostrar que borró un garante y, al mismo tiempo, no poder demostrar que terminó el acceso. No es una contradicción: la entrada publicada, la copia que conserva el servidor de autorización, la vida del token y la configuración de un servidor de recursos avanzan con relojes distintos.

El borrador OAuth 2.0 Client Attester Endorsement se ocupa del primer límite. ATTEST permite que un Client Attester haga afirmaciones firmadas sobre una Client Instance y su clave, pero no determina qué garante está autorizado a hablar por un client_id concreto. La propuesta coloca esa relación en la fuente autoritativa de metadatos del cliente.

Cada elemento de client_attesters nombra exactamente el issuer esperado y la ubicación HTTPS jwks_uri. El editor expresa una autorización limitada: ese garante puede presentar afirmaciones sobre ese cliente. La lista no convierte al garante en confiable para el servidor, no autentica por sí sola una instancia y no concede acceso a ningún recurso.

La confianza requiere una intersección

La aceptación ocurre solo en la intersección de dos conjuntos. Los metadatos actuales deben avalar el iss de la atestación, y la política del servidor debe permitir esa asociación cliente-garante y establecer la confianza en las claves. El servidor puede reducir el conjunto publicado; no puede añadir un garante que el cliente no avaló. El editor puede retirar o limitar su lista; no puede dictar la política del servidor.

En el modo publisher-authorized key selection, el servidor ha autorizado previamente al editor a seleccionar también la fuente de claves. Recupera el jwks_uri avalado bajo controles de HTTPS, origen, ruta y red. Es útil a gran escala, pero no ofrece independencia respecto del editor: quien controle el CIMD puede escoger un garante y una infraestructura de claves propios.

En AS-configured attester trust, el servidor configura la fuente para el issuer exacto. El jwks_uri publicado debe coincidir con ella o con un alias aprobado, y no sirve como alternativa automática. Una discrepancia falla. Así se evita que el editor reemplace una raíz local o que el servidor reescriba en silencio lo que el editor declaró.

La precedencia es amplia. Si existe confianza configurada para un issuer exacto en cualquier cliente, ese régimen gobierna al issuer para todos. Quitar la configuración no entrega de inmediato la selección a los editores. Los alias también abarcan al issuer. Por eso un cambio aparentemente menor debe revisarse como una modificación compartida.

Elegir la clave no consiste en encontrar un kid

Primero se selecciona una sola fuente autoritativa de metadatos para el client_id; no se mezclan registro y CIMD ni se cambia de fuente después de un fallo. Luego se encuentra la única entrada cuyo issuer coincide exactamente con iss, se aplica la política, se elige el origen de claves y se exige que kid resuelva a una única clave pública asimétrica apta.

La clave queda vinculada a cliente, issuer, fuente y política. Un kid aislado o una bolsa de claves de varios garantes no preserva esa relación. Los encabezados jku, x5u, x5c y jwk no seleccionan la clave. Tras ello se valida firma, prueba de posesión, igualdad exacta sub == client_id y el resto de ATTEST.

Todavía falta la autorización. Una atestación aceptada dice algo sobre la instancia que se presenta; no decide el scope, el actor, el recurso ni la operación. Conservar esta separación impide que la evidencia de identidad herede privilegios que nadie aprobó.

Retirar, observar y revocar

El editor retira un garante borrando su entrada. Sin embargo, una copia fresca puede seguir siendo válida hasta alcanzar el máximo configurado. El borrador exige que ese máximo sea finito, pero no fija una cifra. Un acuerdo de confianza debe convertir la latencia en un compromiso mensurable.

Si el servidor observa 404 o 410 en el CIMD o el JWK Set, deja de usar lo almacenado. Un timeout o un 5xx no invalida una copia que aún no caducó. Mientras consulta la copia, desconoce el borrado remoto.

La rotación planificada exige solapamiento: publicar la nueva clave, esperar los cachés, firmar después y mantener la clave vieja hasta que expiren las atestaciones. Cambiar la ubicación necesita además la actualización de metadatos y, en modo configurado, coordinación con el operador.

Nada de esto revoca un grant existente. Para terminar acceso hay que revocar grants y tokens, impedir refresh, publicar estado inactive mediante introspección y considerar los recursos que validan localmente hasta la expiración. Un servidor de recursos que valida Client Attestations directamente usa confianza configurada; la retirada en los metadatos del cliente no le llega por este perfil.

Un recibo debe conservar la cadena de decisiones

La evidencia operativa empieza con el client_id, la fuente de metadatos elegida, su hash, edad y vencimiento. Añade el aval exacto y la autoridad del editor. Después registra el modo de confianza, su precedencia, fuente o alias, hash y frescura del JWK Set, kid, algoritmo y clave única.

El resultado de la firma se acompaña de una respuesta esencial: ¿la atestación era obligatoria? Publicar client_attesters no la hace obligatoria. Si era una señal opcional junto a otra credencial, el servidor puede continuar sin ella según su política. El grant se registra aparte.

Durante una retirada, el recibo incorpora la primera observación, convergencia de cachés, última aceptación, vencimiento de atestaciones, revocación, refresh, introspección, horizonte de tokens offline y validadores directos. Es un modelo operativo propuesto por Daniel Kade, no texto normativo del borrador.

La respuesta pública invalid_client_attestation no revela qué condición falló. Esa opacidad evita filtrar política, pero obliga a que la telemetría interna distinga ausencia de aval, conflicto de fuente, kid ambiguo y fallo transitorio. Reemitir una atestación no corrige un desacuerdo de autoridad.