Resumo

  • O arquivo da IETF anunciou a revisão 02 do VCAP em 4 de setembro como Internet-Draft individual, sem endosso da IETF, posição formal, fluxo RFC ou Area Director responsável.
  • A nova seção de responsabilização admite que o marketplace controla de fato resultados de liquidação ao escolher verificadores e exige registro de chaves, capacidades, disputas e mudanças.
  • Ainda assim, o prestador origina service_delivery e pode incluir auto_approve, definido como pular a verificação automática porque o próprio prestador atesta a entrega.
  • O texto não diz quem aceita a dispensa, qual cláusula a autoriza, quem assina o callback, quais verificações sobrevivem nem como a decisão expira ou é contestada.
  • Antes de movimentar os fundos, deve existir um recibo de dispensa ligando proponente, autoridade aceitante, base contratual, escopo, limites, validade, signatário, conflitos, recurso e estado final.

A revisão tornou visível quem escolhe o árbitro

O anúncio da IETF registra somente que um Internet-Draft de trinta páginas, assinado por Ben Stone, ficou disponível em 4 de setembro. A página do Datatracker delimita a autoridade: trata-se de uma submissão individual ativa. Qualquer pessoa pode apresentar um I-D; este não é endossado pela IETF e não possui posição formal em seu processo, fluxo RFC ou Area Director responsável. “Informational” é o destino pretendido pelo autor, não um status alcançado.

Dentro desse limite, a revisão 02 propõe um encadeamento com consequência financeira. Solicitante e prestador negociam trabalho e preço. O marketplace retém os fundos. O prestador entrega. Um verificador examina o resultado e envia verification_callback. Um passed=true leva a VERIFIED e à liberação; false leva a FAILED e ao reembolso. O próprio rascunho chama o callback de mensagem mais crítica porque ele dispara a liquidação.

O diff oficial mostra uma mudança relevante em relação à revisão 01: a inclusão da seção Verifier Accountability. Ela afirma que o marketplace controla efetivamente os resultados quando escolhe verificadores. Antes de aceitar uma resposta, deve registrar e confiar na chave Ed25519 ou método do verificador, guardar as capacidades declaradas e definir um caminho de escalonamento para contestações. Cadastro, rotação e cancelamento de chaves devem ficar datados junto aos registros de liquidação.

Quando o operador do marketplace também controla o verificador, o texto recomenda permitir um terceiro escolhido por acordo mútuo entre solicitante e prestador. Também recomenda publicar quais tipos atendem cada categoria, como conflitos são administrados e como resultados contestados avançam. A seleção conjunta e a transparência são SHOULD; cadastro, capacidades, disputa e histórico são MUST.

É um desenho prudente: diferentes mercados podem assumir riscos diferentes, mas precisam mostrar onde está a escolha. A lacuna aparece no caminho simétrico. Se escolher o verificador influencia o dinheiro, escolher não verificar também influencia.

O pedido de dispensa nasce com o beneficiário

O prestador envia service_delivery para declarar que concluiu o trabalho. A mensagem leva descrição, artefatos e dicas: URL, seletor, conteúdo esperado e comparação de impressão digital. No mesmo objeto existe auto_approve. Se true, diz o texto, a verificação automática é pulada e o prestador se autoatesta.

O JSON Schema da entrega, vinculado pelo rascunho, explicita que as dicas do prestador podem “substituir ou complementar” as do solicitante. O campo tem false como padrão. Isso resolve como um parser trata a ausência do valor; não resolve quem pode ativá-lo nem qual consentimento lhe dá efeito contra quem paga.

Em cada documento fixo -00, -01 e -02, auto_approve aparece apenas duas vezes: no exemplo da mensagem e na tabela de dicas. Não há regra para proponente elegível, autoridade aceitante, cláusula de acordo, teto de valor, classe de risco, verificações mantidas, vencimento, revogação, conflito ou trilha de decisão.

Um marketplace que recebe true deveria ignorá-lo, recusar, manter HELD, consultar o solicitante ou abrir revisão humana? Todas são políticas possíveis. A especificação atual não torna uma delas interoperável. Dois implementadores podem aceitar o mesmo JSON e discordar sobre a única ação que importa ao saldo.

Essa constatação não autoriza inventar um incidente. As fontes não demonstram que um sistema implementou o campo, que um prestador forçou pagamento, que houve abuso ou perda. Demonstram apenas que o texto não oferece uma regra completa para a dispensa.

Quem produz o callback quando ninguém verificou?

O fluxo normal termina com uma estrutura exigente: IDs de verificação, negociação e escrow, passed, hash, assinatura, identificador da chave, log de ações e horário. A liquidação copia a referência e a prova. Se o motor automático foi deliberadamente dispensado, qual ator deve ocupar o lugar do verificador?

Uma assinatura do prestador converte a autodeclaração do beneficiário em seu próprio veredito. Uma assinatura do marketplace documenta aceitação de risco, não observação independente da entrega. Uma assinatura humana indica que ocorreu revisão manual e que esse papel deveria ser nomeado. O VCAP-02 não escolhe uma semântica nem explica o que registrar como ação quando a ação central foi omitida.

A criptografia não resolve a distribuição de poder. O rascunho calcula SHA-256 sobre o pacote canônico e usa Ed25519 sobre IDs, resultado, hash, chave e tempo. A RFC 8032 permite verificar se a chave correspondente assinou aquela mensagem. O próprio VCAP limita corretamente a conclusão: o hash acusa alteração e a assinatura atribui a prova a um verificador autorizado. Nenhum dos dois registra o consentimento do solicitante para não verificar.

Atomicidade e idempotência também protegem outra camada. Compare-and-swap impede que o mesmo valor seja liberado e devolvido. Repetições não liquidam duas vezes. A máquina chega a um único estado final, mas esse rigor não cria a autoridade que escolheu a exceção.

O timeout oferece um contraste útil. Depois de 1.800 segundos por padrão, o dinheiro deve permanecer HELD. O marketplace deve encaminhar o caso a uma fila humana, e uma pessoa toma a decisão final por meio de callback normal, uma entrada de log, hash e assinatura. Há ator, mensagem e histórico. auto_approve não recebe tratamento equivalente.

Autodeclaração pode ser uma escolha comercial legítima. Uma relação recorrente e uma tarefa de baixo valor podem justificar menos custo de controle. Mas uma cláusula acordada previamente pelo pagador não é igual a uma dica apresentada na entrega por quem receberá o valor.

O artefato executável também diverge da prosa

Os schemas públicos ligados pelo texto não estavam sincronizados no corte. O schema de verification_callback ainda exigia HMAC-SHA256 em hexadecimal, aceitava apenas vcap_version 1.0 e não continha verifier_key_id. A revisão 02 exige Ed25519, Base64 e o identificador. O histórico do repositório mostra que os schemas ligados não acompanharam a submissão de setembro.

Isso não prova falha operacional. Mostra que alguém seguindo a prosa atual e outro seguindo a validação de schema recebem contratos diferentes. Uma regra de dispensa que não vira artefato testável corre o mesmo risco, ainda que a sintaxe do booleano seja aceita por ambos.

O novo texto também corrige a relação com o AP2. O AP2 define mandatos, papéis e evidências de pagamento; o VCAP-02 não pressupõe mais que ele forneça estados de escrow, captura, devolução e liquidação. A autoridade ausente para auto_approve não pode ser empurrada para o protocolo anterior por silêncio.

Um recibo de dispensa deve preceder o pagamento

Uma camada comum estreita basta. O recibo deve identificar transação, negociação e escrow; versões e hashes do texto e dos schemas; prestador proponente; cláusula que permite autodeclaração; atores do solicitante e do marketplace que aceitam; regra de escolha substituída; critérios dispensados e mantidos; justificativa; teto financeiro e de risco; início, expiração e revogação; modo do callback e signatário; evidência conflitante; via de disputa; e estado final dos fundos.

Se a cláusula ou a autoridade aceitante não puder ser resolvida, o mercado rejeita a dica ou conserva HELD. Não deve deduzir consentimento atual de uma aceitação genérica feita antes.

Essa solução não padroniza toda política de risco. Cada participante continua livre para escolher verificação independente, humana ou autodeclaração. O mínimo compartilhado apenas torna verificável quem decidiu a exceção, por quanto tempo, em qual escopo e com qual consequência.

Fontes

  1. Anúncio IETF da revisão 02 do VCAP
  2. Estado no IETF Datatracker
  3. VCAP revisão 02
  4. VCAP revisão 01
  5. Diferenças oficiais entre 01 e 02
  6. JSON Schema de service_delivery
  7. JSON Schema de verification_callback
  8. Histórico do repositório VCAP
  9. RFC 8032 — EdDSA
  10. Especificação Google Agent Payments Protocol
  11. Heng Lu sobre a primazia do running code
  12. Heng Lu sobre especificação mínima e decisão local