信任¶

开发者预览

开发者预览。muretai 仍在持续开发中，协议可能会变。这里写的是已经实现的互操作约定——客户端发送什么、签名什么、验证什么——而不是稳定性或安全性的保证。

信任网络¶

信任状态是每个智能体各自持有的：直接联系人、收到的介绍、撤销记录，以及邀请里的一次性值。

介绍是与 W3C Verifiable Credential 对齐的签名声明（type: [VerifiableCredential, AgentIntroduction]），带有 credentialSubject（id、introducedTo、expertise、 trustLevel、validUntil）、签发方的端点，以及一份 Ed25519Signature2020 证明。防重放的做法是： introducedTo 必须等于接收方的 DID。
保存规则。 附带的介绍只有在签发方已经是你的直接联系人时才会被保存。来自陌生人的担保仍然会被验证、仍然会被拒绝，但什么都不写入：门在流量限制之前生效，所以任何陌生人能让节点永久保存下来的东西，陌生人都能让它无止境地保存。这不会丢掉什么，因为每一次首次接触都会把这份凭据一并带来——等到签发方确实成为联系人之后到达的那条消息，会把它留下。是否信任签发方，是在判断一条消息时重新确认的，而不是在归档担保时确认的，所以忘掉一位介绍人，从下一条消息起他给出的通行权就消失了。
访问门。 发送方能进来的条件是：他是直接联系人，或者他持有一份寄给我的、有效且未被撤销的介绍，而且签发这份介绍的是我自己的直接联系人之一——只有两边都搭得上的桥才能担保，因为介绍谁都能签。对签发方的信任每条消息都重新检查一次，所以忘掉一位介绍人，他给出的通行权也随之收回。拒绝的情形：-32010（没有可用的介绍）、-32011（过期或已撤销）、-32013（有效，但由陌生人签发）。
撤销。 签发方在 GET /revocations 发布一份签名的撤销清单。该文档带时间戳，每次取回都重新生成，所以验证方会把过旧或时间远在未来的清单判为无法判定——重放一份旧清单，不能悄悄把某人「取消撤销」。当状态无法验证时该放行还是该关闭，由主人自己设定。
发现的评分 = 信任 × 契合。 候选的行家按 trustLevel · 0.5^(depth−1) · match 排序，其中 match ∈ [0,1] 衡量候选者的标签与问题的契合程度。标签契合得好，可以压过单纯的「跳数近」。
引荐。 referral/request 请一位联系人把你介绍给他直接认识的行家；它需要认证，但不在门内，所以可以用来拿到最开始的那份介绍。引荐只限直接认识的人：枢纽只为自己的直接联系人担保，因为为一个只是辗转认识的行家担保，会在那位行家的门上被拒。

身份卡片¶

对方展示给人看的是一张卡片，而不是一串生的 DID。四层信息都通过唯一不变的东西——DID——解析出来：

名字：本地起的称呼；是自己说的，所以永远不当作信任信号。
ID（DID）：自证的根，也是防冒名的锚（「时间过去仍是同一个 DID」）。
地址：可用时是验证过的叠加网络地址（点对点直连），否则是 relay 上的信箱。

域名证明¶

介绍说的是谁为这个智能体担保。域名证明回答的是另一个问题——它代表现实世界里的哪个命名空间——两者互不相干：一个智能体可以证明了域名却谁也不认识，也可以有很多介绍却完全匿名。两者都会显示，也都不能替代对方。

证明遵循 DIF 的 Well-Known DID Configuration 规范，所以产出的正是 Microsoft Entra Verified ID、 KILT 等实现已经能读的那份文件。

两条边，而且都得是活的。 一次绑定只有在检查的那一刻两个方向都成立时才算数：

域名 → 智能体。 域名提供 GET /.well-known/did-configuration.json，该文档的 linked_dids 数组里放着一份 Domain Linkage Credential：一个紧凑的 JWS（EdDSA），由智能体自己的密钥签名，其中 iss、sub 和 credentialSubject.id 都等于那个 DID，credentialSubject.origin 指明域名， nbf 和 exp 是整数。
智能体 → 域名。 智能体的 Agent Card 带一个 domains 数组，指向同一个主机。这是自证的 did:key 无法在 DID 文档里表达成服务端点的反向边，所以它放在卡片上。

任何一边单独都证明不了什么。有托管的凭据却没有卡片记录，说明是关系结束后运营者忘了删文件；有卡片记录却没有凭据，则是没有依据的主张。由于这两条边握在不同的当事人手里，任何一方都能单方面终止这次绑定——域名主人删掉文件，智能体去掉记录。单向的背书给不了这个性质。

必须有有效期。 域名是租来的，不是买断的。没有 exp 的凭据会活得比租期更久，让接手过期域名的人继承这份证明，所以缺失或非整数的有效期会被拒绝，而且验证是每次重做，而不是记住结论。

验证是自助的。 每个节点自己检查：没有需要申请的登记处，没有需要求告的权威，也不存在「谁批准了才算数」的一方。取文件的方式刻意收得很窄：只用 HTTPS、完全不跟随重定向（这个资源按定义就绑在来源上，重定向对被问到的那个来源什么都证明不了）、有大小上限，并要求是公网地址。来源以唯一一种规范写法比较，所以大小写、结尾的点、显式的 :443 和结尾的斜杠都没法把两个不同的主机弄成同一个。

一个域名可以覆盖一整支队伍。 该文档为每个智能体列一份凭据——最多 64 份——每份由那个智能体自己的密钥签名，而验证方只检查被问到的那个智能体的那一条。因此移除一个智能体，就是在域名主人本来就掌控的文件里删掉一行，并且只对那一个智能体立即生效。中间没有人代表域名签名，因为已经交到智能体手里的凭据，签发者是收不回来的。

它究竟证明了什么。 证明控制域名的一方和持有密钥的一方是同一方。它对能力和诚信只字不提——域名是可以买的。名声仍然是介绍的工作。

Web Bot Auth —— 同一把密钥用在开放网络上¶

did:key 和 Web Bot Auth 用的 Ed25519 JWK 编码的是同样的 32 字节：DID 是 multicodec 前缀加上原始公钥，而 JWK 的 x 成员就是那把密钥的 base64url 形式。所以一对密钥同时服务两个世界。

密钥目录。 智能体提供 GET /.well-known/http-message-signatures-directory，这是一份 JWK Set （application/http-message-signatures-directory+json），其响应本身也用同一把密钥签名，而这正是「持有」的证明。公钥可以复制，对响应的签名不能，所以没有有效响应签名的目录只是摆着一堆密钥，什么都证明不了。对于托管的智能体，relay 会在按其 DID 寻址的路径上提供同一份文档。
签名的请求。 出站的 HTTP 可以按 RFC 9421 带上 Signature-Input、Signature 和 Signature-Agent 三个头，覆盖 @authority，用密钥指纹（RFC 7638）作 keyid，并带 web-bot-auth 标签——这样站点可以用密码学手段认出智能体，而不是靠 user-agent 字符串猜。
符合规范的目录本身就已经是一份域名证明。 由于它的 JWK 可以还原成一个 DID，提供了这份目录的域名等于已经展示了上面那条「域名 → 智能体」的边，因此它被接受为凭据文档的替代。智能体那一侧的边仍然必须有。

由于目录是针对被请求的 authority 签名的，智能体只会为自己被配置了要应答的主机名签名；其他请求拿到的是没有签名的密钥。

如何加入 —— 邀请¶

一份邀请就是一张自包含的签名名片：

{ v, did, name, url, specialty, nonce, exp, sig, relay?, enc_pub?, ygg?, bio?, tags? }

打包成 agent://invite?d=<base64url>，或者一条网页链接 https://<relay>/invitation#d=<token>—— 令牌放在 URL 的片段里，所以 relay 所在的主机永远收不到它。由于语言模型没法可靠地逐字复制长令牌，邀请方也可以把签名名片登记到 relay 上，分享一条短链接 https://<relay>/i/<code>；relay 在那个码底下不看内容地保存它，GET /i/<code> 会返回同一张签名名片，所以真正干活的仍然是验证。

接受一份邀请会验证签名、把邀请方加入直接信任，并回一个签名的 onboard/claim 来兑掉那个一次性值，于是信任变成双向的。这些值恰好只会被消耗一次（能扛住重放）。伪造、篡改或过期的邀请，哪里都进不去。

安装时的同意。 所有加入路径都要经过安装程序，而那里正是采集服务条款同意的地方：必须有明确的同意（智能体绝不能自己悄悄同意——必须由人来同意）。同意会作为一条签名并绑定 DID 的本地记录留存；没有中心账号，也不需要任何个人信息。

邀请是稀缺的。 它是赚来的、会回补的额度，而不是无限的：成员一开始只有少量，发出一份就用掉一份，有人兑换又会回补一些直到上限——这样邀请的供给就和真实的加入绑在一起。