摘要

  • draft-ietf-privacypass-batched-tokens-08 不是一种批次，而是两种：一份证明覆盖多个 VOPRF 求值的摊销模式，以及允许逐位置为空的通用模式。
  • 每枚令牌都必须使用新的 nonce，但 HTTP 200、HTTP 206 或一份有效批次证明，都不能直接证明最终化、持久入库、单次消费和应用结果的数量。
  • 运营方需要一张隐私友好的批次凭证，逐项对齐请求、返回、最终化、提交和消费，又不能让批次 ID 反过来成为连接签发与兑换的追踪标识。

假设客户端一次申请 64 枚令牌。服务端回了 200，批次证明也通过。监控系统顺手执行 inventory += 64。

这不是协议要求，而是一项未经证明的会计决定。

服务端可能确实对 64 个盲化元素完成了求值，却不代表客户端正确解析了 64 个输出，不代表每个输出都和原来的 nonce 对齐，不代表最终化全部成功，更不代表数据库事务把 64 个不重复的 bearer token 都安全写了进去。一次密码交换可以完全正确，库存数字仍然可能是错的。

这正是批量签发带来的新治理问题。draft-ietf-privacypass-batched-tokens-08 发布于 2026 年 5 月 4 日，目标是 Standards Track；截至本次证据截点，它已由 Privacy Pass 工作组提交 IESG，但状态仍是 AD Evaluation::Revised I-D Needed。它不是 RFC。IANA 当前公开表中存在 0x0001 和 0x0002，草案所建议的 VOPRF(ristretto255, SHA-512) 类型 0x0005 仍未成为活跃登记项。

把状态说准，并不会削弱这项工作。恰恰相反，只有先限制标签的权力，才能看见机制本身解决了什么，以及没有解决什么。

“批次”里藏着两套失败语义

摊销私有可验证模式把同一类令牌的多个盲化元素放在一起。签发方逐个求值，却只生成一份覆盖输入列表与输出列表的证明。客户端先验证这份集合证明，再为各位置生成 authenticator。

通用模式则像一个可以混装的盒子。每个位置仍是普通 TokenRequest，甚至可以属于不同的已登记令牌类型。响应在相应位置放一个可选值：有值表示返回了 TokenResponse，空值表示签发方未能或拒绝处理该项。只成功一部分时，签发方必须返回 HTTP 206，并继续处理后续位置；一枚都不签发时才返回 400。

因此，“批次成功”不是一个足够精确的状态。摊销模式有一个共同证明门；通用模式保留逐位置的部分成功。把两者都压成一个绿色指示灯，相当于主动丢弃协议已经给出的故障信息。

真正有用的统计至少要回答六个问题：申请了多少、接受了多少、返回了多少非空位置、最终化成功多少、持久提交多少、目前仍可用多少。六个数字可以同时不同，而且每种差异都有不同责任人。

新 nonce 保证密码输入独立，不替你数库存

在摊销模式里，客户端必须为每枚令牌重新生成 32 字节 nonce。令牌输入还包含令牌类型、challenge 摘要和签发方密钥标识。也就是说，多枚令牌共用一次往返和一份证明，并不等于它们共用同一个密码身份。

但软件仍要维护位置关系。第 i 个求值元素必须回到第 i 个 nonce，也必须使用对应的 authenticator 切片。重排、截断或 off-by-one 错误都可能让局部关系失真，而“证明通过”这句话本身未必揭露这种错误。

完成最终化之后，另一个系统才刚刚接手：令牌库存。进程可能在最终化成功之后、数据库提交之前崩溃；也可能写入一半再重启；重试可能生成新令牌，也可能把本地记录重复插入；旧备份甚至会让已经兑换的 bearer token 再次出现。

nonce 新鲜度是协议不变量，不是数据库事务。它不能证明没有重复行、没有双进程抢占，也不能证明备份恢复保持了消费状态。

运营凭证需要暂时保存位置对应关系，足够支持最终化和原子入库；之后应主动缩短或删除可关联数据。若系统把一个稳定批次 ID 永久挂在每枚令牌上，并在未来兑换时继续记录，它就会成为协议之外最强的关联器。

摊销的是证明，不是所有成本

草案对性能的表述很克制：BlindEvaluateBatch 对 Nr 个元素仍然是线性复杂度。它减少的是重复生成证明的实际开销；随着批次变大，实际成本可接近 Nr 次单独签发的大约一半。

这绝不是“花一枚的钱拿 64 枚”。逐元素求值、解析、网络字节、配额检查、客户端状态、最终化和存储并没有消失。通用批次的安全说明也直接提醒实现者，其成本仍然线性。

一份共同证明还扩大了共同失败域。摊销请求只要含有不支持的类型、不匹配的截断密钥标识、超过签发方上限的 Nr，或任意一个无法反序列化的盲化元素，签发方便应返回 422。客户端若无法反序列化响应或无法验证证明，也会中止整个流程。

这是一笔明确交易：更大的批次减少重复成本，却让更多未来动作一起依赖同一个解析器、同一密钥、同一次准入和同一证明。批次大小不能只由吞吐基准决定，还要由相关损失和恢复成本决定。

206 不是“差一点成功”，而是精确的缺口收据

通用模式最值得保留的设计，是它拒绝假装完整。每个请求都有一个对应的可选响应。中间一格可以为空，后面的请求仍继续处理。

客户端不应因为不是 200 就丢弃 206 响应，也不能因为 206 属于 2xx 就把全部请求计作成功。它必须逐位置读取，跳过空值，用相应令牌类型的程序最终化非空项，然后只为真正提交的记录增加余额。

草案给出的例子与密钥迁移尤其相关：同一令牌类型的多个请求若指向不同的 truncated token key ID，签发方可能返回 206。这时，部分成功是配置分裂的证据。若客户端无差别重试全批，就会掩盖原本可以定位的问题。

运营语言可以写得很简单：

requested ≠ present ≠ finalized ≠ committed ≠ available ≠ spent。

不要再用一个含混的“issued”字段替代所有阶段。签发方认为自己已经返回，客户端可能根本没收到；客户端收到后可能没完成最终化；最终化成功也可能没有持久写入。谁观察到什么，应成为凭证的一部分。

重试必须有自己的宪法

收到 206 后，是重试整个批次，还是只重试空位置？网络断开后，怎样判断签发方是否已消耗配额？本地在最终化之后崩溃，应该重新签发，还是先修复库存事务？

没有本地状态，协议无法替运营方作答。全批重试可能再制造一批有效令牌，也可能再次消耗准入预算。逐位置重试要求客户端准确重建原始映射。完全不重试可以保护会计，却可能让业务缺少可用库存。

因此，重试单位必须预先定义。每个位置应有不敏感的请求摘要、令牌类型、签发密钥 epoch、响应是否存在、最终化结果和提交结果。它们可以支撑恢复，却不应与 bearer token 或未来 origin 日志永久联结。

一个 timeout 不是重试授权。它只说明观察者失去了消息，不说明远端什么都没做。

批次上限就是写进代码的分配政策

摊销签发方可以限制一次批次签发多少枚。通用签发方也可以忽略超过上限的请求。安全部分还建议按客户端、按密钥限制请求数量。

这些参数不仅影响 CPU，还决定谁可以通过一次在线交互积累多少未来可用的 bearer 库存。大批次利于预取和离线容错，却集中价值与泄漏风险；小批次降低单次损失，却让签发方更频繁地处在关键路径上。

密钥轮换时，上限还会产生断崖。如果旧配置和新配置混在同一批次，206 比例可能突然上升。运营者若没有记录上限版本和变更责任，只会把它误判为密码算法不稳定。

这是一项本地政策，应当有明确所有者、版本、告警和例外路径。IETF 需要统一的是可互操作的结构和错误语义，而不是替所有签发方决定统一配额。签发方也不应把自身的商业或滥用政策包装成标准的唯一要求。

IANA 数字、实现报告和生产事实不能互相替代

修订 08 请求 0x0005 与四个媒体类型。当前 IANA 页面还没有 0x0005。负责的 Security AD 也在 9 月 20 日评论中要求澄清建议值、引用和 downref，并请求 HTTP Directorate 提前审查。

这属于正常的标准化过程，不等于拒绝，更不是已经发现安全漏洞。评论甚至明确说问题应当容易处理。但它提醒运营者保持证据顺序：草案建议、IANA 分配、软件支持、互操作验证、实际交换、最终化、库存和业务结果是八张不同收据。

工作组 shepherd 记录的是一个小型工作组内的强共识和若干实现报告，没有给出实现清单、互操作矩阵或部署测量。因此，准确的说法是“已有实现报告，正在接受 IESG 评估”，而不是“行业已经部署的新标准”。

不能让审计系统摧毁盲化带来的隐私

RFC 9576 把 attestation、issuance 和 redemption 上下文分开，因为隐私最终取决于不同观察能否被拼接。批次签发会暴露自己的元数据：时间、大小、签发方、密钥 epoch、网络入口。

若客户端账本再加入永久批次 ID、设备账户、存储位置和未来兑换记录，这些字段就能重新拼出轨迹。密码层可能完全正确，审计层却把匿名令牌变成行为索引。

可审计与不可关联并不矛盾，但需要刻意设计。优先保留聚合计数和单向摘要；缩短请求—位置映射的保存期；隔离签发和兑换分析权限；禁止把批次 ID 带入 origin 请求；只有针对具体事故的受控流程才允许有限联结。

凭证应当证明“库存是否对账”，而不是轻易回答“某用户后来用的是第 912 批第 37 枚”。

补上真正缺失的批次凭证

一张实用凭证可以分三层。

批次层记录模式、签发端点、令牌类型、challenge/配置摘要、密钥 epoch、请求数量、HTTP 状态、响应向量长度、证明或响应摘要、适用上限与时间。

位置层暂时记录请求摘要、响应有无、反序列化结果、最终化结果、令牌记录摘要和提交状态。它需要保存顺序以证明关联，完成目的后按政策删除。

库存层维护事务化余额：期初、成功提交、隔离、删除、已选择、已确认消费、结果不明和期末。真正的规则不是“200 就加 Nr”，而是“只有最终化成功、未重复且持久提交的记录，才增加可用库存”。

后续兑换再产生自己的凭证：选择了哪项受保护库存、是否匹配 origin challenge、是否通过 replay 状态、origin 是否授权、应用是否产生效果。两个凭证只能通过受保护、目的受限的证据连接，不能通过公开可查询的追踪键连接。

完整链条是：

配置 -> 证明资格 -> 申请 -> 准入 -> 返回 -> 验证/最终化 -> 入库 -> 选择 -> 兑换 -> 授权 -> 观察。

批处理只是让链条前半段更便宜，并没有让任何一道门消失。