本章把外部协议接入理解为一种可追溯的转换过程：先识别外部对象和版本，再把可核对的字段映射到 OpenAgenet (OAN) 资源元数据或资源包，随后分别验证资源控制权、注册凭证、根平台可信发布证明和治理状态，最后向调用方解释哪些信息可用于发现、哪些信息还需要在调用前复核。适配器应保留外部原文、来源、摘要和转换版本，不能把转换后的摘要直接当作 OAN 的可信发布事实。

映射结果回答的是“外部系统如何描述和连接这项资源”，不直接回答“该资源是否已经获得 OAN 网络授权”。后一个判断必须回到 OAN 的 DID、签名、注册凭证、根平台可信发布证明和治理状态。

21.1 W3C DID Core 与 did:oan

适配器应将 DID Core 通用字段和 did:oan 方法字段分层保存。通用字段用于让 DID 工具理解文档，OAN 字段用于表达资源类型、能力、版本、资源包和发布关系。下面的对象只是映射记录示例，不是新的 DID文档：

{
  "source": {"type": "did-document", "version": "did-core-compatible"},
  "oan": {"method": "did:oan", "resourceDid": "did:oan:SKDM:<identifier>"},
  "mapping": {
    "preserved": ["id", "verificationMethod", "service"],
    "mapped": ["resourceType", "capabilityTags", "protocolBindings"]
  }
}

该记录只说明转换过程。did:oan 使用 DID Core 的通用身份和服务表达方式，并通过 OAN 的资源元数据、资源包及关联证明补充资源发现和发布所需的信息。

21.1.1 DID Core 数据结构对应

DID文档中的 id、verificationMethod、控制关系和 service 对应 DID Core 的通用数据模型。OAN 的资源类型、能力标签、用例、版本、资源包引用和发布证明关联属于 OAN 资源模型或方法扩展。适配器应保留原字段和原始路径，不应把 OAN 扩展字段伪装成 DID Core 的标准字段。

21.1.2 did:oan 方法扩展

did:oan 方法扩展用于表达资源主体、资源类型、能力集合、端点、协议绑定、版本引用及发布证据关联。方法扩展必须明确字段类型、必填条件、规范化方式和签名覆盖范围，扩展字段变化应进入 DID 文档或资源包版本管理。

方法扩展的检查顺序为：

1. 解析方法名和方法特定标识符。
2. 根据主体代码核对资源类型或节点角色。
3. 核对元数据、服务、版本和资源包引用。
4. 独立验证控制证明、哈希、注册 VC 和根平台可信发布证明。

影响签名覆盖范围、资源类型、版本选择或治理判断的扩展，应按破坏性变更进入第 24 章的变更记录。

21.1.3 解析行为

解析器接收完整 did:oan 后，先校验方法名和方法特定标识符，再读取对应 DID 文档并验证结构、控制关系、状态和版本。未找到、方法不支持、文档无效、证明缺失和状态未知应分别返回，不能以空文档或最近缓存掩盖错误。

21.1.4 互操作边界

DID Core 互操作保证通用身份结构可以被理解，不保证外部解析器理解 OAN 的资源语义、根平台可信发布证明或治理状态。外部系统可读取 DID 文档并获得入口，但在调用前仍需按 OAN 规则验证资源版本、发布证据和端点。

互操作报告应分别记录格式互操作和 OAN 语义互操作：前者证明外部解析器能够读取通用字段，后者证明调用方能够理解资源类型、能力、版本、资源包和发布证据。两者不能合并为单一的“兼容”结论。

21.2 A2A Agent Card 映射

OAN 与 A2A Agent Card 的关系可按“网络级资源发现”和“服务级调用描述”区分：OAN 通过 DID文档、资源元数据和资源包提供稳定身份、来源、版本及治理关联；A2A Agent Card 以服务提供方、支持的交互入口、能力、技能、输入输出模式和安全声明描述智能体服务。二者可以互相引用，但映射不会改变任一方的身份、签名和授权语义。

OAN 资源档案中的能力描述、用例、端点和协议绑定可以为 A2A Agent Card 提供可信的发现入口；反向接入时，Agent Card 只能作为注册草稿或补充描述的来源，仍需由资源控制方按 OAN 流程生成和签署资源材料。详细调用流程由 A2A、MCP、工具 API 或资源自身协议决定。

21.2.1 能力描述映射

OAN 的 capabilityTags、capabilityDescription 和用例信息可映射到 A2A Agent Card 的 skills、技能名称、描述和示例任务。映射时保留标签树路径、原始文本、资源包版本和来源；OAN 发现节点的语义匹配结果可以帮助定位候选资源，但不能证明资源已获授权或一定具备所声明能力。

建议同时保留规范化标签和原始描述：

{
  "tag": "code.repository",
  "sourcePath": "skills[0].name",
  "sourceVersion": "1.0",
  "resourcePackageVersion": "1.0.0"
}

规范化标签服务于筛选和语义治理，原始文本服务于解释和复核。

21.2.2 用例和技能映射

OAN 的用例字段和技能包信息可用于生成 Agent Card 的技能摘要、示例任务和输入输出说明。生成结果应保留资源包版本和字段来源；若外部 Card 只提供摘要，反向登记时只能形成待核对的资源描述，不能补齐 OAN 中没有声明的控制、版本、端点或治理信息。

21.2.3 服务端点映射

OAN DID文档或资源包中的服务端点、协议类型、传输方式和认证要求可映射到 Agent Card 的 supportedInterfaces、协议绑定和安全声明。端点映射只提供连接准备信息，不代表端点可用；调用方仍需执行 TLS、认证、版本、状态和业务授权检查。 端点映射可按“入口、协议、传输、认证、版本、状态”逐项记录；其中任何一项来自外部描述时，都应保留原始路径或摘要，便于在调用前重新核对。

21.2.4 身份、签名和可信证据映射

Agent Card 的 provider、签名或安全声明可以作为外部输入保存，但 OAN 的资源身份以 did:oan 和其控制关系为准。Agent Card 整体签名证明的是 Card 内容及其发布者声明；注册 VC、根平台可信发布证明和治理状态证明的是 OAN 流程中的不同事实，必须分别保留，不能互相替代。 身份和证据映射应分层保存：

• 资源控制关系回答“谁能控制该 DID”。
• Agent Card 或外部声明回答“外部系统如何描述该资源”。
• 注册 VC 回答“注册服务节点声明了什么登记事实”。
• 根平台可信发布证明回答“根平台验证并发布了什么内容”。

21.3 MCP 资源与服务器元数据映射

OAN 将 MCP 服务作为可发现资源。映射时按“服务器、工具、调用”三层记录：服务器层描述身份、协议版本、传输和端点；工具层描述工具或资源清单、名称、说明和输入 schema；调用层描述会话、认证和错误约束。资源包应保存清单原文或稳定引用、版本和哈希，发现索引可以只保存检索摘要。一次 MCP 初始化成功只说明服务能够完成某次协议交互，不等于根平台已经验证并发布该资源。

21.3.1 MCP Server 映射

MCP Server 的名称、说明、协议版本、传输方式、端点和服务器能力映射到 OAN MCP 服务资源的元数据。服务器 DID、控制证明、资源版本、资源包哈希和根平台可信发布证明独立保存，以区分“服务器自我描述”和“网络已验证发布”。每条工具记录还应保存所属服务器和资源包版本，避免仅凭工具名称跨服务去重。

21.3.2 工具定义映射

MCP 工具名称、说明、输入 schema 和可用能力可映射到 OAN 的工具条目、能力描述和标签。工具条目应带有所属服务器、资源包版本、内容摘要和原始清单位置；工具名称相同不等于属于同一控制主体。发现索引可以使用摘要字段，但调用方应能回到完整清单核验工具边界。

21.3.3 输入输出约束映射

MCP 输入 schema、结果结构和错误约束映射到 OAN 的输入输出描述，并保留 schema 原文、媒体类型、版本和哈希。映射失败或字段不完整时，资源可以登记为描述不完整，但不能向调用方宣称约束已经验证。 输入输出映射可用 schema 版本和摘要建立稳定引用；字段类型、必填关系、枚举值或错误结构发生变化时，应把它视为新的描述版本，而不是只更新展示文本。

21.3.4 调用和认证信息映射

MCP 传输、会话建立、认证要求和调用前条件可作为 OAN 服务信息的一部分，用于发现后的连接准备。OAN 的发布证明只证明声明材料及其来源，不能替 MCP 服务器授予用户业务权限或保证会话成功。 调用和认证映射应区分“发现时可见的接入条件”和“运行时由服务端授予的权限”。OAN 只登记和验证声明及其来源，不代替 MCP 服务或工具 API 的业务鉴权。

21.4 工具与 API 描述映射

OpenAPI 映射建议以路径和操作为粒度建立稳定条目：

operationId: searchRepository
source: openapi.yaml#/paths/~1repositories~1search/get
oanResourceDid: did:oan:TLDM:<identifier>
schemaHash: sha256:<value>

规范化摘要可用于发现和去重，原始文档用于调用前复核。

工具 API 应以路径和操作为最小审计单元，至少保留 operationId、原始文档路径、服务器端点、schema 版本、认证要求和摘要。规范化摘要用于发现和去重，原始文档用于调用前复核，文档可读不等于接口可调用。

21.5 VC 与 VP 生态互操作

VC/VP 处理应采用“解析 → 密码学验证 → 状态检查 → 信任策略判断”的顺序。任何一步失败都要产生明确的中间状态，不能将“JSON 可解析”直接显示为“可信”。

适配器可以解析外部 VC/VP 的主体、签发者、凭证类型、有效期、状态和证明材料，并将原始对象及验证结果保留。能够解析只表示格式可读；是否接受还要看签发者授权、控制关系、治理状态和 OAN 的信任策略。对于无法取得状态信息、签名验证失败或签发者关系不明的输入，应保留失败原因并进入拒绝或人工复核路径。

21.6 外部组织与平台身份映射

外部组织、平台账号、域名或其 DID 可以作为资源提供方、运营方、委托方或端点托管方的关联信息保存，但应记录关系类型、证明来源、责任范围和有效期。域名、企业账号、平台认证和资源控制 DID 不是同一字段，外部账号名称不能替代资源 DID 控制权，域名或平台认证也不能直接产生根平台发布资格。

21.7 外部凭证与信任证据映射

外部证据记录建议包含 issuer、subject、credentialType、issuedAt、expiresAt、statusSource、sourceHash、verifiedAt 和 verifier。缺少状态端点时应记录“状态未检查”，而不是默认有效。OAN 将其作为补充证据，但节点授权、资源控制和根平台发布仍按各自的 OAN 证据链判定。

21.8 字段来源、版本与哈希要求

字段来源可用如下审计记录表示。示例中的 agent-card.json、摘要和时间均为占位值：

{
  "field": "capabilityTags[0]",
  "source": "agent-card.json#/skills/0",
  "sourceHash": "sha256:<value>",
  "mappingVersion": "oan-a2a-v1",
  "verifiedAt": "<timestamp>"
}

每个映射字段应记录来源对象、来源路径、原始版本、规范化版本、签名主体和内容摘要。规范化操作应可重放；排序、大小写、别名或字段裁剪改变摘要时，必须更新摘要和映射版本，并保留旧结果供审计。

21.9 兼容性配置文件与迁移路径

互操作 profile 应明确支持的 DID、A2A Agent Card、MCP、OpenAPI 版本、必选和可选字段、签名算法、传输、错误策略及迁移方式。迁移时先保留原始证据，双读旧、新 profile，核对字段摘要和签名边界，再切换单写；失败时回到旧 profile，不覆盖唯一来源。profile 本身应有名称和版本，便于调用方知道采用的是哪一组映射规则。

21.10 外部协议能力协商

协商结果可分为 compatible、partially-compatible 和 incompatible，并同时给出共同协议、版本、传输和安全能力，以及未满足的能力：

{
  "result": "partially-compatible",
  "commonProtocols": ["https"],
  "missing": ["required-auth-scheme"]
}

客户端或适配器声明支持的协议、版本、传输和安全能力，依据双方交集选择可用 profile；没有共同能力时返回明确的不兼容结果。协商成功只表示格式和交互能力可用，仍须单独验证资源身份、发布证据、治理状态和业务权限。

21.11 外部签名与证据保留

适配器输出应将原文、规范化摘要、外部签名和 OAN 签名分开存储，并为每份材料设置来源标识。重新打包或转发时，不能只保留转换后的对象；至少应能回答“原始对象是什么、谁签署、签署了什么、转换是否改变内容、OAN 哪一方重新签署”。 适配过程中保留外部签名、凭证引用、原始对象、版本、摘要、验证时间、验证器和失败原因。重新编码或生成 OAN 资源包时，不能丢失外部材料与 OAN 控制签名之间的边界；两类签名分别说明覆盖的事实。

适配器输出应分开保存原始对象、规范化对象、外部签名、资源控制签名、注册 VC 和根平台可信发布证明。审计时应能回答：原始对象是什么、谁签署、签署了什么、转换是否改变内容、哪一方重新签署以及验证发生在何时。

参考来源