This chapter explains why OpenAgenet (OAN) needs trusted resource infrastructure for the Internet of Agents (IoA), and how the system goals are realized through design principles covering identity, registration, trusted publication, content distribution, discovery, governance, and pre-call verification. The focus is not on listing isolated product features, but on explaining how these mechanisms work together to address unidentifiable resources, unverifiable origins, untraceable versions, undiscoverable capabilities, and insufficient information for decisions before invocation. It also clarifies the relationship among open interoperability, minimum trust, traceable evidence, and separation of responsibilities.

1.1 OAN and the Internet of Agents

OpenAgenet (OAN) provides resource interconnection infrastructure for the Internet of Agents (IoA). It is not primarily concerned with the conversational capability of a particular agent. Instead, it enables Agent Services, Skills, MCP Servers, and Tool APIs to have stable identities, verifiable control relationships, describable capabilities, traceable publication status, and reusable discovery entry points. OAN treats these objects as network resources, allowing them to participate in cross-node interconnection through a unified did:oan, resource metadata, registration protocol, and discovery protocol rather than through a manually maintained directory on a single platform.

The core result of OAN is to connect “what capability exists” with “whether that capability can be trusted.” The resource provider prepares a DID Document and resource description locally. After admission by a Registrar node, the Root platform verifies the Registrar node’s authorization, the resource control proof, metadata, and version information. The content distribution platform then makes the materials available to authorized Discovery nodes. After receiving search results, the caller still performs pre-call verification using the DID, VC, Root proof, governance status, and endpoint information. This organization preserves differences among resource types and business protocols while providing common foundations for resource discovery, composition, and subsequent governance.

From the user’s perspective, the goal of OAN can be summarized as four consecutive outcomes: the resource can be identified, its origin can be verified, it can be discovered within an authorized scope, and the caller can obtain sufficient grounds for judgment before connecting. These outcomes are jointly supported by identity materials, registration and publication evidence, discovery indexes, and caller-side verification. None of them can be replaced by a single page, directory, or search score.

1.2 Problems Addressed by OAN

When Agent Services, Skills, MCP Servers, and Tool APIs are distributed across different teams, code repositories, or runtime environments, resource providers often have to describe their locations and capabilities through webpages, documentation, configuration files, or manual communication. Such approaches make it difficult to express the controller, version, endpoint, dependencies, applicable protocols, and usage conditions in a stable way. They also make it difficult to determine whether a search result represents the current version, a historical version, or a resource that has already been suspended. As the number of resources grows, directory maintenance, duplicate registration, version updates, and cross-organization collaboration create continuing manual costs.

For callers, name or text matching can answer only “possibly relevant.” It cannot by itself answer whether the resource is genuine, whether it was published by an authorized node, whether it remains valid, or whether it can be used within the current authorization domain. If registration, publication, discovery, and invocation do not have clear responsibility boundaries, an intermediate directory may introduce unverified resources into results or continue displaying resources that have been revoked, replaced, or whose origins are unknown. OAN addresses these problems separately through DID control proofs, node authorization, Root publication, ResourcePackage hashes, authorization-domain filtering by Discovery nodes, and pre-call verification. It does not use a single platform label as a substitute for every trust judgment.

The problems can be mapped to OAN’s handling as follows: dispersed resource endpoints first require common resource identities and service descriptions; difficult origin verification requires control proofs, registration VCs, and Root-verified ResourcePackages; opaque version status requires binding versions, hashes, and lifecycle states to resource records; and difficult cross-organization discovery requires Discovery nodes, authorization domains, capability tags, and semantic queries to work together. OAN therefore does not merely create another resource list. It organizes resource registration, origin verification, network propagation, and pre-call judgment into a traceable process.

{
  "problem": "The same task requires finding reusable capabilities across multiple teams and runtime environments",
  "resource": {
    "type": "skill",
    "did": "did:oan:example",
    "version": "1.0.0",
    "capabilities": ["repository-search", "project-structure-summary"]
  },
  "required_evidence": ["DID document", "control proof", "publication status", "endpoint policy"]
}

The example only represents a minimal shape for problem analysis and resource description. It is not a fixed production schema or a registration request that can be submitted directly. Actual fields, proofs, and validation rules are defined by the resource model, the DID method, the registration protocol, and the data schemas in the appendices.

1.3 Resource-First Interconnection Model

“Resource first” means that the primary objects of OAN registration, publication, distribution, and discovery are resource versions with a resource type, resource DID, description, capability tags, use cases, endpoints, versions, and states, rather than agent instances that must run on a unified platform. An Agent Service may provide a session- or task-oriented service; a Skill may serve as a reusable capability unit; an MCP Server may expose a collection of tools; and a Tool API may provide a specific interface. They differ in business form, but all enter the network through unified resource identity and metadata.

The unified model standardizes common properties without erasing type differences. The resource type determines required fields, endpoint shape, protocol bindings, invocation constraints, and version handling. The resource DID identifies a specific controllable object; the ResourcePackage binds the representation and proofs for a version; and capability tags and use cases support structured and semantic discovery. Resources may express dependencies and composition through DIDs, versions, or package hashes. However, “discoverable” only means that a resource satisfies directory and trust conditions; it does not automatically mean that every business invocation in a composition relationship is authorized.

The resource-first model can be understood through an abstract object: identity fields answer “which resource is this,” description fields answer “what can it do,” version and hash fields answer “which version of the material is being viewed,” endpoint and protocol fields answer “how can it be integrated,” and proof and status fields answer “why may it be treated as a candidate resource.” Different resource types may share these common fields, but this does not turn a Skill into an Agent Service, an MCP Server into a Tool API, or a discovery result into business invocation authorization.

{
  "resourceType": "skill",
  "resourceDid": "did:oan:example",
  "version": "1.0.0",
  "description": "Search a code repository and summarize the project structure",
  "capabilities": ["code-search", "structure-summary"],
  "protocol": "skill",
  "endpoint": "https://example.invalid/skill",
  "status": "published"
}

This is an example object for explaining the resource-first model. The formal fields, endpoint format, hashes, and signature materials for each resource type are defined in the corresponding chapters.

1.4 Trusted Registration, Publication, Discovery, and Invocation

The OAN trust path is not a single action completed by one request. It is a continuous process performed jointly by the resource controller, Registrar node, Root platform, content distribution platform, Discovery node, and caller. The resource controller first generates or imports identity materials locally and prepares the resource DID Document, resource metadata, capability tags, endpoint, and control proof. The Registrar node performs admission checks and submits upstream. The Root platform verifies authorization, signatures, hashes, versions, and governance conditions. Downstream nodes only propagate and index trusted facts that have already been formed. The caller independently verifies the relevant evidence before establishing a business connection.

For a resource version, readers can determine “how far the process has progressed” in this order:

1. Whether the local materials have been generated and the controller can use the corresponding private key to create the proof;
2. Whether the Registrar node has accepted the request and returned the registration result;
3. Whether the Root platform has formed the acceptance and trusted-publication facts for the version;
4. Whether the content distribution platform and Discovery node have completed validation, synchronization, and authorization-domain filtering;
5. Whether the caller has completed checks of the DID, VC, version, status, endpoint, and business policy.

Any failed step should retain a locatable status or error so that readers can determine whether the cause is a material problem, a node-authorization problem, propagation delay, an indexing problem, or a caller-side policy rejection.

1.4.1 Resource Registration and Control Proofs

Resource registration begins when the resource provider generates a resource version locally. The client should collect the name, description, capability tags, use cases, protocol bindings, endpoint, version, and dependencies according to the resource type, and establish a verifiable relationship among the resource DID, control key, public key, and DID Document. The material submitted to a Registrar node should prove that the requester controls the resource DID. The Registrar node may validate formats, fields, tags, endpoints, and policies, but its acceptance does not mean that the Root platform has accepted the resource.

A control proof answers “who can represent this resource in a registration request.” It cannot replace judgments about resource quality, endpoint availability, or invocation permissions. On failure, the service should return locatable field or proof errors while keeping the local draft and key materials outside the service’s control. A second submission for the same DID should distinguish a duplicate request for the same version from an authorized update to a new version, and dispatch them respectively to idempotency handling and version-update rules.

1.4.2 Root Verification and Trusted Publication

After receiving a signed upstream request from a Registrar node, the Root platform should first verify request freshness, request-body hash, nonce, and the Registrar node’s valid authorization. It then verifies the resource DID Document, resource control proof, resource type, metadata hash, ResourcePackage, and version-transition conditions. Only when these facts are consistent and satisfy governance and publication policies does the Root platform form an acceptance record and Root-verified ResourcePackage for the resource version. The Root acceptance record should bind the DID, version, representation hash, authorization domain, status, time, or sequence information so that downstream nodes do not have to determine the origin from readable text alone.

After successful Root verification, publication normally proceeds asynchronously through persistent tasks, messages, or synchronization cursors. The resource provider may receive a registration result from the Registrar node, but the resource should not be described as discoverable across the network until content distribution, Root publication, and Discovery-node indexing are complete. Rejection, isolation, retry, and republishing should have observable states; one successful HTTP response must not be used to represent completion of the entire propagation path.

1.4.3 Content Distribution and Discovery-Node Indexing

The content distribution platform carries ResourcePackages, DID Documents, metadata, proofs, and materials required for indexing after the Root platform has verified them. A Discovery node obtains candidate versions from the distribution layer or Root notifications. The Discovery node must recalculate hashes, verify the Root proof and governance status, and filter by its own authorization domain before writing qualified resources into structured and semantic indexes. The distribution layer improves accessibility and synchronization efficiency, but it does not acquire the Root platform’s trust authority.

Distribution and indexing are asynchronous. It is therefore normal for the Root platform to have published a resource while a Discovery node has not yet made it visible, for structured indexing to be complete while semantic indexing is retrying, or for a node to provide only an older snapshot temporarily. Implementations should retain synchronization cursors, version freshness, rejection reasons, and pending tasks so that operators can distinguish not published, not synchronized, validation failure, authorization-domain mismatch, and search-index failure.

1.4.4 Pre-Call Verification and Integration

After obtaining candidate resources from a Discovery node, the caller must not treat search results directly as invocation permission. At a minimum, it should verify the response origin and freshness, the resource DID Document, the resource control relationship, the registration VC or equivalent registration evidence, the Root-verified ResourcePackage, the ResourcePackage hash, the current version, lifecycle status, the Discovery node’s authorization domain, and the target endpoint’s protocol and authentication declarations. For high-risk operations, the actual request should also include a timestamp, nonce, target DID, request-body hash, and signature to prevent replay or replacement of the result.

Successful verification only means that the candidate satisfies the prerequisites of the OAN trust path and the caller’s local policy. Whether the call can ultimately execute still depends on authentication, authorization, business state, and security policy at the resource endpoint. A client should distinguish DID or signature errors, credential-status errors, Root-proof mismatches, expired versions, invalid governance states, authorization-domain mismatches, and endpoint invocation failures rather than reducing every problem to “resource not found.”

1.5 Separation of Resource Control, Node Authorization, and Governance

Resource control is expressed through the control key and control proof associated with the resource DID, answering “who may submit or update the document on behalf of this resource.” Node authorization is expressed through Root authorization materials and their governance status, answering “which Registrar node, Discovery node, or other infrastructure node is qualified to perform a particular network action.” On-chain governance records express governance facts such as changes to node authorization, answering “when an authorization becomes effective, is suspended, restored, or revoked.” A Root proof answers “whether a resource version has passed Root verification and entered the publication path”; it is not a credential of resource ownership.

These three categories of fact should be checked separately. Possession of a resource private key does not give an unauthorized node registration privileges. Possession of an old node authorization VC does not bypass the current governance status. Root publication of a resource does not replace the caller’s judgment about endpoint and business permissions. This separation allows OAN to manage infrastructure authorization without receiving resource-control private keys, while allowing governance status, resource identity, and publication status to be updated independently.

1.6 Federation, Interoperability, and Incremental Adoption

OAN is federated because multiple Registrar nodes and Discovery nodes can operate independently under the same Root trust and publication rules. Registrar nodes can provide resource admission for different organizations, teams, or integration scenarios. Discovery nodes can provide indexes based on authorization domain, network location, or service capability. The Root platform unifies verification and publication facts; it does not require every resource to be stored in one business platform. A third-party node may enter the corresponding operating state only after completing identity, authorization, interface, and conformance checks.

Incremental adoption can begin with one organization or an experimental network: first adopt did:oan resource identity and the registration-discovery flow, then connect existing Agents, MCP Servers, or Tool APIs, and later add multiple nodes, authorization domains, semantic tags, and governance read models. Interoperability means preserving OAN’s boundaries for identity, proofs, versions, and status while connecting existing business systems through protocol adapters. It does not require a business system to become a unified runtime immediately.

An organization can proceed in the order “make visible first, make trusted next, federate later.” In the first phase, it organizes existing resources and establishes resource identities and descriptions. In the second, it integrates a Registrar node and forms control proofs, registration VCs, and Root publication evidence. In the third, it deploys or integrates Discovery nodes and enables structured and semantic queries. In the fourth, it adds nodes from multiple organizations, authorization domains, governance synchronization, and protocol mappings. Existing business endpoints can remain in place at every phase. OAN mainly provides resource identity, registration, publication, discovery, and pre-call judgment; it does not require an immediate replacement of existing business systems.

Resource organization and identity establishment
    -> Registration and trusted publication
    -> Discovery-node indexing
    -> Multi-node integration and authorization-domain governance
    -> Mapping to existing Agent, MCP, and Tool/API protocols

1.7 Control Plane, Data Plane, and Semantic Plane

The control plane maintains facts that determine whether a resource can enter the network, propagate, or be treated as valid, including identity, authorization, version, lifecycle, and publication status. The data plane carries DID Documents, ResourcePackages, metadata, proofs, and distribution content for clients. The semantic plane maintains capability trees, tag hierarchies, aliases, descriptions, and query explanations for registration recommendations and semantic matching during discovery. The Root platform performs three bounded hub roles at the same time, but facts maintained by the three planes cannot substitute for one another.

The three planes have a clear dependency order. Semantic matching can help a Discovery node find relevant resources, and data distribution can allow a node to obtain a ResourcePackage. However, a candidate has trusted-discoverable status only after the control plane confirms that the resource version has been accepted and published and is within the Discovery node’s authorization domain. Semantic relevance, endpoint accessibility, or interface presentation cannot grant DID control, node authorization, or governance qualification in reverse.

1.8 Public Visibility, Discoverability, and Invocation Authorization

Registration completed means that a Registrar node has accepted or processed the request. Associated evidence normally includes the registration response, registration VC, or registration record. Root publication completed means that the Root platform has accepted a resource version and formed the corresponding publication proof. Discovery-node indexing completed means that an authorized Discovery node has validated the ResourcePackage and written it into its local index. Visibility within an authorization domain means that the node allows the resource to be returned to a particular query caller according to its authorization scope. Invocation permission is the caller’s local decision after verifying OAN evidence together with endpoint authentication and its own business policy.

These states may advance in sequence, or may temporarily diverge because of asynchronous tasks or faults. An older snapshot may continue to provide a limited set of verified historical results when refresh fails, but it must carry freshness or status information. Resource suspension, revocation, version replacement, and node-authorization changes should affect discovery and pre-call verification after the corresponding state has propagated. Any public portal, statistics page, or cache is only an observation interface; it cannot replace the Root acceptance record, governance status, or signature verification as a trust source.

The following diagram compresses the chapter’s goals into a checkable resource-version flow. Each arrow represents the transfer of a fact or material to the next stage. It does not mean that the previous stage automatically grants authority for the next stage. Asynchronous distribution and indexing may create time differences, and the caller must still verify the result before the final connection.

Discoverable does not mean callable. A Discovery node returns candidate resources, but the caller must still make the final decision based on its permissions, endpoint authentication, resource status, and business risk.

The design principles in this chapter can be reviewed through three acceptance questions: Does the resource have a verifiable identity? Does publication have traceable evidence? Can the discovery result carry enough origin and status information to support pre-call judgment? If any answer depends only on page text or name matching, the trusted interconnection process is incomplete.

References