Trusted Resource

A trusted resource is the thing OAN helps the ecosystem publish, find, and verify. It may be an Agent Service, a Skill, an MCP Server, or a Tool/API endpoint. The common point is not that all of them run the same way. The common point is that each one can be represented by stable identity, structured metadata, package facts, and Root-verifiable publication evidence.

This is one of OAN’s most important design choices. OAN is not only a directory of agents. It is infrastructure for agent-facing resources. That difference matters because the agent economy is already heterogeneous: users install skills, connect to MCP servers, call APIs, invoke hosted agent services, and combine all of them inside workflows. A trust layer that only knows how to describe one kind of “agent” would be too narrow.

Four Initial Resource Forms

OAN currently treats four forms as first-class discoverable resources.

These forms share one registration and discovery path, but they do not lose their native character. MCP remains MCP. A skill package remains a skill package. An API remains an API. OAN surrounds them with identity and evidence so that a user, SDK, or agent can ask: “What is this? Who published it? What version was accepted? What domains is it authorized for? How do I verify the result before use?”

What Makes It Trusted

“Trusted” does not mean the resource is guaranteed to be useful, harmless, always online, or best ranked. It means the resource can be evaluated through a verifiable chain. At minimum, a trusted resource should have:

• a did:oan identifier and DID Document;
• resource type and descriptive metadata;
• services, endpoints, artifact links, or protocol bindings appropriate for its type;
• authorizedDomains describing governance scope;
• capabilityTags describing what it can do;
• version and package information;
• hashes binding the accepted material;
• Root proof or package evidence showing what Root accepted;
• lifecycle/status facts that clients can check before use.

That evidence does not remove the need for ordinary product judgment. Users still decide whether a tool is appropriate. Enterprises still apply access controls. Agent runtimes still sandbox or review tool calls. OAN’s contribution is that those decisions can start from a verified resource surface instead of an unstructured endpoint copied from the web.

Resource-First Does Not Mean Protocol-First

OAN does not require every resource to speak an OAN invocation protocol. A Discovery result can point to a native protocol, a package repository, a service endpoint, or a schema. This is deliberate. The network layer should help the ecosystem interoperate without forcing every developer to abandon the tools they already use.

For example, an MCP server can be represented as a resource whose DID Document and metadata describe its MCP endpoint and capability surface. Discovery can index that public surface and return it as a candidate. The client then verifies the evidence and connects through MCP. OAN provides identity and trust; MCP provides the interaction model.

The same is true for Skills. A skill may live in a Git repository and evolve frequently. OAN can publish the skill as a resource with a stable DID, versioned package facts, and discoverable capability metadata. Consumers can discover the skill through OAN, then fetch or install it through the skill ecosystem’s normal mechanism.

Trust Without Central Runtime Control

A trusted resource is not required to run inside an OAN-controlled runtime. This is important for adoption. Product teams can publish existing services. Community users can register resources through official or third-party Registrars. Node operators can run Discovery services without becoming the owner of the resources they expose.

The separation lets OAN scale socially as well as technically. A Registrar helps onboard and check submissions. Root accepts and proves publication. Discovery indexes verified packages. Consumers verify before using. The resource provider continues to operate the actual service or package lifecycle.

Resource Quality Has Two Dimensions

For ecosystem health, a resource needs both trust quality and product quality. Trust quality means identity, hashes, package proof, lifecycle, and authorization scope are correct. Product quality means the resource is useful, well documented, maintained, secure at runtime, and appropriate for the user’s task. OAN directly improves trust quality and indirectly encourages product quality by making metadata and lifecycle visible.

A resource can fail either dimension. A perfectly verifiable API may still be poorly designed. A popular skill may still lack trustworthy package evidence. Mature OAN adoption should make both problems easier to see rather than mixing them together.

Why Resource Granularity Matters

Resource granularity is a product decision. A company might register one broad Agent Service or several narrower Tool/API resources. A skill repository might register one package or multiple domain-specific skills. Too coarse a resource is hard to match and govern; too fine a resource creates noise and lifecycle overhead.

Good OAN resources should be sized around meaningful use and verification. If users would evaluate, install, invoke, update, or revoke something independently, it is often a good candidate to be represented as a separate resource.

Resource Metadata Should Be Useful

Good resource metadata is not marketing filler. It should help a user or agent understand what the resource does, how it should be invoked, what protocol it uses, what domains it belongs to, what examples are representative, and what risks or constraints apply. OAN’s website, SDK, and community skill can help collect this information, but the quality of the resource description still matters.

Useful metadata tends to answer:

• What task does the resource help with?
• Is it a service, skill, MCP server, or API?
• Which protocol or package format should a consumer expect?
• Which domains is it authorized for?
• Which capability tags describe it precisely?
• Which endpoint, artifact, or manifest should be verified before use?
• Which version is being published?

Further Reading

• Resource registration and discovery guide
• OAN TypeScript SDK repository
• OAN white paper