Resumo

  • A primeira versão do Internet-Draft individual AAuth-R3, apresentada em 28 de setembro de 2026, permite que o recurso rode uma chamada retida antes da aprovação apenas se rodá-la não produzir efeito fora do resultado. Não é RFC, endosso do IETF ou evidência de implantação.
  • Nesse caminho, a interface deve informar que a operação já ocorreu. A pessoa decide se o resultado fixo será entregue ao agente; o recurso pode descrever quantidade real e categorias sensíveis encontradas.
  • Se a própria execução registra um acesso sujeito a auditoria, gasta limite, gera cobrança ou aciona terceiros, a aprovação precisa vir primeiro. O nome «consulta» não garante inocuidade.

O que o usuário realmente pode vetar

Um agente pede uma pesquisa em dados de funcionários. A resposta sai com campos de remuneração e endereço; o recurso a segura. O usuário ainda pode impedir a divulgação, mas não pode voltar no tempo para impedir a busca. A seção 10.4 do texto AAuth-R3 exige que a tela diga precisamente isso quando a execução antecede a aprovação. Chamar a decisão de permissão para «rodar» o comando seria atribuir ao usuário um controle que já desapareceu.

Saber o conteúdo aproximado da resposta pode tornar a escolha mais informada. O texto da consulta não revela necessariamente quantas linhas sairão nem quais tipos de dados elas trarão. A proposta de chamada única pode incluir result quando a operação já rodou: uma descrição definida pelo recurso, não o conjunto de dados integral. O recurso escolhe o que mostrar ao serviço de autorização e o que entregar ou suprimir depois. Essa escolha editorial do próprio recurso também limita a visão da pessoa; uma descrição incompleta não vira completa só porque o resumo criptográfico da proposta confere.

O limite crucial é a execução em si. Uma leitura pode produzir um registro auditável, consumir taxa ou quota, cobrar dinheiro, ou chamar outro participante. Nesses casos há uma consequência antes da entrega da resposta. A proposta manda pedir aprovação antes da execução. Guardar o resultado não apaga um débito nem desfaz uma notificação. Por isso, a pergunta de governança é «o que muda fora do resultado quando esta chamada roda?», e não «ela se chama leitura?». A resposta precisa vir do comportamento do recurso, não do texto enviado pelo agente.

A chamada aprovada não pode ser trocada

O Datatracker registra -00 como submissão individual em estado I-D Exists; Standards Track no cabeçalho é intenção, não aprovação. O desenho vincula uma operação e parâmetros concretos a uma proposta referenciada por r3_uri e r3_s256. Com HTTP 202 o recurso mantém a invocação pendente. Com 401, o agente refaz a chamada e o recurso compara os parâmetros efetivos com os aprovados; valores sensíveis representados por digest exigem os mesmos bytes. Um token por chamada não autoriza duas execuções.

Se a execução antecipada foi realmente sem efeito externo, a aprovação passa a cobrir uma resposta já fixada, sem variação entre intenção e resultado posterior. Ainda assim, o recurso deve decidir que partes da resposta podem sair. Não há prova de uso operacional, teste de interoperabilidade ou incidente no registro citado. As matérias anteriores da BTW sobre AAuth tratam de teto agregado de gastos e recebimento intermediário de eventos; esta trata da fronteira entre cálculo concluído e divulgação ainda controlável.

Fontes