摘要

  • 02 版把一个评分对象改为结果数组，每一项都必须带有评估方案和评估者 URI。
  • URI 解决“结果声称来自谁”，却不解决“是否真的由其签发”“转发者是否改动过”以及“方法是否值得信任”。
  • 自动化决策不能只读取数字，而应把对象绑定、方案、评估者、发布端、日期、状态和证据作为一个整体。

目录里的一个绿色数字，很容易在半秒内完成一次权力扩张：读者先看到“8 分”，随后就把它理解为协议已经核验过的安全结论。9 月 6 日提交的 draft-bertoldi-regext-rdap-reliability-scoring-02，价值恰恰在于提前拆开这层错觉。

新版本把扩展名从 reliabilityScoring 改成 reliabilityAssessment，把单一对象换成 reliabilityAssessment_results 数组，并要求每条结果都给出 scoreScheme 和 scoreIssuer。它还增加 validUntil、assessmentId，以及“有效”“复核中”“已撤回”三种状态。作者同时明说，目前没有已知实现。

名字、信任和真实性是三件事

scoreIssuer 回答的是归属：这条记录说谁作出了评估。信任回答的是使用者凭什么相信这位评估者。真实性回答的是这条声明是否真的由其发出，并在传递中保持原样。

02 版只在协议内完成第一件事。评估者必须使用全局唯一、稳定的 URI，而且最好由自己控制；但 URI 不是覆盖评估内容的数字签名。对评估者的信任仍由使用者在协议外配置，签名声明被明确留给后续工作。

HTTPS 也不能替代这项缺口。RFC 7481 让客户端认证响应服务器，并保护传输中的字节。它能证明哪个端点交付了响应，却不能证明响应里提到的第三方评估者就是内容作者。RFC 7481 早已区分“数据在途中没被改”与“数据事实上准确”；评估字段同样需要这道边界。

相同的 JSON，三条不同的信任链

草案预计三种部署。首选是评估者自己运营 RDAP 评估服务；也可以由注册管理机构、注册商或其他服务器转载第三方结果；还允许自我评估。三者的 JSON 可以完全一样，控制关系却不同。

第一方服务里，使用者可能把端点与评估者一并加入信任配置。转载模式里，使用者既要信任评估者，也要信任中间发布者，而响应本身无法完整证明两者的分工。自评模式下，归属或许毫无疑问，激励冲突反而最强。

因此，02 版没有把评估服务塞进 RFC 9224 用于查找权威注册数据服务的引导体系，也拒绝让权威服务器用一个普通链接指向评估者，因为链接可能被理解为背书。能够找到服务，不等于有理由相信它。

真正可执行的是一组关系，而不是分数

数组顺序不代表优先级、权威性或新旧。两个方案中的“7 分”没有天然可比性。validUntil 表示评估者在某一时点后不再保证结果仍然新鲜，并不抹去历史声明。缺少 status 不能默认为有效；已撤回结果可以继续显示，以便持有缓存副本的客户端看到撤回。整个成员缺失，也不能推断对象未被评估、已经通过或评估为负面。

所以，决策对象至少应包括：被正确绑定的主体、稳定的方案标识、评估者 URI、实际发布服务器、评估编号、评估时间、有效期限、生命周期状态和留存证据。只抽取 scoreValue，等于让下游程序替草案编造规则。

主体绑定也没有完全解决。域名可用 ldhName 和现有查询路径。注册商则由评估服务自己的本地 handle 定位，IANA Registrar ID 只能在取回对象后从 publicIds 看见。手里只有 IANA ID 的客户端无法在协议内拼出查询地址。RFC 8521 对象标签只是待讨论方案，ccTLD 注册商以及没有 IANA ID 的注册商仍属开放问题。

协议要求程序保障，却不自封裁判

02 版要求所有打算经 RDAP 发布的评分方案说明披露威胁、事先通知被评估方、预留整改或申诉期、解释数据最小化，并特别论证为什么要发布到单个域名层级。原因很现实：一条低分记录也可能成为攻击者的侦察清单。

但草案没有决定申诉期多长、由谁裁决、如何治理，或者申诉成功后产生什么后果。这些属于各方案的运营制度。共同的数据封装可以记录争议状态，却不能凭字段格式获得裁判权。

这份草案值得肯定的地方，是没有把未知包装成保证。结果只是信息，不是认证证书或执法机制；高分不能保证没有漏洞；证据链接可能改变、受限或消失；签名声明尚不存在。使用它的正确方式，是让记录停留在它能够证明的层级。

来源

  1. IETF Datatracker 文档记录
  2. RDAP 可靠性评估草案 02 版
  3. RDAP 可靠性评估草案 01 版
  4. RFC 7480
  5. RFC 7481
  6. RFC 8521
  7. RFC 9082
  8. RFC 9083
  9. RFC 9224
  10. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  11. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  12. Running-Code Primacy