摘要

  • draft-wilder-scitt-physical-site-engage-receipt revision 03 于 2026 年 9 月 9 日进入 Datatracker，文稿日期为 9 月 10 日。它把每份收据的证明绑定模式写进载荷，并要求无法解析的签发者外部事实保持为 undetermined。它仍是活跃的个人 Internet-Draft，不是 SCITT 工作组文稿，也不是 IETF 标准。
  • 新文本还承认：现有收据和外部披露都没有表示现场所有者与透明服务的关系。因此，“服务独立于签发者”并不能推出“服务独立于现场所有者”。

设想一台机器人在工业现场完成检查。签发者生成带签名的记录，受信执行环境封存证据，透明服务接收这份声明，并返回可验证的收录证明。保险人随后验证签名、证明和日志结构，全部通过。

仍有一个决定证据分量的问题没有答案：透明服务由谁运营？如果运营者正是现场所有者，服务虽然在签发者之外，却不在被观察一方之外。现场所有者未必能伪造签发者的签名，但可能影响哪些记录进入自己控制的服务。收录证明只能证明已经出现的那一条，不能证明所有应出现的记录都已出现。

PSER revision 03 新增专节承认了这条边。这是有价值的规范诚实，但不是问题已经解决的证据。

文稿状态与 revision 03 的真实变化

Datatracker 页面 将其列为活跃的个人 Internet-Draft，没有 RFC stream，也没有登记预期 RFC 状态。封面写着 Standards Track，是作者提出的目标，并不等于工作组采纳、IETF 共识或部署。历史记录 显示 revision 03 在 9 月 9 日 22:26 PDT 入档，文稿本身标注 10 日。

revision 02 曾四次要求验证者读取一份没有定义格式的“签发者清单”。官方差异 显示，新版不是简单润色。profile 从 wilder.pser/0.4 升到 wilder.pser/0.5，每份收据必须携带 attestation.bindingMode。

这个字段区分两种模式。直接见证模式由 TEE 见证密钥签署；委托见证模式由持有 TEE 授权凭证的签发者签署。若收据声称直接见证，但 attestation.witnessKey 与信封中的 iss 不是同一密钥，验证者必须拒绝。原先依赖外部文件的一项“逐收据事实”终于跟随收据本身。

另有两项信息确实留在外部：委托凭证，以及签发者与透明服务的关系。它们必须能从 iss 找到一个由签发者控制的稳定标识；签名密钥变化后，旧缓存结果不能沿用。

当信息无法访问、缺失或不可读时，结果是 undetermined。验证者不能把没做成的检查报告成“已查且不存在”，也不能默认选择最有利于签发者的值。不过，验证者也不能仅因这项不确定性就拒绝整份收据；是否足以影响下游行动，由依赖方预先选择的政策决定。验证输出与业务裁决因此保持分离。

三条关系，只有两条有证据入口

第一条是签发者—现场所有者。收据内的 issuerAffiliation 声明双方为关联、独立或未披露。它是有来源、有时间的签名主张，不自动等于公司控制关系的独立审计，但至少和具体收据一起保存。

第二条是签发者—透明服务。这是一项签发者发布的外部事实。若服务由签发者或其关联方运营，收录证明不能被称为来自签发者之外的证据；若双方独立且披露成功解析，依赖方才获得这项有限属性。解析失败则保持不确定。

第三条是现场所有者—透明服务。PSER-03 没有为它定义载荷成员，也没有定义外部事实。新版第 7.9 节说明，前两条关系不能替代它。签发者可以同时独立于现场所有者和透明服务，而透明服务恰由现场所有者运营。现有两项披露都能成立，关键的现场侧控制仍未进入呈现数据。

文稿进一步指出，这种结构会让现场所有者在登记环节保留压制或扣留与自身现场有关记录的能力。这不是对任何现实机构的指控，也不是已经发现漏记。它只是准确描述：收据当前无法排除哪一种控制能力。

收录真实性不等于历史完整性

RFC 9942 把 COSE Receipt 定义为关于可验证数据结构属性的签名证明。收录证明验证成功，说明该条目确实位于相应结构中。RFC 9943 则把签发者的 Signed Statement、透明服务的登记行为和依赖方的后续判断分成不同角色。

这些属性很强，却很窄。它们可让篡改或日志分叉更容易暴露，不会自动证明日志运营者在法律、资本或业务上独立于所有利害关系人。PSER 自己也强调：即便规定每份收据都必须登记，一份成功登记的收据仍不能证明签发者已登记全部收据。没有外部锚点时，本地哈希链也发现不了被整段扣下的尾部。

用于 SLA 抵扣、保险核赔、监管检查或争议处理时，这个区别会直接改变结论。有的政策只要求真实签名；有的要求服务独立于签发者；还有的要求证据同时独立于现场所有者。三种门槛不能被一个“透明”标签压成同一项。

undetermined 应当一路保留到决定记录。如果第三条关系没有查清，就不能借用第一或第二条关系填空。若后来依据带日期的来源查明控制关系，新观察应追加到链上，而不是改写旧收据和当时的认知状态。

第二个透明服务可能降低依赖，但只有在运营关系和登记观察也彼此独立时才有意义。两个同受现场所有者控制的服务不是两个独立见证者。反过来，已披露的关联关系也不必自动触发拒绝；若政策允许，它可以被明确接受。治理要求是准确分类，而不是一刀切。

为决定增加“三边托管记录”

最小补丁是一份与收据共同评估的三边托管记录。它绑定收据身份和 profile 版本，分别列明签发者—现场所有者、签发者—透明服务、现场所有者—透明服务三种关系，并保存每项关系的来源、解析时间、状态和不确定性，再写明依赖方采用的独立性门槛。

记录还应保留服务身份、收录检查点与观察时间、可选的第二服务或独立监测者、最终决定及理由、纠正或替代链。涉及敏感现场的信息可以受限；公开投影只需说明哪条关系已成立、未解析或按政策不要求，无须公开完整现场档案。

它不要求 SCITT 判断工程是否安全、合规或值得赔付。签名回答谁发言；证明材料回答生成环境的有限属性；收录证明回答某条声明是否进入某个结构；托管记录才回答该服务是否满足这次决定真正采用的独立性政策。

这一补丁延续 The Policy Mirror 对控制面的追问，也采用 Running-Code Primacy 对真实执行证据的要求。Reality, Not Advocacy 则限定报道边界：肯定文稿主动暴露缺口，不把提案写成实施成果。三边托管记录是 Daniel Kade 的编辑建议，不是 IETF 已采纳文本。

PSER-03 已经拆开了“在签发者之外”和“独立于现场”这两个概念。下一版需要让第三条关系也可验证，否则再干净的收录证明，也只能承担它真正证明的那一件事。

来源