Verifiable Intent（可验证意图）
| 分类 | 🛡️ 安全风险 |
| 阅读时间 | ⏱️ 16 分钟 |
| 更新时间 | 📅 2026-10-12 |
| 条目编号 | ENC-SECURITY-18-verifiable-intent |
关键要点 ✦
- 2026 年 3 月 5 日 Mastercard 在马德里与伦敦宣布推出 Verifiable Intent，规范与参考实现在 GitHub 与 verifiableintent.dev 同步开源，当前版本 v0.1（据 Mastercard 新闻室与 PYMNTS 报道）
- 要解决的核心问题：智能体往往在用户给出指令数小时甚至数天后才执行交易，支付网络难以确认消费者是否真的授权、智能体是否严格照办、出现争议时能否举证
- 技术机制：基于 SD-JWT（选择性披露 JSON Web Token）构造加密委托链，把消费者已验证身份、消费者的确切指令与交易结果三要素绑成防篡改记录；消费者、商户、发卡行各参与方只看到其角色所需的最小数据
- 协议无关设计：可与 ACP、UCP、AP2 及卡组织自有流程协同工作，底层建立在 FIDO Alliance、EMVCo、IETF 与 W3C 的既有标准之上；后续将与 Mastercard 可验证凭证平台整合
- 行业伙伴包括 Google、Fiserv、IBM、Checkout.com、Basis Theory、Worldpay、Adyen 与 Getnet；据 Mastercard 开发者文档，该框架将逐步集成进 Agent Pay 的意图 API
- 对照路线：美国运通 2026 年 4 月推出 ACE（Agentic Commerce Experiences）开发者套件，以发卡行与网络合一的闭环结构解决同一问题；开放回环与闭环两种路线的长期竞争值得关注
信任问题：从「能扣款」到「可举证」
线下刷卡时，持卡人在场、意图清晰；而当智能体根据数小时前的指令下单，支付链条上的每一方都面临三个无法回答的问题：消费者真的授权了这笔交易吗？智能体是否严格执行了指令、没有多做也没有少做？如果出了争议， anyone 能拿出证据吗？据 PYMNTS 报道，Mastercard 首席数字官 Pablo Fourez 将此概括为：自主性上升时，信任不能靠默认，必须可证明。
这一信任缺口是智能体支付全部协议栈的公共难题。交易协议（ACP、UCP、AP2，见本站相关词条）规定了消息怎么流转，但「这笔交易究竟是谁授权的、授权范围是什么」需要单独的证明层。Verifiable Intent 的定位正是这层证明：据 Mastercard 新闻室，它为交易附加一个随交易流转的信任凭据，使争议解决更快、更干净。
值得注意的是它与既有条目中 KYA（了解你的智能体）的分工：KYA 回答「这个智能体是谁、由谁负责」，Verifiable Intent 回答「这次交易它被授权做了什么」。两者互补而非替代。
技术机制：SD-JWT 与选择性披露
据 Mastercard 开发者文档，Verifiable Intent 构造一条防篡改的加密记录，绑定三个要素：消费者已验证的身份（谁授权的）、消费者给智能体的确切指令（授权做什么）、交易结果（实际发生了什么）。三要素共同构成争议发生时的加密证据链。
隐私由选择性披露（Selective Disclosure）技术保障：底层采用 SD-JWT（Selective Disclosure JSON Web Token），为交易中的每一方——消费者、商户、发卡行——构造加密委托链，各方只解密其角色所需的最小字段。商户不必知道消费者的完整身份信息，发卡行不必看到商品浏览轨迹，但每一方都足以验证「这笔交易在该环节是合法授权的」。
在人工辅助购买场景，框架确认消费者在场、购物车经确认、交易经授权；在更自主的场景，商户可据框架判断是否需要额外确认才能完成智能体发起的交易。据 Mastercard 开发者指南，结账时的 Verifiable Intent 凭据为「消费者授权了这笔特定购买」提供更强的保证，争议时则作为授权内容与执行内容的加密证据。
协议无关的定位与标准底座
Verifiable Intent 刻意做成协议无关层：据 Mastercard 开发者文档，它可与 ACP、UCP、AP2 以及各支付网络自有流程协同工作，而不是另起一套交易协议与 Google 等竞争。这一互补定位获得了 Google 的明确呼应——Google 支付副总裁 Stavan Parikh 表示，与 Agent Payments Protocol 兼容的可验证意图是扩展智能体商务的天然加速器。
标准底座方面，框架建立在 FIDO Alliance、EMVCo、IETF 与 W3C 的既有规范之上，并计划通过与 Mastercard 可验证凭证平台的整合持续深化，使消费者授权与委托更明确、可携带、可加密验证。这与本站 EMVCo 智能体支付框架词条记录的卡组织标准化进程形成呼应。
开源策略是 Mastercard 的显性押注：规范与参考实现公开在 GitHub 与 verifiableintent.dev，邀请智能体平台、支付与结账服务方、商户与开发者审阅、贡献与构建。一个信任标准能否成立，取决于参与广度而非单点技术，开源是争取行业共识的现实路径。
生态进展与路线对照
发布时公布的伙伴名单包括 Google、Fiserv、IBM、Checkout.com、Basis Theory 与 Getnet；据 Mastercard 开发者文档，Worldpay 与 Adyen 亦在生态合作之列。IBM 表示将把该框架与企业编排层对齐用于企业级部署。据 Mastercard 新闻室，与 Agent Pay 意图 API 的集成将在随后数月内落地，开发者的 API 规范与工具在 Mastercard Developers 渠道提供。
路线对照同样重要：美国运通 2026 年 4 月推出的 ACE（Agentic Commerce Experiences）开发者套件采用闭环思路——卡持有人经 Amex 应用授权特定智能体、在应用内管理授权与购买意图，发卡行与网络合一带来更紧的身份绑定与争议管理。开放回环（Verifiable Intent）与闭环（ACE）分别押注跨网络互操作与单网络强控制，两条路线的消长是智能体支付格局的关键变量。
对本站读者而言，Verifiable Intent 词条的实用价值在于提供了一个评估坐标：无论接入哪种智能体支付协议，都可以用「身份、指令、结果三要素是否可验证、是否最小披露」来评估信任方案的完备程度。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
🎯 应用场景
✅ 最佳实践
- 把 Verifiable Intent 视为信任层而非交易协议，与 ACP/UCP/AP2 组合使用而非相互替代
- 接入时优先验证 SD-JWT 委托链的密钥管理与轮换方案，凭据体系的安全性决定整个框架的可信度
- 商户侧按角色配置选择性披露范围，只解密业务必需字段，避免为「图省事」而全量解密
- 智能体平台应在发起交易时保留原始用户指令的完整快照，作为三要素中「指令」要素的可信来源
- 跟踪 v0.1 之后与可验证凭证平台的整合进展，评估消费者授权数据的可携带性对产品形态的影响
🔮 未来展望
智能体支付的竞争正从交易协议层延伸到信任证明层，Verifiable Intent 与 ACE 分别代表开放回环与闭环两种路线。值得跟踪的节点包括：与 Agent Pay 意图 API 集成后的实际落地规模、与 EMVCo 意图服务及可验证凭证平台的衔接形态、以及主要卡组织之间能否就智能体交易的信任格式达成互认。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。