Resumo

  • Um projeto individual da IETF coloca o usuário na tela do serviço onde ele escolhe escopos, prazo e eventualmente um teto de chamadas antes de entregar ao agente uma credencial de uso único.
  • O objetivo escrito em linguagem livre acompanha a concessão como prova. A autorização efetiva vem dos campos selecionados, conferidos a cada chamada.

Uma frase bonita não fecha uma permissão larga

O usuário escreve: “Envie só esta nota fiscal.” Logo abaixo marca uma opção que permite editar todas. O agente pode ler a frase com a delicadeza de um secretário; o serviço decide a próxima chamada com base na opção marcada. Christopher Emerson põe essa diferença no centro de um rascunho revisado sobre credenciais para agentes. A área de texto conta a história do que a pessoa queria. O catálogo de permissões define o que a máquina pode fazer.

O aviso de 27 de outubro apresentou a revisão 01. O Datatracker da IETF a registra como Internet-Draft individual ativo, sem trilha de RFC ou aprovação da instituição. O desenho começa com a pessoa autenticada no aplicativo que guarda os dados. Ali, numa tela de conexões, ela vê os escopos disponíveis dentro de um teto calculado a partir de seus próprios direitos. Escolhe o acesso, a duração e, se desejar, quantas chamadas por período o agente poderá fazer para determinados grupos de recursos. A tela também mostra concessões anteriores para que sejam mantidas conscientemente ou revogadas.

Uma etapa opcional pede que um autenticador verificado pela pessoa assine um compromisso com os parâmetros exatos, inclusive os textos apresentados. O aplicativo exibe uma vez uma credencial temporária de conexão. A pessoa a entrega ao agente; o agente a troca por um token de acesso restrito e sem caminho de renovação automática. A entrega feita por quem concede o acesso é a peça política do mecanismo: o sistema que executa o agente não escolhe sozinho o canal pelo qual recebe uma nova autorização.

O texto viaja no processo; os limites barram a chamada

A revisão 01 acrescenta um tratamento explícito para dois textos: o propósito declarado pelo aplicativo e a intenção redigida pelo usuário. Eles aparecem no consentimento, na introspecção, nos registros de auditoria, na revogação e nos alertas. Não alimentam o motor de políticas. A prosa não pode ampliar o escopo, e sua interpretação automática serve apenas como indicação para uma pessoa revisar. Pelo mesmo motivo, a frase “só esta nota” não diminui um escopo escolhido para todas as notas. Se a tela oferece uma permissão grosseira, a boa redação do usuário não a conserta.

O controle que importa continua após a troca da credencial. Cada chamada de API passa por introspecção para conferir escopos e tetos. O serviço pode exigir confirmação a cada uso de uma permissão sensível. Nesse caso, a chamada fica pendente e seu conteúdo exato é identificado por digest. O usuário confirma em seu próprio ambiente com um autenticador; o agente repete a requisição com o identificador dessa confirmação. A recusa encerra aquela tentativa. A revogação da conexão mata qualquer confirmação ainda pendente. É um modo de exigir um “sim” para a transferência específica, além do “sim” anterior ao grupo de operações.

A versão 00 já defendia a entrega humana da credencial. A versão 01 detalha o teto de chamadas, a revisão de concessões antigas, o compromisso de presença, a confirmação por ação, o fechamento na revogação e a intenção como prova. O documento informa que o autor opera um serviço baseado nessas ideias. Falta ali uma avaliação independente de conformidade. Há também um problema que o próprio texto reconhece: se o agente controla a tela que mostra a ação a ser aprovada, tocar no autenticador não prova que a pessoa viu a ação verdadeira.

Registros originais