This chapter defines the subjects, resources, credentials, nodes, and trust boundaries involved in resource interconnection within OpenAgenet (OAN). The role definitions support the protocols that follow; they are not abstract descriptions of organizational structures or deployment processes. The subject controls identities and resources, the Registrar node accepts and submits registrations, the Root platform authorizes, verifies, publishes, and governs semantics, the content distribution platform provides already-verified materials, the Discovery node synchronizes, filters, indexes, and returns results, and the caller verifies candidate resources and decides whether to connect. Each role’s permissions should match the facts it can produce or verify.

Three relationships require particular distinction in OAN: whether the resource controller is authorized to represent the resource DID; whether an infrastructure node is recognized by the Root platform and current governance status; and whether a resource version has passed Root publication and been indexed by a Discovery node. DIDs, signatures, VCs, Root proofs, and on-chain governance events carry different facts. No role can replace a verification performed by another role merely because it stores a JSON document, receives a successful HTTP response, or has a search ranking.

When reading this chapter, place each term into four questions: who or what does it describe, what does it prove, who creates or stores it, and can it replace another piece of evidence? For example, a resource DID describes the controlled resource object, a control proof expresses the resource controller’s operational authorization, node authorization expresses an infrastructure node’s qualification to operate, and a Root proof expresses that a particular resource version has passed Root verification. All four may appear in one registration or discovery flow, but they must not be collapsed into a generic “trusted” field.

2.1 Core Terms and Abbreviations

2.1.1 Unified Terminology Table

DIDs in this manual are decentralized identifiers, and did:oan is the method identifier used by OAN. A DID Document is a resolvable document corresponding to a DID. It contains verification methods, service endpoints, and resource-related metadata. The DID control relationship is demonstrated by verifiable keys and signatures. A VC is a verifiable credential used to express registration, node authorization, or other claims for which the issuer assumes responsibility. A VP is a credential presentation organized for verification. A ResourcePackage is a distributable object binding a resource version, metadata, hashes, and Root publication evidence.

The Registrar node is responsible for resource admission, request validation, control-proof verification, and submission to the Root platform. The Discovery node is responsible for synchronizing Root-published content, building indexes, and returning signed discovery responses. The Root platform performs three hub roles: trust authorization, data distribution, and semantic governance. The content distribution platform carries verified materials and is not a trust authority. MCP Servers, A2A, and Tool/API refer respectively to resource types or services and interfaces in external protocol contexts; similar terms do not imply the same lifecycle or permissions.

Names in the unified terminology table should be used directly in the body, interface descriptions, and examples. For example, registration materials may contain a resource type, resource DID, control proof, and service endpoint at the same time. “Resource type” is not “resource DID,” and a “service endpoint” is not a resource control identity. MCP is the name of an external protocol or a protocol identifier in a resource-type context and must not be generalized as a synonym for every tool resource. If an external protocol uses its own object name, explain the correspondence at the first mapping and use the names in Section 2.1.1 thereafter.

2.2 Resource Controller and Resource Provider

The resource controller holds the control key corresponding to the resource DID and is responsible for proving the authority to create, register, or update the DID Document and resource version. The resource provider supplies the actual capability, resource content, service endpoint, protocol binding, and usage instructions, and assumes business and operational responsibility for those claims. In an individual or small deployment, the two are usually the same subject. In an organizational setting, the controller may be an organization or platform, while the provider may be a team or system operating the service under delegation.

The Registrar node and Root platform verify the controller’s control evidence and the consistency of the submitted materials. They must not infer DID control merely because the provider can access an endpoint, nor infer that a business endpoint is genuinely available merely because the controller holds a private key. Resource metadata should make the relationship between controller and provider explicit. When that relationship changes, it should be expressed through an authorization update, ownership transfer, or new resource-version rule rather than by changing only a display name.

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

This example shows that the controller and provider can be separate: the controller creates the signature proof, while the provider is responsible for the endpoint and capability declarations. It does not mean that the provider automatically obtains resource control, nor that a control proof guarantees the business quality of the endpoint.

2.3 Subject Identity and Local Identity

Subject identity is the identity context on which a resource control relationship depends. Local Identity is the client-side collection of subject configuration, control keys, resource keys, and necessary credentials. When a Local Identity is created, keys should be generated or imported in a client environment controlled by the user. A registration request sends only the DID Document, public keys, signatures, and public credentials required for protocol verification; it does not send resource-control private keys or subject private keys. Multiple resources may be controlled by the same Local Identity, but each resource still has its own DID, version, and control-proof boundary.

Subject identity is the identity context on which a resource control relationship depends. Local Identity is the client-side collection of subject configuration, control keys, resource keys, and necessary credentials. When a Local Identity is created, keys should be generated or imported in a client environment controlled by the user. A registration request sends only the DID Document, public keys, signatures, and public credentials required for protocol verification; it does not send resource-control private keys or subject private keys. Multiple resource DIDs may be controlled by the same Local Identity, but each resource still has its own independent control boundary under the protocol. Local Identity is better understood as a client-side container for keys and configuration rather than an account on a Registrar node. It may associate a subject DID, multiple resource DIDs, imported node configuration, and necessary public credentials, but it cannot change the independent control boundary of each DID.

2.3.1 Subject Identity and Resource Control Identity

A subject DID expresses the subject of a control relationship, while a resource DID expresses a resource object that can be registered, published, discovered, and updated independently. Subject identity and resource identity may be associated through the same key system, but they must not be conflated in the protocol. A subject private key proves that the subject can manage related resources; a resource-control signature proves that a particular operation on the resource DID is authorized. A runtime account of the provider, a web-login account, or an account for a Registrar node cannot automatically replace either type of DID control evidence.

2.3.2 Local Key Generation, Import, and Backup

The Local Identity flow should support creating a subject identity in the client, importing an existing identity backup, storing resource-control materials, and restoring them when needed. A backup file may contain the subject DID, public key, control key, resource configuration, and necessary credentials, but its sensitivity and custody responsibility must be explicit. During import, the structure and correspondence among keys must be checked; a filename or display text must not be treated as proof of identity authenticity. Downloads, imports, and restoration in a browser-based registration flow are client-side operations. The server receives only the public materials required for protocol verification.

{
  "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"
}

This is a conceptual example of a Local Identity backup. The actual backup format, encryption method, and fields depend on the client implementation. The private material in the example must not be uploaded to a Registrar node, the Root platform, or a Discovery node.

2.3.3 Private-Key Custody and Node Visibility

Resource-control private keys, subject private keys, and node-runtime private keys should be held by their respective controllers. A Registrar node, Root platform, Discovery node, content distribution platform, or off-chain trust indexer should not obtain these private keys from ordinary registration or discovery requests. Nodes may see public keys, signatures, and public credentials in DID Documents, and may retain submission records, Root proofs, and index data, but public evidence cannot be used to derive private keys. Server privileges, log privileges, and backup policies held by node operators remain part of the deployment security boundary and must be managed separately.

2.4 Root Platform

The Root platform is OAN’s network-level coordination and verification center, but it is not the execution center for all business capabilities. It receives submissions from authorized infrastructure nodes, verifies identities, control proofs, resource types, versions, hashes, and publication conditions in registration requests, maintains trusted publication facts that nodes can synchronize, and coordinates notifications to the content distribution platform and Discovery nodes. The Root platform stores and issues proofs and statuses required for network verification; it should not hold the control keys of resource-provider business endpoints.

2.4.1 Trust-Authorization Hub

As the trust-authorization hub, the Root platform determines, according to governance status, which Registrar nodes, Discovery nodes, and other infrastructure participants are qualified to perform corresponding network actions, and provides eligible nodes with verifiable authorization materials. The subject of this judgment is node qualification, role, and authorization scope, not the business quality of a resource. Nodes must also check whether authorization remains valid at runtime; they must not continue restricted operations solely because an old VC exists or a previous request succeeded.

The question answered by this hub is “can this node perform a particular network action,” not “is every item of business content returned by the node trustworthy.” Node authorization materials normally need to be associated with node identity, role, authorization domain, validity period, and governance status. When processing a restricted request, the executing node should check both the authorization material and current status rather than checking only whether the VC signature is valid.

2.4.2 Data-Distribution Hub

As the data-distribution hub, the Root platform organizes verified resource versions, DID Documents, ResourcePackages, hashes, Root proofs, and synchronization cursors, and makes verifiable materials available to authorized Discovery nodes through the content distribution platform. The content distribution platform may cache and transmit these materials in batches, but it must not modify facts accepted by the Root platform. A Discovery node must still recheck hashes, proofs, versions, and authorization domains after receipt.

{
  "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"]
  }
}

This example distinguishes the publication fact formed by the Root platform from the transmission task performed by the content distribution platform. Successful distribution only means that the materials arrived; it does not mean that the receiver has completed verification, and it does not grant a Discovery node visibility beyond its authorization domain.

2.4.3 Semantic-Governance Hub

As the semantic-governance hub, the Root platform maintains capability tags and their hierarchy, identifiers, aliases, and versions for tag selection and recommendation during registration, and for semantic indexes and query explanations at Discovery nodes. Semantic governance determines how tags are organized and evolved, but it does not replace resource control proofs or node authorization. A Discovery node may use local indexing and ranking methods on the basis of Root vocabulary, but it must not extend its authorization domain through local tags.

The capability tag tree answers “how can capabilities be described and located with shared vocabulary.” It does not answer “who controls the resource” or “which node can publish the resource.” A Discovery node may map a natural-language task to one or more capability tags and return tag matches and relevance explanations, but the final result must still be associated with the resource DID, version, origin, governance status, and Root proof.

2.4.4 Root Platform Responsibility Boundary

The Root platform is responsible for network-level verification, authorization, publication, and coordination. It does not execute specific business invocations for resource providers, guarantee the business quality of resource endpoints, or automatically grant a caller business permission because a resource has been published. Public websites, metrics, maps, and governance-event displays are observation entry points, not replacements for Root facts. When the Root platform is unavailable, nodes may provide limited existing data under explicit freshness and fallback rules, but they must not fabricate new acceptance, authorization, or publication facts.

2.5 Registrar Service Node

The Registrar node is the admission and submission boundary through which resource providers enter OAN. It may provide forms, SDKs, or Skills, check DID syntax, resource types, required fields, capability tags, endpoints, hashes, and control proofs, and package qualified requests into signed submissions to the Root platform. A registration VC or registration result issued by the Registrar node proves only that it processed the relevant registration fact. It cannot replace a Root proof or allow the Registrar node to expand the resource’s network visibility by itself.

The Registrar node must perform restricted actions using its own valid node authorization and permitted authorization domain, and must retain enough request IDs, verification results, error reasons, and submission status for auditing. It may reject malformed requests or requests with unclear control. When the Root platform rejects a request or asynchronous publication fails, the Registrar node must return the actual status and must not display local admission as network-wide publication completion.

From the evidence-chain perspective, the Registrar node produces at least three distinguishable results: whether the request arrived and passed local validation, whether it was submitted to the Root platform, and whether the Root platform accepted and published it. When troubleshooting registration, a client or operator should query these levels using the request ID, resource DID, version, and submission status rather than relying only on a page saying “submission successful.”

2.6 Discovery Service Node

The Discovery node is the authorized read side of Root-published content. It obtains candidate ResourcePackages from the content distribution platform or Root notifications, verifies Root proofs, hashes, versions, and governance status, filters resources according to its authorization domain, and builds structured and semantic indexes. Its responses to users, applications, and agents are locally processed discovery responses. It must therefore retain resource origin, version, freshness, and verification status, and must assume responsibility for response content when signed responses are supported.

A Discovery node may optimize query performance, ranking, and semantic matching, and may retain an older snapshot for limited fallback display. It must not modify Root publication facts, add unauthorized resources to a trusted index, or use local ranking to override revocation, suspension, or version status. Search results are inputs to the caller’s subsequent verification, not automatic invocation permission.

{
  "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
}

The score, tag match, and explanation in a discovery response belong to the index or query layer. resourceDid, version, source, and freshness support subsequent verification. Even a high relevance score cannot bypass DID Document, Root proof, governance-status, or endpoint checks.

2.7 Content Distribution Platform

The content distribution platform carries ResourcePackages, DID Documents, metadata, proofs, hashes, and synchronization materials that have been verified by the Root platform and permitted for propagation. Its goal is to improve the reachability, batch efficiency, and caching capability of node synchronization. It is a data-plane component, not an authority for governance or identity trust. Recipients must reverify distributed content using the Root proof, hashes, and status. The distribution layer may be operated by the same organization as the Root platform or by independent infrastructure, but that deployment relationship must not change the protocol responsibility boundaries.

2.8 Off-Chain Trust Indexer

The off-chain trust indexer is the read-side projection component for on-chain governance facts. It reads governance events such as node authorization, authorization-domain changes, suspension, restoration, and revocation, and writes authorization status into a queryable model for the Root platform, Registrar nodes, and Discovery nodes according to sequences or cursors. Projection results may be delayed or affected by faults. They must retain the last processed position, event source, projection time, and error status. Runtime code must not equate “seen by the indexer” with the final on-chain fact.

When the Root platform or another executing node uses indexer status, it must define expiration, staleness, and fallback behavior. For actions that must prevent an unauthorized node from continuing, the node should fail closed when status cannot be confirmed or exceeds the allowed freshness. Public statistics or historical displays may show delay and old data, but must not change the actual authorization decision.

{
  "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"
}

This projection is an off-chain read model of on-chain governance events and must retain the event sequence and projection time. If the sequence is interrupted, the status is stale, or the source cannot be verified, the executing node should follow the failure policy for sensitive actions rather than treating the last successful projection as permanent authorization.

2.9 Caller, User, Application, and Agent

The user is the person expressing an intent to register, discover, or use a business capability. The browser or another client is the tool that carries the Local Identity and requests. The application is software that calls OAN interfaces and executes local policies. The user agent is an agent that can query and initiate calls on behalf of the user. These roles may appear together in one flow, but their sources of authority differ: the user controls local keys, the client protects private materials, the application verifies network evidence, and the user agent selects resources based on the verification result.

During discovery, the caller is a relying party. During an actual business invocation, it must also handle request signing, credential presentation, replay protection, and local authorization policies. It must not trust only search ranking, a website display name, or a resource description forwarded by a third party. Before connecting, it should verify the DID, VC, Root proof, governance status, version, and endpoint declaration, and decide whether to continue according to the concrete business risk.

2.10 Governance Authority and Authorization Domain

The governance authority decides whether an infrastructure node enters, remains within, or exits OAN’s trusted operating scope. An authorization domain is the capability or resource scope that a node is permitted to process. It may constrain which resources a Registrar node accepts, which resources a Discovery node synchronizes and returns, and which network actions a node may perform. An authorization domain is not a resource control relationship or a capability tag: tags describe and match capabilities, while authorization domains limit permissions and visibility.

Governance status may be formed jointly from on-chain events, Root runtime status, and node authorization materials, but an executing node must state the source and priority of each fact. A historical authorization VC, cached status, or manually maintained display must not override a current revocation or suspension. When authorization-domain changes propagate with delay, the node should follow the prescribed freshness and fail-closed rules for sensitive actions.

An authorization domain can be understood as “resource scope + action scope + observation scope.” Resource scope limits which resources or resource types a node can process. Action scope limits whether the node can register, synchronize, index, or perform management actions. Observation scope limits which callers or network areas may receive results. These three scopes jointly determine effective node permissions; a broad active status cannot replace them.

2.11 Trust Boundaries and Responsibility Matrix

The OAN responsibility matrix should be established along four dimensions: producing facts, verifying facts, storing status, and making external statements. The resource controller produces resource identity and control proof. The Registrar node verifies admission materials and submits registration. The Root platform verifies node authorization and resource versions and forms publication facts. The content distribution platform transfers verified materials. The Discovery node verifies and indexes them within its authorization domain. The off-chain trust indexer projects governance status. The caller verifies candidate resources and executes local invocation policy. Every action should point to a corresponding signature, credential, hash, governance event, interface response, or persistent record.

2.11.1 Resource Controller and Resource Provider

The resource controller is responsible for the resource DID, control key, and update authorization. The resource provider is responsible for capability descriptions, resource content, endpoints, and business availability. They may be the same subject or may be separated through an explicit delegation or operating relationship. The Registrar node and Root platform should determine resource-operation permission only through a verifiable control proof. They must not infer that the provider controls the resource DID merely because it submitted a service address or successfully logged in.

2.11.2 Registrar Node, Root Platform, and Discovery Node

The HTTP interfaces of these three roles correspond to different trust boundaries. The resource publisher submits a ResourceRegistrationSubmission to the Registrar node. The Registrar node submits a ResourceVerifyAndPublishRequest containing registrarDid and upstreamAuth to the Root platform. The Discovery node returns a ResourceDiscoveryResponse to the caller. The first interface receives resource-control materials, the second proves that an authorized node is representing the network, and the third provides local-index candidates. Interface reachability, request parseability, and candidate visibility are different facts and cannot replace one another across roles.

The Registrar node accepts, validates, and submits registrations. The Root platform verifies node authorization and resources, performs trusted publication, and coordinates distribution. The Discovery node synchronizes, verifies, filters by authorization domain, and serves queries over published materials. A Registrar result cannot replace a Root publication fact, and a Discovery result cannot rewrite Root status. Interfaces, proofs, and states among the three must remain traceable.

2.11.3 Caller and Verifier

The caller may be a user, application, or user agent. It submits queries, receives candidate resources, and decides whether to establish a business connection. The verifier may be the caller itself, an SDK, or a verification component trusted by the caller. It checks DIDs, signatures, VCs, Root proofs, governance status, versions, endpoints, and invocation policies. A verification component may provide a verification result, but it must not directly execute a high-risk business action without the caller’s policy authorization.

2.11.4 Responsibility for Key Actions

Resource creation and updates belong to the resource controller. Registration acceptance and registration credentials belong to the Registrar node. Root acceptance and trusted publication belong to the Root platform. Material transfer belongs to the content distribution platform. Authorization-domain indexing and discovery responses belong to the Discovery node. Governance-event projection belongs to the off-chain trust indexer. Final business invocation authorization belongs to the resource endpoint and the caller’s local policy. A public website, statistics interface, or manually maintained event table is an observation and presentation layer and cannot serve as protocol authority for these key actions.

The boundaries among roles can be checked by asking who produces facts, who verifies facts, who stores status, and who makes external statements. “Responsible” in the table below means protocol responsibility; it does not mean responsibility for all business content or runtime environments.

When a key action occurs, the corresponding signature, credential, hash, governance event, synchronization cursor, or interface response should be locatable. If a result has only “a node returned success” as evidence and its source and verification scope cannot be explained, it can be treated only as an observation of runtime status, not as a cross-role trust proof.

When troubleshooting a resource or node, establish the evidence chain in this order: identify the object and version, confirm the control proof or node authorization, check the publication fact and governance status, and finally inspect the discovery index, endpoint, and caller policy. This order applies to registration failures, stale discovery results, and propagation after node-authorization revocation. If any step lacks a source or cannot be verified, limit the conclusion to the observable scope.

References