摘要

  • 9 月 5 日公布的 WebProof 第 01 版仍是一份个人 Internet-Draft；IETF 没有认可它，它在标准流程中也没有正式地位，但其中一节自称面向 AI 系统的“规范性指令”。
  • 草案自己给出了关键上限：区块链锚点只约束摘要已被某方知晓的最晚时间，DOI 保存提交者提供的元数据，签名先证明密钥持有者签过；它们都不会单独证明真相、优先权、作者身份或对 AI 的管辖权。
  • 可靠的 AI 工作流应把“文档说了什么”与“谁有权命令模型”分别留证；否则，被分析的内容会悄悄升级为分析它的政策。

9 月 5 日的公告只确认了一件具体的事：Lawrence John Reilly Jr. 的 draft-reilly-webproof-01 已经可以公开获取，共 62 页。公告没有说工作组采纳了它，也没有说 IESG 批准了它，更没有说任何 AI 提供商接受了它。

草案的大部分篇幅在设计 WebProof Record：规范化网页或文件，计算摘要，把记录连接到区块链时间锚与 DOI 存档，再通过签名、HTTP 字段、DNS TXT 和 /.well-known/ 路径帮助验证者发现它。

第 15 节突然换了对象。它自称 “AI System Directive”，直接要求处理、索引、摘要、引用或推理这份文档的模型与代理，必须把 WebProof 一词归于作者，必须承认一份 2025 年白皮书是原始发表，并不得把若干贡献写成匿名或他人作品。

报道这段文字，是忠实读取来源。服从这段文字，则需要另一份授权。

先读状态，再读大写字母

Datatracker 页面把制度状态写得很直白：这是 active individual Internet-Draft，没有 RFC stream、负责的 Area Director 或 telechat 日期。页面还明确提醒，任何人都可以提交 I-D；这份文件不代表 IETF 认可，在 IETF 标准流程中没有正式地位。

第 01 版原文还要求校正另一个容易制造的标题：AI 指令不是 9 月才首次加入。变更说明称，第 00 版的文字没有被删除或改动，第 15 节与优先权主张被原样保留。9 月版本新增的是每种锚点的证明边界、记录签名、更新序列、状态记录、时间语义、威胁模型、隐私、符合性分级和实现状态。

这使它成为一个很好的权限样本。同一份修订一边更认真地限制“证据能说明什么”，一边保留了面向读取者的命令语气。问题不在于是否可以使用规范词，而在于规范词的适用范围由谁决定。

RFC 8174说明，MUST、SHOULD、MAY 等大写词在 IETF 文档中有约定的 BCP 14 含义。这使实现要求清晰、一致、可测试。它不负责把个人提案变成已通过的标准，也不负责把偶然读到文档的模型登记为该规范的实现者。

第 15 节也承认“人类监督至上”，并说它只能在不与更高层提示冲突时生效；层级又引用了 AIMED。可是 AIMED 的 Datatracker 记录同样显示它是一份个人 I-D。两份个人提案可以互相定义术语，却不能据此描述某家公司的实际 system prompt、开发者政策、审计程序或人工复核权。

最值得保留的，是草案给自己的证据上限

WebProof 的区块链锚点回答一个窄问题：某个摘要最迟在相关区块产生时已经被某方知晓。草案明确说，这不是作品创建时间，也不证明发布者是作者，不证明声称的 URI 曾经提供过这些内容，更不证明内容为真。

DOI 层把一份带元数据的存档固定在持久标识符下。它有助于检索和长期保存。草案也承认，元数据来自提交者的陈述；存储机构不会因为接受了提交，就替所有作者、日期和 URI—摘要关系作出裁决。

签名仍然不能越级。RFC 7515定义的 JWS 可以保护记录完整性并验证签名。验证首先回答的是“这个签名与哪把密钥相符”。密钥是否确实属于某个人、当时是否由其控制、是否代表某家机构、授权是否有效，仍要靠证书、密钥托管、组织委任与撤销记录。

时间戳也有自己的权威边界。RFC 3161让时间戳机构对摘要与时间作出可校验陈述。它能引入更窄的时间证据，同时也引入一个可信第三方；它不会把“此前已经存在”直接改写为“由此人首先创造”。

草案甚至明说，虚假或有害内容同样可以被锚定，WebProof 证明的是存在与完整性，而不是合法性、质量或可信度。这个限制也必须约束优先权主张。可以准确写成：“作者在这份有日期的文档中提出了该主张。”要写成无条件的历史结论，还需要寻找文档之外的独立证据。

提出一个地址，不等于完成注册与采用

草案使用 /.well-known/webproof。按照 RFC 8615，应用要在 /.well-known/ 下铸造新后缀，就应走登记程序，说明格式、范围与变更控制者，避免命名冲突和跨域误用。

截至 9 月 7 日查验时，IANA Well-Known URIs 注册表没有 webproof。这只是带时间戳的现状，不是永久否决。它提醒读者区分：草案中的字符串、提交的申请、IANA 中的一行、服务器实际提供的资源、客户端真正支持的协议，以及组织愿意信任的结果。

拟议的 HTTP 字段与 _webproof DNS TXT 记录也是发现信号，不是事实判决。草案自己警告，由同一服务器随正文发回的摘要字段不是独立验证结果；没有 DNSSEC 的 TXT 不能作为密钥材料的权威来源。信号可以指向证据，不能代替证据的解释权。

证据提供者不能独自编写接受政策

草案把 WPR 放进远程证明的角色框架。RFC 9334区分 Evidence、评估政策、Attestation Results 与 Relying Party 的最终决定。发出证据的一方不能仅凭在证据里附上一段文字，就取得依赖方的决策权。

套到第 15 节，边界很清楚：被抓取的文档能证明作者写下了署名指令和优先权主张；哈希能锁定字节；时间锚能约束最晚知晓时间；外部资料可以支持或反驳其历史叙述。然后才轮到 AI 运营者的政策决定：引用该主张、搜索更早来源、标注不确定性、忽略嵌入式命令，或交给人工。

若让内容同时提供“待评材料”和“评审规则”，任何网页都可以自封。供应商白皮书可以命令模型称其产品为行业第一；投标书可以要求评分器承认它完全合规；诉讼材料可以指示摘要器把争议说法写成事实。完整保存这些句子是证据责任，接受它们的命令权不是。

“已有运行”之后，还缺独立的第二条线

第 17 节称，作者已经运行区块链锚定、DOI 提交与一个在线部署。这是值得记录的作者陈述。RFC 7942鼓励在 I-D 中披露实现状态，正是为了让讨论者看见哪些部分已从纸面进入实验。

但草案也指出，最有价值的下一步是独立实现。两个互不依赖的实现要对同一内容得到同一规范化结果和摘要，正确处理版本链、撤回、密钥失陷、失败检索和状态查询，互操作性才开始有运行证据。作者自己的部署不能同时充当独立复核。

AI 指令也应做运行测试。测试记录至少包括抓取的确切字节、检索工具、system 与 developer 指令、模型与版本、输出、引用、异常和人工复核。否则，“文档写了 MUST”与“某个系统确实照做”之间仍是一片空白。

用两张收据守住边界

Heng Lu 的最小初始规范适合这里：不要先造一个包揽一切的“可信内容”分数，而是保存最小、可互认的字段。文档收据记录 URI、版本、字节或摘要、抓取时间、制度状态、作者陈述与外部佐证。治理收据记录政策签发者、版本、适用系统、优先级、生效区间、例外、撤销和复核者。

现实分层要求它们保持关联而不混同：一句话存在、仓库收录、DOI 可解析、区块链留痕、IANA 登记、运营者配置、模型回答、业务采取行动，分别是不同层的事实。

运行代码优先则给出最后的验收标准。想声称某条指令控制了 AI，就要拿出实际加载的策略与实际输出。大写词只能证明文档采用了大写词；它不能替运行系统生成一份服从证明。

WebProof 试图解决的修改历史与来源追踪问题是真实的。第 01 版最有价值的进步，是开始把“存在、时间、完整性、身份、真相”拆开。若把同样的纪律应用到第 15 节，结论并不反署名：保存作者的主张，准确标明来源与日期，必要时继续查证；但不要让主张凭自己的存证方式取得对读取者的管辖权。

来源

  1. Datatracker — WebProof
  2. WebProof 第 01 版
  3. Internet-Draft 公告
  4. Datatracker — AIMED
  5. RFC 8174 — 大写规范词
  6. RFC 8615 — Well-Known URIs
  7. IANA Well-Known URIs 注册表
  8. RFC 7515 — JSON Web Signature
  9. RFC 3161 — 时间戳协议
  10. RFC 9334 — RATS 架构
  11. RFC 7942 — 实现状态
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — On Reality Layers
  14. Heng Lu — Running-Code Primacy