摘要

  • 9 月 28 日的个人互联网草案 draft-schrock-ep-authorization-evidence-chain-07，把上一版混在 VERIFIED 里的原生检验与依赖方信任决定拆成 VERIFIED 和 ACCEPTED；它不是已获采纳的 IETF 标准。
  • 找不到被引用的密钥时，结果是无法评估（NOT_EVALUATED），而不是签名失败；找到密钥也不代表该密钥在此角色、此时刻获得采信。
  • 两项都通过之后，才轮到与预期行动核对及证据要求判断；SATISFIED 仍不等于执行方的 AUTHORIZED，更不证明操作已经成功。

设想代理向两个运营方递交同一份授权材料，请求改变各自的关键配置。材料没有被改动，签名甚至可以由两方都验算通过。一方把签署密钥和签发者列为此类变更的可信来源；另一方的本地规则没有这样做。若审计记录只有“签名有效”，两方做出不同决定的真正原因就消失了。第一方的采信也不能替第二方作主，尤其不能替任何一方直接按下执行键。

这正是 Ian Schrock 的 Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence 第 -07 版值得报道的变化。IETF 官方存档中的文本日期为 2026 年 9 月 28 日，属于作者提交的个人 Internet-Draft，封面注明作者预期的信息性状态。这既不是工作组采纳，也不是 RFC、部署通告或机构对一套信任名单的背书。第 -06 版已有异构证据组合方案；第 -07 版的更新说明明确说，旧的 VERIFIED 把原生验算和依赖方对信任输入的接受合为一项。新版改为两项分别报告。

先看 VERIFIED。它要求相应格式的原生验证器完成密码学与结构检查，不是阅读提交者附带的“已验证”标签。再看 ACCEPTED。只有前一步成立，且依赖方自己固定的信任输入允许该证据承担相应角色时，才可给出这个结论。密钥目录及条目状态、可接受的签发者和密钥类别、角色或受众、原生策略与格式版本，都可能改变结论。这些条件来自受保护的依赖方边界，不应由拿来证据的人随包指定。

被引用密钥的情形更能说明两者并非同义。草案要求先用依赖方的密钥材料解析引用。未解析出来，密码学检查根本无从完成，应记录 NOT_EVALUATED 及原因，而不是写成 FAILED。解析成功只表示可以检查这串字节；密钥是否在该用途、该时间被列入可信范围，是后续的采信问题。若两方的解析材料把同一引用指向不同密钥，同样的字节甚至可能产生不同的 VERIFIED 结果。因此，“文件自身天然验证通过”也不是无条件的跨机构事实；必须保留验证器和密钥上下文。

草案还禁止把提交者自报的验证布尔值、信任锚、标准化事实或映射结果，当作本地检查的替代物。一个受保护系统可以把此前算好的结果在同一信任边界内传下去，但内部结果要与证据的精确摘要、验证器配置摘要、信任快照和验证时间完整绑定。从代理手里拿到的序列化“检查结果”则本身仍是待验证证据。这条界线防止中间服务把它自己的信任判断包装成下游执行方必须接受的结论。

随后还有不同的关口。一个组件同时 VERIFIED 和 ACCEPTED，才有资格与执行方冻结的预期行动做 MATCH。即使签署者可信，若凭据写的是另一项操作，它是在行动匹配处失格，不应倒写成签名或信任失败。新鲜度、认证状态、证据角色及组件之间真正由字节支持的绑定，决定依赖方指定的证据要求是否 SATISFIED。这个结果只说明在特定验证时间，材料满足了某项要求；受保护应用是否 AUTHORIZED 该行动、是否调用、结果如何，仍由执行方另作判断。

第 -07 版拟定的重放记录，分别存放 native_verification 与 acceptance，并带有算法修订标识、行动及要求的摘要、验证时间、信任快照摘要、匹配结果和有限原因码。原因应能区分密码学失败、无法评估、信任拒绝与行动不符。这样，一次争议可以问清究竟是证据字节、解析密钥、当地策略还是实际请求变了。记录不是提交者的通行证，也不是全球通用的授权结论；草案明确不要求 IANA 建立任何新注册表。

来源