DID 文档需要表达更多资源事实
很多人第一次接触 DID 时，会把 DID 文档理解成“公钥和服务端点的集合”。这当然是 DID 文档的重要用途，但在智能体互联网中，仅有公钥和 endpoint 远远不够。调用者还需要理解资源类型、能力边界、协议入口、授权域、版本信息和验证材料。OAN 的 did:oan 设计正是把 DID 文档扩展为智能体资源的可信发现面。
在 OAN 中，资源 DID 标识的是一个稳定资源主体，而不是某个临时 URL 或版本号。DID 语法采用 did:oan:<semantic-code>:<suffix>，其中语义代码用于表达主体类别，例如 Agent Service、Skill、MCP Server、Tool/API、基础设施节点等。解析 DID 时，系统可以检查语义代码与 DID 文档中的资源类型是否一致，避免“标识看起来是一类资源、元数据却说成另一类资源”的混乱。
OAN 扩展字段让资源可发现
资源 DID 文档承载这个主体对外可读、可验证、可索引的基础信息。除了标准 DID 文档中的控制者、公钥和服务项，OAN 还需要表达 oanMetadata、resourceDescription、protocolBindings、implementationLinks、addressBindings、delegationChain、credentialRequirements、packageInfo、modelFingerprints 等扩展信息。不同资源不一定都需要填满这些字段，但这些字段给智能体资源提供了比普通 URL 更完整的机器可读描述。
| DID 文档字段 | 作用 | 对发现的帮助 |
|---|---|---|
resourceDescription |
描述资源做什么 | 帮助理解用途 |
protocolBindings |
声明协议入口 | 帮助选择连接方式 |
implementationLinks |
指向实现或工件 | 帮助追溯代码和包 |
credentialRequirements |
说明访问条件 | 帮助判断是否可调用 |
packageInfo |
绑定包版本和哈希 | 帮助验证版本一致性 |
modelFingerprints |
标识模型相关特征 | 帮助识别模型能力面 |
authorizedDomains |
声明治理边界 | 帮助过滤不合规候选 |
在密码套件上，did:oan 也考虑了不同部署环境的兼容性。面向通用开源生态，可以使用 Ed25519 等常见签名算法；面向国内合规或联盟链环境，也可以引入 SM2、SM3 等国密配置。对上层资源发现来说，关键不是要求所有参与方使用完全相同的密码实现，而是把密钥、签名套件、哈希算法和验证材料明确写入可验证对象中，让客户端知道应该用什么规则核验。
DID 文档既是发现入口也是验证对象
这与普通服务目录有本质差异。服务目录中的一条记录通常由平台数据库维护，外部用户只能相信平台展示的结果。OAN 的资源 DID 文档则可以被哈希、签名、打包并通过 Root 验证流程固化到 ResourcePackage 中。Discovery 节点同步资源包后，不只是读取字段，还要检查 DID 文档哈希、元数据哈希、包哈希、Root Proof 和 bulletin 事件。也就是说，DID 文档既是发现入口，也是验证对象。
OAN 的 DID 文档还承担语义发现职责。capabilityTags 用于描述资源能力，帮助 Discovery 做匹配和筛选；authorizedDomains 表示资源在治理和授权层面的适用边界；服务项和协议绑定则告诉调用者如何进一步连接。例如，一个 MCP Server 可以在 DID 文档中描述 MCP transport 和 endpoint，一个 Tool/API 可以声明 API 样式、输入输出 schema 或认证要求，一个 Skill 可以引用外部 manifest 或实现资源。
从发现到调用的机器可读桥梁
这种结构让“发现”和“调用”之间有了可机器处理的桥。用户可以从自然语言查询进入 Discovery，Discovery 返回候选资源；客户端再解析 DID 文档，确认资源类型、协议入口和信任材料；最后才进入 MCP、A2A、HTTP API 或其它实际调用协议。如果资源 DID 文档缺少这些字段，自动化调用就会退回到人工判断。
DID 文档还适合表达可验证控制关系。智能体资源可能由个人、组织、服务节点或其它 DID 控制，也可能存在委托发布、凭证要求和跨域访问约束。OAN 支持通过主体控制证明和授权凭证把“资源由谁控制”“谁有资格注册”“调用方需要满足什么凭证要求”表达为协议对象。这样，发现结果不只是告诉调用者“这里有一个 endpoint”，还可以告诉调用者“连接这个 endpoint 前应核验哪些身份与凭证条件”。
外部工件通过引用和哈希绑定
当然，DID 文档也不应该变成大而全的文件仓库。OAN 的设计倾向是：DID 文档承载身份面和发现面，外部文件通过 URL、哈希和版本引用表达。Skill 包、OpenAPI 文件、MCP manifest、模型说明、测试报告或源码仓库，都可以通过 implementationLinks、packageInfo 等字段引用，并由资源包中的哈希关系保证一致性。这样既避免把大型包、代码或 manifest 全部塞进 DID 文档，也能保证客户端在需要时可以验证外部工件是否与注册时一致。
从生态角度看，把 DID 文档作为可信发现面，可以帮助不同协议资源形成共同入口。MCP Server、Agent Service、Skill 和 API 不必在调用协议上完全统一，但可以在身份、描述、授权和验证上使用统一结构。这让 OAN 能够在不替代现有协议的前提下，为智能体互联网提供一个更稳定的资源识别和信任层。
未来，随着更多智能体资源进入开放网络，DID 文档可能不再只是“证明我是谁”的文件，而会成为“让机器理解我能做什么、如何安全连接我、凭什么相信我”的关键协议对象。OAN 的 did:oan 正是在这个方向上的工程化尝试。
外部工件如何绑定到 DID
| 工件类型 | DID 文档中的表达 | 验证方式 |
|---|---|---|
| 代码仓库 | URL 加 commit 或 tag | 检查引用是否一致 |
| 资源包 | URL 加 hash | 校验包哈希 |
| 模型或数据 | 指纹加说明 | 校验来源和版本 |
| 证明材料 | proof 字段 | 校验签名和绑定关系 |
未来，随着更多智能体资源进入开放网络，DID 文档可能不再只是“证明我是谁”的文件，而会成为“让机器理解我能做什么、如何安全连接我、凭什么相信我”的关键协议对象。OAN 的 did:oan 正是在这个方向上的工程化尝试。
DID 扩展思路
DID 文档不应该只是一份纯身份说明，而应该成为资源发现的可读入口。也就是说，DID 文档里除了标识符，还应该有足够多的机器可读字段，帮助发现节点做筛选和排序。
| DID 文档字段 | 作用 | 对发现的帮助 |
|---|---|---|
resourceDescription |
描述资源用途 | 帮助理解任务匹配度 |
protocolBindings |
声明入口协议 | 帮助选择调用方式 |
implementationLinks |
指向实现或工件 | 帮助追溯代码和包 |
authorizedDomains |
声明治理边界 | 帮助过滤不合规候选 |
packageInfo |
绑定版本和哈希 | 帮助验证一致性 |
发现面与验证面可以共用一份事实
这类字段的价值在于，它们既能服务人工阅读，也能服务自动发现。用户看的是“这是什么”，系统看的是“能不能用、是不是同一个版本、是否仍然有效”。
