Resumo

  • A versão -00 de uma proposta individual apresentada em 28 de setembro de 2026 define client_instance_id, atribuído pelo atestador e passível de continuidade após uma troca de chave verificada. Ainda não é RFC, posição de um grupo de trabalho ou evidência de adoção.
  • O identificador não altera o vínculo de tokens de renovação já emitidos. Pela regra padrão do documento-base, usar a nova chave com um token preso à antiga falha, mesmo que a instância seja reconhecida; outro perfil aplicável teria de mudar essa regra.
  • Para concessões feitas sob a proposta, o servidor compara a identidade da instância numa atestação atual com a Source Instance Identity registrada. Essa comparação não dispensa a prova de posse nem a verificação do vínculo do token.

A continuidade que não cabe dentro do token antigo

Pense em uma equipe que substitui a chave criptográfica de um cliente instalado. O atestador examina a passagem entre a chave antiga e a nova e confirma que a instalação permanece a mesma. O servidor de autorização, por sua vez, recebe um token de renovação emitido antes da mudança. Se a plataforma reduzir tudo a um único campo — “ID da instância bateu” — poderá aceitar uma credencial fora da condição em que foi originalmente concedida.

A proposta inicial de K. McGuinness não autoriza esse salto. Na seção 5.1, ela afirma que seu perfil de identidade não faz novos vínculos de concessões à instância e não realoca para outra chave os tokens existentes. O documento-base de autenticação com atestação vincula, por padrão, o token de renovação à Client Instance Key. Uma tentativa de renovar usando a chave substituta, portanto, falha nesse vínculo. Apenas um perfil separado e efetivamente aplicável poderia estabelecer outro comportamento; a simples presença de client_instance_id não basta.

Não se trata de escolher qual verificador está “certo”. O atestador pode acertar ao reconhecer a instalação, e o servidor pode acertar ao recusar o token. O primeiro resultado fala da continuidade de uma inscrição. O segundo aplica uma condição concreta de uma credencial. Transformar uma identidade persistente em autorização móvel seria uma decisão de política, não uma consequência automática da criptografia. Equipes que desejem uma transição de acesso precisam declarar sua regra e sua evidência, em vez de escondê-las sob o nome da instância.

Um nome durável precisa de um limite de inscrição

O identificador proposto deve ser opaco, difícil de prever e jamais redistribuído a outra instância. Atestação de uma sucessão autenticada pode manter o mesmo valor após a troca de chave. Reinstalar, criar um clone independente ou iniciar outra unidade de execução normalmente exige uma nova inscrição. Copiar chave, dados e identificador não demonstra continuidade. Até uma imagem restaurada precisa trazer evidência nova e autenticada de sucessão. Esse cuidado impede que uma cópia obtenha a aparência de legitimidade apenas por exibir material antigo.

Há ainda um limite de privacidade. O valor é, por padrão, próprio de um Receiver, não um número universal reutilizável em todos os serviços. Cliente e atestador precisam escolher o escopo conscientemente e separar chaves entre escopos. Um Receiver isolado não consegue verificar apenas pela sua atestação o que foi apresentado em outros. A proposta também afirma que a identidade da instância não determina sub, não amplia uma cadeia act e não substitui prova de posse. O contexto opcional client_instance em token ou introspecção informa qual instalação aparece na transação; não concede poderes novos a ela.

Quando uma concessão foi criada sob esse perfil, o servidor de autorização registra a Source Instance Identity. No pedido de renovação, verifica uma atestação atual e confere se a identidade coincide com a registrada. A divergência impede a continuidade por essa via. A coincidência, contudo, não conserta um token cujo vínculo com a chave não foi satisfeito. Registrar os dois resultados permite explicar uma recusa correta, mesmo quando a troca de chave foi corretamente autenticada.

O Datatracker mostra um Internet-Draft individual em seu primeiro número, com estado I-D Exists. “Standards Track” indica uma pretensão do texto, não aprovação do IETF. Não há nessa fonte comprovação independente de implantação, interoperabilidade ou incidente. A análise aqui examina um desenho proposto e seus controles, não um comportamento já observado em produção.

Fontes