White Paper
The OAN white paper is the best starting point for the broad argument. It explains why the agent-resource ecosystem needs trusted identity, governed infrastructure, registration, publication, Discovery, and verification as one connected system.
If the yellow paper is the technical map, the white paper is the strategic map. It explains the problem OAN is trying to solve and why a simple directory or marketplace is not enough for agentic infrastructure.
The white paper is also useful for explaining OAN to people who are not yet deep in DID, VC, Root proof, or Discovery internals. It frames the ecosystem problem first: agent resources will be created by many parties, operated under different policies, and consumed by agents that need more than a plain URL.
What the White Paper Explains
The white paper frames OAN around a future where agents, tools, skills, MCP servers, APIs, and services need to find and use each other across organizational boundaries. In that world, raw connectivity is not enough. Agents need to know what a resource is, who controls it, whether it was published through a governed path, what scope it belongs to, and how to verify it before use.
The paper therefore treats OAN as open infrastructure rather than a single application. It emphasizes identity, governance, resource registration, discovery, verification, and ecosystem participation.
One of its central claims is that the agent ecosystem needs compatibility before replacement. OAN should work with existing agent protocols, MCP servers, APIs, skills, enterprise platforms, and future resource types. The trust layer should make those resources easier to discover and verify without forcing them into one runtime.
Key Ideas
The most important ideas are:
- resource-first modeling rather than agent-only directories;
did:oanidentity for portable resource subjects;- governed Registrar and Discovery infrastructure;
- Root-backed publication evidence;
- semantic and structured Discovery over verified resources;
- verification before native protocol invocation;
- staged adoption through official services, SDKs, skills, and third-party nodes.
These ideas make OAN complementary to MCP, A2A-style protocols, APIs, DID/VC systems, and domain-specific agent frameworks. OAN does not try to replace them. It gives them a trust-governed discovery layer.
The paper also explains why OAN is resource-first. If a system only models agents, it may struggle to represent skills, APIs, MCP servers, datasets, workflows, prompts, or future agent-facing assets. Resource-first modeling gives OAN room to support the ecosystem as it expands.
Who Should Read It
Product leaders should read it to understand why OAN is an ecosystem layer, not only a technical component. Researchers should read it to see the problem framing. Standards collaborators should read it to understand the intended scope before reading drafts. Developers should read it when they want to explain why OAN’s trust objects exist.
If you are only trying to register one resource today, Docs and the registration guide may be faster. If you are deciding whether OAN’s direction matters, the white paper is the right place.
Policy and ecosystem readers should pay special attention to the governance sections. They explain why operator legitimacy, current status, and domain scope matter for open multi-operator infrastructure.
Relation to Implementation
The white paper’s concepts already map to concrete implementation surfaces: official website pages, TypeScript SDK, community skill, Root, Registrar, Discovery, authorized domains, package proof, semantic Discovery direction, and trial-network material.
This implementation connection is important. The paper is not meant to sit apart from the code. It provides the rationale for why the system is built around resource identity and governed discovery.
When reviewing the implementation, use the white paper as a question list. Does the system really support staged adoption? Are resources modeled beyond agents? Can users publish and discover through official services? Can third-party participation be explained without private operational knowledge? These are practical tests of the paper’s argument.