摘要

  • 9月27日提交的 Capability Language Core 个人草案，在“允许”“拒绝”之外提出 allow_unresolved：格式正确、但尚无评估者的时间或网络限制不能自动消失。
  • 草案要求消费这一结果的执行端逐项确认限制，确认不了就拒绝；作者自己报告的三种语言实现尚不等于独立互操作验证。

一条自动化指令可能同时满足“有权查询”与“只能在指定网络内查询”两层条件。通用授权程序读得懂第二层的写法，却不一定知道请求发起时设备究竟连在哪个网络。若把“读懂了，但没查到”简化成“已允许”，权限表面没有变化，实际边界却已被悄悄放宽。Jijie Wei 新提交的 Capability Language Core（CLC）草案，把这种悬而未决的状态做成第三种机器可读结论。

这份 draft-wei-capability-language-core-00 日期为2026年9月27日，作者以个人身份提交，预期状态为 Experimental。IETF Datatracker 显示 I-D Exists，并特别注明个人草案没有正式标准化地位。它不是 RFC，也不能由此推出工作组采纳、商业部署或真实安全事件。草案拟统一的是能力名称、授权集合是否覆盖具体操作、多来源授权如何取交集，以及评估器该如何给出确定的理由与结果。

第8.4节划出了本文最重要的边界。核心程序能够识别的时间窗口、网络范围，如果当前版本并不负责实地评估，其内容就必须留在 unresolved 清单里，结果是 allow_unresolved，而不是 allow。后者是可放行的明确信号，前者不是附了一句警告的放行票。草案写明：消费决策的政策执行点或规则所属组件须在允许之前确认每一项残余条件；做不到，就应拒绝。多个未决条件是“且”的关系，不是任选一项通过即可。

第8.5节又给出 Resolve：外部组件对每个条件报告“满足”“违反”或“未知”，核心据此重算决策。这解决了结果怎样反馈的问题，却没有凭空提供可信的网络观测、部署现场的时钟或谁有资格解释规则。若一个现有接口只有真假两个出口，把所有不等于 deny 的值都转成执行许可，第三种结论仍会在接口处丢失。这是对设计失配的分析，不是在报告某个系统已经有漏洞。

CLC 对自身范围也有限定。它不规定谁签发可信授权、不承担原生签名验证、不定义动作执行后的结算，也不提供通用收据或令牌格式。现行 RFC 9396 已为 OAuth 定义 authorization_details，CLC 草案仅把它列为可映射的载体之一；RFC 9396 本身没有把 CLC 纳入标准。表达权限的语言与验证权限来源的制度、执行操作的程序，不应因为能接在同一条链上就被当成同一件事。

草案称，CLC-A 授权部分有123个测试向量及1184个性质案例，Go、Python、TypeScript 三个实现均通过。但三者出自同一作者，文档也明确指出这只是对文本的一致性回归测试，尚未达到“两套独立实现”成熟门槛。它主张 CLC-A 基线，不主张证据侧的 CLC-E 已达到同等状态。可复现的作者测试是进展，不是外部互操作性证明。

资料