摘要

  • IETF 档案于9月4日发布 VCAP 个体 Internet-Draft 第02版；它没有 IETF 背书、正式标准地位、RFC 流或负责 Area Director。
  • 新版增加“验证者问责”一节，承认平台选定验证者时会实质控制结算结果，并要求登记密钥、能力、争议通道和变更历史。
  • 但提供方提交的 service_delivery 仍可携带 auto_approve；草案把它定义为跳过自动验证，由提供方自行证明交付。
  • 现有文本没有规定谁可接受这项豁免、哪条协议授权、谁生成并签署 callback、哪些检查仍保留，或豁免如何到期和被争议。
  • 资金移动前应生成一张验证豁免回执，连接提出者、接受权限、合同依据、范围、上限、期限、签名者、冲突证据、争议路径与最终资金状态。

新版先承认了普通路径上的权力

IETF 发布通知记录的是一个有限事件：Ben Stone 撰写的30页 Internet-Draft 于9月4日进入公开档案。Datatracker 页面给出了制度边界。这是活跃的个体提交，任何人都可以提交；它不代表 IETF 认可，在标准流程中没有正式地位，也没有 RFC 流、负责 Area Director 或 telechat 日期。文首的 Informational 只是作者设定的目标状态。

在这条边界内，第02版描述了一条会产生经济后果的消息链：请求方与提供方协商任务和价格，市场平台托管资金，提供方提交成果，验证者检查交付并向平台发回 verification_callback。其中 passed=true 把验证状态送往 VERIFIED，并推动资金释放；passed=false 则送往 FAILED 和退款。草案把 callback 称为整套协议最关键的消息，因为它触发结算。

官方版本差异显示，相比第01版，新版补上了“验证者问责”。它直说：当市场平台选择验证者时，平台实际上控制着结算结果。因此，平台接受任何结果前，必须登记并信任验证者的 Ed25519 公钥或验证方法，记录其声称具备的能力，并定义结果被质疑后的升级路径。验证者登记、密钥轮换与注销，都必须带时间戳并与结算档案一同保存。

如果平台运营者同时控制验证者，草案建议支持由请求方和提供方共同选择第三方验证者；也建议公布不同服务类别如何分配验证类型、利益冲突如何处理，以及争议结果如何升级。这里的“共同选择”和“公开政策”是 SHOULD，密钥、能力、争议通道和变更日志则是 MUST。

这是一项实质进步。它没有假装技术验证天然中立，而是指出了选任权所在。不同交易仍可采用不同风险安排，不必由一个全球机构统一决定。但同一套文本没有对“选择不进行自动验证”的权力作出同等交代。

跳过验证的开关来自收款一方

当提供方声称工作完成时，它发送 service_delivery。消息包含交付状态、说明、文件或链接，还可附带验证提示，例如目标网址、选择器、预期内容和页面指纹变化。提示对象中另有 auto_approve。它是可选布尔值；若为 true，就跳过自动验证，并由提供方自证。

草案链接的交付 JSON Schema把来源关系写得更清楚：消息由提供方提交，提供方的验证提示可以“覆盖或补充请求方提示”。auto_approve 默认为 false。默认值只解决字段缺失时如何解析，却没有回答授权问题：收款方能否自行把它设为 true，这个值又要得到谁的同意才产生效力？

在固定的 -00、-01 与 -02 文本中，auto_approve 每版都只出现两次：一次在消息样例，一次在提示字段表。附近没有处理流程，没有列出合格提出者、接受者、合同条款、金额或风险上限、保留检查、到期、撤销、冲突与审计记录。

若平台收到一个未经识别的 true 值，它应该忽略、拒绝、继续 HELD、向请求方再确认，还是送人工复核？草案没有答案。独立实现者可以各自作出合理选择，却无法从相同文本导出一个唯一可互操作的结果。

这个缺口不能被写成事故。公开资料没有证明任何产品实际处理了该字段，更没有证明提供方曾据此强迫平台放款、发生错误结算或利用行为。可确认的事实更窄：当前规范没有完整描述该字段的权限与状态转换。

从“跳过”到“已结算”之间少了一座桥

普通路径的 callback 要求携带 passed、证明摘要、证明签名、验证者密钥标识、动作日志和完成时间。结算记录再复制验证标识、摘要和签名。如果自动引擎根本没有运行，谁扮演验证者？

由提供方签名，会把受益人的自证变成自身裁决；由平台签名，签的是风险接受决定，而不是对交付内容的独立观察；由人类签名，则实际上进入人工复核，理应明确记录其角色。现有文本没有选择其中一种，也没有说明“刻意不做检查”应如何写进动作日志。

密码学不能代替这个决定。VCAP-02 对规范化证明包计算 SHA-256，并用 Ed25519 签署验证、协商、托管标识、passed、摘要、密钥标识与时间。RFC 8032让拿到公钥的第三方可以验证签名。VCAP 自己也准确限定：摘要说明内容未被改动，签名说明内容来自被授权的验证者。它们不说明请求方曾同意自证，也不携带允许豁免的合同条款。

原子操作同样回答不了权限问题。compare-and-swap 可以阻止同一笔托管同时被释放和退款；幂等规则可以阻止重试消息重复结算。这些机制确保只有一个终态，却不能证明通往终态的例外由正确主体批准。

超时路径提供了鲜明对照。自动验证在默认1,800秒内未完成时，资金必须保持 HELD；平台应创建人工复核项，最终必须由人类决定。该复核者仍要发出标准 callback，用一条动作日志记录人工决定，并正常计算摘要与签名。这个例外可以回答谁决定、通过什么消息、依据什么材料。auto_approve 路径没有同等级的记录。

自证本身不必被禁止。低金额、重复性任务或长期合作可能使请求方愿意用更低验证成本换取速度。问题在于，“双方事先约定可以自证”与“收款方交付时发送一个 true”不是同一治理状态。

被链接的可执行材料已经出现版本分叉

草案还链接了机器可读 schema。截稿时，verification_callback Schema仍要求十六进制 HMAC-SHA256，只接受 vcap_version 1.0，而且没有 verifier_key_id。第02版正文则要求 Ed25519、Base64 编码和密钥标识，并要求实现根据版本选择签名算法。仓库提交历史显示，这组链接 schema 没有随9月稿件同步更新。

这不证明某个生产系统失败。它只证明遵循最新正文的人和遵循链接 schema 的验证器会拿到不同合同。auto_approve 的权限若继续停留在暗示中，即使双方都能解析相同 JSON，也可能在最重要的分支上执行不同含义。

新版还修正了对 AP2 的描述。AP2 规定授权、支付证据与角色验证；VCAP-02 不再假设它定义托管、扣款、退款和结算状态。因此，auto_approve 的缺失权限不能被默认为“上游协议会处理”。

资金移动前生成验证豁免回执

修复不需要建立统一验证机构，只要增加一张小而明确的回执：交易、协商与托管标识；VCAP 正文和 schema 的版本及哈希；提出自证的提供方；允许它的合同条款；请求方与平台的接受主体；被替代的验证者选任规则；放弃和保留的每项标准；理由；金额与风险上限；生效、到期与撤销时间；callback 模式及签名者；冲突证据；争议路径；最终资金状态。

这张回执必须在结算前形成。如果系统不能解析授权条款或接受者身份，就拒绝该提示或维持 HELD，不能从先前的一般协商同意中猜出一次新的验证豁免。

各方仍可自行设定信任阈值。共同层只保存互操作所必需的最少事实：谁有权选择例外、例外覆盖什么、持续多久、最终产生什么后果。这样既不把本地商业判断中央化，也不让收款方的一项提示悄悄变成全局有效的放款权限。

来源

  1. IETF 关于 VCAP 第02版的发布通知
  2. IETF Datatracker 状态页
  3. VCAP 第02版
  4. VCAP 第01版
  5. 第01至02版官方差异
  6. service_delivery JSON Schema
  7. verification_callback JSON Schema
  8. VCAP 规范仓库提交历史
  9. RFC 8032 — EdDSA
  10. Google Agent Payments Protocol 规范
  11. Heng Lu：Running-Code Primacy
  12. Heng Lu：最小共同规范与本地决定