Resumen

  • El 28 de septiembre de 2026 apareció la versión inicial de una propuesta individual sobre client_instance_id. El atestador puede mantener ese identificador al verificar que una clave nueva pertenece a la misma inscripción; no es una RFC ni una decisión del IETF.
  • La propuesta no vuelve a vincular los tokens de actualización ya emitidos. Bajo la regla predeterminada del borrador base, un token asociado a la clave antigua no se renueva con la nueva, aunque coincida el identificador de instancia.
  • Para concesiones emitidas bajo el perfil propuesto, el servidor compara también la identidad de instancia de una atestación actual con la que registró al conceder acceso. La comparación y la prueba exigida por el token siguen siendo controles distintos.

El cambio de clave no es un cambio de contrato

Un equipo decide retirar la clave de una aplicación instalada y acreditar una sustituta. El atestador ve pruebas suficientes de continuidad y firma una nueva atestación con el mismo client_instance_id. Si el servidor de autorización solo comprueba ese nombre persistente, podría permitir que un token de actualización emitido antes de la rotación abra la sesión con la clave nueva. Esa conclusión parece práctica, pero modifica de hecho la condición con la que se emitió el token.

La versión -00 presentada por K. McGuinness traza otra frontera. Su sección 5.1 dice que el perfil identifica una instancia a través de cambios de clave verificados; no crea concesiones vinculadas a la instancia ni reata a otra clave los tokens existentes. El borrador base de autenticación mediante atestación liga por defecto el token de actualización a la clave de la instancia. Si se presenta con una clave distinta, la prueba falla bajo esa regla. Otro perfil aplicable podría redefinir la vinculación, pero el identificador nuevo no lo hace por sí solo.

No hay contradicción entre los resultados. El atestador puede responder correctamente «es la misma instalación» y el servidor puede responder correctamente «este token no acepta esa clave». Uno establece continuidad de identidad; el otro aplica una restricción sobre una credencial ya concedida. Convertir el primer resultado en sustituto del segundo sería una decisión de autorización que el texto no delega al atestador. El problema de gobierno no consiste en impedir la rotación, sino en registrar qué derecho, si alguno, debe acompañarla y mediante qué procedimiento.

Cuándo deja de ser la misma instancia

El identificador propuesto es opaco, impredecible y no reutilizable para otra inscripción. Un cambio de clave con pruebas autenticadas puede conservarlo. En cambio, reinstalar la aplicación, producir un clon independiente o empezar una unidad de ejecución nueva exige una inscripción nueva. Una copia de la clave, de los archivos o del identificador anterior no demuestra sucesión. Incluso una instantánea restaurada necesita una prueba fresca de que el nuevo estado es el sucesor autorizado. El proyecto no promete que toda rotación preserve la identidad; exige que la continuidad tenga una base verificable.

Por defecto, la identidad se limita a un Receiver, no a todos los destinatarios de la red. Esto dificulta correlacionar instalaciones entre receptores, siempre que el atestador y el cliente mantengan la separación de ámbitos y claves. No sería correcto presentar client_instance_id como un número global inmutable de dispositivo. Tampoco debe confundirse con una persona: la propuesta dice expresamente que la identidad de la instancia no otorga autoridad, no determina por sí sola sub, no amplía una cadena act y no sustituye una prueba de posesión. La posibilidad de exponer un contexto client_instance en un token o una introspección es informativa, no una cesión automática de privilegios.

La sección 5.1 añade una obligación específica para las concesiones creadas bajo este perfil: registrar la Source Instance Identity y, en cada actualización, validar una atestación actual cuyo identificador coincida con ese registro. La ausencia o discordancia impide aprobar por esa vía. Una coincidencia, sin embargo, no rescata un token cuya prueba de vinculación a clave fracasa. En un tablero operativo, ambos controles deberían conservar estados separados; un único indicador verde ocultaría justamente la frontera que la propuesta aclara.

El registro de Datatracker identifica el documento como Internet-Draft individual en estado I-D Exists. Que su autor indique Standards Track como destino deseado no significa adopción por un grupo de trabajo, RFC publicada ni implantación. Las fuentes revisadas no acreditan un incidente, ataques observados o pruebas de interoperabilidad. Este análisis describe las consecuencias de un diseño propuesto.

Fuentes