摘要

  • 9 月 28 日提交的个人 Internet-Draft 拟用 client_attesters 元数据表明客户端认可哪些证明方；授权服务器仍需独立决定是否接受该证明方及其密钥来源。
  • 把证明方从权威元数据中删去，只会在服务器看见变更后阻止其凭该背书进行新的客户端认证。已签发的授权与访问令牌不会因此自动作废。

应急清单里最容易打勾的一项，往往是“已从名单移除”。但系统里至少还有三个格子：授权服务器是否仍持有未过期的旧名单，是否继续接受新的证明，以及以前发出的访问凭证是否还被资源服务器认可。K. McGuinness 的《OAuth 2.0 Client Attester Endorsement》首稿恰好把这些问题拆开；它没有提供一枚按下便使所有权限消失的按钮。

这份文件日期为 2026 年 9 月 28 日，是拟走 Standards Track 的个人 Internet-Draft。IETF Datatracker将其列为已存在的草案，不等于已经成为 RFC、被 OAuth 工作组采纳、完成互操作测试或在某次事故中实际使用。其基础是另一个仍在演进的基于证明的客户端认证草案。新稿不创造新的凭证或客户端认证方法，拟补上的关系是：对同一个 client_id，究竟由谁授权某个证明方为它的实例作证明。

第一项控制属于客户端的发布者。它可在登记信息或 Client ID Metadata Document 中提供 client_attesters，列出所认可的证明方及验证密钥位置。第二项控制属于授权服务器：按这份方案处理的请求，只有权威客户端元数据当前认可证明的签发者，而且服务器自身策略允许该证明方服务于该客户端、选定可信的密钥来源，证明才可能被接受。客户端发布者不能借“我认可”强迫服务器信任；服务器也不能借“我信任”给未获该客户端认可的证明方开绿灯。两层判断均不是用户授权或资源访问许可。

名单修改后，时间问题出现了。草案要求授权服务器为背书元数据和 JWK 密钥集的缓存副本设定有限的最长寿命；副本过期后必须重新核实或刷新，失败则拒绝旧副本。它没有替所有部署规定统一上限。因此，客户端发布者不能只凭协议文本推断撤回会在多少分钟内生效。若需要可预期的上界，双方应把它写进信任安排。该缓存规则针对副本，而非作为权威来源的客户端登记本身。服务器一旦取得或保存更新，就必须在下一次提交证明时使用新状态；服务器策略直接拒绝某证明方，则对后续请求生效，无须等缓存过期。

还有更容易漏掉的追溯问题。第 6.3 节明确说，撤回背书是面向未来的：它阻止被撤下的证明方继续帮助客户端完成新的认证，却不撤销已有 grants 或访问令牌。需要证明的续期请求会重新受检；真正要终止访问，则应另行撤销相应授权和令牌，并停止进一步签发续期。RFC 7662 的令牌自省可报告被撤销令牌为不活跃；本地校验令牌的资源服务器则需要独立的撤销渠道，或等待令牌到期。元数据缓存即时更新，也不能把过去发出的令牌从所有使用地点抹掉。

草案还提醒：如果授权服务器允许发布者自行选择证明方及密钥，发布者可以运营自己的证明方，这样的证明不提供独立于发布者的保证；若客户端还有另一种获准的认证方法，且证明不是强制信号，仅列出 client_attesters 并不会逼它提交证明。元数据站点被控制时，背书可以在服务器策略允许范围内改变，而本草案本身不提供恶意改动的独立证据。这些是设计威胁模型，不是关于某家公司已经遭入侵的事实。

因此，一份可信的撤回应急记录不宜只附上新名单。它还应说明是谁有权改动、旧名单与新名单分别是什么、每个授权服务器采用何种信任模式和缓存寿命、何时第一次拒绝新的证明、哪些授权和令牌受影响、续期是否停止、资源服务器怎样处理既有令牌。这是本文提出的治理核对办法，不是 IETF 规定的新字段。它要防止“发布者已经声明撤回”被偷换为“整套系统已经完成终止”。

来源