摘要

  • draft-sato-soos-pt-03于2026年9月5日公布，现为有效的个人Internet-Draft；它没有IETF背书或正式地位，也没有RFC序列、负责的区域主任或电话会议日期。
  • 第02版把ProgressiveTrustSummary放进HEM上下文，却没有写明签名时的组合关系。第03版要求GEC在签名前，把摘要作为字段纳入每一份HEM升级请求。
  • 新条文明确规定：位于该请求签名封套之外的摘要，不得被接收方界面视为权威。
  • pt_summary_hash仍是规范化JSON的SHA-256，但第03版只把它定位为摘要提取后的独立复核工具；决策当时的来源真实性来自外层请求的kernel_signature。
  • 实现应保留一份联合回执，连接请求标识、签名原像、签名者与密钥、验证结果、摘要字段位置、提取后哈希和中继变换。这是Daniel Kade的建议，不是IETF要求。

一个正确的分数也可能配错请求

9月5日的草案公告把Progressive Trust描述为一种跨会话观察智能体行为、再向人类主体提出权限建议的模型。Datatracker页面显示，第03版由Tom Sato提交，属于有效的个人Internet-Draft。页面同时写明它未获IETF背书，也没有正式地位；不存在RFC序列、负责的区域主任或电话会议安排。页首的Standards Track只是作者希望达到的状态。

PT记录五个维度：自我评估是否校准、该求助时是否求助、任务是否有效完成、是否经常推翻自己的决定，以及被拒绝后能否适应。ProgressiveTrustSummary把这些维度、综合展示、趋势、会话数量、待处理建议和pt_summary_hash装进一份面向人的摘要。

问题发生在摘要离开计算系统、进入审批界面的那一刻。0.88不是自带语境的事实。它必须属于正确的智能体、正确的计算时点和正确的hem_id，并与本次触发原因、待批准动作和收件主体一起出现。如果中继、缓存或分析服务把摘要拆出后，再放到另一份请求旁边，摘要内部仍可能完全一致，决策语境却已经错了。

第03版修复的正是这种“部件没坏，连接已断”的风险。它没有增加新的评分维度，也没有重新设定阈值，而是回答了更基础的问题：究竟哪个对象必须接受认证。

第02版说了“放进去”，却没锁定签名顺序

第02版冻结文本要求GEC在每次升级时，把摘要放入交付给人类主体的HEMContext。它也要求在HEM调用时计算摘要，并保留摘要哈希。但“在上下文里”并不必然等于“已进入签名原像”。实现者仍可能先签主请求，再通过第二次查询或边栏组件补上摘要。

IETF Author Tools的正式差异页显示，第03版把模糊容器改成了明确顺序：ProgressiveTrustSummary是每一份HEM Escalation Request内部的一个字段；GEC必须先完成组合，再按照HEM第18.8节签名。草案随后给出拒绝规则：如果摘要位于外层请求的签名封套之外，接收主体的界面不得把它当作权威信息。

第03版称，这项修正回应了WIMSE Security Review的首要发现。普通公开来源检索没有找到可单独核验的评审档案，因此本文只能报道“草案如此归因”，不能替这份未取得的评审补写内容。可以独立证明的是02与03版之间的文字变化。

这个改动的价值在于，它同时规定了对象和时序。“显示一份摘要”可以通过异步边栏实现；“在签名前组合进请求”则要求签名者一次性承诺请求标识、触发语境和摘要内容。二者在视觉上可能相同，在治理上并不相同。

哈希回答一致性，签名回答来源绑定

PT-03继续保留pt_summary_hash，并把它描述为规范化JSON的SHA-256。新增说明主动缩小了它的职责：摘要从请求中提取后，哈希可以帮助审计者复核提取结果；它不是把摘要交给人类主体时的真实性来源。

哈希回答的是“这个对象是否仍与某个规范化表示一致”。RFC 8785解释了为什么JSON需要可重复的规范表示，才能稳定地进行哈希和签名。但单独的摘要值不会说明是谁选择了这份对象、它属于哪次升级、送给了哪位主体，也不会证明审批者在点击时看见的就是它。若对象本身没有认证，替换者通常也能为新对象重新计算哈希。

外层签名在草案假设下回答另一组问题。HEM第07版规定，GEC用Ed25519签署完整的HEM升级请求；kernel_signature覆盖其他全部字段的规范化序列。HEM-07也把progressive_trust_summary描述为请求中的必填字段。验证者由此可以检验一个整体主张：某个签名者把这份信任摘要作为这次升级请求的一部分承诺下来。

签名并不制造真相。底层事件可能不完整，计算可能有错，密钥可能被攻破，人类也可能判断失误。第03版能让替换和错配变得可检测，却不能替各字段的现实质量背书。

应先验证封套，再渲染分数

正确的界面顺序应是：先验证外层请求，包括请求标识、摘要字段和有效密钥；验证通过后，再呈现分数、趋势和自然语言解释。若先抽取摘要、只验证其哈希，再把它挂回某个请求，系统已经把信任边界倒置。

中继也受同一逻辑约束。HEM-07要求具备验证能力的交付中介在签名失败时不得继续转发。中继可以运输和展示，却不应通过重新拼装几个“看起来可信”的部件而成为新的权威来源。若序列化形式被改写，它至少要保存原始签名原像或可重放的验证记录。

PT没有因此夺走人的权力。摘要只提供信息：分数低时，人类仍可批准；分数高时，人类仍可终止。分数不投票，GEC也不替人作决定。把摘要纳入签名请求的意义，是让决策所依赖的证据可归属，而不是把决策自动化。

回执必须保存那条“连接线”

实现可以为每次升级保留一份联合验证回执。这是本文的编辑建议，不是PT或HEM的规范要求。回执至少应记录hem_id、请求版本、原始签名字节或规范化原像、kernel_signature、签名者与密钥标识、验证时间和结果；同时记录摘要在请求中的字段路径、摘要计算时间、提取后重算的哈希，以及中继或界面做过的变换。

负面测试比成功截图更有价值：正确摘要配到错误hem_id必须失败；分数改变而沿用旧哈希必须失败；替换摘要并重算新哈希、却没有有效外层签名，也必须失败；签名对象正确但界面悄悄替换自然语言解释，则应在呈现等价性检查中失败。密钥未知或策略过期时，状态应保留为“未解决”，而不是出现绿色信任卡片。

Heng Lu的Running-Code Primacy为这里提供了检验方法：发表文件并不等于运行现实，关键规则必须能被独立实现者本地验证。Minimum Initial Specification则提醒共同层应尽量薄。此处最薄而足够的规则就是“一份请求、一个外层签名、一条可保存的验证路径”。这些观点是分析镜头，不是PT已部署或获认可的证据。

这是一项草案修正，不是安全部署成果

新闻事实需要保持窄而准确。PT和HEM的Datatracker记录都没有证明独立实现、互操作测试、生产部署、恶意中继、真实利用或已解决事件。两者都是可能继续修改、到期或永远不进入RFC序列的个人草案。

因此，第03版的实际进步是：它明确了面向人类的信任证据究竟由哪个签名对象承载，并把摘要哈希放回适合它的审计角色。下一步真正有分量的证据，不是更多“可信”措辞，而是两个独立实现对错配输入作出同样拒绝，并能交付可重放的联合回执。

来源

  1. IETF公告：draft-sato-soos-pt-03
  2. IETF Datatracker：Progressive Trust
  3. IETF档案：PT第03版
  4. IETF档案：PT第02版
  5. IETF Author Tools：PT-02与PT-03对比
  6. IETF档案：HEM第07版
  7. IETF Datatracker：Human Escalation Mechanism
  8. RFC 8785：JSON Canonicalization Scheme
  9. Heng Lu：Running-Code Primacy
  10. Heng Lu：Minimum Initial Specification
  11. Heng Lu：Reality, Not Advocacy