Resumo

  • Em 28 de setembro, a revisão -07 de um Internet-Draft individual dividiu o antigo VERIFIED em verificação nativa VERIFIED e aceitação do usuário da prova ACCEPTED.
  • Quando a referência de chave não pode ser resolvida, a verificação fica NOT_EVALUATED, não FAILED; localizar uma chave não a torna automaticamente confiável para aquele papel.
  • Prova aceita ainda precisa corresponder à ação esperada. Evidência SATISFIED não concede, por si, AUTHORIZED nem demonstra que a operação ocorreu.

Dois operadores recebem o mesmo pacote de evidências antes de deixar um agente alterar um serviço. O verificador de cada lado encontra a chave e confirma a integridade da assinatura. Mas apenas um deles havia fixado aquela classe de chave e aquele emissor como adequados a esse tipo de autorização. O outro recusa o componente. Não houve mudança de bytes nem necessariamente um erro matemático: houve duas decisões de confiança. Um painel que registrasse apenas “assinatura válida” faria parecer que os dois operadores chegaram à mesma conclusão; um painel que dissesse “aprovado” daria um salto ainda maior, da prova à permissão de agir.

É esse salto que a nova redação de Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence procura impedir. A cópia oficial de draft-schrock-ep-authorization-evidence-chain-07 tem data de 28 de setembro de 2026 e autoria de Ian Schrock. É um Internet-Draft individual com intenção Informational indicada pelo autor. Não representa adoção por um grupo de trabalho, RFC, controle implantado nem consenso operacional. O mecanismo de compor provas de identidade, delegação, política e aprovação já estava na revisão -06. A alteração expressa na lista de mudanças da -07 é mais precisa: aquilo que antes aparecia como VERIFIED combinava integridade nativa e a confiança do operador; agora os dois resultados são informados separadamente.

VERIFIED depende das verificações criptográficas e estruturais da especificação nativa do componente. ACCEPTED exige primeiro esse resultado positivo e depois consulta os parâmetros fixados por quem vai depender da prova: material de resolução de chaves, estado das entradas do diretório, emissores aceitos, classes de chave, papel ou audiência, política do formato e revisão aplicável. O apresentador do pacote não pode levar consigo uma âncora de confiança e obrigar o executor a adotá-la. Quando o componente traz apenas uma referência a uma chave, a ausência de resolução impede avaliar a assinatura. A revisão orienta registrar NOT_EVALUATED, com um motivo como chave não localizada, em vez de afirmar que houve falha. A resolução, por sua vez, só abre a possibilidade da conferência. Ela não responde se a chave pode sustentar aquela reivindicação no horário da decisão.

Essa ressalva torna inadequada a ideia de um único veredito universal que viaje com o artefato. Se dois operadores resolvem a mesma referência para chaves distintas, até a verificação sobre os mesmos bytes pode divergir. Se resolvem para a mesma chave, ainda podem adotar políticas diferentes de aceitação. A versão -07 exige que resultados internos reaproveitados dentro de uma fronteira protegida sejam ligados ao resumo exato da evidência, ao perfil do verificador, à fotografia das condições de confiança e ao instante de verificação.

Uma declaração serializada enviada pelo próprio agente não substitui essas etapas: ela é mais um artefato que precisa de exame nativo. O texto também rejeita como atalho o Booleano “verificado” ou “aceito” fornecido pelo apresentador.

O próximo teste não é de confiança no emissor, e sim de identidade da ação. Apenas componentes simultaneamente verificados e aceitos podem alimentar MATCH. Se um comprovante genuíno e aceito disser respeito a outra mudança que não a operação congelada pelo executor, a falha ocorre na correspondência da ação. Depois entram validade temporal, estado autenticado, restrições de papéis e vínculos comprovados entre os documentos. SATISFIED é o veredito de que a exigência de evidência escolhida pelo operador foi preenchida naquele instante. Não é uma linguagem de política universal e não substitui a autorização local da aplicação protegida. Execução e resultado também permanecem fatos separados.

O registro de reavaliação proposto guarda revisão do algoritmo, resumos da cadeia, da ação e da exigência, horário, resumo da fotografia de confiança e, para cada componente, campos distintos de native_verification e acceptance. Os códigos de motivo devem permitir separar assinatura reprovada, exame impossível, recusa de confiança e ação incompatível. É uma trilha mais útil para descobrir por que uma decisão mudou quando muda uma chave, um diretório ou uma política. Mas continua sendo uma saída de avaliação de uma proposta. A própria revisão declara não criar ações para a IANA ou um cadastro mundial de confiança.

Fontes