Summary

  • 11 月 1 日的个人互联网草案修订版要求，依赖方在授权时重新核对代理实例的工作负载身份令牌是否到期。
  • 随后签发的访问令牌也不能活得比该身份令牌更久；一张仍有效的委托书，不能让过期的执行者继续办事。

设想一笔跨机构付款：代理带来委托，收款一侧核对了授权链，却还在等共同签署。共同签署终于到了，委托书依然有效，代理实例的身份令牌却刚好过期。真正改变决定的不是委托人的意愿，而是门口那个执行者此刻还有没有可用的身份。

Cristian Hulea 的 -01 版草案把这个问题放在第 10.2 节。依赖方在完成义务并签发访问令牌的同一操作中，从自己的时钟取得授权时刻 A；它必须重新检查委托链、支持授权的声明、所选时间窗口，以及工作负载身份令牌的到期时间。不满足条件就拒绝。签发的访问令牌还要受这些期限中最早一个约束，且只能执行一次，资源服务器须拒绝第二次使用。

对照此前的 -00 版，二次检查本来就存在，但名单上没有工作负载身份令牌。旧版给访问令牌设寿命上限时也漏了它。新版的修订记录明确指出这两处新增。这里报道的是草案文字的变化，草案并未报告某家银行发生此类事故。

三种凭证分工清楚。委托说明被允许做什么；授权声明说明委托人有没有资格授予这项权限；工作负载身份令牌则由运营方签发，指明它正在运行哪个代理实例和密钥。草案还写明，这个令牌不保证模型、配置或行为。把“委托有效”画成一个总绿灯，会遮住执行者身份的独立时钟。

草案把验证时刻 T 与授权时刻 A 分开。T 时刻的结论保留为当时核验的记录；如果必须依靠的状态证据在等待中变旧，依赖方要取得新证据并重新验证，或者按策略处理不确定结果。新增的身份期限检查处理另一种等待成本：即便委托和状态都没有问题，已经过期的实例也不能凭旧验证结果冲关。

决定权最终落在依赖方：要么让运营方更新身份，并赶在放行前完成核验；要么拒绝这次动作。IETF 资料页目前记录的是一份个人草案。它提出了明确的闸门，尚无这道闸门在生产系统中运行的结果。