摘要

  • 钱包状态证明草案第 -01 版于 2026 年 9 月 27 日发布；它是作者个人提交的活跃 Internet-Draft，不是 IETF 认可的标准或部署报告。
  • JSON 签名的顶层对象只有 id、pass、results、attestedAt；具体条件可能包含地址，但格式不保证签名对象总体写明被查询的钱包。
  • JSON 的 expiresAt 在签名之外。可选 JWT 将钱包 sub 与过期 exp 纳入自己的签名；依赖方不能用旁边那份 JSON 的验签替代 JWT 验证。

核验收据离开请求现场之后

这份第 -01 版草案设想，由发行方读取钱包的公开链上状态，按运营者设定的条件给出布尔结果或结构化事实，再签名交给核验方。核验方可用公开密钥集离线验证；持有人无需出示身份凭证。这种设计想把“满足门槛吗”与“具体持有多少”分开。它的代价是，需要明确谁保管查询时的上下文。

如果请求方和最终放行方是同一个进程，它知道自己刚查询了哪个地址。若核验结果经由队列或另一家公司转交，接收者只握着一份 JSON，情况就不同。新版第 5 节明确列出签名顶层对象：id、pass、results、attestedAt。钱包地址并非总在这四项中。某些 evaluatedCondition 可把地址带入签名保护的 results，但草案没有保证每种条件都这么做。因此，“签名有效”只能证明这些字节来自相应密钥，不能凭空还原被查询的钱包。

问题不必表现为攻击。两个并发请求、一个缓存键写错或一次跨团队交接，只要把正确的“通过”接到错误账户，访问决定便可能出错，而验签结果仍是绿色。这是一个有条件的风险场景，不是已发生的事故。要求提供请求 ID、钱包地址与结果的可核对绑定，也不是草案现成规定的强制字段，而是 Daniel Kade 提议的运营控制。

时间戳与过期提示不在同一个信封

在 JSON 形态下，attestedAt 和每项结果的链上区块等观察锚点受签名保护，expiresAt 则放在相邻字段里，没有被那份签名覆盖。草案把它当作发行方提供的存续提示。核验方若依赖该字段，应对照已签的 attestedAt 和发行方公开的有效期上限，拒绝被拉长的过期时间；若需要更严格的时效，还可直接对已签时间和区块参考设置自己的最长可接受年龄。只检查签名，并不能自动完成这些步骤。

新版的七步核验过程也划出不同责任。选取 kid 对应的密钥与签名方式、重建签名字节、验签、重算每个 conditionHash，属于草案要求的步骤；检查新鲜度与过期时间则被写作建议。读者不应把建议误说成所有实现均已执行的事实。kid 缺失或查不到时，结果是“无法核验”，不能试用密钥集里的第一把钥匙；在选定密钥下签名不成立，才是“被证伪”。两者都不足以放行，但原因不同，补救动作也不同。

JWT 是另一份需要亲自打开的信封

请求中可选择 JWT 格式；此时发行方还会给出一枚单独签名的令牌。它的 sub 指向实际被条件评估的钱包，exp 是签过的过期时间，受保护的头部中有 kid。这比 JSON 主体提供更多主体与时效绑定，却不是“只要旁边有 JWT，JSON 签名就自动变强”。依赖方若读取 JWT 的声明，必须验证这枚令牌本身；如果同时收到两种形态，新版还规定核对它们的对应字段。附带 JWT 验证失败或与 JSON 不符，整个答复须被拒绝。JSON 本身不因此获得一个原本没有的 sub。

可选的 Merkle 证明也不是万能补丁。有的条件或链不支持相应证明；在可用时，证明可能暴露原本由布尔结果遮蔽的余额等原始链上值。它能改变对发行方观察结果的依赖方式，也会改变隐私成本，仍不能替接收方决定“这是否就是我要查询的钱包”。

第 -01 版增加了按 kid 选择的域分离 JSON 签名方式、第二算法的可选附加签名，以及更明确的核验分支。但作者在修订说明中表示，第 -00 版已经签发的证明仍可按原样验证。不能说本次修订“造成”钱包字段缺位或无签名的 JSON 过期字段；它把既有格式的覆盖范围讲明白了。Datatracker将其列为无 RFC stream 的个人 I-D，IESG 状态为 I-D Exists，并明确说明 I-D 不代表 IETF 背书。稿内列举的生态采用和生产发行方，不等于本文已经独立核实了实际部署。

来源