OAuth 委托链能收权，却不能证明意图

Summary

draft-li-oauth-delegated-authorization-03 提议由授权服务器签发根令牌，再由持有父级绑定密钥的客户端本地签发更窄的子令牌，末端客户端用 DPoP 证明自己掌握叶节点密钥。
验证能确认签名、相邻密钥、权限、受众、时间与委托深度的连续收窄，却不能确认具体任务是否符合人的意图，也不能保证离线资源服务器已经获知撤销。
Daniel Kade 提出协议外的“委托意图回执”，把根授权、逐跳托管、任务与影响边界、撤销新鲜度、资源决策和收尾证据连起来，同时不保存令牌或私钥。

这条链解决的是权限放大

代理系统常遇到一个现实问题：编排器拥有较宽的访问权，却只想把一小部分工作交给专门组件。如果直接转交原始访问令牌，子组件拿到的权力过大；如果共享私钥，责任边界更糟；如果每次都回到授权服务器重新发证，又失去本地分工的效率。

修订 03 给出的办法是 Delegated Authorization Token。授权服务器先签发根令牌，并用 cnf.jkt 把它绑定到第一个客户端的公钥指纹。该客户端若仍有委托额度，就用这把绑定密钥签发子令牌，并把子令牌绑定到下一个客户端的密钥。重复这一过程，就形成从根到叶的有序链。

资源服务器验证时，根密钥必须来自受信配置或认证过的元数据，不能因为令牌自己附带了某把钥匙就相信它。每个子令牌在受保护头中公开用于验签的公钥；其 RFC 7638 指纹必须与父令牌的 cnf.jkt 相等。最后，叶节点密钥对 DPoP proof 签名，把请求方法、目标 URI、完整链的精确序列和新鲜度材料绑定起来。

因此，偷到一串令牌还不够。调用者必须证明掌握叶节点私钥。草案为此提出独立的 DA HTTP 认证方案，并明确 Delegated Authorization Token 不是 bearer token，不能按 Bearer 或普通 DPoP 令牌来接收。

这套机制给出一个很强但很窄的答案：父级绑定的密钥确实授权了下一把密钥，末端调用者也确实控制预期密钥。它没有承诺回答所有带“授权”二字的问题。

权限变窄不是 JSON 变短

草案要求子级的权限、受众、有效期和剩余委托深度都不能比父级更宽。普通 scope 可以按集合处理：子级不能增加父级有效集合里没有的 scope；省略它意味着放弃这一权限分量，而不是悄悄继承一个更宽的默认值。

authorization_details 更难。一个支付、数据选择或基础设施操作对象，可能包含金额、动作、资源标识、数组、通配符与默认语义。字段更少不等于权力更小。若省略某个限制会触发宽松默认值，一份更短的 JSON 反而可能扩大权限。

所以草案要求每种授权详情类型定义可确定执行的包含关系。只比较原始文本或只看 type 名称都不够。验证器若无法证明子值被父级有效值覆盖，就必须拒绝整条链。影响授权的扩展 claim 也一样：若预定验证方并未共同实现其委托语义，它就不能充当有效限制。

这把治理责任放到了词汇和实现版本上。签名保护了值没有被篡改，却不解释值之间谁更窄。真正的“单调收权”依赖各方对默认值、通配符、数组和动作有一致的可计算解释。审计记录因此不能只写“签名成功”，还要写明用了哪个包含规则版本。

深度只计算边，不衡量后果

每个根令牌都必须带有限的 max_delegation_depth。有效值为零时不能再签发子级；父级值为正整数 m 时，子级可以显式选择零到 m-1，省略则得到 m-1。授权服务器还要设本地上限，解析器和验证器也必须限制链的数量、大小与验签成本。

这个数字回答的是“图上还能增加几条边”，不是“最后一项操作有多危险”。一次终端委托可以允许不可逆写入，三次委托也可能只得到只读查询。零深度不表示低风险，不表示最终客户端被用户看见，也不表示人批准了这笔具体交易。

当流程涉及 resource owner 时，初始授权决定必须覆盖两件事：客户端今后可以在没有新一轮授权服务器或所有者交互的情况下发出子令牌，以及允许的最大深度。普通访问许可不能被解释成委托许可；若所有者拒绝显式请求的深度，系统不能暗中改成较小数字并当作同意。

然而，草案并不定义这项能力应如何向人展示。界面即使正确显示“两层委托”，也未必解释未来会出现哪些代理、密钥如何在带外发现、每一层能做何种业务动作、什么影响需要重新确认。协议限制了未来分支的形状，却不叙述分支里的具体角色。

意图位于协议主动留白的地方

修订 03 明确把多项功能留给部署政策或扩展：客户端之间怎样发现公钥，带外怎样协商委托，多条链怎样传递，交付的链怎样与某个请求或任务绑定，各业务类型怎样判断包含关系，以及撤销状态怎样送达资源服务器。

这些不是边角问题，恰恰是通用权限与具体目的之间的接缝。

假设一个研究代理得到十分钟、单一受众、只读且不可再委托的令牌。链可以完全有效，但它仍无法区分“摘要获准项目文件”和“搜索所有可访问的人事档案”。应用权限与请求上下文会排除一部分错误，但“为什么今天由这个代理执行这项任务”仍来自协议之外。

草案也明确说，链验证成功并不自动意味着受保护资源请求获准。资源服务器还要验证 DPoP、请求绑定、受众和应用特定权限。即便最终返回允许，也不证明操作成功，更不证明后续影响停留在原任务边界内。

必须把五个问题分开：谁批准了根委托能力；哪几把密钥传递了权力；哪个任务与影响边界需要这次传递；资源服务器当时看到了哪版政策与撤销状态；最终发生了什么。一个绿色结果不能替所有问题作答。

撤销有写入时间，也有生效时间

撤销根令牌会使所有以它为根的链失效。撤销某个子令牌，会使包含它的链以及其后代无效，但不会自动撤销父级、兄弟级或恰好复用同一密钥的其他令牌。目标必须以精确序列的抗碰撞摘要等方式被无歧义识别。

可是，RFC 7009 风格的成功响应只说明授权服务器记录了状态。离线验证的资源服务器不会自动知道。草案没有定义状态分发机制；短寿命只能把未知窗口封顶，不能证明每个节点何时收到更新。

因此事故复盘需要两个时钟。第一是撤销在授权服务器落库的时间，第二是资源服务器作决定时实际持有的状态版本、年龄与失败策略。事后看到 10:00 的撤销记录，不能倒推出所有验证器在 10:01 已经知晓。

链验证缓存也不能抹掉这个差别。资源服务器可以按完整链摘要缓存签名和有效限制，但必须随到期、授权服务器密钥状态、本地政策和已收到的撤销信息失效。DPoP 新鲜度与重放检测仍需逐请求执行。

隐私没有消失，只是换了观察者

本地委托的一个收益，是授权服务器不必看到每个下游客户端、每次访问、每个资源和完整多跳路径。这能减少中心对工作流的观察。

另一边，接收请求的资源服务器会看到完整有序链。根与中间令牌可能暴露发行者、主体、客户端关系、受众、权限和工作流结构。稳定的 cnf.jkt、根 jti 或其他持久标识还可能跨请求形成关联。

因此审计可见性从中心转移到多方，而不是凭空消失。草案建议记录根签发、本地委托、链验证结果、有效权限和资源决策，同时只用单向链摘要关联事件，日常日志中删去 Authorization 与 DPoP 头，并保护授权详情与主体标识。

健康的审计不是把整条凭证复制到中央仓库，而是让授权服务器、委托客户端和资源服务器能用最小摘要对齐各自观察。

一把密钥承担两种权力

绑定私钥既能证明当前叶令牌的使用权，也能在剩余深度允许时签发子令牌。连续性很清楚，密钥泄露的影响也因此有两层：攻击者既可使用尚未到期的现有权限，也可在有效范围内制造更窄的后代。

草案建议采用不可导出的密钥和受限签名接口，把“签子令牌”与“签 DPoP proof”的输入类型区分开，并尽量每个令牌使用不同密钥。密钥复用会增大关联性与事故半径。

还有一个容易忽略的设计选择：子令牌不包含父令牌标识。只要另一条链的前一令牌绑定同一签名密钥，且有效限制能够覆盖这个子令牌，它就可能在另一条链中有效。若业务要求只绑定一个父链，就要使用不同父级密钥或增加应用限制。

公钥指纹证明的是哪把钥匙签了字，不自动证明当时哪个进程掌管它、签名接口是否只接受正确任务，或组织内部认为它属于哪条工作流。

委托意图回执

我建议另建一份委托意图回执。这是 Daniel Kade 的治理设计，不是草案要求，也不是要塞进 OAuth 的新 claim。

根段保存授权事件和同意界面版本的安全摘要、发行者与受信元数据快照、允许的委托能力、有效 scope 或授权详情、受众、期限和深度。它不保存令牌、私钥、DPoP proof、原始请求头或不必要的主体数据。

每一跳保存完整链摘要、父子公钥指纹、收权前后的有效限制、包含规则及版本、签名服务身份与选择该客户端的最小证据。若复用了密钥，或子级本应只能属于一条父链，也要显式标记。

协议外的关键段落是任务与影响：具体任务、可接受输出和影响边界的摘要；决定负责人；环境、金额或操作类别限制；何种变化必须重新取得人的或授权服务器的批准。这里应只留最小证据，不复制敏感任务内容。

资源决策段记录资源服务器的政策版本、包含关系实现、已收到撤销状态的版本与新鲜度、DPoP 结果、计算出的有效权限以及允许或拒绝。收尾段再记录观察到的操作类别、成功或失败、重大次生影响与回滚或事故引用。

最小可用版本只需五项：根授权、逐跳摘要、任务与影响摘要、撤销新鲜度、最终决策。它不试图从哲学上“证明意图”，而是保存委托链从未承诺携带的操作证据。

应该让验证结果保持准确

修订 03 截至研究时点仍是 2026 年 7 月 24 日更新的个人 Internet-Draft。它不是 OAuth 工作组已采纳文件、IETF 共识、Last Call、IESG 批准或 RFC；文中的 IANA 项目也只是申请。技术细节不能证明任何厂商或运营者已经部署。

在这个边界内，它的贡献很扎实：本地委托有了可验证的密钥谱系；有效权限只能收窄；验证器不能假装理解未知的业务语义；离线撤销的传播缺口也被正面承认。

真正危险的说法是“链有效，所以用户想要这项操作”。更准确的结论是：“一组密钥在给定限制下，有权继续收窄并行使这份授权。”人的目的属于另一份证据。

数据一旦披露、系统一旦改变，后来再完美的签名也无法重建当时没有保存的意图。让权力沿链传递，让意图在链旁留下回执，二者缺一不可。

委托链能收窄权限，却无法承载意图

为何重要

Summary

这条链解决的是权限放大

权限变窄不是 JSON 变短

深度只计算边，不衡量后果

意图位于协议主动留白的地方

撤销有写入时间，也有生效时间

隐私没有消失，只是换了观察者

一把密钥承担两种权力

委托意图回执

应该让验证结果保持准确

来源

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报