AP2 v0.2のMandate：ユーザーの意図、自律購入、FIDOの標準化体制

概要

2026年10月25日時点の情報である。公開されているAP2仕様は、自らのバージョンをv0.2としている。実装前に、そのリビジョン、承認フレームワーク、およびその後のFIDOの公開文書を再確認する。AP2は、コマースプロトコルの中で購入権限の委任を裏付ける証拠を提供するものであり、カタログやチェックアウト更新のAPIは定義しない。

用語の違いに注意が必要である。v0.1.0仕様では、ユーザー不在時の承認をIntent Mandate、ユーザーが承認した購入をCart Mandate、支払い固有の情報を伝えるものをPayment Mandateとしていた。v0.2のMandateはCheckoutとPaymentの2種類である。それぞれ、制約を表すopenか、特定の取引を承認するclosedのいずれかになる。明示的な移行設計なしに、旧版の例と現行スキーマを混在させてはならない。

重要な理由

Checkout Mandateは、承認を販売者が署名したチェックアウトに結び付ける。Payment Mandateは、それに伴う支払いを承認する。これにより、エージェントの説明を課金の根拠にするのではなく、各参加者が自分の責務に対応する証拠を得られる。

承認フレームワークでは、選択的開示が可能な署名付きJSONトークンであるSD-JWT VCを用いて、検証可能なデジタル資格情報を記述している。署名、鍵とのバインディング、制約の評価は、それぞれ異なる目的を持つ。署名が有効というだけでは、購入がユーザーの制限を満たすことは確認できない。

標準化の体制についても、正確に表現する必要がある。2026年4月28日、FIDOは、GoogleによるAP2の寄贈と、Payments Technical Working Groupを通じた今後の開発を、MastercardによるVerifiable Intentの寄贈とともに発表した。この発表が示すのは標準策定プロセスの開始であり、最終的なFIDO仕様の成立や実装の認証ではない。

適用方法

• 責務を分ける。 Shopping Agent、Credential Provider、Merchant、Merchant Payment Processor、Trusted Surfaceを特定する。AP2は、Trusted Surfaceがエージェントとして動作しないこと、および検証が決定的なコードで実行されることを求めている。
• ユーザーによる直接承認に対応する。 文書化されたユーザー同席時のフローでは、信頼できるインターフェースがclosedのMandateを表示し、同意を得る。資格情報プロバイダーは支払いの承認を確認し、販売者は取引を完了する前にチェックアウトの承認を検証する。
• 事前の権限委任に対応する。 ユーザー不在時の運用では、ユーザーがopenのMandateを承認する。これらのMandateはcnfを介してエージェントの公開鍵と結び付けられ、エージェントは後から、自ら署名したclosedのMandateとともに提示する。制約は範囲を狭く定め、適切な有効期限を設定する。
• 不確かな場合は拒否する。 Mandateの連鎖を検証し、openのMandateによって固定されたクレームを保持し、すべての制約を評価する。このフレームワークは、未知の制約を失敗として扱う。unresolved_constraintではユーザーによる直接承認に戻れる場合があるが、invalid_credentialは検証を終了させるエラーである。
• 証拠のつながりを保持する。 フローの例では、Checkout ReceiptとPayment Receiptが返される。運用上の実務として、承認を調査時に再構成できるよう、関連するMandateとReceiptへの参照を注文に紐付け、アクセス制御の下で保持する。

落とし穴

フロー図は、規範ではない例として明示されており、適合性テストではない。署名付きMandateを受け取ったことは、商品の引き渡しの証拠にも、紛争の生じた購入に対する返金の保証にもならない。無人での購入を有効にする前に、検証、Receiptの保管、未解決の取引について、運用上の責任を定める。