Resumo

  • A revisão 07 diz que um JWT não pode carregar mais de uma audiência, salvo quando não é possível obter múltiplas credenciais ou influenciar a audiência; a revisão 06 dizia apenas que o JWT deveria ter uma audiência.
  • O mecanismo é a personificação entre receptores: toda parte que recebe o mesmo bearer token pode apresentá-lo às demais partes que também o aceitam.
  • Um recibo de exceção por capacidade deve registrar a limitação, o grafo de receptores, a duração e o alcance, as validações, os controles compensatórios, a próxima revisão e a condição de saída.

Considere um Pod que apresenta seu token projetado de service account à API do Kubernetes e depois reutiliza a mesma credencial para federar com um provedor de identidade externo. Nenhum dos dois destinos é indevido. Ainda assim, ambos ficam com o mesmo bearer token. Se a audiência permite os dois usos, o provedor externo pode reapresentá-lo à API e assumir a identidade da carga.

Essa rota não depende de interceptação, vazamento de log ou comprometimento do emissor. Ela aparece porque um receptor legítimo passa a deter material reutilizável que outro receptor aceita. Cada validação local pode estar correta, enquanto a separação do sistema já falhou.

Esse é o ponto operacional de draft-ietf-wimse-workload-identity-practices-07, enviado em 22 de setembro de 2026. O texto continua sendo um Internet-Draft ativo, destinado à categoria Informational. O Datatracker mostra AD Evaluation::AD Followup e Charles Eckel como responsável pela ação. Isso não é aprovação, RFC, evidência de implantação nem veredito de descumprimento por uma plataforma.

A troca de SHOULD por MUST muda o padrão

A revisão 06 já recomendava credenciais de escopo estreito e, quando a plataforma permitisse múltiplas emissões, uma credencial distinta para cada recurso ou provedor de identidade. Na seção de audiência, dizia que cada JWT deveria conter apenas uma audiência.

A revisão 07 torna essa arquitetura obrigatória. Credenciais MUST ter o menor escopo possível. A credencial para recurso da plataforma MUST ser destinada a esse recurso. A credencial de federação MUST ter o provedor de identidade como audiência exclusiva. Fora da exceção de capacidade, um JWT MUST NOT conter mais de uma audiência.

Não é uma alteração editorial menor. SHOULD permite uma decisão diferente após avaliação; MUST transforma a separação em condição padrão e exige que a exceção explique a ausência. A nova revisão também explicita o risco: qualquer relying party listada no mesmo aud pode apresentar o token a outra e obter acesso não pretendido.

A audiência não é só uma etiqueta de roteamento. Ela enumera os lugares em que a credencial pode falar. Cada lugar adicional também cria um novo detentor capaz de reproduzi-la onde mais for aceita.

O mesmo limite aparece em três modelos

O Kubernetes pode emitir vários tokens projetados, cada qual com audiência e validade próprias. A revisão 07 separa o acesso à API, a um recurso interno e a um provedor de identidade externo. São necessários tokens e audiências diferentes.

Validar aud em cada receptor não corrige um grafo compartilhado. O provedor externo pode checar emissor, assinatura, expiração e audiência corretamente e ainda guardar uma credencial que a API aceita. Todos os controles locais podem retornar sucesso sem preservar a fronteira global.

O exemplo do SPIFFE exige JWT-SVIDs diferentes para o recurso interno e a federação externa. No padrão de nuvem, a revisão 06 dizia que a carga deveria separar as credenciais e não deveria reutilizar o token interno com um STS externo. A revisão 07 usa MUST e MUST NOT. A plataforma muda; o problema continua sendo quem recebe a mesma credencial.

Exceção é déficit de capacidade, não desenho equivalente

Há plataformas que emitem somente uma credencial por carga e outras que não permitem à carga influenciar a audiência. A revisão 07 admite a exceção nesses casos.

O texto não a trata como atalho de conveniência. Um ambiente que reutiliza a credencial entre contextos não pode depender de audience scoping para conter comprometimento. Precisa adotar a menor validade permitida, restringir quais componentes alcançam o token e considerar cada receptor capaz de se passar pela carga diante dos demais.

A defesa sai do isolamento criptográfico e passa para tempo, acesso a componentes, rede, validação e detecção. São compensações por uma capacidade ausente. A revisão 07 repete essa franqueza quando não há proof of possession: validade menor, audiência mais estrita e controles de rede tornam-se obrigatórios. Reduzir o tempo não vincula um bearer token ao remetente.

O recibo de exceção por capacidade

Um registro útil deve preservar:

Campo Evidência
Capacidade do emissor Plataforma, emissor, versão e capacidade de emitir múltiplas credenciais
Controle de audiência Se a carga pode solicitar ou influenciar aud, com evidência de API ou configuração
Uso pretendido API de plataforma, recurso interno, federação ou recurso externo
Identidade da credencial Impressão não secreta ou geração, nunca o valor do token
Grafo de receptores Todos os receptores e caminhos de reapresentação entre eles
Validade TTL solicitado e emitido, renovação e invalidação
Alcance Componentes, mounts, sidecars, proxies, logs e saídas que podem acessá-la
Validação Emissor, audiência, tipo, PoP e controles de rede em cada destino
Motivo da exceção Capacidade ausente e razão que impede a separação
Compensação Validade curta, restrição, rede, monitoramento e alerta
Revisão Responsável, data, próxima análise, gatilho de correção e saída

A impressão deve ser unidirecional e não secreta. O recibo nunca deve guardar o bearer token em um chamado. Ele liga uma decisão de risco à geração, aos receptores e aos controles que estavam realmente em vigor.

Também precisa diferenciar “não pode” de “não fez”. Se o emissor suporta credenciais separadas e a integração reutiliza uma por facilidade, a exceção não se aplica. Quando uma atualização passa a permitir audiência específica, a saída já chegou. Exceção sem data de revisão vira arquitetura permanente.

O texto anterior da BTW, A Workload Credential Is Not the Workload, examinou oito provas do bootstrap ao resultado. Aqui, o recorte é menor: onde este bearer token pode representar a carga, e quais receptores podem levá-lo a outro destino?

Fontes e limites

As fontes centrais são o registro da revisão 07, o histórico do documento, o texto imutável da revisão 07 e o texto da revisão 06. A diferença entre artefato de coordenação e realidade operacional segue Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Essas fontes comprovam estado documental, linguagem normativa e mecanismo de risco. Não comprovam incidente real, não oferecem um censo de implementações e não declaram nenhum operador em desconformidade. O recibo é uma proposta editorial de Daniel Kade, não requisito do rascunho WIMSE.