Summary

  • A revisão de 27 de outubro de um Internet-Draft individual propõe decision.operationKey para identificar a intenção de uma operação. Uma repetição usa a mesma chave; um novo pagamento recebe outra.
  • No exemplo do texto, um teto de 500 libras já tem 300 gastas e 120 reservadas. Repetir a operação mantém o compromisso em 420; autorizar mais 120 chega a 540.

O sistema recebeu uma ordem de pagar 120 libras, mas a resposta sumiu. O agente envia a instrução outra vez. Essa segunda mensagem não pede mais 120 do orçamento: o primeiro pagamento continua reservado enquanto ninguém sabe o desfecho. Agora chega uma nova encomenda, do mesmo valor e com os mesmos dados. Se a contabilidade só compara o conteúdo das mensagens, pode chamar a nova despesa de “repetição”. É um apelido simpático para um rombo de 120 libras.

A versão -02 do rascunho dá a cada operação pretendida uma chave própria. decision.operationKey viaja na requisição assinada. Toda tentativa de executar aquela operação conserva a chave; outro pagamento usa outra, ainda que ação, parâmetros e recurso sejam iguais. A chave vale dentro do limite delegado identificado por limitDigest. Assim o auditor consegue ligar a intenção, a permissão e a fatia de autoridade financeira que ela pretende consumir.

O histórico do documento aponta a falha da versão -01: a identidade da repetição era o digest da requisição. Como esse digest deriva do conteúdo, duas compras separadas e iguais podem produzi-lo igualmente. A mudança nova dá um nome à operação, não à aparência do bilhete.

O exemplo do autor põe números na mesa. O limite é de 50.000 pence; 30.000 já foram consumidos e uma permissão de 12.000 segue pendente. Quando o agente repete a operação com a mesma chave, o total comprometido continua em 42.000. Se pede um novo pagamento de 12.000, a soma vai a 54.000, acima do teto. O registro precisa mostrar o excesso mesmo se algum ponto de decisão conceder a permissão.

Para isso, cada autorização pendente fica na lista held, acompanhada de chave, digest da requisição e montante. A soma da lista tem de bater com o total reservado. O verificador recalcula withinLimit a partir do que já foi gasto, do que está reservado e do novo pedido. Também observa a revisão do estado que a decisão consultou; uma revisão antiga pode ter ignorado uma reserva recém-criada.

A resposta perdida não serve como comprovante de que a cobrança falhou. A permissão só sai da reserva quando outro registro da mesma operação informa que o efeito ocorreu, passando o valor para consumido, ou que nenhum efeito ocorreu. Quem guarda os registros compara as revisões e procura permissões que desapareceram sem esse desfecho.

O Datatracker do IETF apresenta o texto como Internet-Draft individual em I-D Exists. A proposta não precisa ser tratada como solução já instalada para revelar o problema: quando uma máquina recebe autoridade para gastar, a identidade de cada promessa importa tanto quanto a soma no final da planilha.