Yellow Paper

The OAN yellow paper is the deeper technical reference. It explains protocol roles, DID objects, infrastructure authorization, ResourcePackage, Root proof, Discovery responses, verification algorithms, security properties, and deployment considerations.

Readers who want to implement or review OAN should eventually read the yellow paper. It is where the trust model becomes precise.

The yellow paper is especially important because many OAN concepts sound simple until they become protocol objects. “Discovery result,” “Root proof,” “resource package,” “current authorization,” and “domain scope” all need exact behavior if independent implementations are expected to interoperate.

OAN trust stack

What the Yellow Paper Covers

The yellow paper covers the architecture behind:

  • did:oan resource identity;
  • Registrar onboarding;
  • Root acceptance and proof;
  • ResourcePackage binding rules;
  • authorized-domain scope;
  • Discovery synchronization and response evidence;
  • governance-derived infrastructure authorization;
  • lifecycle and revocation;
  • client verification before invocation.

It is the reference for why OAN separates identity, package proof, lifecycle, Discovery response, and native protocol use.

It also explains why Root is a trust anchor but not a monolithic runtime. Root accepts package facts and enforces infrastructure authorization. Discovery handles search. Clients verify before use. Native protocols handle the actual session, installation, or API call.

Why It Matters

Without a precise technical model, OAN could be misunderstood as a website, marketplace, search feature, or ordinary API catalog. The yellow paper makes the trust stack explicit. It explains what Root is responsible for, what Discovery is responsible for, what clients must verify, and why current governance state matters.

It also helps prevent implementation drift. SDKs, website forms, service APIs, tests, and public Docs should align with the yellow paper’s trust semantics.

For developers, the yellow paper should guide negative tests as much as happy paths. A robust implementation should reject malformed DID Documents, stale request envelopes, missing hash algorithms, domain mismatches, invalid Root proof, revoked lifecycle states, and unauthorized Discovery exposure.

Authorized Domains

The current OAN implementation has refined authorized domains into a typed and enforced scope model. The yellow paper is the right place to understand how this fits the architecture: resource domains, node domains, Registrar coverage, Discovery visibility, and governance state all need consistent interpretation.

This domain model should not be confused with capability tags or semantic codes. Domains are authorization scope; tags and semantic fields help Discovery.

The yellow paper’s treatment of domains is also useful for governance. It explains why infrastructure nodes and resource packages both need domain semantics, and why parent, child, wildcard, and empty-list behavior must be consistent across modules.

Who Should Read It

Implementers should read it before changing core protocol objects. Security reviewers should read it before evaluating verification. Node operators should read it before applying for infrastructure roles. Researchers should read it to compare OAN with adjacent identity, governance, and discovery systems.

Standards reviewers should read it with interoperability in mind. Which fields need canonical serialization? Which signatures need freshness and replay protection? Which proof references must be portable? Which objects belong in a public profile and which belong to deployment-specific operation? Those questions are where the yellow paper is most useful.

Read the Paper