Resumo

  • A revisão -02 de um Internet-Draft individual propõe recusar o token inteiro quando o verificador não sabe avaliar um tipo de authorization_details; descartar apenas a parte desconhecida faria a aprovação parecer mais abrangente que a avaliação real.
  • O solicitante precisa distinguir que reapresentar o mesmo token não resolverá o problema, mas não deve receber o caminho, a concessão ou o item exato que falhou. O motivo completo pertence à auditoria protegida do operador.

O mesmo resultado — “não autorizado” — pode esconder dois defeitos opostos de projeto. Em um deles, o serviço devolve uma falha genérica com aparência temporária e o agente insiste com bytes idênticos. No outro, o serviço explica tão minuciosamente o motivo que permite ao agente testar quais elos da delegação continuam ativos. A recusa era correta nos dois casos. O que falhou foi a distribuição da informação que acompanha a recusa.

Wes Jackson acrescenta essa fronteira ao Verifier-Side Evaluation Semantics for Delegated Authority Chains, versão -02, de 29 de setembro de 2026. O Datatracker da IETF registra um Internet-Draft individual em I-D Exists, sem fluxo de padronização definido. O cabeçalho indica intenção informativa, não adoção pelo grupo WIMSE. Portanto, os requisitos escritos no documento são propostas do autor, não comandos de um RFC, nem comprovação de implantação ou incidente.

A mudança em relação à versão -01 é mais que uma troca de verbo. A regra que se chamava “Process Every Entry or Reject” passou a “Process Every Entry or Refuse”. A nova terminologia reserva a recusa à avaliação do verificador sobre token ou registro; rejeição passa a ser a decisão terminal de um aprovador humano sobre uma chamada retida. Isso impede que uma falha de interpretação de credencial seja confundida com uma pessoa que negou a ação. São superfícies de controle distintas, mesmo quando ambas terminam sem execução.

Pela seção 4.1, nenhum item authorization_details apresentado pode ser omitido em silêncio. Se um tipo está fora do repertório do verificador, o token é recusado. A revisão qualifica a recusa como permanente para aquele token apresentado: reenviá-lo não altera os tipos que o receptor consegue processar. Não é uma afirmação de que o agente jamais poderá obter um token diferente, nem de que qualquer erro na cadeia tem solução idêntica. A precisão do escopo importa para as políticas de reenvio.

A seção 5 impõe uma segunda condição. O solicitante deve conseguir reconhecer, quando o transporte tiver meio apropriado, que insistir no token atual é inútil. Mas a resposta não deve dizer qual item, qual percurso de delegação ou qual concessão falhou, para além de propriedades que o verificador já torna públicas. Se cada tentativa devolvesse um diagnóstico desse nível, o erro se transformaria em consulta indireta ao estado de uma árvore de permissões. O documento reserva o detalhe ao registro de auditoria do próprio verificador.

Separar resposta externa econômica de diagnóstico interno preciso é a interpretação de governança aqui; o rascunho não cria um novo recibo obrigatório.

Os dois RFCs citados ajudam a preservar as fronteiras de protocolo. No RFC 9396, invalid_authorization_details trata de dados desconhecidos ou inválidos no servidor de autorização; o código é registrado para os endpoints de autorização e token. No RFC 6750, invalid_token aparece no servidor de recursos que usa bearer tokens; o cliente pode solicitar um token novo e tentar novamente. Jackson não define código nem formato adicional. Tratar os exemplos como intercambiáveis ou proibir toda tentativa futura seria ler mais do que os textos dizem.

Ainda não há demonstração pública de que verificadores estejam vazando caminhos de delegação nem uma medição de tempestades de reenvio. A implementação de referência mencionada no draft não consome authorization_details, conforme o próprio autor assinala. A notícia é uma proposta de semântica para um problema que costuma desaparecer sob a palavra “erro”: para quem o erro precisa ser útil, e de quem a razão específica precisa continuar protegida.

Fontes