摘要

  • AIC-JWT 第 02 版要求委托人签署内层 Delegation Authorization；当前 ver=3 还把智能体公钥的 SPKI 哈希写进 agent_key_binding，发行方则对携带这段精确紧凑序列的外层凭证签名。
  • 验证方必须把外层 cnf 指定的持钥证明密钥与委托人签过的绑定相互核对；发行方的有效签名不能替换密钥，续发也必须取得一份带新 nonce 的委托人新签 DA。

凭证看起来没有破绽。发行方在信任名单中，外层签名正确，期限尚未届满，cnf 也指向智能体正在证明持有的公钥。验证方却拒绝了请求：内层授权里，委托人签过的是另一把钥匙。

这正是 AI Agent Identity Certificate (AIC) JSON Web Token Profile 第 02 版最值得保留的控制面。该稿于 2026 年 10 月 2 日发布，是一份仍在演进的个人 Internet-Draft，2027 年 4 月 5 日到期；存档文本把预期状态写为 Informational。它不是 RFC，不代表 IETF 共识或认可，也不能证明已有生产部署。本文只使用它来分析一个更窄的问题：在机器委托链上，谁有资格陈述哪一项事实。

两个签名不是同一种权力

流程从 Delegation Authorization（DA）开始。委托人创建并签署一枚紧凑序列化的 JWT。智能体或发行服务把这整段字符串原样放进外层 AIC-JWT 的 da 声明，随后由发行方签署外层。因此，内层 JOSE 头、载荷或签名只要有一处变化，外层载荷也随之改变，发行方签名就会失效。

“内容相同”并不足够。验证方必须针对收到的精确紧凑字符串验证内层签名，不得把 JSON 解析后重新排序、重新编码，再凭语义相似认定它是原件。只保存解析对象，会丢掉委托人究竟签了哪些字节这一关键证据。审计需要保存原始 DA 及其摘要，而不是事后重建的等价表示。

外层签名回答：这家发行方是否为这只封套及其中的声明背书。内层签名回答：这位委托人是否写下了这项授权。两种权力不能互相吞并。受信发行方能生成新封套，并不意味着它可以改写委托人的授权；一份签名正确的 DA，也不能自动使任意外层发行方进入被接受的信任域。

令牌类型同样必须隔离。内层 DA 不是一枚可独立使用的 AIC-JWT 或访问令牌。明确的 typ 防止原本为授权申请而签的对象，被拿去冒充授权结果。它看似只是头字段检查，实际守住了“请求权力”和“已经获得权力”之间的边界。

委托人批准的是哪把钥匙

第 02 版把 ver=3 定为当前 DA 版本，并要求 agent_key_binding。这个字段是对智能体公钥 DER SubjectPublicKeyInfo 按指定算法计算的哈希，位于 DA 内，因此由委托人的签名覆盖。外层 AIC-JWT 另行要求 cnf，把所发行的令牌绑定到一把用于持钥证明的密钥。

完整验证不是分别看两边格式正确，而是比较两边是否指向同一把钥匙。cnf 指定的密钥必须匹配委托人签过的 agent_key_binding。发行方若替换了智能体密钥、误绑了另一台设备，或把中介自己的密钥带进封套，外层签名仍可能完全有效。真正揭示问题的是二者不一致：封套中的密钥不是委托人同意的密钥。

ver=2 是遗留模式，只绑定 agent_id，不绑定智能体公钥，因此草案只允许在落实指定替换攻击缓解措施时接受。ver=1 必须拒绝，新签 DA 应使用版本 3。运营界面不能把三种状态都归为“兼容”。这里的版本号描述的是授权证据的强弱和位置，而不只是解析器走哪条分支。

这也解释了为什么 kid、x5c 和 x5t 不能自己创造信任。kid 只是在已经受信且作用域正确的密钥集中选择候选；证书链或指纹出现在头部，也不等于路径和策略已经通过验证。外层发行方密钥与内层 DA 签名密钥都要按已配置策略建立信任，并锚定在同一个被接受的信任域。方便的头字段没有资格把未知根提升为权威。

续期是一场新的同意

时间边界仍由委托人控制。外层 exp - iat 不能超过 DA 请求的期限，外层到期时间也不能晚于 DA 到期时间。发行方可以缩短窗口，不能加长委托人签过的授权。

DA 的 nonce 同时充当它的 jti，首次发行时即被消费。同一份 DA 与 nonce 不能支撑第二枚外层令牌。续期或重新发行必须让委托人签署一份带新 nonce 的新 DA。这把“续期”从发行方的计时器操作，恢复为一次新的同意事件。

系统中其实存在两种重放时钟。DA nonce 防止一份授权被用于多次铸造凭证；而访问令牌发行后，在有效期内重复呈现可能完全正常。逐请求的重放防护属于证明层，例如 DPoP proof 自己的 jti，不属于已经消费过的 DA nonce。前一本账问“是否又铸造了一枚凭证”，后一本账问“这次请求证明是否被重复使用”。

所以日志要分别保留精确 DA 的摘要、nonce 消费事务、发行出的令牌标识和逐请求证明标识。否则，合法的令牌复用会被误报成重复发行，真正的第二次发行反而可能淹没在普通 API 调用之中。

一致性先于许可判断

完整配置文件还会跨层比较委托人、能力、委托模式、约束，以及不同模式下的主体或行动者位置。任何冲突都应拒绝。系统不能把不合规的能力集合静默裁剪成一个方便的子集，再声称那就是委托人签过的内容；若请求与发行范围不满足配置文件的子集规则，凭证本身就无效。

只有这些完整性检查完成后，本地策略才获得一个值得判断的对象。有效权限受委托人授权、智能体能力与 AIC 约束共同限制，网关策略还会进一步收紧。密码学验证成功，不代表今天这笔采购、路由变更或数据传输是合适的；它不证明执行已经发生，更不证明银行、网络或交付系统抵达了预期外部状态。

可选的轻量消费者配置文件主动缩短了证据链：在获准的低风险模式中，它可以省略 DA，因此没有完整配置文件提供的委托人密码学授权证明。这可以是明确的风险选择，却不能被标成等价保证。