摘要

  • draft-zehavi-oauth-authz-req-del-chain 第 01 版于 2026 年 9 月 10 日公告，当前是个人提交的 Internet-Draft，并非 OAuth 工作组采纳稿或 RFC。
  • 分离式 JWS、前一节点哈希、序号和受众连续性用于保护上游授权服务器能够看见的经纪路径。
  • 删除链尾或中间节点会破坏验证；但经纪方可以把自己设为新的 chain[0]，生成内部完全有效的新链。
  • 草案承认密码学无法证明首节点之前不存在上下文，并要求授权服务器用本地策略决定该签发者能否成为可见起点。

从零开始，也可以全部验签成功

上游授权服务器看到三份排列整齐的声明：每个签名都有效，序号连续，前后哈希相接，后一站的受众正好对应下一站的签发者。最后一项也确实指向正在处理请求的服务器。

这足以证明“收到的这条链”结构完好，却不能证明“真实经历只有这条链”。

OAuth Authorization Request Delegation Chain 第 01 版讨论的是经纪式重定向授权。下游客户端的请求可能经过多个中间授权服务器，最后才到负责征得用户同意并签发令牌的上游服务器。每个经纪方在下游关系中是授权服务器，在上游关系中又是 OAuth 客户端；最上游往往只直接认识最后一名经纪方。

草案为此定义一种 RAR authorization_details 对象。链中每个 JSON 节点写明谁作证、声明给谁、处在第几位、为哪个客户端作证，并附带分离式 JWS。p_hash 把本节点与前一份已签署事件连接起来。

验证从链尾向链首倒查。最后节点的 aud 必须是接收服务器，签发者还要与实际通过 OAuth 身份验证的客户端相符。之后逐项检查密钥、签名、序号、命名空间、前一节点哈希以及相邻节点的签发者—受众连续关系。

关键限定不是“可验证”，而是草案反复使用的“可见链”。

截掉三个位置，只有两个会留下断口

第 01 版把截断分成三类。去掉尾部，链最后一项就不再指向真正的接收服务器；从中间抽走一项，后继节点的 p_hash 和相邻受众关系都会断裂。这两种改动可以由链内证据发现。

截掉头部不同。一个经纪方可以舍弃更早的上下文，另起一条链，把自己写在序号零，令前一哈希为 null。从这个新起点往后的每个字节都可能符合规则，所有签名也都真实。草案称之为“重新发起”（re-origination），并明确说密码学验证不能证明 chain[0] 之前什么都没有。

这不是外部发现的一项攻击，也不是对草案的漏洞通报，而是提案自己标出的证明范围。哈希链可以保证所声明的起点前后一致，却没有链外证人来保证它就是历史起点。

因此，授权服务器必须用本地策略判断：针对当前客户端、资源和部署环境，这个签发者是否获准成为第一个可见签发者。数学验证结束的地方，恰好是治理责任开始的地方。

类似边界还有两条。签名有效只说明该签发者签过节点，不代表它有权处理这次委托。新增的 client_roles 元数据可以把客户端标为 oauth_broker，但自行声明的角色不能证明可信或获权。眼前的 OAuth 客户端仍须单独完成身份验证，并与链尾绑定。

明示降级，不等于补齐起点

第 01 版还增加了上游支持发现和降级处理。经纪方可以通过 RFC 8414 元数据查看上游是否在 RFC 9396 的支持类型里列出这条委托链。若下一站不支持，已有的链不得被静默丢弃。

经纪方只能拒绝交易、用另一种受信机制保留上下文，或者在本地策略与已签链同时允许时改为无链转发。可选字段 omit_chain 取值为 allowed 或 forbidden；缺省视为禁止，而且所有已验证节点都必须允许，才有可能显式降级。

这项规则让后续证据损失可见，却无法倒查新链创建之前发生了什么。omit_chain 管的是“眼前已有的链能否在下一跳消失”，而重新发起问的是“这条链出现之前是否已有被舍弃的路径”。两者不可混为一谈。

草案还建议向 IANA 登记 client_roles 动态注册元数据。目前这些仍是个人 Internet-Draft 的提案，不是 IETF 共识、工作组采纳、已完成登记或部署事实。

来源