client_id 的两条路：DID 原生路与元数据文档路

2026-10-22 · RTTP · IQA

规范解读 · 第 10 篇 · 本文引证来源 · W3C AI Agent Protocol CG 会议纪要，2026 年 10 月 21 日（英文原文照录） · draft-ietf-oauth-client-id-metadata-document-02 · W3C DID Core 1.1 · 我方草案 draft-li-rttp-iqa-addressing-00 · 姊妹柱：rttp://（CRI 27） · iqa://（CRI 28）

W3C Agent Protocol CG 10 月 21 日会议最长的一段讨论，给了一个看似很小的问题：当智能体走到 OAuth 授权服务器面前，它拿什么字符串当 client_id？两条路被摆上桌面。纪要记录了两条都没有被选中——“No final selection between the two authorization approaches, adoption decision, or PR merge was recorded.”（没有记录下对两种授权方案的最终选择、采纳决定或 PR 合并。）本篇仍然要把两条路都读一遍，因为有趣的部分不在两者如何取舍。在于两条路各自悄悄承认了什么。

图 1：会议摆出的两条入职路。路 A 把 DID 放进 URL 的位置，并把元数据绑到其精确字节的摘要上；路 B 保留 URL，加一条可选的 DID 绑定。两者均未采纳；两条路都终结在授权服务器的策略闸门前。

元数据路，用它自己的话

标准的路是客户端 ID 元数据文档（Client ID Metadata Documents，CIMD），目前是 OAuth 工作组的互联网草案。它的摘要：“This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata.”（本规范定义了一种 OAuth 客户端向授权服务器表明身份的机制，无需事先的动态客户端注册或其他既有注册方式；它把一个 URL 用作 OAuth 流程中的 client_id，该 URL 指向一份包含必要客户端元数据的文档。）URL 的约束很紧——“MUST use the https URL scheme”（必须使用 https scheme）、必须带 path、不得带 userinfo 或 fragment——而客户端的身份，说到底，是一份发布在客户端自己控制的地址上的文档，由服务器抓取并做字符串比对。

DID 原生路，用纪要的话

摆到 CG 面前的提案往那个槽位里放了别的东西。纪要：“Use the agent DID as the OAuth client_id. A validated DID Document identifies authorized authentication keys and links to self-published, CIMD-style client metadata. The shared slides describe binding the metadata URL to a SHA-256 digest of its exact bytes.”（把智能体 DID 用作 OAuth client_id；经验证的 DID Document 标识出经授权的认证密钥，并链接到自发布的、CIMD 风格的客户端元数据；共享幻灯片描述了把元数据 URL 绑定到其精确字节的 SHA-256 摘要。）备选路保留 CIMD、追加绑定：“Keep the HTTPS metadata URL as client_id and the normal CIMD/OAuth path, while adding a verifiable association with a DID.”（保留 HTTPS 元数据 URL 作为 client_id 与正常 CIMD/OAuth 路径，同时增加与 DID 的可验证关联。）以及会议的诚实条款，按纪要的原话：两条路均未采纳，第二条“remains an alternative for discussion, not a second normative path already implemented.”（仍是供讨论的备选，并非已实现的第二条规范路径。）

走进房间的那个 SHA-256

路 A 里安静却值得注意的部分不是 DID——是那个摘要。把元数据 URL 绑到“a SHA-256 digest of its exact bytes”（其精确字节的 SHA-256 摘要）上，意味着把信任锚在「对规范字节的计算」上，而不是锚在一个可变的指针上。这和我们两个方案的地基是同一条直觉：在我们的寻址层里，地址就是哈希——SHA-256(canonical_authority)[:16]，即从权威本身算出的 16 位十六进制字符，没有文档可抓，没有指针可跟。两个动作共享一种哲学，又在一件后来被证明是全部的细节上分岔：哈希对什么计算，以及它买到了什么。在提案里，哈希绑定的是一份仍住在某个 URL 上的文档，验证任何东西之前仍要把它抓回来。在我们的方案里，哈希就是名字本身；验证从不出机器。

房东账

W3C DID Core 1.1 把愿景说得漂亮——DID 的设计“so that they may be decoupled from centralized registries, identity providers, and certificate authorities”（使其可以与中心化注册表、身份提供方与证书签发机构解耦）。而实践里，讨论中的两条路在令牌移动之前都还要走完一串房东：方法相关的解析、文档托管、摘要校验、授权服务器的准入策略。纪要为路 B 说了句不加修饰的实话：“A server that validates the extension can rely on the verified DID as identity evidence. A server performing only ordinary CIMD checks has not thereby validated a DID.”（验证了该扩展的服务器可以把经验证的 DID 当作身份证据；只做普通 CIMD 检查的服务器并没有因此验证过任何 DID。）那些检查里的每一项，都是一次到别人持有的基础设施的网络往返——而别人持有的基础设施，是可以对你关门的。

图 2：两条路与我们的寻址层分岔的地方。两条入职路都穿过一串在线闸门来完成验证；派生地址是算出来的，不是抓回来的，它的新鲜度陈述由字节自己携带。

我们不主张什么

我们不给一场还没打的比赛记分：无采纳记录，我们也不主张任何结局。我们只记录纪要摆上台面的东西——哈希锚定、精确字节、字节级绑定的词汇，已经走进了设计客户端入职的那个房间。那恰恰是寻址层与授权层将来可以相遇而互不吞并的地方：寻址层计算名字，授权层决定令牌，谁也不假装干对方的活。我们的两根柱子已经分立在这条线的两侧——RTTP（rttp://）计算名字，IQA（iqa://）证明关于它的主张是否仍然成立。

一句话：两条路，一条共同的直觉——少信指针，多信算术；两条路在「谁让字节在时间里保持诚实」的问题上分岔，而那是一道租约题，不是注册题。