ANP Profile 2：身份与发现（最终修订稿）

文档编号：ANP-P2
标题：身份与发现
状态：Draft
版本：0.2.0（最终修订稿）
语言：中文
适用范围：本 Profile 适用于 ANP 中 Agent 身份、Group 身份、服务发现与服务端点解释。

1. 目的

本 Profile 定义 ANP 的标识模型与发现模型，规定：

Agent 与 Group 如何使用 DID 表示；
DID 文档中哪些属性对 ANP 有规范性意义；
ANP 服务端点如何在 DID 文档中表达；
调用方如何根据 DID 文档发现可交互的 ANP 服务；
哪些动态状态不得放入 DID 文档。

本 Profile 不定义：

DID 方法本身；
DID 解析协议本身；
设备标识；
内部副本同步；
具体 E2EE 算法细节；
具体群状态机细节。

2. 术语与规范性约定

2.1 规范性关键字

本文中的 MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、OPTIONAL 按照其大写形式解释为规范性要求。

2.2 术语

Agent DID：表示一个 Agent 协议主体的 DID。
Group DID：表示一个群协议主体的 DID。
Controller：能够更新 DID 文档或代表 DID 发起受控动作的实体。
ANPMessageService：DID 文档对外公开的统一 ANP 服务入口。
联邦服务 DID：部署方在跨域服务到服务 HTTP 身份认证中使用的服务 DID，通常由 ANPMessageService.serviceDid 声明。
Discovery：根据一个 DID 解析其 DID 文档，并选择适当服务端点以完成后续交互的过程。

3. 标识模型

3.1 基本原则

ANP 采用以下一等标识：

Agent DID
Group DID

ANP 协议层不定义设备 DID、终端 DID、会话 DID 或副本 DID。
如果某实现内部存在多个运行副本、多个设备、多个执行器，这些实体均属于该 Agent 内部实现问题，不属于 ANP 互通边界。

3.2 Agent DID

每个能够作为 ANP 协议主体发送或接收消息的 Agent MUST 持有一个 agent_did。

agent_did 用于：

标识直接消息的发送方与接收方；
标识控制操作的发起方；
解析可用服务端点；
获取安全 Overlay 需要的公开材料；
建立授权与审计上下文。

3.3 Group DID

每个可被跨域发现、被引用、被管理或被发送群消息的群 MUST 持有一个 group_did。

group_did 用于：

作为群的全局应用层标识；
作为群发现与治理的锚点；
作为群管理与群消息的共同目标标识；
作为群服务端点的发现入口；
作为后续群加密 Profile 的绑定对象。

3.4 加密标识分离

若后续某安全 Overlay Profile 定义独立的密码学内部标识，例如 crypto_group_id、session_id、channel_id，则：

它们 MAY 与 group_did 或 agent_did 不同；
但对应 Profile MUST 明确规定如何将这些内部标识与 DID 进行密码学绑定；
这种绑定 MUST 可由接收方验证。

3.5 ANP 身份分层

为避免跨文档把不同层次的身份混用，ANP 中至少区分以下三类 DID：

Business Origin DID：业务发起者或业务逻辑发送主体，例如请求中的 meta.sender_did；
Logical Issuer DID：某些通知、回执或治理对象在逻辑上所代表的签发主体，例如 group_did；
Service DID：执行 hop-level 服务到服务调用时所使用的服务身份，即 ANPMessageService.serviceDid。

上述三类身份：

MUST NOT 被自动视为同一个主体；
MUST 由对应 Profile 明确说明谁负责签名、谁负责授权、谁负责路由；
在跨域场景中，serviceDid MUST NOT 替代业务主体 DID；
serviceDid 只表示“哪个公开服务入口在执行一跳服务调用”，MUST NOT 被直接拿来参与群内 owner/admin/member 等业务角色判定。

ANP 中最容易被误读的地方之一，是把业务发送者、对象签发者和一跳服务身份混为一谈。下图把这三层 DID 放在同一视图中，以便后续各 Profile 分别引用。

mermaid

flowchart LR
BO[Business Origin DID<br/>meta.sender_did]
LI[Logical Issuer DID<br/>group_did / 回执或治理对象签发者]
SD[Service DID<br/>ANPMessageService.serviceDid]

BO --> U1[业务发起 / 应用语义]
LI --> U2[对象签发 / 结果见证]
SD --> U3[跨域一跳服务身份]

W[三者不得自动等同]
BO -.-> W
LI -.-> W
SD -.-> W

图 P2-1：ANP 身份分层关系（非规范性）。

后续文档若要求签名、授权或路由，应明确指出自己使用的是哪一层 DID，而不是默认读者会自动把三者视为同一主体。

4. DID 文档的 ANP 解释规则

4.1 一般规则

对于 ANP 而言，DID 文档承担以下职责：

提供稳定身份入口；
声明验证关系与受信任密钥材料；
暴露服务端点；
提供服务发现线索。

DID 文档 MUST NOT 被当作：

实时消息状态数据库；
群成员实时存储；
在线状态存储；
高频密钥轮换日志；
Agent 内部副本列表。

4.2 DID 文档最小要求

对于被 ANP 使用的 DID 文档：

id MUST 存在；
对于会被主动发现并交互的 DID，service MUST 存在；
对于仅用于验证或引用的 DID，service MAY 缺省；
对于会作为业务发起者 DID 出现在请求中的 DID，authentication MUST 存在；
若支持声明式签名对象，assertionMethod SHOULD 存在；
若支持加密 Overlay，keyAgreement SHOULD 存在；
capabilityInvocation 属于可选扩展能力，MAY 存在，但不属于 v1 最小互通要求。

4.3 DID 文档最小化原则

DID 文档中的信息 SHOULD 保持：

低频变更；
低敏感度；
低可关联性；
与 DID 使用直接相关。

凡不满足上述要求的内容，SHOULD 转移到受控服务端点提供，而不是直接嵌入 DID 文档。

5. Agent DID 规范

5.1 Agent DID 文档必需语义

一个用于 ANP 的 Agent DID 文档 MUST 至少表达：

id
至少一个可用于后续交互的 service

5.2 认证关系

若 Agent DID 会作为业务发起者身份出现在 meta.sender_did，或出现在任何声明使用 anp-rfc9421-origin-proof-v1 的业务 proof 的 keyid 验证链路中，则 DID 文档 MUST 提供 authentication 关系。

若某请求使用 auth.origin_proof，则验证方 MUST 检查 keyid 指向的验证方法是否被该 DID 文档的 authentication 关系授权。

若 Agent DID 仅用于被动引用、对象归属或离线验证上下文，而不会作为请求发起者参与 ANP 交互，则 authentication MAY 缺省。

若 Agent 需要对群管理对象、声明对象、签名控制对象进行断言，则 DID 文档 SHOULD 提供 assertionMethod 关系。

5.3 密钥协商关系

若 Agent 支持任何 E2EE Overlay，则 DID 文档 SHOULD 提供 keyAgreement 关系。
供 keyAgreement 使用的验证方法 MUST 仅用于表示该 DID 在密钥协商或接收机密信息时可被使用的公钥材料。

5.4 服务端点

凡支持接收 Direct、Capability、Object 控制面或其它需要主动发现的 ANP 能力的 Agent DID 文档，MUST 至少包含一个 ANPMessageService。

该统一服务入口 MAY 同时承载以下能力：

直接消息主入口；
能力协商；
安全 Overlay 公开材料访问；
对象控制面与对象下载入口发现。

若部署方在内部将这些能力拆分为多个组件，这种拆分属于实现细节；DID 文档 SHOULD NOT 为这些能力分别暴露多个独立的 ANP 服务类型。

对外公开的附件控制面方法 MUST 仍通过 DID 文档中公开的统一 ANPMessageService 进入。部署方在内部是否再把请求路由到独立 Object Service、Key Service 或 Group Host 子组件，属于实现细节，不改变对外的标准服务发现模型。

6. Group DID 规范

6.1 Group DID 文档必需语义

一个用于 ANP 的 Group DID 文档 MUST 至少表达：

id
controller
至少一个群服务端点（ANPMessageService）

6.2 群控制权

controller 可为单个 DID，也可为多个 DID。
若存在多个控制者，它们之间的内部协作机制不由本 Profile 定义，但：

DID 文档更新的合法性 MUST 由 DID 方法保证；
调用方 MUST 以解析所得 DID 文档为准；
群治理 Profile MUST 进一步定义群内角色与授权规则。

6.3 群治理验证关系

对支持 anp.group.base.v1 的 Group DID 文档：

assertionMethod MUST 存在；
capabilityInvocation MAY 作为额外治理能力委托关系存在，但不替代 assertionMethod。

当群管理对象、群策略对象、群状态对象需要被签名验证时，验证方 MUST 使用 DID 文档允许的验证关系。

6.4 Group DID 文档禁止内容

以下内容 MUST NOT 直接嵌入 Group DID 文档：

动态成员列表；
在线成员列表；
当前消息序号；
当前群 epoch；
逐消息状态；
一次性预密钥列表；
MLS KeyPackage 实时集合；
高频变化的邀请 / 入群治理队列；
Agent 内部副本列表。

6.5 Group DID 文档可选内容

以下内容 MAY 存在，但必须避免敏感泄露：

群显示名称；
群图标引用；
群公开描述；
群公开策略摘要；
文档版本信息；
服务能力摘要。

如果某可选字段可能带来明显隐私泄露或相关性风险，实现方 SHOULD NOT 将其写入 DID 文档，而应改由受限服务端点提供。

7. ANP 服务端点类型

7.1 总则

ANP 基于 DID 文档中的 service 进行服务发现。
所有 ANP 服务端点对象 MUST 具有：

id
type
serviceEndpoint

服务端点对象 MAY 携带少量静态 hint，但 v1 标准互通只要求：

profiles
securityProfiles
serviceDid

当前版本中，DID 文档对外公开的 ANP 标准服务类型 SHOULD 仅使用 ANPMessageService。
实现方若在内部将私聊、群、密钥、对象或跨域转发能力拆分为多个组件，这种拆分属于实现细节，而不是 DID 文档中的多个独立标准 service type。

为降低跨域调用时的服务选择歧义，每个 DID 文档 MUST 只暴露一个可跨域调用的 ANPMessageService。
若实现内部确有多个服务组件，它们 MUST 被收敛到同一个对外公开的可跨域 ANPMessageService 之下。

7.2 `ANPMessageService`

7.2.1 语义

ANPMessageService 表示 ANP 在 DID 文档中公开发现的统一消息与交互入口。

7.2.2 用途

接收 direct.send
接收 group.get_info、group.send、group.e2ee.send 以及群管理 / 群 E2EE 相关动作
提供 anp.get_capabilities
提供 Direct / Group E2EE 所需公开材料访问
承载 group.e2ee.notice 的接收或分发（若部署支持群 E2EE）
提供 attachment.create_slot、attachment.commit_object、attachment.abort_object、attachment.get_download_ticket
作为对象 HTTP(S) 下载入口发现的服务锚点（若部署支持）

对外公开的附件控制面方法 MUST 仍通过该 DID 暴露的统一 ANPMessageService 进入。部署方在内部是否再把请求路由到独立 Object Service、Key Service 或 Group Host 子组件，属于实现细节，不改变对外的标准服务发现模型。

7.2.3 要求

一个可被主动发现并交互的 Agent DID 文档 MUST 至少包含一个 ANPMessageService
一个 Group DID 文档 MUST 至少包含一个 ANPMessageService
若该 ANPMessageService 会参与跨域服务到服务调用，则其服务条目 MUST 声明 serviceDid
若实现内部存在多组件，DID 文档 MUST 只暴露一个统一入口，并通过运行时能力协商返回更细粒度能力边界
对外公开的 service-scoped 方法，包括密钥材料方法与附件控制面方法，MUST 以该统一入口的 serviceDid 作为目标服务身份锚点，除非对应 Profile 明确声明为 endpoint-local

为了降低跨域服务选择歧义，v1 只鼓励对外暴露一个统一的 ANPMessageService。下图把这个统一入口与常见内部逻辑角色之间的关系放在一起，帮助读者区分“公开服务类型”和“实现内部分工”。

mermaid

flowchart TB
DID[DID 文档]
DID --> S[唯一公开 ANPMessageService]

S --> Home[Home Role<br/>私聊入口]
S --> Group[Group Role<br/>群 Host / 群入口]
S --> Key[Key Role<br/>E2EE 材料]
S --> Cap[Capability Role<br/>anp.get_capabilities]
S --> Obj[Object Role<br/>附件控制 / 下载票据]
S --> Join[Join Role<br/>加入 / onboarding]

图 P2-2：统一 ANPMessageService 与内部角色关系（非规范性）。

本图中的角色只是实现内部的能力边界示意，不构成新的 DID service type，也不应被拿来替代标准化的服务发现字段。

7.3 `ANPMessageService` 的逻辑角色

本节仅用于非规范性说明统一入口背后的常见能力边界；它们不是 DID 文档中的独立标准 service type，也不是 v1 的服务选择字段。

7.3.1 Home Role

Home Role 表示 Agent 侧的主入口能力，用于接收 direct.send、返回能力信息并指示进一步的交互路径。

7.3.2 Key Role

Key Role 表示安全 Overlay 所需公开材料的发布或发现能力，用于：

发现直接消息 E2EE 所需公开材料
发现群 E2EE 所需的引导材料
发现后续安全 Profile 定义的公开对象

7.3.3 Group Role

Group Role 表示群的主入口或 Host 能力，用于：

处理 group.create 之后的群管理动作
接收 group.send 与 group.e2ee.send
暴露群策略、群 E2EE 能力或相关控制入口
作为群状态变化排序的权威入口

7.3.4 Join Role

Join Role 表示加入与邀请相关的入口能力。

7.3.5 Capability Role

Capability Role 表示能力协商入口能力。

7.3.6 Object Role

Object Role 表示对象上传、对象访问控制、下载票据签发以及对象下载入口发现的能力。

7.3.7 跨域转发功能

部署方 MAY 在 ANPMessageService 背后实现跨域转发或域网关功能，但当前版本不为该功能定义独立的 DID service type。

若部署方启用跨域服务到服务调用，则该域网关或域服务在执行外层 HTTP 身份认证时，SHOULD 使用域名所有者保留的联邦服务 DID，而不是普通 Agent DID 或 Group DID。对应规则由 P8 定义。

7.3.8 透明目录与审计索引

若部署方支持目录透明性、透明日志或审计索引，则 MAY 将其作为 ANPMessageService 的扩展能力提供；当前版本不单独定义独立的 DID service type。

8. ANP 服务端点扩展字段

为了便于跨实现发现，本 Profile 只把少量字段作为 v1 静态 hint；其余能力信息 SHOULD 下沉到 anp.get_capabilities。

8.1 `profiles`

类型：字符串数组
语义：服务端点直接支持的 ANP Profile 集合
要求：SHOULD
说明：该字段仅表达静态、可缓存的粗粒度 hint，不替代运行时能力协商。

8.2 `securityProfiles`

类型：字符串数组
语义：服务端点支持的安全模式集合
要求：SHOULD
说明：该字段表示端点级支持范围，不保证所有方法在所有安全模式下都可用。

8.3 `acceptedContentTypes`

类型：字符串数组
语义：服务端点可接受的消息内容类型集合
要求：不作为 v1 标准 DID hint
说明：
- 若需要暴露此类信息，SHOULD 通过 anp.get_capabilities 返回；
- DID 文档中若出现该字段，接收方 MAY 将其视为实现扩展。

8.4 `acceptedObjectTypes`

类型：字符串数组
语义：服务端点可接受的控制面对象类型集合
要求：不作为 v1 标准 DID hint
说明：建议作为运行时能力返回，而不是静态写入 DID 文档。

8.5 `priority`

类型：整数
语义：端点优先级
要求：不作为 v1 标准 DID hint
说明：
- v1 规范不依赖 DID 文档中的 priority 做服务选择；
- 若部署自定义了该字段，应视为私有扩展。

8.6 `authSchemes`

类型：字符串数组
语义：该端点支持的 caller → service 调用方认证方式
要求：不作为 v1 标准 DID hint
说明：
- 该能力通常会随运行时网关配置变化；
- 更适合通过 anp.get_capabilities 暴露；
- 它也不描述业务层 anp-rfc9421-origin-proof-v1 的 proof 承载格式。

8.7 `serviceDid`

类型：字符串
语义：该 ANPMessageService 在跨域服务到服务 HTTP 身份认证中使用的 DID
要求：若该端点参与跨域服务到服务调用，则 MUST

规则：

serviceDid MUST 是 DID 字符串，而不是 DID URL；
外层 HTTP Message Signatures 的 keyid MUST 指向该 serviceDid 文档中某个被 authentication 关系授权的验证方法；
对于 did:web 与 did:wba 部署，serviceDid SHOULD 优先使用裸域名 DID；
serviceDid 表达的是“哪个服务身份在执行跨域调用”，而不是 meta.sender_did 所表达的业务主体身份；
serviceDid 的具体运行时校验流程由 P8 定义；
DID 文档中的 serviceDid 是发现 hint，真正的信任建立以 P8 运行时校验成功为准；
对 service-scoped 方法，调用方 SHOULD 把 meta.target.did 绑定到目标公开 ANPMessageService.serviceDid；对象控制面、密钥材料方法与群加入材料方法均遵循这一原则，除非具体 Profile 明确声明为 endpoint-local。

9. 发现流程

本章后续各节分别描述了 Agent、Group 与 serviceDid 的发现细节。下图先给出统一总览，帮助读者看到三条路径最终都会收敛到公开 ANPMessageService 与运行时能力协商。

mermaid

flowchart TD
Start[调用方持有目标 DID]
Start --> K{目标类型}

K -->|Agent DID| A[解析 Agent DID 文档]
K -->|Group DID| G[解析 Group DID 文档]
K -->|Service DID| SV[解析 Service DID 文档]

A --> S1[选择唯一公开 ANPMessageService]
G --> S1
SV --> S1

S1 --> H[读取静态 hint<br/>profiles / securityProfiles / serviceDid]
H --> C[可选调用 anp.get_capabilities]
C --> R[以运行时结果作为权威能力]

图 P2-3：Agent / Group / Service 的统一发现流程（非规范性）。

阅读后面的 9.1、9.2 与 9.3 时，可以把它们理解为这张统一发现图在三类目标上的具体化，而不是三套彼此独立的发现哲学。

9.1 Agent 发现

对 agent_did 的发现流程如下：

解析 agent_did，获得 DID 文档；
读取 service 列表；
选择唯一的跨域 ANPMessageService；
若后续涉及跨域服务到服务调用，读取该服务条目的 serviceDid；
结合 profiles、securityProfiles、运行时能力协商结果与本地策略，确定该统一入口上可用的具体能力；
如需显式协商能力，调用同一入口上的 anp.get_capabilities。

9.2 Group 发现

对 group_did 的发现流程如下：

解析 group_did，获得 DID 文档；
读取唯一的 ANPMessageService；
若后续涉及跨域服务到服务调用，读取该服务条目的 serviceDid；
结合 profiles、securityProfiles、运行时能力协商结果与本地策略，确定该统一入口上可用的群管理、群消息、加入或群 E2EE 相关能力；
若启用群 E2EE，则通过同一入口发现与该群加密 Profile 绑定的群端公开材料、密码学结果交付能力以及相关控制动作；成员侧加入材料仍按对应 Agent DID 的统一入口发现。

9.3 Service DID 发现

当调用方已知某个 service-scoped 方法的目标 serviceDid 时，发现流程如下：

解析 serviceDid 对应的 DID 文档；
选择与该 serviceDid 对应的 ANPMessageService；
读取其 serviceEndpoint 与静态 hint；
如需精确能力边界，调用同一入口上的 anp.get_capabilities；
仅在通过 P8 规定的运行时服务身份绑定校验后，方可将该 serviceDid 视为可信跨域服务身份。

对于附件下载票据获取，调用方 MUST 以承载该附件清单的原始消息发送者 DID 作为发现锚点，解析其公开 ANPMessageService；在群场景中，该 DID 取自原始群消息发送者，而不是 group_did。调用方 MUST NOT 仅凭 object_uri 的 URL 域名反推控制面服务。

9.4 服务选择

若存在多个候选端点，调用方 MUST 先按下列顺序选择：

先按所请求 profile 过滤；
再按所请求 security_profile 过滤；
然后以运行时能力协商结果作为权威校验；
若仍有多个结果，按本地策略选择。

v1 规范不依赖 DID 文档中的 supportedMethods、logicalRoles 或 priority 做标准服务选择。

9.5 缓存

调用方 MAY 缓存 DID 解析结果与服务选择结果。
但在以下情形下 SHOULD 重新解析：

签名验证失败；
密钥协商失败；
服务端点返回能力变更；
DID 控制权疑似变更；
serviceDid 校验失败；
endpoint-origin 绑定失败；
静态 hint 与运行时能力结果冲突；
本地缓存到期。

10. DID 文档与安全 Overlay 的关系

10.1 `keyAgreement` 的使用

若某 Agent DID 或 Group DID 文档声明了 keyAgreement，则后续安全 Profile MUST 仅使用其中允许的方法作为该 DID 的机密信息接收或密钥协商依据。

10.2 签名验证关系

当某对象声称由某 DID 断言时：

其中，对使用 auth.origin_proof 的请求，验证方 MUST 把它视为认证控制行为，并检查 authentication。

若对象是认证控制行为，验证方 SHOULD 检查 authentication；
若对象是声明或签名断言行为，验证方 SHOULD 检查 assertionMethod；
若对象是治理能力调用行为，验证方 MAY 检查 capabilityInvocation，但这不是 v1 最小互通要求。

10.3 动态安全材料外置

以下内容 SHOULD 通过受控服务端点提供，而非内嵌于 DID 文档：

高频轮换公开材料；
一次性引导材料；
群 epoch 相关材料；
动态群状态摘要。

11. Group DID 与群治理

11.1 Group DID 的角色

group_did 是群的应用层全球标识，不等于任何特定密码学实现内部 ID。

11.2 群治理外置

群成员关系、角色授权、邀请状态、成员状态、策略版本、群状态摘要等对象，SHOULD 由：

群对应的 ANPMessageService
或未来群治理 Profile

提供与签名，而不是放在 DID 文档中。

11.3 控制权与群策略分离

DID 文档中的 controller 只表示谁有权控制 DID 文档本身；
群内“谁能加人、踢人、改策略”属于应用层治理规则，不应直接从 controller 机械推导。
同理，serviceDid 只表示服务调用身份，不应被直接解释成群内 owner/admin/member 之类的业务角色主体。

12. 隐私与最小披露

12.1 服务端点最小化

DID 文档中的 service 项 SHOULD 最小化。
若某服务不需要公开发现，则 SHOULD NOT 出现在 DID 文档中。

12.2 相关性控制

实现方 SHOULD 避免：

在多个 DID 文档中复用会产生强相关性的独特端点模式；
在 DID 文档中放置可直接推断组织结构、部署拓扑、内部角色分布的描述；
通过 DID 文档暴露消息量、活跃度、在线状态或内部副本结构。

12.3 公开与受限分离

公开发现所必需的信息 MAY 放入 DID 文档；
需要访问控制的信息 SHOULD 由受限服务端点返回。

13. 最小互通要求

一个符合本 Profile 的实现至少 MUST 满足：

每个 Agent 有 agent_did；
每个 Group 有 group_did；
Agent DID 与 Group DID 文档至少提供一个 ANPMessageService；
支持根据 DID 文档执行服务发现；
静态 hint 最少支持 profiles、securityProfiles、serviceDid；
运行时能力以 anp.get_capabilities 为权威；
不在 DID 文档中嵌入动态群状态；
不把设备 / 副本概念引入协议层。

14. 示例

14.1 Agent DID 文档片段示例

json

{
  "id": "did:example:agent-a",
  "verificationMethod": [
    {
      "id": "did:example:agent-a#sig-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:agent-a",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "..."
      }
    },
    {
      "id": "did:example:agent-a#ka-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:agent-a",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "X25519",
        "x": "..."
      }
    }
  ],
  "authentication": [
    "did:example:agent-a#sig-1"
  ],
  "assertionMethod": [
    "did:example:agent-a#sig-1"
  ],
  "keyAgreement": [
    "did:example:agent-a#ka-1"
  ],
  "service": [
    {
      "id": "did:example:agent-a#message",
      "type": "ANPMessageService",
      "serviceEndpoint": "https://agent-a.example.com/anp",
      "serviceDid": "did:example:domain-a",
      "profiles": [
        "anp.core.binding.v1",
        "anp.direct.base.v1",
        "anp.direct.e2ee.v1",
        "anp.attachment.v1"
      ],
      "securityProfiles": [
        "transport-protected",
        "direct-e2ee"
      ]
    }
  ]
}

14.2 Group DID 文档片段示例

json

{
  "id": "did:example:group-123",
  "controller": [
    "did:example:group-host",
    "did:example:group-admin-controller"
  ],
  "verificationMethod": [
    {
      "id": "did:example:group-123#gov-1",
      "type": "JsonWebKey2020",
      "controller": "did:example:group-123",
      "publicKeyJwk": {
        "kty": "OKP",
        "crv": "Ed25519",
        "x": "..."
      }
    }
  ],
  "assertionMethod": [
    "did:example:group-123#gov-1"
  ],
  "service": [
    {
      "id": "did:example:group-123#message",
      "type": "ANPMessageService",
      "serviceEndpoint": "https://group-host.example.com/anp/groups/group-123",
      "serviceDid": "did:example:group-host-domain",
      "profiles": [
        "anp.core.binding.v1",
        "anp.group.base.v1",
        "anp.group.e2ee.v1"
      ],
      "securityProfiles": [
        "transport-protected",
        "group-e2ee"
      ]
    }
  ]
}

15. 注册表占位

本标准后续版本 SHOULD 建立以下注册表：

ANP DID Service Type 注册表；
ANP 服务端点扩展字段注册表；
ANP 身份发现错误码注册表；
ANP 群治理对象类型注册表。

16. 参考实现说明（非规范性）

实现方在落地本 Profile 时，宜采用如下原则：

DID 文档是“稳定入口”，不是“实时状态表”；
服务端点是“发现锚点”，不是“全部数据容器”；
动态能力尽量通过 anp.get_capabilities 返回，而不是堆在 DID 文档里；
群 DID 是“应用层群标识”，不是“所有密码学内部状态的唯一序列化”；
设备、副本、内部执行器等概念留在 Agent 内部，不进入线协议。

ANP Profile 2：身份与发现（最终修订稿） ​

1. 目的 ​

2. 术语与规范性约定 ​

2.1 规范性关键字 ​

2.2 术语 ​

3. 标识模型 ​

3.1 基本原则 ​

3.2 Agent DID ​

3.3 Group DID ​

3.4 加密标识分离 ​

3.5 ANP 身份分层 ​

4. DID 文档的 ANP 解释规则 ​

4.1 一般规则 ​

4.2 DID 文档最小要求 ​

4.3 DID 文档最小化原则 ​

5. Agent DID 规范 ​

5.1 Agent DID 文档必需语义 ​

5.2 认证关系 ​

5.3 密钥协商关系 ​

5.4 服务端点 ​

6. Group DID 规范 ​

6.1 Group DID 文档必需语义 ​

6.2 群控制权 ​

6.3 群治理验证关系 ​

6.4 Group DID 文档禁止内容 ​

6.5 Group DID 文档可选内容 ​

7. ANP 服务端点类型 ​

7.1 总则 ​

7.2 ANPMessageService ​

7.2.1 语义 ​

7.2.2 用途 ​

7.2.3 要求 ​

7.3 ANPMessageService 的逻辑角色 ​

7.3.1 Home Role ​

7.3.2 Key Role ​

7.3.3 Group Role ​

7.3.4 Join Role ​

7.3.5 Capability Role ​

7.3.6 Object Role ​

7.3.7 跨域转发功能 ​

7.3.8 透明目录与审计索引 ​

8. ANP 服务端点扩展字段 ​

8.1 profiles ​

8.2 securityProfiles ​

8.3 acceptedContentTypes ​

8.4 acceptedObjectTypes ​

8.5 priority ​

8.6 authSchemes ​

8.7 serviceDid ​

9. 发现流程 ​

9.1 Agent 发现 ​

9.2 Group 发现 ​

9.3 Service DID 发现 ​

9.4 服务选择 ​

9.5 缓存 ​

10. DID 文档与安全 Overlay 的关系 ​

10.1 keyAgreement 的使用 ​

10.2 签名验证关系 ​

10.3 动态安全材料外置 ​

11. Group DID 与群治理 ​

11.1 Group DID 的角色 ​

11.2 群治理外置 ​

11.3 控制权与群策略分离 ​

12. 隐私与最小披露 ​

12.1 服务端点最小化 ​

12.2 相关性控制 ​

12.3 公开与受限分离 ​

13. 最小互通要求 ​

14. 示例 ​

14.1 Agent DID 文档片段示例 ​

14.2 Group DID 文档片段示例 ​

15. 注册表占位 ​

16. 参考实现说明（非规范性） ​

ANP Profile 2：身份与发现（最终修订稿）

1. 目的

2. 术语与规范性约定

2.1 规范性关键字

2.2 术语

3. 标识模型

3.1 基本原则

3.2 Agent DID

3.3 Group DID

3.4 加密标识分离

3.5 ANP 身份分层

4. DID 文档的 ANP 解释规则

4.1 一般规则

4.2 DID 文档最小要求

4.3 DID 文档最小化原则

5. Agent DID 规范

5.1 Agent DID 文档必需语义

5.2 认证关系

5.3 密钥协商关系

5.4 服务端点

6. Group DID 规范

6.1 Group DID 文档必需语义

6.2 群控制权

6.3 群治理验证关系

6.4 Group DID 文档禁止内容

6.5 Group DID 文档可选内容

7. ANP 服务端点类型

7.1 总则

7.2 `ANPMessageService`

7.2.1 语义

7.2.2 用途

7.2.3 要求

7.3 `ANPMessageService` 的逻辑角色

7.3.1 Home Role

7.3.2 Key Role

7.3.3 Group Role

7.3.4 Join Role

7.3.5 Capability Role

7.3.6 Object Role

7.3.7 跨域转发功能

7.3.8 透明目录与审计索引

8. ANP 服务端点扩展字段

8.1 `profiles`

8.2 `securityProfiles`

8.3 `acceptedContentTypes`

8.4 `acceptedObjectTypes`

8.5 `priority`

8.6 `authSchemes`

8.7 `serviceDid`

9. 发现流程

9.1 Agent 发现

9.2 Group 发现

9.3 Service DID 发现

9.4 服务选择

9.5 缓存

10. DID 文档与安全 Overlay 的关系

10.1 `keyAgreement` 的使用

10.2 签名验证关系

10.3 动态安全材料外置

11. Group DID 与群治理

11.1 Group DID 的角色

11.2 群治理外置

11.3 控制权与群策略分离

12. 隐私与最小披露

12.1 服务端点最小化

12.2 相关性控制

12.3 公开与受限分离

13. 最小互通要求

14. 示例

14.1 Agent DID 文档片段示例

14.2 Group DID 文档片段示例

15. 注册表占位

16. 参考实现说明（非规范性）