摘要

  • REGEXT 当前草案允许在 RDAP 实体对象中说明哪些联系字段经过何种验证，并可附带日期、验证者、信任框架、方法与证据类别；这些字段大多可选，也没有任何一个字段自动授予普遍披露权。
  • 运营者应为每次披露保留一份“受众与有效性回执”，记录向谁、因何目的、披露了哪些字段，以及本地政策认为结果可沿用多久。这是 Daniel Kade 的编辑性运营建议，并非 IETF 草案要求。

验证事实不会自动选择读者

假设一个域名注册人在开户时收到邮件，点击链接后完成确认。这个动作能够支持一个狭窄判断：当时有人可以接收该邮箱的邮件并完成指定操作。它没有自动回答点击者的法定身份、注册人的最终受益所有权、点击者代表机构行事的权限，也没有证明几个月后邮箱仍由同一主体控制。

同样，它也没有回答谁应当看到验证过程。面向公众的 RDAP 查询、完成身份认证的滥用调查和依法提出的主管机关请求，可能适用不同的字段、目的限制与留痕要求。验证回答“做过什么检查”；披露回答“可以把什么告诉谁”；依赖判断回答“接收方可以据此做什么”。三者相关，但绝不是同一个动作。

机器可读格式让这一区分更重要，而不是更不重要。丰富的验证对象进入下游系统后，第一块看板也许只保留“已验证”；第二次导出丢掉声明范围；第三个评分系统又丢掉日期和方法。最终，“某邮箱在某日完成可达性确认”被重写成“这个注册人可信”。每一层都可能正常运行，组合起来却制造了原始记录从未表达的结论。

第 04 版草案处在什么位置

《Registration Data Access Protocol (RDAP) Extension for Verified Contact Information》第 04 版发布于 2026 年 8 月 24 日。IETF Datatracker 将其列为 REGEXT 工作组语境下的活跃 Internet-Draft，工作组状态为“Candidate for WG Adoption”，IESG 状态为“I-D Exists”。它尚未获得 IETF 正式认可，也不是已经发布的标准。草案页眉写有 Standards Track 的预期状态，只能说明作者的目标，不能当成已经完成的程序结果。

草案拟在 RDAP 的实体对象中加入 verifiedContacts_data 数组。数组中的每个对象可以标明经过验证的声明，例如邮箱、电话号码、传真、地址、姓名、名、姓或出生日期；还可以包括验证完成时间、验证者标识与名称、验证事件标识、信任框架、方法、证据类别、备注和扩展数据。

使用数组而不是单一状态很关键。姓名可能由证件核对，邮箱可能由链接确认，地址可能由数据库比对；三个动作由不同主体在不同日期完成，适用的政策也可能不同。数据模型允许保留这种差异，界面却仍可能把它们压成一个布尔值。实现者若只展示一枚徽章，便主动丢掉了数组设计所保留的意义。

主要说明字段几乎都是可选项。因此，缺失必须被当成“没有提供”，不能被解释成积极结论。第 04 版特别补充：verificationDate 表示验证流程完成的时点；没有这个字段，并不意味着验证当前仍然有效。即使日期存在，它也不是失效日期。某次邮箱确认可被沿用多久、什么变更会触发复核、缺失日期时是否允许高风险用途，都属于运营政策。

第 03 版到第 04 版的官方比较还显示，修订纠正了 JSON 示例，并按最新 RDAP 版本化草案调整文字。草案自己的变更记录将本次更新概括为示例修正、版本化文字更新与文本清理。由此可以确认的，是语义表达正在继续完善；不能据此宣称工作已经稳定或获得采用。

“验证了什么”比“是否验证”更重要

草案把方法与证据分开。reachability 可达性验证要求接收方主动确认，例如输入验证码、点击链接或签收。其他方法涉及实物或图像检查、电子记录匹配、密码学特征验证、电子认证、令牌、知识问答、现场或远程人工核验，以及生物识别。

证据类别则包括身份证、护照、居留许可、银行或公共事业账单、税务文件、出生证明、人口登记、书面或数字证明、邮件与邮寄验证日志、地址数据库等。同一种证据可以通过不同方法检查，同一种方法也可以用于不同证据。可解释的结果来自“声明—方法—证据—框架”的组合，而不是孤立的“verified”。

这一点直接限制了下游结论。邮件可达性不能等同于法定身份；身份不能等同于机构授权；机构授权不能等同于当前控制域名或网络资源；对一个字段的核验也不能证明整条注册记录完整无误。把这些边界说清楚，不是在贬低验证价值，而是在让验证价值可被正确使用。

例如，反滥用团队可以把近期邮箱可达性当成联络排序信号，但不能仅凭此认定对方是资源的合法控制者。域名转移或执法流程可能要求更高层次的身份与权限证据。不同业务的证据门槛可以不同，前提是没有借“已验证”三个字越级。

私有信任框架不是万能等级

trustFramework 是可扩展字段。草案列举 eidas 与 private；后者表示验证依据服务器运营者自己的政策，而非已注册的外部信任框架。private 并不等于无效，也不应被自动当成低质量。它意味着解释工作依赖具体运营政策。

如果系统只保存“private”而没有保存政策标识和版本，就像只写“依照规定”却不说明是哪一版规定。运营者可能改变可接受证据、复核周期、执行主体或例外条件。下游若想重建当时结果的意义，就必须知道事件发生时适用的文本。

外部框架也不能只凭名称完成解释。还要看实际声明、具体保障级别、适用法域与验证方法。互操作不是把不同结果涂成同一种绿色，而是让差异能够被可靠比较。

不公开原件，并不等于没有隐私风险

多数运营者都知道不应通过 RDAP 返回护照扫描件或银行账单。但仅仅披露“使用过护照”“查询过税务记录”或“进行了生物识别”，也可能揭示一个人的身份核验路径。对有权的接收者，这些信息或许有助于评估结果；对匿名公众，它们可能完全没有必要。

草案安全章节明确提醒，联系信息验证数据可能具有隐私影响，服务器必须确保披露符合适用的数据保护法律和政策。草案导言还明确设想了两种环境：公开可访问的 RDAP 服务，以及需要事先授权、供合法请求者或主管机关使用的封闭 RDAP 服务。

这不是让实现者永久二选一。它说明同一数据结构可能跨越不同访问模式，因而运营者必须把访问决定保留下来。公开响应可以只提供最低限度信息；受限响应可以在目的与权限支持时提供更多上下文；某些证据类别也可能完全不适合通过 RDAP 披露。

草案引用 NIS2 第 28 条，作为顶级域注册管理机构和域名注册商收集、维护准确完整注册数据的背景。不能把这段背景扩大成“法律要求公开验证元数据”。收集、维护、验证、受限访问和向公众发布，是五个不同的治理动作，应当各自有依据。

通用徽章为何危险

一枚没有上下文的徽章至少隐藏五个问题：它对应哪个 RDAP 对象；具体核验了哪个字段；使用什么方法与证据；结果产生于何时并适用什么时效政策；它原本面向谁披露。任何一个答案变化，徽章可能仍保持绿色。

更难处理的是复制。一旦公共数据经纪、案件系统或搜索索引取走了徽章，源头后来补充限定、撤销结果或更正记录，都未必能追回副本。原本真实但狭窄的事实因此变成持久却误导的声誉判断。

还有一个对称误区：公开响应没有验证元数据，不代表底层没有做过验证。它也可能表示当前读者无权获知。隐私披露状态与数据质量状态必须分开，否则“保护信息”会被误读为“没有验证”，进而形成不必要的公开压力。

建立“受众与有效性回执”

可行的运营控制，是在保存的验证数据转化为一次 RDAP 响应时生成回执。它不是要给草案增加字段，而是在运营者内部保留披露决定的完整来龙去脉。

回执首先绑定来源：RDAP 对象、精确声明集合、验证事件标识、验证者与完成日期（如果存在），以及实际声明的方法、证据类别和信任框架。框架旁应记录解释它的具体政策与版本。字段缺失时写明缺失，不用默认值制造确定性。

然后绑定接收方：请求者类别、必要时的认证身份、声明目的、公开或受限渠道、实际披露和删减的字段。授权规则可能来自法律、合同、公开访问政策或个案决定，回执应能够定位它。责任人、决定时间和复核途径同样需要保留。

最后是有效性：运营者采用的复验周期、触发复核的事件、对无日期记录的处理，以及更正、撤销、替代状态。这里不是给 verificationDate 偷偷增加协议语义，而是公开本地决策如何判断一项旧结果能否继续服务于当前目的。

回执不复制证件、原始生物特征或验证秘密。它只记录为什么在那个时点向那个对象披露那些元数据。这样既能追责，也避免创建第二个高敏感数据库。

从最小范围开始，给未来留下余地

Heng Lu 所强调的“最小初始规范、未来决策本地化、自愿采用”适合处理这类问题。统一声明、方法、证据与框架的名称，可以降低交流成本；它不要求全球运营者立刻采用完全相同的披露政策。

一个谨慎的起点可以只覆盖一个联系字段、一个有版本的政策、一个完成认证的受众和较短复验周期。公开响应可以借助 RDAP 的删减说明表示某些字段未提供，而不公开具体证据。运营者先观察过期率、申诉、误用与访问需求，再决定是否扩大。

共同语法使各地经验可以比较；本地回执使责任不会漂移。最小化并非永远不前进，而是确保每一步都有退出路径，不让一次方便的上线自动演变成不可撤回的全球声誉机制。

资料来源