A chave mudou. A continuidade da instância ainda dependia de um livro-razão.

Resumo

• O client_instance_id proposto pode permanecer igual após uma troca de chave verificada, mas seu valor probatório vem do cadastro do atestador, e não da sequência de caracteres.
• Continuidade da identidade, continuidade do vínculo de chave, confiança no atestador, mapeamento no token e identificação do apresentador atual são decisões distintas.
• A operação defensável precisa conservar um recibo tipado: emissor, cadastro, granularidade, Receiver Scope, chaves anterior e atual, evento de ciclo de vida, frescor, mapeamento e prova do apresentador.

Imagine o momento mais perigoso de uma rotação bem-sucedida. A chave antiga já foi retirada; uma nova atestação chega com outra chave e o mesmo identificador. O servidor reconhece a instância, recupera uma concessão anterior e segue adiante. A criptografia pode estar perfeita e, ainda assim, a decisão decisiva não está na nova chave.

Ela ocorreu quando alguma autoridade concluiu que o novo portador sucede o cadastro anterior. A chave não lembra de sua antecessora. O identificador opaco não revela se houve atualização, reinstalação, clonagem, restauração de snapshot ou substituição. A continuidade é uma afirmação histórica mantida por quem controla o cadastro.

O draft-mcguinness-oauth-client-instance-id-00, publicado em 28 de setembro de 2026, torna esse limite explícito. Trata-se de um Internet-Draft individual, destinado ao Standards Track segundo seu texto, sem estado de grupo de trabalho, AD responsável, telechat ou fluxo de RFC no Datatracker. Ele substitui o desenho anterior de uma assertion separada. O documento-base de autenticação por atestação está no OAuth WG e em Working Group Last Call, mas isso não constitui adoção deste perfil individual. As fontes congeladas não provam implementação, interoperabilidade, implantação nem resultado operacional.

A pergunta histórica não cabe na prova de posse

O mecanismo-base verifica se uma Client Instance autorizada possui uma chave. O perfil acrescenta outra pergunta: é a mesma instância já encontrada por este Receiver? Uma atestação nova resolve a posse presente; não resolve sozinha a sucessão entre duas chaves.

O identificador estável oferece um ponto de referência. Sua identidade exata é o par (iss, client_instance_id), porque o mesmo texto emitido por outro atestador não representa a mesma origem. O Logical Client, designado por client_id, é um conjunto mais amplo: muitas instalações, contêineres ou processos podem pertencer a ele. O principal autorizado é ainda outro objeto.

Misturar essas camadas produz autoridade acidental. Possuir a chave atual não concede herança automática do cadastro anterior. Ser reconhecido como a mesma instância não transfere, por si só, a vinculação de um refresh token. Ter participado da emissão de um token não prova que o mesmo processo o apresenta agora. E nenhuma dessas evidências demonstra que o recurso executou a operação pretendida.

O ID é uma etiqueta para uma decisão preservada

O draft exige identificadores distintos, opacos, imprevisíveis e jamais reatribuídos. Eles não devem conter hostname, usuário nem atributos da instância. Mesmo quando o valor parece uma URI, o Receiver o compara como uma string exata e não deve deduzir escopo, granularidade ou local da chave.

Essas propriedades evitam vazamento e colisão, mas não criam continuidade. O atestador precisa conservar o cadastro ativo, o Logical Client, o Receiver Scope, a granularidade, as chaves previamente aceitas e a evidência que autorizou a transição de custódia. Na rotação, ele verifica posse fresca da nova chave e registra qual controle estabeleceu a sucessão.

As regras de ciclo de vida revelam o verdadeiro produto. Renovação, troca verificada, reinício de processo quando a granularidade é instalação e atualização no lugar podem manter o identificador. Reinstalação, clone independente, substituição, reinício quando a granularidade é execução e mudança de granularidade exigem novo cadastro. Restauração ou rollback precisam de nova prova de sucessão; copiar dados e chaves não basta. Um fork detectado deve aposentar ou separar os pretendentes, salvo evidência autenticada que escolha o continuador.

Portanto, apagar os registros de continuidade obriga novo cadastro. Um insumo estável da plataforma não pode sozinho regenerar o mesmo ID após reinstalação, pois isso ressuscitaria uma identidade aposentada. A string só é útil como índice para uma máquina de estados governada.

Receiver Scope é política invisível no artefato

Por padrão, o identificador é pareado a um Receiver. Contudo, Receiver Scope é uma entrada administrativa de cadastro ou emissão, não um parâmetro OAuth nem a audience da atestação. O Receiver não consegue ler no identificador se recebeu o escopo correto.

O atestador deve atribuir IDs diferentes por Receiver, a menos que exista acordo explícito para um escopo compartilhado. O cliente também deve separar Client Instance Keys entre escopos que se pretende isolar. Caso contrário, a mesma chave pode recompor a correlação que os IDs pareados tentavam impedir.

Se o cliente encaminhar uma atestação ao Receiver errado, o destinatário não identifica a violação olhando a string. A garantia depende da configuração seguida pelo cliente e pelo atestador. Um recibo operacional precisa, portanto, registrar o escopo configurado, a versão da política e o sistema responsável por aplicá-los.

O desenho de privacidade é uma escolha entre observadores. IDs pareados reduzem a correlação entre Receivers, mas deixam o atestador saber o Receiver Scope. Um escopo compartilhado oculta o destino individual do atestador ao custo de permitir que os Receivers correlacionem a instância. Reutilizar chaves de instância ou DPoP pode desfazer ambas as separações.

Confiança no atestador é uma associação local

O Receiver deve ligar cada Attester Issuer aprovado às suas chaves de validação e aos Logical Clients pelos quais pode falar. Um iss declarado, uma prova de posse ou metadados publicados pelo próprio cliente não criam essa autoridade. Client Attester Endorsement pode ajudar o servidor de autorização, mas validadores diretos ainda precisam de associações configuradas.

Há duas aprovações: o atestador afirma que o portador sucede uma instância cadastrada; o Receiver decide se aquele atestador tem autoridade para fazer a afirmação naquele contexto. Uma assinatura correta de um emissor não aprovado continua inadequada. Um emissor aprovado, por sua vez, pode ser comprometido ou exagerar a qualidade da evidência.

O próprio perfil não transforma autodeclaração, verificação de plataforma e raiz de hardware em garantias equivalentes. Sem evidência independente, chaves e estado copiados podem ser indistinguíveis do original. A automação precisa preservar o nível de evidência, não reduzir tudo a “atestado válido”.

Identidade contínua não rebinda a concessão

Um cadastro pode sobreviver à troca de chave sem que um refresh token passe automaticamente para a nova chave. O vínculo padrão do token continua associado à Client Instance Key anterior, salvo outro perfil autorizado definir a mudança.

Na renovação, o servidor precisa verificar separadamente que a Source Instance Identity coincide com a registrada e que a prova atual satisfaz o vínculo de chave exigido pela concessão. A primeira verificação trata da história; a segunda, de quem pode usar a concessão agora.

Essa separação impede um atalho frequente: manter a mesma linha de banco, trocar o certificado e supor que toda autoridade migrou. O recibo correto aponta qual decisão autorizou a transição do credential para aquela concessão, sob qual política e com qual prova de posse presente.

Suspensão opera com vários relógios

O atestador deve parar de emitir para cadastro suspenso ou aposentado. O servidor de autorização pode revogar concessões ou marcar tokens como inativos. Ainda assim, atestações já emitidas permanecem aceitáveis até seu vencimento; access tokens têm vida própria; um validador offline não recebe automaticamente uma revogação local. A distribuição de status está fora do escopo.

Além disso, recadastro ou Receiver Scope diferente pode produzir uma nova identidade que o Receiver não associe à suspensa. Contenção depende de política de admissão, coordenação com o atestador e janelas de validade ainda abertas. “Suspenso” sem autoridade, momento efetivo, cadastro afetado, conjunto de tokens e alcance da notificação descreve apenas uma linha local.

O contexto downstream cria uma segunda autoridade

O objeto opcional client_instance permite que um emissor de token exponha contexto validado ao resource server. Ele não precisa repetir o ID bruto do atestador. O emissor mapeia a Source Instance Identity para seu próprio par (iss, id) dentro de um Consumer Scope definido pela audience.

Esse mapa tem obrigações próprias. Deve separar instâncias, permanecer estável durante renovação e rotação verificadas e continuar reproduzível enquanto concessões ou tokens relevantes forem válidos. Se o emissor perder o mapa, deve omitir o contexto, não inventar outro. Token sem audience, ou com audiences que atravessam Consumer Scopes, não tem mapeamento único e deve omiti-lo. Um chamador de introspecção fora do escopo não deve recebê-lo.

Assim surgem dois livros-razão: um do cadastro para a Source Instance Identity e outro da origem para a identidade consumida downstream. Autoridades e retenções não coincidem. Perder o primeiro rompe a história da instância; perder o segundo rompe a continuidade da política do consumidor. Substituí-los silenciosamente falsifica o passado.

Participar da emissão não é apresentar a requisição

Instance Context não concede autoridade. Sem perfil consumidor e sender constraint validado, ele diz apenas qual instância participou da obtenção do token. Não atribui a requisição HTTP atual àquela instância.

DPoP, mutual TLS ou outro vínculo definido pode demonstrar o apresentador em emissão direta. Uma chave compartilhada não distingue instâncias. Um bearer token não suporta a atribuição. Se o consumidor exige essa certeza e o emissor não consegue fornecer o vínculo, o contexto precisa ser omitido e a política deve falhar de modo explícito.

Token exchange amplia o problema. Validar o input token autentica as afirmações de seu emissor, não cada autoridade anterior preservada no contexto. Um perfil consumidor deve dizer se o valor representa a instância atual ou uma instância upstream e como prova associação, preservação ou remapeamento. O objeto identifica uma instância; não é actor chain nem token separado.

O recibo de continuidade

Uma implementação auditável deveria produzir um recibo tipado. Ele começa pelo emissor do atestador, chave de validação, Logical Client, cadastro, granularidade, Receiver Scope e versão da política de confiança. Em cada transição, liga fingerprints das chaves anterior e atual, evento de ciclo de vida, prova de custódia, testes de continuidade, frescor, horário e resultado: retido, novo cadastro, aposentado, suspenso ou bifurcado.

Para concessões, mantém separadas Source Instance Identity, vinculação de chave e eventual perfil de rebinding. Para consumo, registra emissor do token, entrada do mapa, Instance Context, Consumer Scope, audience, época de retenção e proveniência de preservação. Em cada requisição, registra sender constraint e decisão local do resource server.

Por fim, liga a operação protegida ao resultado observado. Uma rotação válida fecha somente a transição que nomeia. Não prova integridade atual do software, autorização corrente, identidade do apresentador, execução nem efeito para o usuário.