摘要

  • RFC 9560 让 RDAP 服务器通过 OpenID Connect 与 OAuth 识别用户和验证令牌，不必让用户在每个服务分别维护凭证。
  • 可选的用途声明与“请勿追踪”声明只是本地政策的输入；它们不证明真实动机、单次查询权利、全链路不留痕或返回记录的可靠性。
  • 一条可审计的访问链必须把令牌验证、政策版本、查询用途、字段披露、源记录来历和后续调查结果连接起来。

服务器接受了 Bearer Token。发行者、受众、有效期和令牌结构已经足以让流程继续，这是有价值的协议事实。危险从下一句话开始：已认证的用户，被顺手写成“有权查询的人”；被允许的用途，又被写成“真实的动机”；返回的记录，最后被写成“已经核实的现实”。RFC 9560 没有授权这种连跳。

RFC 9560 于 2024 年 4 月作为 IETF 标准轨文档发布。它让 RDAP 客户端发现 OpenID Provider，以会话型或令牌型流程完成身份交互，并减少逐站点建立账户的负担。它能成为共同层，正因为数据访问决定仍由每台 RDAP 服务器按本地政策作出。

认证只关闭一个问题

令牌型查询到达时，服务器必须按本地政策验证访问令牌，并确认它确实是合法令牌。验证可以走 RFC 7662 的 introspection，也可以分析 JWT。aud 受众不匹配时，服务器可以不信任该令牌；RFC 8693 的令牌交换则可把受众改到合适的依赖方。

这些步骤回答的是：本次交互中，服务器是否愿意依赖这份凭证。它们没有决定每个身份能看什么。验证之后，服务器还要比较身份声明与本地政策，为每一次查询单独判断授权；结果可以是拒绝、字段省略、字段遮蔽或披露。

用途是获配的资格，不是内心的证词

可选的 rdap_allowed_purposes 表示某个身份获准使用的用途类别。身份提供者只能把用途值发给有资格使用它的身份。客户端还可用 farv1_qp 声明本次查询用途；若用途不在获准集合，服务器必须返回 403。

这套约束很有用，但证据边界必须守住。用途值说明“此身份被授予某类使用资格”，并不能观察一个人为何发起查询，也不能证明数据日后仍按原用途处理。服务器若认为用途声明与本地政策冲突，可以忽略两者。即使查询没有提供用途参数，服务器仍要用其他信息作出访问决定。

门禁卡可以证明员工身份，并打开一扇门；它不会同时证明进门理由、所取文件的必要性和文件后续用途。联邦认证同样不应承担超过其设计的道德证明。

不追踪以一种保证换取另一种保证

rdap_dnt_allowed 可以授权服务器不记录用户身份与查询之间的对应关系。前提是身份和权限已经确认、声明为 true，而且接受该要求符合当地日志法规。RFC 对此非常坦白：不追踪依赖服务器及代理的善意与事先建立的带外信任，还可能因信息损失而严重削弱审计。

这不是自相矛盾。敏感调查确实可能需要隐藏查询轨迹。治理重点是：谁批准、哪些代理包含在承诺内、保留什么替代证据、权限何时失效。“接受不追踪”是一项政策决定，不是所有系统均未留痕的密码学证明。

返回值也有自己的举证责任

响应中的 farv1 表示支持该扩展，不替底层注册记录背书。合规响应可能只含政策允许的子集；源记录还有采集、更新、核验、纠错与歧义问题。HTTP 200 不证明完整、最新或有用；HTTP 403 也不证明请求者恶意。

最小共同层应统一发现、令牌处理、声明名称与查询参数，不应伪装成全球统一的合法用途、披露尺度或调查结论。陆恒对现实层的区分在这里格外重要：身份、令牌、用途资格、授权决定、披露记录和现实结果都是真的，但前一层无权借用后一层的证明力。