摘要

  • draft-wei-aic-jwt-01 于 2026 年 9 月 8 日发布，目前只是活跃的个人 Internet-Draft。它没有获得 IETF 工作组采纳或标准批准，也不能证明已有部署；Experimental 只是作者写下的预期状态。
  • 完整模式把委托人签署的 DelegationAuthorization JWT 放进签发者签署的 AIC-JWT。内层签名保护授权内容与 agent_id，外层签名覆盖原样保留的 DA 和 cnf 字段。
  • 修订版明确说，当前 DA 把授权绑定到代理身份；由 DA 直接绑定代理公钥，要等未来的声明集版本。现阶段，代理用于持有证明的密钥由外层 cnf 表示，并在凭证使用时执行。
  • 审计记录不应只留下“双签名通过”，而应保存每位签名者究竟证明了哪条连接。本文提出代理密钥绑定回执；它是 Daniel Kade 的治理建议，不是草案要求。

新修订不是机构背书

I-D 公告把 01 版的发布时间记为 9 月 8 日 14:48 UTC。Datatracker 将它归入 Individual Submissions，状态为 I-D Exists，没有 RFC 文档流、负责的 Area Director 或 telechat 日期。任何人都可以提交 Internet-Draft。页眉中的“Intended status: Experimental”表达作者希望走向哪里，不表示 IETF 已决定采纳、批准或建议上线。

这项限制很重要，因为草案描绘的体系相当完整。AIC-JWT 不是自称创造一套新授权模型，而是把另一个 X.509 AIC 草案的数据模型投射到应用层。HTTP、Web 与 OAuth 环境可以用 JWT/JWS 承载它，但能力语义、授权边界与本地执行策略仍来自外部模型与部署规则。

01 版也不只是换了措辞。它把内层 DA 的声明集版本从 1 升到 2，加入 RFC 7523 所需字段，要求新实现遇到旧版 DA 时关闭失败，不能悄悄降级。更有治理价值的变化，是把“代理是谁”和“代理拿哪把密钥证明持有”拆成两个可以追责的密码学命题。

内层签名锁定的是授权文本

按 PKI 流程，代理先生成密钥对，再构造带有所需能力、委托模式、约束与随机数的签发请求。委托人审阅请求、签署 DA JWT，再交回代理；代理把它提交给 CA。在 OAuth 授权服务器模式中，代理则把这份 DA 当作 RFC 7523 JWT bearer grant 送到令牌端点。

DA 并非一句宽泛的同意。它含有 iss、sub、aud、exp、jti，以及 agent_id、委托人绑定、理由、能力、委托模式、约束、请求寿命、签署时间与 nonce。验证 DA 的公钥必须与委托人绑定相符，jti 必须等于 nonce。内外层分别使用 aic+da+jwt 与 aic+jwt，避免把委托书当成最终凭证。

外层的 da 保存收到的紧凑序列化字符串。验证者不得先重建或重新序列化再验内层签名。签发者若改动能力、受众、模式或 agent_id，委托人签名就会失效；反过来，只有委托人私钥也造不出有效外层令牌，因为外层还需要签发者签名。

因此，内层验签成功能支持一项很强但有限的结论：这位委托人签署了这份授权，并把它交给这里写明的代理身份。它还不能证明委托人签名的字节中包含稍后用于出示凭证的具体公钥指纹。

cnf 把密钥放到另一层责任里

代理密钥出现在外层必填的 cnf 声明。RFC 7800 定义了这种 confirmation claim，草案建议使用 RFC 7638 的 JWK 指纹 jkt。部署若使用 DPoP，cnf.jkt 必须与 DPoP 证明密钥的指纹一致；使用 mTLS 时，还可以把客户端证书公钥与 cnf 交叉核对。

01 版在 PKI 和 OAuth 两条签发路径里重复说明：由 DA 本身绑定代理密钥，是留给未来声明集版本的工作；当前版本由 cnf 在使用时绑定出示密钥。cnf 位于外层载荷中，所以覆盖这项绑定的是签发者签名，同时外层也覆盖未被改动的整个 DA。

这不等于签发者可以随意选一把钥匙。流程明说代理生成密钥，委托人审阅请求；签发者必须核验 DA 签名、委托人密钥绑定、受众、有效期、nonce 唯一性与适用的能力限制，也不能让外层令牌活得比委托人签署的授权更久。这里讨论的不是漏洞，而是事后证据的归属。

假如一次批准界面确实把密钥指纹展示给委托人，组织可以另外保存这次确认。但不能因为 DA 签名有效，就倒推出该指纹必定在内层签名覆盖范围里。现有字节只能证明 agent_id；外层签名才证明签发者签过哪一个 cnf。

cnf 存在也不等于持有证明已执行。草案的安全章节直说，AIC-JWT 并非天然 sender-constrained。若验证者没有真正检查 DPoP 或等价机制，被窃取的令牌仍可能在过期前按 bearer token 使用。声明指出应当持有哪把钥匙；成功的出示验证才证明本次请求真的使用了它。

用一张回执保留四次决定

我建议为高后果场景保留代理密钥绑定回执：DA 的准确哈希与版本、委托人密钥标识、agent_id、签发者、外层令牌哈希、cnf 方法与公钥指纹、签发策略及版本、nonce 消耗结果、内外层有效期交集、持有证明方法、验证决定与撤销或纠错引用。若委托人曾看到并确认密钥，回执应把它列作独立事件，不能把它冒充成 DA 的固有属性。

回执还要分开两只防重放时钟。当前设计要求一个 DA 只生成一个外层令牌：首次签发时消耗 nonce，外层 jti 与之相同。但已经签发的访问令牌可以在有效期内多次出示。逐请求防重放由 DPoP proof 的 jti 或同类机制承担。只记录“nonce 已使用”无法证明每次请求没有重放。

公钥指纹和委托关系可能构成长期关联标识，因此回执不必向所有人公开原值。它可以按权限披露承诺值、策略结论或审计引用。最小化不应变成失忆：保护身份图谱与保存责任链可以同时做到。

Heng Lu 的“政策镜像”要求观察谁拥有选择、谁承担后果。委托人选择代理身份与能力；签发者接受 DA 并签署当前密钥绑定；验证者决定是否执行持有证明与本地策略；资源所有者承担动作结果。双签名的价值，恰恰在于这四步不被压扁成一个绿色图标。

来源