Resumo

  • O Internet-Draft de 28 de setembro propõe client_attesters para o editor de um cliente indicar quais atestadores endossa. O servidor de autorização ainda decide, por política própria, se aceita cada um e de onde confia nas chaves.
  • Remover um endosso limita autenticações futuras após o servidor observar a mudança; concessões e tokens de acesso já emitidos exigem revogação separada para deixar de valer.

Há uma diferença entre poder tirar um nome da lista e poder desligar o que esse nome ajudou a autorizar ontem. O novo texto de OAuth 2.0 Client Attester Endorsement dá ao editor de um cliente o primeiro poder, sob a política do servidor de autorização. Não promete o segundo. É um desenho de governança que fica mais claro quando se acompanha a mudança desde a origem dos metadados até o uso de um token já emitido.

K. McGuinness apresentou a revisão -00 em 28 de setembro de 2026 como Internet-Draft individual destinado a Standards Track. A página do Datatracker registra sua existência; não demonstra adoção pelo grupo OAuth, publicação como RFC, implantação nem incidente. A proposta se apoia no rascunho de autenticação de clientes baseada em atestação, mas não cria credencial ou método de autenticação novo. Ela descreve a relação que falta entre o cliente e o atestador autorizado a falar de suas instâncias.

O editor pode incluir client_attesters tanto nos metadados de um cliente registrado quanto num Client ID Metadata Document. A lista aponta atestadores e locais das chaves que verificam suas declarações. Sua força é delimitada por outra decisão: para uma requisição sujeita a este perfil, o servidor de autorização só aceita a atestação se o emissor estiver atualmente endossado nos metadados autoritativos e sua própria política permitir aquele atestador para o cliente, com uma fonte de chaves confiável. O servidor pode restringir o conjunto endossado, mas não incluir um atestador que o cliente não endossou. Da mesma forma, o editor não transforma um atestador em confiável apenas publicando seu nome. Nenhuma das escolhas equivale a delegação do usuário ou autorização para acessar um recurso.

Quando o editor remove um endosso, pode haver uma cópia anterior ainda válida no servidor. A seção 6.1 manda limitar a idade dos metadados e dos conjuntos JWK em cache com máximos finitos configurados e renovar ou rejeitar uma entrada vencida. Não escolhe, entretanto, um teto universal. Uma hora é um exemplo de intervalo curto, não um prazo obrigatório. O editor que precisa de limite previsível deve negociá-lo no acordo de confiança. O texto distingue essas cópias dos registros de cliente que são a fonte autoritativa. Após receber ou armazenar a atualização, o servidor tem de aplicá-la na apresentação seguinte.

Uma proibição imposta diretamente pela política do servidor funciona nas requisições posteriores sem esperar o cache.

Esse é o primeiro teste de término. O segundo envolve direitos já concedidos. O projeto diz que a retirada é prospectiva: impede futuras autenticações sob o endosso retirado, mas não revoga concessões nem tokens de acesso existentes. Uma solicitação de renovação que exige atestação passa por nova verificação. Para encerrar acesso, a implantação precisa revogar separadamente concessões e tokens afetados e cessar a emissão por renovação. A introspecção do RFC 7662 pode apontar tokens revogados como inativos; um servidor de recursos que valida localmente depende de outro mecanismo de revogação ou do vencimento do token. A confirmação de que a lista mudou não responde à pergunta de como cada servidor de recursos tratará credenciais antigas.

Também importa quem está por trás de uma atestação. Se o editor puder escolher tanto o atestador quanto suas chaves, pode operar seu próprio atestador: a declaração não oferece garantia independente do editor. E listar atestadores não obriga o cliente a apresentar atestação se outra forma de autenticação for aceita e o sinal for opcional. O texto ainda observa que o controle indevido da hospedagem dos metadados pode alterar a lista dentro da política do servidor, sem que esta proposta, sozinha, prove que a mudança foi maliciosa. São riscos de projeto descritos pela fonte, não alegações sobre uma empresa concreta.

Um registro útil de retirada deveria separar a lista antes e depois, quem tinha autoridade para editá-la, o modo de confiança do servidor, os máximos e a idade efetiva de cada cache, a primeira atestação rejeitada, o inventário das concessões e tokens atingidos, o fim das renovações e a resposta de cada servidor de recursos. Esse registro é uma sugestão editorial de prestação de contas, não um formato exigido pelo IETF. Ele permite que o responsável diga exatamente qual parte da operação parou, em vez de trocar uma edição documental por uma conclusão abrangente.

Fontes