摘要

  • Steven Mih 于 9 月 26 日提交的首版《请求可核验证据的交互模型》是拟作信息性文件的个人 Internet-Draft，不代表 IETF 采纳，也不是已运行系统的说明。
  • 草案把“对谁作答”与“答复内容是什么”拆开。请求对象、最终确定的覆盖锚点及派生方式都相同时，交付的证据工件必须字节相同；请求者自己持有的 expected_pin 比由答复方选择锚点的 min_freshness 更利于交叉核验。
  • 合规答复不只有交付工件：还可能是签名拒绝，或等待期过后由请求者记录的无答复。后者不是答复方承认拒绝，更不能单凭沉默推断动机。

先保存检查点，再去索要记录，顺序很重要。设想两家机构分别调查同一代理行动，手中握着同一个事先保存的检查点，却收到内容不同的历史工件。即使每份工件都能各自验签，差异仍是一个明确的问题：保管者是否按受众改写了同一道题的答案？这是说明规则的假设场景，并非现实事件。Steven Mih 新草案最有价值的地方，正是把这类比较写成可检验的答复条件。

IETF Datatracker 将 draft-mih-agent-evidence-request-00 列为“Individual”和“I-D Exists”，日期为 2026 年 9 月 26 日。个人互联网草案的公开并不等于工作组采纳、共识或标准生效。它提出的是如何发问、如何表述结果，不定义证据工件本身的格式，也不授予任何人索取档案的权利。

请求先标明对象：整段历史、检查点、一条记录、范围、关联项或一次往来。随后必须在两种覆盖方式中二选一。expected_pin 是请求方已经独立掌握的检查点；min_freshness 给出最低新鲜度，由答复方选出合格锚点。两者都不给或同时给，草案都视为请求有误。差别并非纯技术细节：若两名调查者只要求“够新”，答复方可能为他们各选一处不同锚点。这样一来，工件不相同尚不足以直接认定违反“同一锚点同一答案”的规则。

草案把不随调用者变化的条件限定得很清楚：对象、解析后的覆盖锚点、若有则包括派生请求，都一致时，证据工件的字节不应随请求者身份或传输通道而改变。访问政策仍可决定向谁作答；这条规则并不要求把敏感历史交给所有人。它限制的是已经决定作答后，按对象提供不同版本的权力。

但统一工件不等于统一历史。草案要求同一流的已提供锚点能归入互相一致、只追加的历史。如果答复方给不同群体展示两个分叉锚点，只检查某一锚点下的字节相同无法发现全貌。调查者还需比对独立保存的锚点、查验锚点间的一致性证明，必要时借助外部见证。即便这些检查通过，也不能证明每个现实行动都曾进入日志；遗漏事件同样可能留下一个内部自洽的记录。

三类最终结果还决定了责任如何归属。签名拒绝把请求字节的摘要、签发时间、机器可读的原因和答复方签名捆在一起；原因可指授权不足、覆盖无法满足或政策拒绝。为避免透露某个对象是否存在，答复方还可以使用较宽泛的政策理由。相反，等待期届满仍无终局答复时，记下“无答复”的是请求方，并非答复方签发了一份拒绝。只有额外的、仍在有效期内的签名留存承诺，才可能让后续缺席具有更强的可归责性；承诺本身也不保证网络可达。

草案还提醒，隐藏记录正文的 history_card/1 仍可能暴露检查点频率和规模，低熵内容的摘要也未必保密。这些是设计边界，不是对某家运营方的事故指控。审计应分别保存问题、独立锚点、确实收到的工件、签名拒绝和等待后的缺席；将它们压成一个“已验证”绿灯，会抹掉真正需要治理的差异。

来源