Resumen

  • draft-mcguinness-oauth-client-instance-id-00 permite mantener client_instance_id después de un cambio de clave verificado, pero esa igualdad es una afirmación respaldada por el historial del atestador.
  • Continuidad de identidad, continuidad de la clave ligada al grant, confianza en el emisor, alcance, autorización y atribución del presentador actual son comprobaciones independientes.
  • El recibo operativo debe enlazar enrolamiento, granularidad, Receiver Scope, evento de vida, claves anterior y nueva, frescura, proyección al Consumer Scope y prueba del presentador.

Una aplicación administrada cambia su clave. El servidor recibe una atestación válida, ve el mismo identificador y recupera decisiones que pertenecían a la instalación anterior. La operación parece una simple búsqueda en una tabla.

Sin embargo, la clave nueva no recuerda la anterior. El texto opaco no explica si hubo actualización, reinstalación, clonación o restauración. Alguien decidió que el solicitante heredaba el pasado. Ese alguien es el Client Attester y la base de esa decisión es su registro de enrolamiento.

La revisión 00 fue publicada el 28 de septiembre de 2026 como Internet-Draft individual con intención Standards Track. No es un documento adoptado por el grupo OAuth, un RFC, una asignación IANA definitiva ni prueba de producto. Sustituye el diseño anterior de una aserción separada. El borrador base de autenticación por atestación está en Last Call del grupo, pero esa condición no se transfiere a este perfil.

Posesión y continuidad responden preguntas distintas

La atestación base demuestra que una instancia autorizada posee una clave actual. El perfil intenta reconocer a la misma instancia tras cambiarla. Una nueva atestación es necesaria, aunque por sí sola no distingue una instalación continua de otra recién creada.

El atestador asigna client_instance_id. La identidad fuente no es la cadena aislada, sino (iss, client_instance_id). El cliente lógico identificado por client_id puede abarcar muchos portátiles, contenedores o agentes. El principal humano o delegado tampoco es la instancia.

Esta separación tiene consecuencias prácticas. La posesión es un hecho del presente. La continuidad es una afirmación histórica. El permiso es una decisión del Receiver. La ejecución pertenece al servidor de recursos. El resultado se observa después. Un JWT correcto no cierra esa cadena completa.

La evidencia está en el enrolamiento

Los identificadores deben ser distintos, opacos, impredecibles y no reasignables. No pueden codificar usuarios, nombres de host ni atributos de ejecución. Aunque tengan forma de URI, no deben interpretarse como URI. Estas restricciones evitan que el consumidor fabrique significado, pero no demuestran la sucesión.

Para conservar el identificador, el atestador verifica un enrolamiento activo que une instancia, cliente lógico, Receiver Scope, granularidad y claves previas. Comprueba posesión fresca de la clave actual y evidencia autenticada del cambio de custodia. También registra los controles de continuidad, su frescura y los eventos de ciclo de vida.

Una renovación o rotación verificada puede conservar el ID. También un reinicio de proceso si la unidad se definió como instalación. Una reinstalación, un clon independiente, un reemplazo o el reinicio de una unidad definida como ejecución requieren enrolamiento nuevo. Una instantánea restaurada necesita evidencia fresca de sucesión; copiar datos y claves no basta. Un fork detectado obliga a retirar o separar identidades salvo que la evidencia señale al continuador.

Por eso perder el registro exige enrolar otra vez. El identificador es la etiqueta del historial, no su sustituto. Incluso una derivación determinista necesita una entrada única de enrolamiento para no recrear un ID retirado después de una reinstalación.

El alcance no viaja como una propiedad comprobable

Por defecto, el atestador crea identificadores distintos para cada Receiver. Pero Receiver Scope es una entrada administrativa de enrolamiento o emisión, no un parámetro OAuth ni la audiencia de la atestación. El Receiver no puede deducir del ID cuál era el alcance correcto.

Compartir un identificador entre Receivers exige un acuerdo explícito. Compartir cliente lógico o dominio de confianza no lo autoriza. Además, las claves de instancia deben separarse entre alcances; de lo contrario, una huella común correlaciona registros aunque los IDs sean diferentes.

Así, un cliente puede presentar fuera de alcance una atestación bien formada y el Receiver no lo detectará mirando el valor. El recibo de control debe conservar el alcance configurado, la política y la parte responsable de aplicarlos.

La autoridad del atestador también es local

El Receiver asocia cada issuer aprobado con claves de validación y clientes lógicos autorizados. El claim iss, una firma válida o metadatos publicados por el cliente no crean esa relación. La aprobación del publisher y la confianza del servidor de autorización son controles separados, como ya explica el artículo adyacente sobre Client Attester Endorsement.

Aquí el riesgo aparece después de aceptar al atestador. Si se compromete, puede suplantar instancias dentro de sus asociaciones. Si exagera la calidad de su evidencia, derrota la política de confianza. Evidencia autodeclarada, verificada por plataforma y enraizada en hardware no son equivalentes.

Sin observación independiente, un clon con claves y estado copiados puede ser indistinguible del original. El borrador prescribe qué hacer ante forks detectados; no promete detectar aquello que la plataforma no observa.

El grant no sigue automáticamente a la identidad

El perfil permite que la identidad fuente permanezca estable. No cambia por sí solo la clave a la que está ligado un refresh token. En un refresh, el servidor debe verificar por separado que la identidad actual coincide con la registrada y que la prueba satisface la vinculación de clave original o un perfil autorizado de rebinding.

Una comprobación responde “es la misma unidad enrolada”. La otra responde “esta petición posee la credencial admitida por este grant”. Confundirlas convertiría una rotación de identidad en transferencia silenciosa de autoridad.

La misma regla debería aplicarse a códigos y otros artefactos ligados a instancia: si el servidor hizo depender la autorización de la instancia, debe exigir la evidencia al redimirlos. No puede permitir una ruta alternativa que omita la señal justo donde necesita comprobarla.

La suspensión no se propaga sola

El atestador deja de emitir para un enrolamiento suspendido o retirado. El servidor de autorización puede revocar grants y marcar tokens inactivos. Aun así, una atestación anterior puede sobrevivir hasta expirar, un token hasta el final de su vida y un recurso que valida offline puede no conocer la revocación.

El perfil no define distribución de estado. Tampoco impide que la instalación aparezca con identidad nueva tras un enrolamiento de reemplazo o en otro Receiver Scope. Contenerla requiere reglas de admisión, coordinación con el atestador, inventario de tokens y un presupuesto explícito de demora.

Un estado “suspendido” sin autoridad, instante efectivo, enrolamiento afectado y cobertura de notificación es solo una fila local.

La proyección downstream crea otra autoridad

El objeto opcional client_instance permite transmitir contexto en un token o respuesta de introspección. El token issuer proyecta la Source Instance Identity a su propio par (iss, id) dentro de un Consumer Scope. No tiene por qué exponer el ID original.

La proyección debe ser estable mientras sobrevivan tokens o grants. Si deja de ser reproducible, se omite; no se inventa un reemplazo. Sin audiencia, o con audiencias que cruzan Consumer Scopes, no existe una única representación correcta. Un caller de introspección fuera del alcance tampoco debe recibirla.

Aparecen dos registros: el atestador mantiene la sucesión del enrolamiento y el emisor mantiene la vista para cada consumidor. Tienen autoridades, secretos y períodos de retención diferentes. La pérdida de cualquiera es una ruptura que debe hacerse visible.

Participar en la emisión no prueba presentar ahora

Instance Context no otorga autoridad. Solo señala que la instancia participó en la obtención del token. Para atribuir la petición actual se necesita sender constraint: DPoP, mutual TLS u otro mecanismo definido por el perfil, usando una clave asociada a esa instancia.

Una clave compartida entre instancias no individualiza. Un bearer token sin prueba no atribuye presentador. En token exchange, validar el token de entrada autentica las afirmaciones de su issuer, no toda autoridad upstream nombrada en su interior. La política debe definir preservación, remapping, procedencia y asociación con sujeto, actor o presentador.

Incluso una prueba DPoP correcta cierra solo ese borde. No demuestra que el servidor autorizó la acción, la ejecutó una vez o produjo el resultado pretendido.

La privacidad elige quién puede correlacionar

IDs diferentes por Receiver reducen la correlación entre Receivers, pero el atestador aprende el Receiver Scope. Un alcance compartido oculta destinos individuales al atestador a cambio de permitir que los Receivers unan la actividad.

La separación falla si se reutiliza la misma clave DPoP o certificado. IDs distintos pueden mostrar la misma huella. Otros claims y datos de aplicación también enlazan eventos. La propiedad real no es “pairwise” en una columna, sino la capacidad conjunta de observadores, claves y retención.

El recibo que falta

El recibo debe nombrar issuer, clave de validación, cliente lógico, enrolamiento, granularidad, Receiver Scope y política de confianza. Cada cambio enlaza claves anterior y nueva, evento, evidencia de custodia, frescura y decisión: conservar, re-enrolar, suspender, retirar o dividir.

Los grants registran identidad fuente y vinculación de clave como campos separados. La capa downstream registra emisor, entrada de mapping, Context ID, Consumer Scope, audiencia y procedencia. La petición registra la prueba del presentador y la autorización local. La ejecución y el resultado cierran la cadena sin ser inferidos del ID.