Summary

  • 11 月 1 日的 -02 版撤回了“接收方评估链上每个代理”的旧要求，改为只依据令牌顶层声明和当前代理作准入判断。
  • 被停用的上游代理仍会留在记录里；草案明说，接收方无法仅凭这个历史身份挡下后续请求。

接力跑到最后一棒，守门人看见前一棒已经失去资格，却仍须按最后一棒的证件决定是否开门。这个有些刺眼的场景，正是 《代理执行证据》草案 -02 版 新写清的边界。它记录代理之间的交接，却不把整条历史链变成准入名单。

旧版 -01曾要求服务方评估每个代理。新版删去这句，要求服务方按交易主体和当前代理执行自身政策；嵌套 act 声明中的早期代理只进入 actor_chain，不得用于准入决定。作者解释说，发布的 -01 来自较早的代码提交，漏掉了原本打算加入的修订。新版与 RFC 8693 第 4.1 节一致：令牌顶层声明和当前代理决定访问控制，历史代理提供线索。

线索并非摆设。草案拟在发起方与接收方各自留下收据，再把跨服务调用连起来。事后验证可以指出：上游代理被停用之后，工作是否仍向下游流动、每一跳是谁放行、当时记录了什么 admission_basis。但事后查明与当场拦截相隔一道门；草案明确写出，接收方不能因为历史代理后来停用而拒绝调用。

这条链还不是权力传递的完整证明。接收时看到的历史由令牌签发者主张；已取得的收据相互一致，也不保证没有缺失一跳，更不能证明每次交接都收窄了权限。草案要求当前调用代理的保证声明与注册状态符合接收方的新鲜度政策；受限的当前代理只能执行获准类别。历史代理的停用状态没有同等入口。

第 14 节把“依据完整历史准入”列为待讨论问题，要求另定历史完整性、信任及其与 RFC 8693 冲突的规则。IETF 文档记录显示这仍是 11 月 1 日更新的个人草案。要改变眼下的判断，需要看到一条已写明并实际部署的上游状态准入规则。