摘要

  • RFC 9578 的私有可验证与公开可验证协议都只建立一条狭窄事实：认证器与令牌输入、发行方密钥相匹配。
  • 人类身份、挑战结果、自动化与否、重复使用、授权政策和实际交付分属不同控制面，必须各自留下可核查收据。

匿名票据最容易制造一种错觉：既然票据无法被轻易追踪，它就仿佛也无法被错误理解。实际上，隐私保护缩小了可见范围，却没有扩大票据能够证明的范围。

RFC 9578 对此写得异常克制：Privacy Pass 令牌除了证明某台服务器曾经创建它之外，不证明其他事情。RFC Editor 记录、IETF Datatracker 页面、文档历史和勘误查询能确认标准身份与状态，却不能证明某次线上发行、部署质量或访问决定。

密码学只接管它被交付的那一段

私有可验证协议采用 P-384 与 SHA-384 上的 VOPRF，只有掌握私钥的发行方能够验证最终令牌。公开可验证协议采用 2048 位模数的盲 RSA，持有公钥的一方即可验证。RFC 9497规定 VOPRF，RFC 9474规定盲 RSA 签名。

流程先依赖发行方配置：令牌类型、发行方名称、请求端点，以及公开验证场景中的公钥。客户端生成新的 32 字节 nonce，对不透明挑战计算 SHA-256 摘要，加入密钥标识，再盲化令牌输入。发行方检查结构和支持的类型，对盲化元素求值或签名并返回；客户端随后完成最终认证器。

发行时看不到最终令牌，是协议建立的重要隐私边界。但网络时间、账户上下文、证明方信号、配置获取路径、来源站点元数据，以及多个角色是否由同一组织控制，都不在盲化元素之内。消息不可见不等于整个部署已经实现不可关联。

挑战被哈希，不代表挑战已经完成

RFC 9578 把挑战当作不透明输入。它可能来自 RFC 9577 的 HTTP 认证与兑付流程。哈希能把令牌约束到一串字节，却无法验证这串字节究竟代表 CAPTCHA、设备证明、付费额度，还是运营方临时定义的其他条件。

如果界面显示“已完成人机挑战”，相应证据必须来自执行挑战的组件；如果它显示“设备可信”，则必须由证明系统承担。发行方只能证明自己处理了被提交的输入，不能替缺席的上游收据补写事实。

RFC 9576 的 Privacy Pass 架构区分客户端、来源站点、证明方与发行方，并讨论元数据和串谋风险。它是设计责任边界的依据，不是某个生产部署已经保持角色隔离的证明。BTW 关于 RFC 9614 的既有文章继续拥有“架构分离是否带来不可关联性”这条问题线；本文只追踪发行之后的验证、兑付、授权与结果。

验证成功仍在授权之前

私有协议用发行方秘密重新计算 VOPRF 输出；公开协议用公钥检查盲签名。成功结果只回答认证器是否与令牌输入及所选密钥相符。它不回答所有客户端看到的密钥配置是否一致，令牌是否新鲜，是否已经兑付，配额是否尚存，或请求动作是否被允许。

因此，兑付存储与来源站点政策不可省略。IANA Privacy Pass 注册表协调令牌类型和媒体类型，但注册不证明采用，更不产生授权。当前的发行方密钥一致性草案和限速令牌草案恰好说明：一致密钥视图与配额语义各自都是协议问题。这些仍是草案，不能当成 RFC 共识或部署证据。

可审计链条至少应保留配置来源与哈希、密钥标识、挑战字节及政策版本、nonce 与令牌输入哈希、发行响应、客户端完成结果、验证方与选用密钥、兑付存储裁决、重放状态、授权理由、响应状态和应用结果。隐私要求的是减少跨域关联，而不是把所有责任压缩成一个“通过”。

Heng Lu 的现实层级文章提醒我们，密码学有效性不能接管政策权力。Running-Code Primacy要求把真相放回运行中的组件与可观察行为。为什么 BTW Media 存在则给出编辑纪律：只陈述令牌真正挣得的那条事实，不替组织放大成更悦耳的结果。

来源