本章定义 OpenAgenet (OAN) 中参与资源互联的主体、资源、凭证、节点和信任边界。角色定义服务于后续协议，而不是对组织架构或部署进程作抽象描述：主体负责控制身份和资源，注册服务节点负责受理和提交，根平台负责授权、验证、发布和语义治理，内容分发平台负责提供已经验证的材料，发现服务节点负责同步、过滤、索引和返回结果，调用方负责验证候选资源并决定是否连接。每个角色的权限都应与其能够产生或验证的事实相匹配。

OAN 中需要特别区分三类关系：资源控制方是否有权代表资源 DID，基础设施节点是否得到根平台和治理状态认可，资源版本是否已经通过根平台发布并被发现服务节点索引。DID、签名、VC、根平台可信发布证明和链上治理事件分别承载不同事实。任何角色都不能仅凭自己保存的一份 JSON、一次 HTTP 响应或一个搜索排名，替代其它角色负责的验证。

阅读本章时，可以把一个术语放回四个问题中理解：它描述的是谁、它证明了什么、它由谁产生或保存、它能否替代其他证据。例如，资源 DID 描述被控制的资源对象，控制证明表达资源控制方的操作授权，节点授权表达基础设施节点的运行资格，根平台可信发布证明表达特定资源版本已经通过根平台验证。四者可以同时出现在一次注册或发现流程中，但不能合并成一个笼统的“可信”字段。

2.1 核心术语与缩写

2.1.1 统一术语表

本规范中的 DID 是分布式标识符，did:oan 是 OAN 使用的方法标识。DID文档是与 DID 对应的可解析文档，包含验证方法、服务端点及资源相关元数据；DID 控制关系由可验证的密钥和签名证明。VC 是可验证凭证，用于表达注册、节点授权或其它由签发者承担责任的声明；VP 是为验证目的组织的凭证呈现。资源包是绑定资源版本、元数据、哈希和根平台发布证据的可分发对象。

注册服务节点负责资源接入、请求校验、控制证明验证和向根平台提交；发现服务节点负责同步根平台发布内容、建立索引和返回签名发现响应；根平台承担信任授权、数据分发和语义治理三个枢纽职责；内容分发平台是承载验证后材料的分发层，不是信任权威。MCP Server、A2A 和 Tool/API 分别表示资源类型或外部协议语境中的服务与接口，术语相近不代表它们拥有相同的生命周期和权限。

统一术语表中的名称应直接用于正文、接口说明和示例。例如，资源登记材料可以同时出现资源类型、资源 DID、控制证明和服务端点，但“资源类型”不是资源 DID，“服务端点”也不是资源控制身份；MCP 是外部协议名称或资源类型语境中的协议标识，不应被泛化为所有工具资源的同义词。若一个外部协议使用了自己的对象名称，应在首次映射时说明对应关系，后续仍按第 2.1.1 节的中文名称书写。

2.2 资源控制方与资源提供方

资源控制方掌握资源 DID 对应的控制密钥，负责证明自己有权创建、登记或更新该资源的 DID文档和资源版本。资源提供方负责提供实际能力、资源内容、服务端点、协议绑定和使用说明，并对这些声明承担业务和运行责任。在个人或小型部署中，两者通常是同一主体；在组织场景中，控制方可以是组织或平台，提供方可以是受其委托运营服务的团队或系统。

注册服务节点和根平台只验证控制方对 DID 的控制证据以及提交材料的一致性，不因资源提供方能够访问端点就推定其拥有 DID 控制权，也不因控制方持有私钥就保证业务端点真实可用。资源元数据应明确两者关系；关系发生变化时，应通过授权更新、所有权转移或新的资源版本规则表达，而不能只修改展示名称。

{
  "resourceDid": "did:oan:example-resource",
  "controller": "did:oan:example-controller",
  "provider": {
    "name": "示例团队",
    "endpoint": "https://example.invalid/resource"
  },
  "controlProof": {
    "createdBy": "controller",
    "verification": "signature over resourceDid and version"
  }
}

该示例表达控制方和提供方可以分离：签名证明由控制方产生，端点和能力声明由提供方负责。它不表示提供方自动取得资源控制权，也不表示控制证明能够保证端点的业务质量。

2.3 主体身份与本地身份

主体身份是资源控制关系所依附的身份语境，本地身份是客户端侧保存主体配置、控制密钥、资源密钥和必要凭证的材料集合。创建本地身份时，密钥应在用户可控制的客户端环境生成或导入；注册请求只发送完成验证所需的 DID文档、公钥、签名和公开凭证，不发送资源控制私钥或主体私钥。资源 DID 可以由同一本地身份控制多个资源，但每个资源仍应有独立的 DID、版本和控制证明边界。 主体身份是资源控制关系所依附的身份语境，本地身份是客户端侧保存主体配置、控制密钥、资源密钥和必要凭证的材料集合。创建本地身份时，密钥应在用户可控制的客户端环境生成或导入；注册请求只发送完成验证所需的 DID文档、公钥、签名和公开凭证，不发送资源控制私钥或主体私钥。资源 DID 可以由同一本地身份控制多个资源，但每个资源仍应有独立的 DID、版本和控制证明边界。本地身份更适合被理解为客户端侧的密钥和配置容器，而不是注册服务节点上的账户；它可以关联主体 DID、多个资源 DID、导入节点配置和必要的公开凭证，但不能改变各个 DID 在协议中的独立控制边界。

2.3.1 主体身份与资源控制身份

主体 DID 用于表达控制关系的主体，资源 DID 用于表达可独立注册、发布、发现和更新的资源对象。主体身份与资源身份可以由同一密钥体系建立关联，但二者在协议中不能混为一个标识：主体私钥证明主体能够管理相关资源，资源控制签名证明具体资源 DID 的当前操作获得授权。资源提供方的运行账号、网页登录账号或注册服务节点账号也不能自动替代这两类 DID 控制证据。

2.3.2 本地密钥生成、导入与备份

本地身份流程应支持在客户端新建主体身份、导入既有身份备份、保存资源控制材料并在需要时恢复使用。备份文件可以包含主体 DID、公钥、控制密钥、资源配置和必要凭证，但必须明确文件的敏感性和保管责任；导入时应校验结构和密钥对应关系，不能把文件名或展示文本当作身份真实性证明。浏览器注册流程中的下载、导入和恢复属于客户端行为，服务端只接收协议验证所需的公开材料。

{
  "subjectDid": "did:oan:example-subject",
  "resources": [
    {
      "resourceDid": "did:oan:example-resource",
      "controlKey": "stored locally"
    }
  ],
  "publicMaterial": ["subject public key", "resource public key", "credential references"],
  "privateMaterial": "client-side only"
}

这是本地身份备份的概念示例。真实备份格式、加密方式和字段以客户端实现为准；示例中的私密材料不应被上传到注册服务节点、根平台或发现服务节点。

2.3.3 私钥保管与节点可见范围

资源控制私钥、主体私钥和节点运行私钥应由各自控制者保管，注册服务节点、根平台、发现服务节点、内容分发平台和链下信任索引器不应从普通注册或发现请求中取得这些私钥。节点可以看到 DID文档中的公钥、签名和公开凭证，也可以保存提交记录、发布证明和索引数据，但这些公开证据不能反推出私钥。节点运营者的服务器权限、日志权限和备份策略仍属于部署安全边界，应单独管理。

2.4 根平台

根平台是 OAN 的网络级协调和验证中心，但不是所有业务能力的执行中心。它接收授权的基础设施节点提交，验证注册请求中的身份、控制证明、资源类型、版本、哈希和发布条件，维护可供节点同步的可信发布事实，并协调内容分发和发现服务节点通知。根平台保存和签发的是网络验证所需的证明与状态，不应代替资源提供方持有业务端点的控制密钥。

2.4.1 信任授权枢纽

作为信任授权枢纽，根平台负责依据治理状态确认哪些注册服务节点、发现服务节点和其它基础设施参与者有资格执行相应网络动作，并向符合条件的节点提供可验证的授权材料。该枢纽的判断对象是节点资格、角色和授权范围，不是某个资源的业务质量。节点在运行期还必须检查授权状态是否仍然有效，不能仅凭历史 VC 或曾经成功的请求继续执行受限操作。

根平台在这一枢纽上回答的是“节点能否执行某类网络动作”，而不是“节点返回的每项业务内容都值得信任”。节点授权材料通常需要与节点身份、角色、授权域、有效期和治理状态关联；执行节点在处理受限请求时，应同时核对授权材料和当前状态，不能只检查 VC 的签名是否有效。

2.4.2 数据分发枢纽

作为数据分发枢纽，根平台组织已经验证的资源版本、DID文档、资源包、哈希、根平台可信发布证明和同步游标，并通过内容分发平台向授权发现服务节点提供可校验材料。内容分发平台可以缓存和批量传输这些内容，但不能修改根平台接受的事实；发现服务节点收到后仍应重新校验哈希、证明、版本和授权域。

{
  "publication": {
    "resourceDid": "did:oan:example-resource",
    "version": "1.0.0",
    "packageDigest": "sha256:example-digest",
    "rootProof": "available for verification",
    "publicationSequence": 42
  },
  "distribution": {
    "consumer": "authorized discovery service node",
    "verification": ["packageDigest", "rootProof", "governanceStatus"]
  }
}

该示例用于区分根平台形成的发布事实和内容分发平台承担的传输任务。分发成功只说明材料到达，不说明接收方已经完成验证，也不授予发现服务节点超出授权域的可见范围。

2.4.3 语义治理枢纽

作为语义治理枢纽，根平台维护能力标签树及其层级、标识、别名和版本，服务于注册时的标签选择与推荐，以及发现服务节点的语义索引和查询解释。语义治理决定标签如何组织和演进，但不替代资源控制证明或节点授权。发现服务节点可以在根平台词汇基础上使用本地索引和排序方法，但不得通过本地标签扩展自身的授权范围。

能力标签树解决的是“如何用共同词汇描述和查找能力”，不解决“谁控制资源”或“哪个节点有权发布资源”。因此，发现服务节点可以把自然语言任务映射到一个或多个能力标签，也可以返回标签命中和相关性解释，但最终结果仍需关联资源 DID、版本、来源、治理状态和发布证明。

2.4.4 根平台职责边界

根平台负责网络级验证、授权、发布和协调，不负责替资源提供方执行具体业务调用，不保证资源端点的业务质量，也不因资源发布而自动授予调用方业务权限。公开网站、指标、地图和治理事件展示是观察入口，不是根平台事实的替代品。根平台失效时，节点可以依据明确的新鲜度和降级规则提供有限的既有数据，但不得伪造新的接受、授权或发布事实。

2.5 注册服务节点

注册服务节点是资源提供方进入 OAN 的受理和提交边界。它可以提供表单、SDK 或 Skill 支持，检查 DID 语法、资源类型、必填字段、能力标签、端点、哈希和控制证明，并将合格请求包装为向根平台提交的签名请求。注册服务节点签发的注册 VC 或登记结果只证明其处理过相应登记事实，不能代替根平台发布证明，也不能让注册服务节点自行扩大资源的网络可见范围。

注册服务节点必须以自身有效的节点授权和允许的授权域执行受限动作，并保留足以审计的请求标识、验证结果、错误原因和提交状态。它可以拒绝格式不合格或控制权不明的请求；根平台拒绝或异步发布失败时，注册服务节点应如实返回状态，不得把本地受理显示成全网发布完成。

从证据链看，注册服务节点至少产生三类可区分结果：请求是否到达并通过本地校验，是否已经向根平台提交，以及根平台是否接受并发布。客户端或运营人员排查注册问题时，应根据请求标识、资源 DID、版本和提交状态逐级查询，而不能只依据页面上的“提交成功”判断资源已经可发现。

2.6 发现服务节点

发现服务节点是根平台发布内容的授权读侧。它从内容分发平台或根平台通知获取候选资源包，验证根平台证明、哈希、版本和治理状态，按自身授权域过滤资源，并建立结构化和语义索引。它向用户、应用和智能体返回的是经过本地处理的发现响应，因此必须保留资源来源、版本、新鲜度和验证状态，且在支持签名响应时对响应内容负责。

发现服务节点可以优化查询性能、排序和语义匹配，也可以保存旧快照用于有限降级展示，但不得修改根平台的发布事实、把未经授权的资源加入可信索引，或用本地排名覆盖撤销、暂停和版本状态。搜索结果是调用方后续验证的输入，不是自动调用许可。

{
  "resourceDid": "did:oan:example-resource",
  "version": "1.0.0",
  "match": {
    "type": "semantic",
    "capabilities": ["code-search", "structure-summary"],
    "score": 0.91
  },
  "source": {
    "discoveryNode": "authorized-node",
    "publicationSequence": 42,
    "freshness": "known"
  },
  "verificationRequired": true
}

发现响应中的分数、标签命中和解释属于索引或查询层结果；resourceDid、版本、来源和新鲜度用于后续验证。即使相关性分数较高，也不能绕过 DID 文档、根平台可信发布证明、治理状态和端点检查。

2.7 内容分发平台

内容分发平台承载根平台已验证并允许传播的资源包、DID文档、元数据、证明、哈希和同步材料，目标是提高节点同步的可达性、批量效率和缓存能力。它是数据面组件，不是治理和身份信任的授权者；任何分发内容都必须由接收方依据根平台证明、哈希和状态重新验证。分发层可以由根平台同一组织运营，也可以采用独立基础设施，但其部署关系不应改变协议中的责任边界。

2.8 链下信任索引器

链下信任索引器是治理链上事实的读侧投影组件。它读取节点授权、授权域变更、暂停、恢复和撤销等治理事件，按序列或游标写入可供根平台、注册服务节点和发现服务节点查询的授权状态。索引结果具有同步延迟和故障可能，必须保留最后处理位置、事件来源、投影时间和错误状态；运行时不能把索引器的“已看到”简单等同于链上最终事实。

根平台或其它执行节点使用索引状态时，应明确失效、过期和回退策略。对于需要阻止未授权节点继续工作的动作，应在状态无法确认或已超过允许新鲜度时采取 fail-closed 行为；对于公开统计或历史展示，可以展示延迟和旧数据，但不得改变实际授权判断。

{
  "governanceProjection": {
    "nodeId": "did:oan:example-node",
    "role": "discovery",
    "authorizationDomain": "example-domain",
    "status": "active",
    "eventSequence": 128,
    "source": "governance event stream",
    "projectedAt": "2026-09-09T00:00:00Z"
  },
  "decision": "allow indexed discovery within the authorization domain"
}

该投影是链上治理事件的链下读模型，必须保留事件序列和投影时间。若序列中断、状态过期或来源不可验证，执行节点应按敏感动作的失败策略处理，而不是把最后一次成功投影当作永久授权。

2.9 调用方、用户、应用与智能体

用户是发起注册、发现或业务使用意图的人，浏览器或其它客户端是承载本地身份和请求的工具，应用是调用 OAN 接口并执行本地策略的软件，用户助手智能体是可以代表用户查询和发起调用的智能体。它们可以共同出现在一次流程中，但权限来源不同：用户控制本地密钥，客户端保护私密材料，应用验证网络证据，用户助手智能体依据验证结果选择资源。

调用方在发现阶段是依赖方，在实际业务调用阶段还要承担请求签名、凭证呈现、重放防护和本地授权策略。它不得只信任搜索排序、网站显示名称或第三方转发的资源描述；在连接前应验证 DID、VC、根平台证明、治理状态、版本和端点声明，并根据具体业务风险决定是否继续。

2.10 治理权威与授权域

治理权威负责决定基础设施节点是否进入、保持或退出 OAN 的受信任运行范围。授权域是节点获准处理的能力或资源范围，可以约束注册服务节点接收哪些资源、发现服务节点同步和返回哪些资源，以及节点能够执行哪些网络动作。授权域不是资源控制关系，也不是能力标签；标签用于描述和匹配，授权域用于限制权限和可见范围。

治理状态可以由链上事件、根平台运行状态和节点授权材料共同构成，但执行节点必须明确事实来源和优先级。历史授权 VC、缓存状态或人工展示不能覆盖当前撤销或暂停状态；授权域变化传播存在延迟时，节点应按规定的新鲜度和 fail-closed 策略处理敏感动作。

授权域可以用“资源范围 + 动作范围 + 观察范围”理解：资源范围限制节点能处理哪些资源或资源类型，动作范围限制节点能执行注册、同步、索引或管理中的哪些动作，观察范围限制节点能够向哪些查询方或网络区域返回结果。三类范围共同决定节点的有效权限，不能用一个宽泛的 active 状态替代。

2.11 信任边界与责任矩阵

OAN 的责任矩阵应沿着“产生事实、验证事实、保存状态、对外声明”四个维度建立。资源控制方产生资源身份和控制证明，注册服务节点验证接入材料并提交登记，根平台验证节点授权和资源版本并形成发布事实，内容分发平台传递已验证材料，发现服务节点验证并按授权域索引，链下信任索引器投影治理状态，调用方验证候选资源并执行本地调用策略。每一项动作都应能指向对应的签名、凭证、哈希、治理事件、接口响应或持久化记录。

2.11.1 资源控制方与资源提供方

资源控制方对资源 DID、控制密钥和更新授权负责，资源提供方对能力描述、资源内容、端点和业务可用性负责。二者可以是同一主体，也可以通过明确的委托或运营关系分离。注册服务节点和根平台只应依据可验证控制证明判断资源操作权限，不能因资源提供方提交了服务地址或因某个账号登录成功，就推定其取得资源 DID 控制权。

2.11.2 注册服务节点、根平台与发现服务节点

三者的 HTTP 接口也对应不同的信任边界：资源发布者向注册服务节点提交 ResourceRegistrationSubmission，注册服务节点向根平台提交包含 registrarDid 和 upstreamAuth 的 ResourceVerifyAndPublishRequest，发现服务节点向调用方返回 ResourceDiscoveryResponse。前一个接口负责接收资源控制材料，中间接口负责证明授权节点在代表网络提交，后一个接口负责提供本地索引候选；接口可达、请求可解析和候选可见分别是不同事实，不能在角色之间相互替代。

注册服务节点负责受理、校验和上游提交，根平台负责节点授权校验、资源验证、可信发布和分发协调，发现服务节点负责对已发布材料进行同步、验证、授权域过滤和查询服务。注册服务节点的登记结果不能替代根平台发布事实，发现服务节点的搜索结果不能改写根平台状态；三者之间的接口、证明和状态应保持可追踪。

2.11.3 调用方与验证方

调用方可以由用户、应用或用户助手智能体承担，负责提出查询、接收候选资源并决定是否建立业务连接；验证方可以是调用方自身、SDK 或受其信任的验证组件，负责检查 DID、签名、VC、根平台证明、治理状态、版本、端点和调用策略。验证组件只能提供验证结果，不能未经调用方策略授权直接执行高风险业务动作。

2.11.4 关键动作的责任归属

资源创建和更新归资源控制方，注册受理和登记凭证归注册服务节点，根平台接受和可信发布归根平台，材料传输归内容分发平台，授权域内索引和发现响应归发现服务节点，治理事件投影归链下信任索引器，最终业务调用授权归资源服务端点和调用方本地策略。任何公共网站、统计接口或人工维护的事件表都属于观察和展示层，不能承担上述关键动作的协议权威。

角色之间的边界可以按“谁产生事实、谁验证事实、谁保存状态、谁对外声明”四个问题检查。下表中的“负责”是协议职责，不等同于对全部业务内容或运行环境承担责任。

flowchart LR
    RC[资源控制方] -->|DID文档与控制证明| R[注册服务节点]
    RP[资源提供方] -->|元数据与端点| R
    R -->|登记材料| ROOT[根平台]
    GOV[治理事件] --> IDX[链下信任索引器]
    IDX --> ROOT
    ROOT -->|可信发布材料| CDN[内容分发平台]
    CDN --> DISC[发现服务节点]
    DISC --> CALL[调用方/验证组件]
    RC -.控制私钥不出本地.-> CALL
    ROOT -.授权与发布事实.-> DISC

关键动作发生时，应能够定位到对应的签名、凭证、哈希、治理事件、同步游标或接口响应。若一个结果只有“某节点返回了成功”这一层证据，而无法说明事实来源和验证范围，则只能作为运行状态观察，不能作为跨角色信任证明。

实际排查一个资源或节点问题时，可以按以下顺序建立证据链：先确认标识对象和版本，再确认控制证明或节点授权，然后核对发布事实和治理状态，最后检查发现索引、端点和调用方策略。这个顺序既适用于注册失败、发现结果过期，也适用于节点授权撤销后的传播排查；任何一步缺少来源或无法验证，都应把结论限制在可观察范围内。

参考来源