Mandatos do AP2 v0.2: intenção do usuário, compras autônomas e governança da FIDO

O que é

Situação em 25 de outubro de 2026. A especificação publicada do AP2 se identifica como v0.2. Confira novamente essa revisão, seu modelo de autorização e as publicações posteriores da FIDO antes de implementar. O AP2 fornece evidências de autorização delegada de compra dentro de um protocolo de comércio; ele não define o catálogo nem a API de atualização do checkout.

A terminologia importa. A especificação v0.1.0 descrevia um Intent Mandate para autorização na ausência do usuário, um Cart Mandate para uma compra aprovada pelo usuário e um Payment Mandate que transmitia informações específicas do pagamento. Na v0.2, há dois tipos de mandato: Checkout e Payment. Ambos podem ser abertos, expressando restrições, ou fechados, autorizando uma transação específica. Não combine exemplos antigos com os esquemas atuais sem um projeto de migração explícito.

Por que importa

O Checkout Mandate vincula a aprovação ao checkout assinado pelo comerciante. O Payment Mandate autoriza o pagamento associado. Assim, cada participante recebe evidências pertinentes às suas responsabilidades, em vez de usar o relato do agente como autorização para cobrar.

O modelo de autorização descreve credenciais digitais verificáveis baseadas em tokens JSON assinados que permitem divulgação seletiva, os SD-JWT VCs. Assinaturas, vinculação de chaves e avaliação de restrições cumprem funções distintas. Uma assinatura válida, por si só, não comprova que a compra respeita os limites do usuário.

A governança também exige termos precisos. Em 28 de abril de 2026, a FIDO anunciou a contribuição do AP2 pelo Google e a continuidade de seu desenvolvimento por meio do Payments Technical Working Group, junto com a contribuição do Verifiable Intent pela Mastercard. Esse anúncio estabelece um processo de desenvolvimento de padrões; ele não estabelece uma especificação definitiva da FIDO nem certifica uma implementação.

Como aplicar

• Separe as responsabilidades. Identifique os papéis de Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor e Trusted Surface. O AP2 exige que a Trusted Surface não seja baseada em agentes e que a validação seja executada em código determinístico.
• Trate a aprovação direta. No fluxo documentado com presença humana, a interface confiável exibe os mandatos fechados e obtém o consentimento. O provedor de credenciais verifica a autorização de pagamento; o comerciante verifica a autorização de checkout antes de concluir a transação.
• Trate a delegação prévia. Para operar sem a presença humana, o usuário autoriza mandatos abertos. Esses mandatos vinculam a chave pública do agente por meio de cnf; depois, o agente os fornece junto com seus mandatos fechados assinados. Use restrições de escopo limitado e um prazo de validade adequado.
• Negue a operação em caso de incerteza. Verifique a cadeia de mandatos, preserve as declarações fixadas pelos mandatos abertos e avalie todas as restrições. O modelo trata restrições desconhecidas como falhas. unresolved_constraint pode levar de volta à aprovação direta pelo usuário; invalid_credential é um erro que encerra a verificação.
• Preserve a trilha de evidências. Os fluxos de exemplo retornam Checkout Receipts e Payment Receipts. Como prática operacional, guarde com o pedido as referências aos mandatos e recibos pertinentes, com controles de acesso, para que uma investigação possa reconstituir a aprovação.

Armadilhas

Os diagramas de fluxo são explicitamente exemplos não normativos, e não um teste de conformidade. Receber um mandato assinado não comprova a entrega nem garante que uma compra contestada será reembolsada. Defina a responsabilidade operacional pela verificação, pela retenção dos recibos e pelas transações não resolvidas antes de habilitar compras sem supervisão.