ANP Message协议重大升级：为Agent协作而设计的协议
这段时间，我们对ANP消息收发协议做了一个大的调整，我们在社区的例会上也分享了我们对协议升级的思考。今天系统的讲下这个问题。
首先整体上回答一些关键问题（后面有详细的升级总结，对技术细节感兴趣的，可以继续阅读，要了解整体思考，看下面的这段就可以了）：
1、为什么需要协议
这个问题我的文章中讨论过多次，一句话解释就是：未来智能体不单单要在组织内协作，也要在互联网上进行跨域协作。协议是上下文传输最高效的方式，特别是在互联网上。
2、为什么需要新的协议
关于消息协议，xmpp、martix、Email等已经有很多，为什么还要设计一个新的？
其中最大的考虑是，这些协议大部分是为人类使用的IM或邮箱系统设计，大部分都是身份和通信一体的方案。而在智能体场景，身份除了用了通信，还要做更多的事情，比如支付、交易、授权等。
所以，我们需要一个智能体原生的协议。而ANP在身份和业务的耦合度上，是最低的。
3、为什么不用DIDComm，这个基于did，同时也是身份和通信分离的方案
我们在设计之初调研过这个方案，DIDComm 是一个基于 DID 的通用安全消息传递框架，不是一个完整 IM 协议。它偏“安全消息信封 + 路由 + 上层协议承载”，而不是“聊天系统”。
它没有群等IM常见的核心概念。
4、这次升级主要解决什么问题？
这次升级花的时间有些长。不过是非常值得的。这次升级主要做了一下几个能力的增强：
- 安全新增强，签名的时候使用RFC 9421和RFC 9530增强安全性，使用更加标准的方法来进行身份的验证。
- 跨域能力的增强。之前的方案在跨域协作上还有些缺口，比如，如何在密码学上证明一个消息确实来自于某个人而不是服务器自己构造的？最新的方案使用proof来保证跨域场景中，每个环节都是安全的。
- E2EE(端到端加密)的增强。我们对端到端加密一直都非常重视。海外也非常重视，比如马斯克的XChat，主打的一个能力就是端到端加密。这次端到端加密方案的升级，在私聊了对齐signal的方案，在群聊上则使用IETF的MLS，将MLS和DID结合起来使用，MLS解决了很多之前群里端到端加密的缺陷，比如成员变更的复杂度。
- 支持文件传输，以及文件的端到端加密。上一个版本文件上支持的不好，这个版本文件支持非常的完善了。包括私聊和群聊的文件支持，文件的安全性考虑以及文件的端到端加密。
- 采用更灵活的消息封装格式，使用jsonrpc2.0做封装。jsonrpc2.0用了封装消息，还是非常灵活的，所以直接复用jsonrpc2.0。
5、那些没有放到这次升级来支持
- 没有支持多设备。martix和signal在多设备上支持的比较好，我们这次在协议上没有支持多设备。我们认为ANP作为一个定位在跨域互通的协议，一个智能体有多少个设备，属于他们域内的事情，而不需要把这个信息和复杂度暴露到域外。也就是，我发送一个消息给另外一个域的智能体，这个智能体有一个设备或多个设备接受这条消息，是他自己的事情，我不管。这样降低了整体的发展，也给实现更大的灵活性。否则协议会非常的复杂。
- 架构上，暂时只支持中继转发。什么意思？一个智能体，要想和另外一个平台的智能体互发消息，需要有一个自己消息服务，而不能直接发送消息给另外一个智能体。当然，直接发消息到另外一个智能体，这个在技术上是没有问题，这次没有做的主要原因是，我们认为未来的主流智能体就近接入消息服务，消息服务提供中继能力。这个架构也是QoS最好的方案。
6、升级过中最大的惊喜是什么
DID是真的好用。我们除了为Agent申请了DID身份，我们也为群组、服务申请了DID身份，完美的解决了多方流程中身份、权限、凭证等复杂难题。
最后，如果你对这个技术感兴趣，我们会在明天（5-14）的社区例会再次介绍我们的升级，欢迎来参加讨论、贡献。
下面是详细的协议升级说明，感兴趣的可以阅读，或者直接阅读原始技术文档：
- did:wba方法规范：https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/chinese/03-did-wba方法规范.md
- 基于DID:WBA的命名空间规范：https://github.com/agent-network-protocol/AgentNetworkProtocol/blob/main/chinese/04-ANP-基于DID-WBA的命名空间规范.md
- 即时消息规范：https://github.com/agent-network-protocol/AgentNetworkProtocol/tree/main/chinese/message
摘要
这次协议升级的重点，不是对旧规范做局部修补，而是把“身份认证”和“即时消息”都从“能工作”提升到“更标准、更可验证、更适合跨域互通”的层级。
在身份侧，新版 did:wba 不再只是“基于 DID 做一次请求签名”，而是进一步引入了路径型 DID 与绑定公钥指纹的强绑定、DID Document 顶层完整性证明、基于 RFC 9421 的 HTTP Message Signatures、基于 RFC 9530 的 Content-Digest，从而把 DID、密钥、文档、请求四层关系真正打通。
在消息侧，新版 ANP 不再使用一份大而全的单体规范来承载所有语义，而是拆分为 核心绑定、身份与发现、私聊基础、群组基础、私聊 E2EE、群组 E2EE、附件与对象传输、联邦与跨域 八个 Profile。这样做的结果，是业务语义、安全语义、对象传输、跨域调用彼此解耦，但又能通过统一的绑定层重新组合。
如果用一句话概括，新方案的价值就是：让身份更可信，让消息更分层，让加密更标准，让跨域协作真正具备工程可落地性。
一、为什么还要继续升级
旧版 did:wba 和旧版即时消息协议，其实已经完成过一轮重要升级。旧版身份方案已经把 DID 引入跨平台认证流程；旧版即时消息协议也已经从更早期的 WebSocket 路由和交互式握手，演进到了基于 JSON-RPC 2.0 的消息格式、基于 HPKE 的私聊 E2EE，以及基于 Sender Key 的群聊 E2EE。也就是说，旧方案并不原始，它已经解决了“让 Agent 能聊天、能加密”的核心问题。
但当协议进一步面向跨域互联、群治理、附件传输、联邦服务调用和长期标准化时，旧方案开始暴露出新的瓶颈：
身份认证的标准化和绑定强度还不够。
旧版 did:wba 已经能做签名认证，但 DID 路径与绑定公钥之间缺少默认强绑定；请求签名仍然是自定义Authorization: DIDWba ...头；DID Document 顶层 proof、现代 TLS 身份校验规则、标准化挑战机制等都还不够完整。消息协议的结构还偏单体化。
旧版即时消息规范把消息格式、传输绑定、E2EE、群组、接口示例等能力放在同一份文档中，虽然上手快，但后续继续演进时，边界会越来越模糊。群组、附件、联邦这些复杂场景需要更清晰的抽象层。
旧版群聊 E2EE 使用 Sender Key + epoch 轮转，能工作，但在大群扩展性、标准化程度、群状态绑定、群结果见证方面还有进一步升级空间；对象传输和联邦跨域在旧版里也没有被拆成清晰的独立能力层。
所以，新方案不是推翻旧方案，而是在旧方案已经打下的基础上，继续向“长期可维护的协议栈”演进。
二、新的身份认证方案：从“能签名”走向“强绑定、强验证、强互操作”
2.1 新版 did:wba 的整体思路
新版 did:wba 的核心目标，是让一个 DID 不只是“能找到一份文档”，而是同时回答以下问题：
- 这个 DID 到底绑定的是哪把密钥？
- 这份 DID Document 有没有被平台静默替换过？
- 这次请求是不是由 DID 对应的私钥持有者发起的？
- 服务端能否在不增加交互次数的情况下完成标准化验证？
围绕这几个问题，新版 did:wba 给出了四层设计：
- DID 层：路径型 DID 默认携带绑定公钥指纹
- 文档层：
e1_路径型 DID 强制要求 DID Document 顶层proof - 请求层：基于
Signature-Input/Signature/Content-Digest做请求签名 - 会话层：认证成功后通过
Authentication-Info返回 access token
2.2 路径型 DID 默认引入 e1_ 绑定公钥指纹
新版 did:wba 最大的结构变化，是为新创建的路径型 DID定义了默认方案：DID 路径最后一个 segment 必须是 e1_ 绑定公钥指纹。它的意义不是“多加一个后缀”，而是让 DID 本身直接携带与绑定公钥相关的可验证语义。
这件事带来三个直接好处：
- DID 与用户自持密钥形成强绑定
- 平台静默替换身份公钥的风险下降
- 身份轮换边界更清晰，稳定名称交给 Handle / WNS 解决
新版主规范默认 profile 是 e1_，也就是 Ed25519；同时保留了附录中的 k1_ 兼容扩展，以兼容 secp256k1 生态。这意味着新方案的主线更强调标准化和长期互操作，但没有粗暴放弃现有生态兼容性。
相比之下，旧版 did:wba 的路径型 DID 只是普通路径，并没有把绑定公钥指纹直接放进 DID 路径本身。
2.3 DID Document 从“列出公钥”升级为“证明绑定关系”
旧版 did:wba 的 DID Document 已经可以表达 authentication、keyAgreement、service 等字段，也允许出现多种验证方法类型。但在新版中，DID Document 的角色进一步提升：它不仅要“列出密钥”，还要“证明这个文档与 DID 路径绑定关系一致”。
因此，对于默认 e1_ profile，新版增加了几个关键约束：
- DID Document 顶层 必须有
proof proof必须使用DataIntegrityProof + eddsa-jcs-2022proof.verificationMethod对应的 Ed25519 公钥，其 RFC 7638 thumbprint 必须与 DID 路径最后的e1_指纹完全一致
这一步非常关键。旧版 did:wba 更多是在“请求认证”层验证签名；新版则把DID 路径、绑定密钥、文档 proof、认证关系四者统一到了一条连续的验证链路上。
2.4 请求认证从自定义头升级为标准 HTTP Message Signatures
旧版 did:wba 的请求认证方式，是自定义的：
Authorization: DIDWba did=..., nonce=..., timestamp=..., verification_method=..., signature=...这个方案能用，但它本质上仍是协议私有格式，不利于与现成 HTTP 安全机制和标准生态衔接。
新版 did:wba 直接切换到标准化路线：
- 用 RFC 9421 的
Signature-Input和Signature头表达请求签名 - 用 RFC 9530 的
Content-Digest绑定消息体完整性 - 认证成功后通过
Authentication-Info返回 access token - 认证失败时用
WWW-Authenticate+Accept-Signature返回挑战信息和下一次请求应覆盖的组件
这意味着新版身份认证不再是“自定义一套 DID 签名头”，而是把 DID 身份验证嵌入到成熟的 HTTP 标准语义里。对于工程实现来说，这种变化的价值非常大：
- 请求覆盖范围更清晰
- 服务端挑战更规范
- 中间件和网关更容易对接
- 标准库和已有实现更容易复用
2.5 TLS、Token 和高等级授权语义也更清晰了
新版 did:wba 还对几个工程上非常重要的问题做了收紧：
- TLS 服务身份校验：旧版更接近“证书通用名称匹配”的表达；新版明确要求以
subjectAltName.dNSName为准，不再依赖 Common Name。 - Token 返回方式：旧版更接近把 access token 当普通
Authorization: Bearer ...响应头返回；新版明确要求服务端通过Authentication-Info返回 access token。 - 人工确认语义：旧版 DID Document 中有
humanAuthorization字段；新版明确取消这一字段，把“是否需要人类在场确认”从 DID Document 中抽离，交由上层授权策略和接口语义表达，例如authorizationLevel: user-presence-required。这使 DID 文档回到“声明身份能力”的职责，而不是混入过多业务授权语义。
2.6 身份认证：旧版 vs 新版
| 维度 | 旧版 did:wba | 新版 did:wba | 变化意义 |
|---|---|---|---|
| 路径型 DID | 普通路径型 DID，不要求默认携带绑定指纹 | 默认使用 e1_ 指纹路径 | DID 与绑定密钥形成强语义绑定 |
| 默认主线 | 多种 key type 并列，主线不够明确 | 主规范默认 e1_，兼容 k1_ | 主线更清晰，兼顾兼容性 |
| DID Document | 重点是列出验证方法与服务 | e1_ 路径型 DID 强制要求顶层 proof | 文档完整性与身份绑定统一验证 |
| 请求认证 | 自定义 Authorization: DIDWba ... | Signature-Input + Signature + Content-Digest | 更标准、更易互操作 |
| 消息体完整性 | 没有统一标准字段 | 使用 Content-Digest | 防篡改语义更明确 |
| 成功后 token | 语义较宽松 | 通过 Authentication-Info 返回 | 更符合 HTTP 认证语义 |
| 人工确认 | DID 文档中有 humanAuthorization | 上移到授权策略层 | 身份与授权职责分离 |
| TLS 校验 | 更接近 CN 匹配 | 明确使用 subjectAltName.dNSName | 更符合现代 TLS 实践 |
一句话总结：新版 did:wba 把“DID 是谁”“文档是否可信”“请求是否由它发起”三件事，做成了一条完整、标准、可验证的链路。
三、新的端到端即时消息协议：从“单体消息协议”走向“分层协议栈”
3.1 从一份大规范，演进为八个 Profile
旧版即时消息协议的优点，是直观：一份文档里把消息格式、传输绑定、私聊、群聊、E2EE、接口示例都讲完，读者拿到就能实现一个基础版本。
但它的问题也很明显：当协议继续扩大时，所有能力都塞在一个规范里，边界会越来越模糊。比如，哪些是绑定层问题，哪些是业务层问题，哪些是加密层问题，哪些是对象传输问题，哪些又是跨域联邦问题，都会逐渐混在一起。
新版 ANP 的核心升级，就是把整个协议拆成八个 Profile：
| Profile | 作用 | 解决的问题 |
|---|---|---|
| P1 核心绑定 | 统一外层消息绑定 | JSON-RPC 约束、meta/auth/body、能力协商、幂等、错误模型 |
| P2 身份与发现 | 统一 DID 与服务发现 | Agent DID、Group DID、ANPMessageService、发现与选择 |
| P3 私聊基础语义 | 统一私聊业务层 | direct.send、内容模型、接受语义、sender_proof |
| P4 群组基础语义 | 统一群生命周期与群消息 | 建群、加人、踢人、群策略、group_receipt、Group Host 排序 |
| P5 私聊端到端加密 | 定义私聊 E2EE Overlay | Prekey Bundle、X3DH-like、Double Ratchet-like |
| P6 群组端到端加密 | 定义群 E2EE Overlay | MLS、KeyPackage、External Commit、did_wba_binding |
| P7 附件与对象传输 | 统一附件/大对象语义 | attachment_manifest、Object Service、下载票据、对象级加密 |
| P8 联邦与跨域 | 统一跨域调用原则 | 服务发现、跨域转发、Group Host、Object Service 落点 |
这套拆分的最大价值是：基础业务、E2EE、安全证明、对象传输、联邦跨域都能独立演进，但仍共享同一外层绑定。
3.2 新协议不是“聊天 API”，而是“面向 Agent 生态的跨域通信标准”
旧版协议的阅读体验更像一个“消息系统 API 规范”。新版协议的定位则更高一层：它要解决的是 不同域、不同平台、不同实现的 Agent 如何互通。
因此，新协议非常强调几个一等概念：
- Agent DID
- Group DID
- ANPMessageService
- Group Host Service
- Object Service
这意味着协议不再只是“发送一条消息”，而是开始明确描述：
- 身份如何发现
- 消息如何寻址
- 群状态由谁排序
- 对象由谁控制
- 跨域成功语义在哪一层成立
四、新消息协议的核心技术路线
4.1 统一外层绑定：更严格的 JSON-RPC 2.0
这里需要特别强调：新版并不是第一次引入 JSON-RPC 2.0。 旧版即时消息协议已经使用 JSON-RPC 2.0 作为统一消息格式。新版真正的变化，是在此基础上进一步收紧和制度化。
新版 P1 的关键收紧包括：
params必须是对象id必须是非空字符串- 禁止 batch
- Notification 只用于明确的异步通知
- 通用
params顶层结构固定为meta / auth / body - 引入
anp.get_capabilities做能力协商 - 引入
operation_id、message_id做统一幂等与消息标识 - 用
security_profile明确区分transport-protected、direct-e2ee、group-e2ee
也就是说，新协议不是“换成 JSON-RPC”，而是把 JSON-RPC 真正提升为整个协议栈的统一绑定层。
4.2 统一身份发现：ANPMessageService 作为统一入口
新版 P2 的一个重要变化，是把 Agent、群组、对象等能力尽量收束到 统一的 ANPMessageService 之下。它背后可以承载 Home、Key、Group、Join、Capability、Object 等逻辑角色。
相比旧版更偏“总纲式”的接口与端点描述方式，新版把“发现入口”与“能力协商”做得更协议化，也更适合联邦场景。
4.3 私聊安全模型：从“一步 HPKE init”升级到“Prekey Bundle + X3DH-like + Double Ratchet-like”
这里也必须准确表达：旧版私聊 E2EE 已经不是早期 ECDHE 三步握手，它已经是 HPKE 一步初始化 + 链式 ratchet。 所以新旧对比不能简单说成“从不安全变成安全”，而应该说成“从可用的 HPKE 会话初始化，升级为更成熟的异步建链模型”。
新版私聊 E2EE 的核心技术栈是：
- Prekey Bundle
- Signed Prekey / One-Time Prekey
- X3DH-like 初始异步建链
- Double Ratchet-like 后续消息保护
- AAD 绑定、乱序处理、重放防护、会话重建
这套设计的意义在于：
- 更适合异步离线场景：发送方不需要等对方在线响应。
- 比单纯 HPKE init 更接近成熟 IM 安全模型。
- 安全边界更清晰：P5 明确要求签名/断言密钥与
keyAgreement密钥分离，并强调 Bundle 签名不可省略。 - 为未来升级预留空间：P5 明确说明 v1 不是后量子方案，但保留向 PQXDH-like 升级的空间。
4.4 群组安全模型：从 Sender Keys 演进到 MLS 主线
旧版群组 E2EE 的核心方案，是 Sender Keys + epoch 轮转。这个方案在中小规模群聊里很实用，但它的局限也很明显：
- Sender Key 分发是 O(N) 的
- 群成员变更、欢迎、外部加入、群状态证明等场景，很难在一个长期标准化的群密码学模型中优雅表达
旧版规范自己也明确把 MLS 集成列为未来方向。新版 P6 则直接把这条“未来路线”前移为主线方案：
- MLS 作为群密钥状态机
- did:wba 作为身份锚点
- did_wba_binding 负责把 MLS 叶子签名键绑定到
agent_did - Group Host Service 负责排序和回执，但默认不持有群明文
group_did、group_state_version、policy_hash与密码学群状态建立绑定- 群消息使用 MLS PrivateMessage 承载
这一步的意义非常大：群聊 E2EE 不再是“自定义一套能跑的群加密”，而是直接接入了长期标准化主线。
4.5 Proof 模型升级：sender_proof、actor_proof、group_receipt
旧版协议里，消息加密和消息发送是主要焦点；新版则把“谁发起了请求”“谁接受并排序了请求”“谁拥有解密权限”这三件事严格拆开了。
在私聊里：
sender_proof用于证明某条direct.send确由sender_did发起- Hop-level 认证只证明某一跳调用方身份，不能替代原发者证明
在群里：
actor_proof证明群操作或群消息是谁发起的group_receipt由 Group Host 生成，证明该群已经接受并排序了该操作或消息- MLS 成员签名则负责证明哪个密码学成员产生了该握手或密文
这使新版群协议更适合治理场景：它同时保留了发起者证明、群结果见证、群内机密性三层语义，而不是把所有问题混在一个签名里。
4.6 附件与对象：从消息内联到 Manifest + Object Service
旧版协议虽然支持 image、file 等消息类型，也承认大文件效率问题，但并没有形成一套独立、完整、可跨域复用的附件对象规范。
新版 P7 则把附件正式制度化了：
- 消息层只传
attachment_manifest - 对象层通过 Object Service 上传和下载
- 访问控制通过 短时下载票据
- 需要更高保密性时，可启用 对象级加密（object-e2ee）
- Relay 不转发对象字节流
这意味着新协议把“消息控制面”和“对象数据面”彻底分开。对工程实现来说，这一步几乎是必须的，因为它显著降低了跨域消息链路对大字节流的耦合。
4.7 联邦与跨域：从“以后再定义”到正式入栈
旧版协议明确说过：Message Server 之间的通信协议不在该规范范围内，跨服务器互通属于后续工作方向。
新版 P8 则把这部分正式纳入主规范体系：
- 跨域时直接使用原有业务方法，而不是再包一层新的 Relay 方法
- 私聊跨域直接
direct.send - 群操作跨域直接
group.create、group.send、group.add、group.remove等 attachment.get_download_ticket直接送到最终 Object Service- 对象字节流 不得 走跨域服务调用链路
- 群操作的跨域成功语义以 Group Host 的接受与排序 为准
- 私聊的跨域成功语义以 目标 Agent 入口服务的接受 为准
- 原始
sender_proof/actor_proof在跨域时必须保留，不能被中间服务重写
这标志着新协议已经不只是“单域消息 API”，而是真正具备了联邦式 Agent 互通的协议边界。
五、端到端即时消息协议：旧版 vs 新版
| 维度 | 旧版即时消息规范 | 新版 ANP Profile 体系 | 变化意义 |
|---|---|---|---|
| 规范结构 | 单体式大规范 | 八个 Profile 分层组合 | 边界清晰，便于独立升级 |
| 外层绑定 | 已使用 JSON-RPC 2.0 | 继续使用 JSON-RPC 2.0，并加入更严格互操作约束 | 统一绑定层更稳固 |
| 服务发现 | 更偏总纲式端点描述 | DID 文档中的 ANPMessageService + anp.get_capabilities | 发现和协商更加协议化 |
| 私聊模型 | send + 多种消息 type | direct.send + Base 语义 + E2EE Overlay | 业务语义与安全语义分离 |
| 私聊 E2EE | HPKE 一步 init + 链式 ratchet | Prekey Bundle + X3DH-like + Double Ratchet-like | 更适合异步建链 |
| 群聊 E2EE | Sender Keys + epoch | MLS 主线 + did:wba 绑定 | 更适合大群和长期标准化 |
| 群治理 | 有群消息和群接口，但证明边界较弱 | 引入 Group Host、group_state_version、group_event_seq、group_receipt | 群状态排序和结果见证更清晰 |
| 原发者证明 | 重点在消息内容和加密 | 明确 sender_proof / actor_proof / hop auth 分层 | 更适合跨域和审计 |
| 附件对象 | 有文件消息，但无独立对象规范 | attachment_manifest + Object Service + 下载票据 + 对象级加密 | 大对象传输工程化 |
| 联邦跨域 | 作为未来工作方向 | P8 正式定义跨域连接与成功语义 | 真正具备联邦协议形态 |
一句话总结：旧版已经是一套可工作的消息协议；新版则把它升级成了一套可以长期演进、适合跨域 Agent 生态的协议栈。
六、新方案最值得强调的五个特点
6.1 特点一：标准化程度更高
身份侧对齐 RFC 9421、RFC 9530、W3C Data Integrity；群组加密侧转向 MLS；消息绑定层继续建立在 JSON-RPC 2.0 之上并加以收紧。新方案明显更接近长期标准化路线，而不是产品内部私有协议。
6.2 特点二：身份绑定更强
e1_ 指纹路径 + DID Document proof，让 DID、密钥、文档三者之间的绑定从“逻辑上成立”变成“协议上强制验证成立”。这是新版身份方案最关键的安全提升之一。
6.3 特点三：业务层与安全层真正解耦
transport-protected、direct-e2ee、group-e2ee 是可叠加的安全 profile。基础业务可以独立跑，安全 Overlay 可以按需叠加。这种设计让协议既适合渐进部署，也适合后续升级。
6.4 特点四：联邦与对象传输进入主线
附件对象、下载票据、跨域转发、Group Host 排序、Object Service 落点，这些在旧版仍偏“工程实现问题”或“未来工作”的内容，现在都变成了规范主线的一部分。
6.5 特点五：更适合 Agent 协作，而不是只适合聊天
新版协议的关键词不只是 message，更是：
- DID
- discovery
- proof
- governance
- object
- federation
- receipt
这决定了它更像一套 Agent 之间的跨域协作协议，而不只是一个“带 E2EE 的聊天接口”。
七、分享时建议怎么讲
如果这篇文稿要拿去做一次对外或对内分享，我建议主线这样讲：
第一层：先讲升级目标
不是为了换术语，而是为了让身份更可信、跨域更自然、群治理更清晰、协议更能长期演进。
第二层：再讲身份
重点突出三个词：
- 路径绑定
- 文档证明
- 标准请求签名
第三层：再讲消息协议分层
让听众理解：新协议不是一份“聊天接口文档”，而是一套分层协议族。
第四层：重点讲加密路线变化
- 私聊从“HPKE init”升级到“Prekey Bundle + X3DH-like + Double Ratchet-like”
- 群聊从“Sender Key + epoch”升级到“MLS 主线”
第五层：最后讲工程价值
附件走独立数据面，跨域走直接业务方法，群结果有回执，服务发现有统一入口。这说明它不只是密码学设计，更是面向真实系统落地的协议工程。
八、结语
新的身份认证方案和新的端到端即时消息协议，可以概括为一句话：
身份侧，新版 did:wba 从“能认证”升级成“强绑定、强证明、强标准化”；消息侧，新版 ANP 从“能聊天、能加密”升级成“分层、可治理、可联邦、可长期演进”的协议栈。
如果说旧版方案解决的是“把 Agent 通信做出来”，那么新版方案解决的就是：怎样让 Agent 通信成为真正可互联、可验证、可扩展的基础设施。
附：可直接拆成 PPT 的 12 页结构
第 1 页：标题页
- 从 did:wba 到 ANP：新一代身份认证与端到端即时消息协议解读
- 一句话定位：面向 Agent 生态的跨域通信标准
第 2 页：为什么还要升级
- 身份绑定强度不够
- 协议结构偏单体
- 群组、附件、联邦缺少独立抽象层
第 3 页：新版身份认证总体思路
- DID 路径绑定
- DID Document proof
- HTTP Message Signatures
- Content-Digest
- Access Token 会话优化
第 4 页：did:wba 新旧对比
e1_/k1_proofSignature-InputAuthentication-InfohumanAuthorization的语义上移
第 5 页：新版消息协议架构图
- P1 ~ P8 的分层关系
- 业务层 / 安全层 / 对象层 / 联邦层
第 6 页：统一绑定层
- JSON-RPC 2.0 收紧
meta/auth/bodyoperation_idmessage_idanp.get_capabilities
第 7 页：私聊 E2EE
- Prekey Bundle
- X3DH-like
- Double Ratchet-like
- 异步建链
- 重放与乱序处理
第 8 页：群组 E2EE
- Group DID
- Group Host
- MLS
did_wba_bindinggroup_receipt
第 9 页：原发者证明与群结果见证
sender_proofactor_proof- hop-level auth
group_receipt
第 10 页：附件与对象传输
attachment_manifest- Object Service
- 下载票据
- 对象级加密
- 数据面独立下载
第 11 页：联邦与跨域
- 直接使用原有业务方法跨域
- 群以 Group Host 排序为准
- Object Service 是票据最终落点
- Relay 不转发对象字节流
第 12 页：总结
- 身份更可信
- 加密更标准
- 协议更分层
- 工程更可落地
- 更适合跨域 Agent 生态
如果你要，我下一条可以继续把这份内容压缩成更适合演讲稿的 10 分钟版本。