Summary

  • Um rascunho individual de protocolo propõe que a pessoa assine, com passkey, limites de gasto para um agente. No exemplo do autor, um teto de 200 libras é confrontado com recibos que somam 230; o verificador registra o excesso.
  • O teto é somado dentro de cada registro. Com dois registros para a mesma permissão, ambos podem parecer regulares isoladamente enquanto a despesa conjunta passa do valor autorizado.

A mesma autorização, duas caixas

A proposta de Pavel Izmaylov põe um agente para comprar material de escritório. A pessoa autoriza no máximo 200 libras ao todo e 100 por pedido. O fornecedor contrassina cada compra, e pedidos acima de 60 libras exigem aprovação individual do principal. O exemplo chega a 230 libras num único registro. O verificador encontra tanto o estouro do teto quanto uma aprovação que faltou. Assim funciona a matemática quando todos os pedidos estão no mesmo livro.

Divida a execução entre dois registradores. Cada um recebe pedidos por 125 libras sob a mesma permissão, com as contrassinaturas e aprovações exigidas. Cada verificador soma 125, vê um número menor que 200 e aprova seu próprio histórico. A pessoa recebe 250 libras em cobranças. O cenário é uma conta construída a partir da regra escrita, sem notícia de ocorrência real. A seção de segurança do próprio rascunho informa que totais, contagens, períodos e identificadores repetidos valem dentro de um registro; recibos da mesma permissão mantidos em registros distintos não entram numa soma comum.

Uma assinatura correta pode acompanhar uma conta errada para o objetivo do titular. A passkey vincula a pessoa ao limite. A assinatura do agente vincula cada recibo à ação que ele registrou. A contrassinatura acrescenta a chave indicada para o fornecedor. Nenhuma dessas marcas responde a pergunta operacional: onde vive o saldo único, e quem pode impedir o segundo executante de gastar o que o primeiro acabou de reservar?

A competência do verificador termina no arquivo que recebe

A revisão 01, de 24 de outubro de 2026, consta no Datatracker da IETF como Internet-Draft individual, sem diretor de área responsável nem adoção por um grupo de trabalho. O mecanismo proposto é detalhado: uma permissão assinada pela pessoa pode estabelecer valores totais, limites por ato, número de ações e janelas móveis; o agente assina recibos; um registrador os dispõe em árvore com cabeças assinadas e carimbos de tempo. Terceiros podem avaliar depois, offline, os documentos apresentados.

A revisão apertou as regras de verificação. O apêndice C compara as versões 00 e 01 e diz que os bytes dos registros não mudaram. Mudaram os casos em que o leitor rejeita chaves mal codificadas, tamanhos de assinatura e alguns campos. Há mais rigor para dizer se um histórico local é válido; continua ausente a conta que reúne históricos separados.

A própria proposta se ocupa de auditoria posterior. Ela não especifica um executor que barra um pedido antes de ele produzir efeito. No exemplo de 230 libras, o aviso vem depois da entrada que ultrapassou 200. Serve para atribuir responsabilidades e corrigir o processo. Não devolve as libras já comprometidas. Um limite preventivo exige reserva compartilhada antes do pedido, inclusive quando há repetição por timeout ou dois executores em regiões diferentes.

O papel do fornecedor também tem limites precisos. Sua contrassinatura mostra que alguém com a chave listada na permissão assinou aquele recibo; o texto distingue isso de provar quem é essa pessoa no mundo real. A aprovação do titular cobre uma ação específica. Uma cabeça assinada protege um trecho da história entregue ao auditor. A entrega do produto e o saldo gasto por outro registrador exigem registros adicionais. Um pacote pode ser criptograficamente impecável e não responder à pergunta financeira que motivou sua compra.

O carimbo de uma árvore não conta a outra

A proposta usa a árvore de Merkle da RFC 9162. Uma prova de consistência demonstra crescimento sem reescrever o passado de uma árvore; uma cabeça preservada fora do registrador ajuda a denunciar um corte posterior no trecho coberto. Isso melhora a disputa sobre a integridade do histórico. Com duas árvores, cada prova ainda fala apenas da sua própria sequência. A segunda parcela do orçamento precisa entrar na mesma conta por decisão de arquitetura, não por repetição do carimbo.

O autor explicita outros riscos: a última cabeça pode desaparecer sem testemunha externa, e um registrador pode mostrar visões diferentes sem uma prova definida que as reconcilie. Mesmo sem desonestidade ou corte, a soma de 125 com 125 atravessa o teto de 200. O problema mais simples é também o mais caro: o sistema mede subconjuntos quando a pessoa autorizou um conjunto inteiro.

A seção de implementação aponta bibliotecas JavaScript e Python do próprio autor. Registra que a biblioteca Python ainda não verifica uma das assinaturas SLH-DSA da cabeça e que há uma falha conhecida no tratamento de atributo do carimbo temporal. Não há implementação independente conhecida na lista. O fato que mudaria a avaliação é um teste público de concorrência com a mesma permissão em dois registradores, uma rejeição verificável do excesso e uma reconstrução completa por terceiros.

Sources