Summary

  • A seção 3.6 de draft-liu-oauth-authorization-evidence-01 assina apenas id e o objeto completo user_confirmation, com conteúdo exibido, ação do usuário e horário.
  • O audit_trail, que deveria explicar a expansão semântica até operações autorizadas, é excluído expressamente. Dois históricos incompatíveis mantiveram a mesma projeção de assinatura em uma reprodução local.
  • Um JWT assinado e intacto ainda protege o objeto inteiro. Na extração de token opaco, TLS protege a consulta, mas não amplia a assinatura destacada sobre os metadados vizinhos.

O motor trabalha com aquilo que a pessoa não viu

Um sistema não compra “barato”. Ele aplica um teto monetário, uma moeda, uma categoria, uma quantidade e regras de vendedor. Esses parâmetros podem ser razoáveis, mas são decisões. Quando a tela mostra uma frase e a política recebe campos estruturados, existe um estágio de interpretação que precisa ser identificável.

O rascunho cria authorization_evidence como tipo de Rich Authorization Requests. O núcleo exige um identificador, user_confirmation e as_signature. A confirmação preserva o texto exato apresentado, a forma da confirmação e um NumericDate.

A seção 3.6 manda construir um novo objeto JSON contendo somente id e user_confirmation, aplicar JCS do RFC 8785 e assinar os bytes em uma JWS destacada. Campos de extensão além de id, user_confirmation e as_signature não entram. O histórico de auditoria está fora por definição normativa.

Essa assinatura prova, nos limites declarados, que o servidor de autorização registrou uma confirmação. O próprio texto rejeita uma leitura mais ampla: como o servidor controla a interação e a chave, isso não prova independentemente que a pessoa consentiu. Não repúdio mais forte exige assinatura do usuário ou auditoria independente.

Também não é prova de operação concluída. A orientação para o servidor de recursos separa ID, horário e resumo da tela da operação executada e do resultado. Autorização, despacho, execução e efeito externo continuam sendo registros diferentes.

O histórico semântico tem informação, mas não compromisso interno

A seção 4 atribui ao audit_trail a explicação de como a intenção foi interpretada e convertida em operações autorizadas. Seus campos opcionais incluem evidence_ref, o nível de expansão e proposal_ref.

Os níveis none, low, medium e high são classificações. Não são uma diferença semântica reproduzível. medium não informa qual regra transformou “barato” em 50 dólares ou qual conjunto de produtos foi aceito.

proposal_ref é uma URI opaca atribuída pelo servidor de autorização para a proposta anterior à política, à redução de escopo ou à modificação no consentimento. A revisão não define protocolo de recuperação, hash do conteúdo, retenção nem autorização de leitura. A referência pode sobreviver sem que um revisor consiga recuperar os mesmos bytes.

Isso não denuncia uma exploração. Uma implantação pode usar armazenamento imutável, compromisso por hash ou uma resposta assinada mais ampla. A lacuna é de portabilidade: essas garantias não decorrem do objeto mínimo definido aqui.

A reprodução trocou o histórico sem trocar a entrada assinada

Criamos localmente dois objetos com o mesmo id, frase, ação e horário. Um marcou expansão medium e apontou para uma proposta com 50; o outro marcou high e apontou para 500. Os objetos completos e seus hashes eram diferentes. A projeção da seção 3.6 era igual nos dois e produziu aec26fa5351ab57f144fd6b387b297969f73e34ec3ea5a557592a0b2d3a7b512.

O teste demonstra apenas a fronteira de construção. Não valida a JWS abreviada, não quebra JWS ou JCS, não testa produto real, não mostra servidor malicioso, transação nem prejuízo.

A proteção disponível depende do recipiente preservado

Quando a evidência permanece em um token de acesso JWT assinado conforme RFC 9068, a assinatura externa cobre todo o objeto incorporado, inclusive o histórico. Alterar o histórico dentro do JWT intacto seria detectado pela verificação externa. A exclusão da assinatura interna não remove essa proteção.

Em token opaco, o servidor de recursos recupera dados por introspecção RFC 7662 ou endpoint dedicado. O rascunho chama as_signature de única proteção de integridade do registro nesse caso e exige TLS. TLS autentica e protege a resposta durante a conexão. Depois de extrair, guardar ou encaminhar o objeto, o canal não se transforma em assinatura portátil do histórico.

Introspecção ainda é uma visão corrente: active depende do servidor, respostas podem variar por recurso e cache troca atualidade por desempenho. Ela não é automaticamente um recibo durável da expansão.

Evidência e política não podem fundir autoridade

O rascunho associado de Rego separa a evidência que registra por que uma operação foi autorizada da política que define o que o agente pode fazer. No exemplo, authorization_evidence e rego_policy são irmãos. A assinatura interna não cobre URI, ponto de entrada ou entradas da política.

Um JWT externo intacto pode comprometer a representação conjunta. Em sistemas opacos, recuperação e retenção precisam ligar explicitamente os objetos. Caso contrário, “autorizado” passa a esconder tela, interpretação, política, decisão do recurso, despacho, execução e efeito em uma única palavra.

Um passaporte para os parâmetros

Uma ação de alto impacto deveria levar um passaporte de interpretação: IDs de evidência e sessão; hash e idioma da tela; bytes ou hash imutável da proposta; operação resolvida e restrições; diferença semântica e componente gerador; ID, hash, entrada e insumos da política; emissor, audiência, sujeito, agente, cliente e expiração; decisão do recurso; hash do pedido despachado; recibo de execução; resultado externo separado.

Esta é uma proposta analítica de Daniel Kade, não uma obrigação da revisão 01. Conteúdo sensível pode ficar em registros com acesso controlado. O vínculo por hashes mantém a camada comum pequena sem entregar ao executor o poder exclusivo de explicar sua própria interpretação.

Sources and limits

As observações foram congeladas em 30 de setembro de 2026, Asia/Shanghai. A revisão 01 é um Internet-Draft individual ativo, não RFC, consenso do grupo OAuth ou prova de adoção. A reprodução local só demonstra a projeção especificada. Não demonstra falha em JWS/JCS, alteração durante TLS, defeito de implementação, má-fé, perda ou ação concluída. O rascunho pode mudar, ser substituído ou expirar.