摘要

  • 10 月 28 日的个人草案提出“结论记录”：发行者写明主张、结果、规则，并用 SHA-256 摘要指向依据。检查者必须持有证据原件，使用自己的政策和信任锚。
  • 全部步骤通过时报告 released；缺材料而未失败时报告 held；步骤失败时报告 refused。草案禁止把整条记录叫作“verified”或“true”。

谁把绿灯接到了谁的电源上

发行者可以把结论写得很整齐：有编号、有版本、有证据清单，还有一项“通过”的结果。真正昂贵的问题在收件人手里：清单上的文件到没到，文件字节是否吻合，规则重算后是否还得出同一结果？Darren Wright 的新提案把这些动作写成检查程序。它目前是个人 Internet-Draft，拟走 Experimental 路线；没有 IETF 采纳结论。

记录本身使用严格的规范化 JSON。writer 标示发行者，body 放主张和用于运算的值，evidence 为每件材料列出格式和精确字节的 SHA-256 摘要，check 指出规则与结果。版本可以通过前版摘要串起来。签名、发行者密钥归属和记录存在的时间上界，要由承载记录的外层机制让检查者建立；带收录回执的 SCITT 签名声明只是其中一种载体。把 JSON 排得整齐，不能自己长出一枚印章。

检查程序的关键是输入来自哪里。草案要求每个能令步骤通过的输入都离开发行者的控制：检查者从手中的字节算摘要、验签、重跑规则，或采用自己选定的政策、信任锚和规则规格。发行者说“我查过”，可以作为发行者的话记录；它不能替检查者完成检查。这里的权力边界很实在：出题人可以递交答案，不能自己规定阅卷标准。

证据少一份，流程就停在明确的地方。检查者必须拿到每件被引用的完整材料，核对摘要，并按其格式规则验证。缺文件、格式不在允许范围，那个步骤是 NOT RUN。机械规则重算得出不同结果，步骤失败。非机械的 judgement 只适用于检查者政策允许的记录类型。材料持有人即使扣住一份不利文件，也只能让检查暂停，不能靠“没看见”换来通过。

因此最终状态有四个，而不是一个大勾：步骤全部通过为 released；存在失败为 refused；没有失败但有步骤无法运行则为 held；检查者自己的政策无效则为 no verdict。报告要列每一步、所缺输入、时间上界，以及所用政策和信任锚集合的摘要。草案更往前一步，禁止用“verified”“valid”“true”“trusted”“correct”“proven”“confirmed”或“OK”概括整条记录。屏幕上省下一个绿色词，读者才有机会看见证据究竟断在哪里。

released 的范围也很窄：某发行者在给定时间上界之前，用这些证据和规则作过这个结果声明。主张的真假另有检查对象。记录可以被审计，发行者却不能借审计的外壳替世界宣布事实成立。

来源：Wright 草案、IETF 状态、SCITT RFC 9943、JSON RFC 8259。