Resumo

  • Um caso novo de um rascunho individual da IETF permite ao agente gastar até US$ 30 por compra e US$ 100 no dia entre comida, transporte e itens de casa. A viagem de US$ 38 fica à espera de uma exceção aprovada pela pessoa.
  • Três caixas independentes não conhecem automaticamente o gasto umas das outras. O rascunho identifica a falta de limites monetários interoperáveis, revogação da concessão inteira e imposição dos limites no momento de cada compra.

A calculadora não mora em nenhuma das lojas

Dave dá ao assistente uma tarefa muito comum: cuide dos pequenos pedidos de hoje sem me acordar a cada compra. O limite é US$ 30 por transação e US$ 100 no dia. O robô pede um jantar de US$ 24, tenta uma corrida de US$ 38 e compra artigos para casa por US$ 18. A corrida para no teto por operação e precisa da aprovação específica de Dave. À meia-noite, o poder termina. É o cenário criado pelos autores na revisão 05 do estudo de autorização de agentes, não uma série de compras reais. Seu detalhe mais caro não é o jantar: é o contador que nenhuma das lojas isoladamente possui.

O anúncio de 27 de outubro e o Datatracker da IETF registram um Internet-Draft individual, sem trilha de RFC ou aval institucional. A revisão 04 ainda não tinha o caso dos pedidos diários de baixo valor. Os autores chamam o acordo inicial de consentimento amortizado: uma autenticação forte compra um período curto de autonomia limitada. Poupa interrupções, mas transfere trabalho para a contabilidade que precisa acompanhar o agente entre empresas.

Uma loja consegue verificar que seu pedido de US$ 24 cabe no teto de US$ 30. A empresa de transporte consegue segurar uma corrida de US$ 38. Já o limite diário de US$ 100 exige saber o que ocorreu nas outras caixas. Um comércio não descobre o gasto externo olhando apenas para seu próprio pedido. Para autorizar a próxima compra, os serviços precisam reconhecer a mesma concessão e consultar um total confiável antes de concluir o efeito. Alguém também precisa definir em que momento uma ordem entra na soma e quando um cancelamento devolve margem. O rascunho enumera essa necessidade sem oferecer um protocolo final de caixa compartilhado.

A autorização precisa sobreviver à troca de balcão

Os requisitos do novo caso formam uma escada de ações: ler opções, rascunhar, enviar e gastar. A concessão deve indicar os aplicativos permitidos, impor prazo, impedir que o agente aumente sozinho seus poderes e permitir que a pessoa encerre tudo com uma revogação única, inclusive permissões derivadas. Cada ação precisa ser atribuível por prova criptográfica à concessão específica que a autorizou. De outra forma, a loja vê um token válido, mas não sabe a qual promessa diária ele pertence.

Os autores listam ferramentas existentes de OAuth que cobrem trechos do caminho. O fluxo de código de autorização ajuda a criar a concessão inicial; Rich Authorization Requests expressa detalhes estruturados; DPoP liga o token a quem o apresenta; a revogação termina tokens individuais. O vazio aparece na combinação: não há semântica padrão para o teto monetário cumulativo, nem comando comum para derrubar uma concessão inteira, nem trilha interoperável da regra até serviços independentes quando a compra é executada. Um número bonito na tela de consentimento ainda precisa de um funcionário atrás do balcão.

A corrida de US$ 38 deixa a distinção clara. Ela viola o teto por transação antes de testar o orçamento diário. A exceção de Dave deve servir para aquela corrida e aquele valor, sem virar salvo-conduto para futuras viagens. A revogação antecipada e o fim do dia devem alcançar todos os tokens derivados, mesmo distribuídos por comida, viagem e casa. Se o assistente depois explica o extrato do cartão, a resposta deve poder ser comparada com o identificador da concessão, o pedido e a exceção que realmente o autorizou.

Registros originais