摘要

  • Wes Jackson 的验证方评估草案第 02 版要求验证方处理提交的每一项 authorization_details；遇到无法评价的类型，应拒绝整个令牌，而不是悄悄删掉那一项后放行。
  • 新版还区分两种信息：调用者应明白原样重试这枚令牌无效，但不应从错误响应获知具体失败的委托路径或上层授权状态。精确原因应留在验证方可控的审计记录中。

想象一家机构的代理向另一家机构提交令牌。令牌里的授权细目有四项，接收方只能识别其中三项。此时最危险的“成功”不是一眼可见的错误，而是系统把第四项忽略，随后报告授权检查通过：收到的请求与实际检查的请求已不相同。拒绝令牌可以阻止这种偏差，但拒绝后的话该说到哪一步，又是另一道治理题。

9 月 29 日的 draft-jackson-wimse-evaluation-02 为这道题增添了明确文字。IETF Datatracker 将其列为 Wes Jackson 提交的个人 Internet-Draft，状态为 I-D Exists，没有标准化流归属；这不是 WIMSE 工作组已采纳的文本，更不是 RFC 或现行产品要求。第 01 版把首条评估规则称为“逐项处理或 Reject”，第 02 版改为“逐项处理或 Refuse”。新稿的术语部分将验证方对令牌／记录的拒绝，与审批者对已暂停调用的最终否决分开。两个动作分别发生在证据验证和人工授权的边界，不应混写成一个“拒绝”。

新版第 4.1 节的主张是全量处理：验证方不懂某个授权细目类型，就无法声称完整评价了这枚令牌。草案把这种拒绝界定为针对已提交的同一令牌的永久结果。原样再送一次不会让验证方凭空获得对该类型的支持。这并不等于调用者永远不能申请别的令牌，也不等于所有失败都无法修复；“永久”的作用域很小，却足以决定重试策略。

真正微妙的地方在第 5 节。草案建议让调用者辨认出原令牌继续重试无望，以免产生没有意义的请求循环；同时，它明确禁止错误响应越过验证方已公开的能力信息，指出到底是哪个授权细目、哪一段委托路径或哪个上层 grant 失效。后一类解释会把验证接口变成探测他人权限图谱的工具。即使提交方诚实地相信自己仍有授权，验证方也不必在外部错误中替它修订内部授权地图。具体故障原因可以进入本方受控的审计记录，供运维者追查。

这里不能把两个既有 OAuth 错误码当作同一处的万能答案。RFC 9396 第 5 节的 invalid_authorization_details 是授权服务器处理未知或不合规授权细目时的错误；登记适用位置是授权端点与令牌端点。RFC 6750 的 invalid_token 对应资源服务器使用 bearer token 的场景，并允许客户端换取新令牌后重试。Jackson 草案援引这些例子，但没有登记新错误码，也没有制定通用响应格式。该用什么信号，必须看实际端点与传输协议；对同一令牌不宜重试，不能偷换为“任何后续尝试都禁止”。

草案没有证明生产环境已经发生授权图泄漏，也没有统计实际重试负载。文中提及的公开参考实现并未消费 authorization_details，相关规则不能被说成已通过全面互操作验证。这篇新闻的价值因此不在于渲染事故，而在于指出一个容易被单一状态码掩盖的两难：外部必须得到足够少、但足够有用的信息；内部则必须留下足够精确、但不外泄的诊断。

资料来源