Who Uses OAN?

OAN is not only for one kind of user. It is infrastructure, so different people meet it from different directions. A product builder may care about registering a resource. A user may care about finding and verifying one. A node operator may care about applying for authorization. An enterprise may care about evidence intake. A researcher may care about whether the trust model is coherent.

All of those roles touch the same trust path.

OAN ecosystem map

Resource Builders

Builders publish resources that other agents or users may discover. The resource can be an Agent Service, a Skill, an MCP Server, or a Tool/API endpoint.

For builders, OAN answers practical questions:

How should this resource be identified?
Which resource type should it use?
What endpoint, manifest, or artifact should be referenced?
Which authorized domains describe its governance scope?
Which capability tags help Discovery understand it?
What hashes and version fields allow another party to verify it?
How does the builder update the resource later without losing identity continuity?

Builders do not need to run the whole OAN topology to start. They can use official services, SDKs, website forms, or community skills to publish one resource and observe the lifecycle.

Ecosystem Strategists

Some readers care less about a single registration and more about ecosystem structure. They ask whether an open agent economy can avoid becoming a set of isolated vendor catalogs. For them, OAN offers a coordination layer: shared resource identity, governed infrastructure roles, domain-scoped authority, and public evidence that can be discussed across organizations.

This role matters because the Agent Internet will need policy, interoperability, incentives, and governance as much as APIs. OAN gives strategists a concrete vocabulary for those discussions rather than leaving every platform to define “trusted resource” privately.

Resource Consumers

Consumers use Discovery to find candidates and then verify evidence before use. A consumer may be a human developer, an enterprise platform, a user agent, or another automated system.

For consumers, OAN helps answer:

Is this candidate Root-accepted?
Does the DID Document match the package?
Are the package and metadata hashes valid?
Is the lifecycle current?
Is the resource in the right authorized domain?
Does the Discovery response carry enough provenance?
What native protocol checks remain after OAN verification?

This makes Discovery safer. Results are no longer just ranked text; they are candidates connected to verifiable package facts.

Enterprises

Enterprises can use OAN evidence inside existing controls. OAN does not replace procurement, risk review, IAM, API gateways, audit logs, data policy, or legal approval. It gives those systems better inputs.

An enterprise may start by consuming public Discovery results and verifying them. Later it may register controlled resources, require OAN evidence before internal agents use external tools, or operate a domain-specific Registrar or Discovery node.

The enterprise value is not only technical. OAN creates a vocabulary for trust review: resource DID, Root proof, lifecycle, authorized domains, package hash, endpoint binding, and Discovery provenance.

Node Operators

Node operators run infrastructure such as Registrar or Discovery nodes. This is a different role from publishing a resource. Operators need node identity, endpoint commitments, authorized domains, operational reliability, governance recognition, and Root-issued authorization.

A Registrar operator helps onboard resources within its scope. A Discovery operator exposes verified packages within its scope. Neither should be trusted merely because the server is reachable. Effective authority depends on current governance state and Root authorization.

Trial-network material is the public entry point for understanding this path.

SDK and Skill Developers

OAN needs developer tooling so trust checks do not become manual work. SDK developers expose typed request and response models, baseUrl configuration, endpoint overrides, registration helpers, Discovery queries, lifecycle observation, and verification routines.

Skill developers make OAN usable by AI assistants. A community skill can help a user prepare resource metadata, select domains and tags, run Discovery, and interpret evidence. Official operations skills, by contrast, automate private deployment and governance work. These roles should stay distinct.

Standards and Policy Readers

Standards collaborators, public-sector reviewers, and policy-minded enterprises use OAN differently again. They look for whether the model can be explained without relying on private platform knowledge, whether trust boundaries are clear, and whether implementation evidence supports the claims. For them, the papers, DID method document, IETF drafts, and public Docs should form one coherent review surface.

Researchers and Standards Contributors

Researchers can study OAN as an architecture for resource identity, governance, trusted Discovery, semantic matching, verification, and protocol-neutral invocation. Standards contributors can evaluate how did:oan, ResourcePackage, Discovery response, and authorized-domain semantics might be expressed in broader interoperability language.

This is why the project maintains papers, slides, public specs, and running implementations together. OAN is intended to be reviewable as both research and engineering.

A Shared Path

These roles are different, but they are not disconnected. A builder publishes a resource. Registrar and Root process it. Discovery exposes it. A consumer verifies it. SDKs and skills automate the process. Operators and governance maintain infrastructure authority. Researchers and reviewers inspect whether the whole model is sound.

That shared path is the OAN ecosystem.