Node Authorization
Node authorization defines what an infrastructure node is allowed to do. A Registrar may be authorized to onboard resources within certain domains. A Discovery node may be authorized to expose resources within certain domains. Future issuer roles may have their own credential scopes. The role and the domain list matter together.
OAN’s node authorization model exists so that third-party participation can grow without turning trust into a free-for-all.
This is a core difference between “anyone can run compatible software” and “anyone is automatically trusted.” OAN can encourage independent deployment while still requiring explicit authorization before a node participates in the governed publication or Discovery path.
Effective Authorization
Effective authorization requires more than an endpoint:
| Required piece | Why it matters |
|---|---|
| Node DID identity | Identifies the infrastructure subject. |
| Role | Registrar, Discovery, or another governed role. |
| Governance status | Shows whether the node is authorized, suspended, recovered, or revoked. |
| Domain scope | Defines which resource domains the node may handle. |
| Root-recognized state | Lets Root enforce the current authorization at runtime. |
If any required piece is missing, authoritative actions should fail closed.
Failing closed is important because node authorization errors are high-impact. If a Registrar is accepted without current scope, it may publish resources it should not onboard. If a Discovery node serves outside scope, users may see resources through an authority path they did not choose.
Registrar Scope
A Registrar should accept resource submissions only when the resource authorizedDomains are covered by the Registrar’s own scope. If the Registrar covers technology, it can onboard resources in that parent domain and its children. If it lacks sports_and_fitness.sports_technology, it should reject resources that require that subdomain.
This rule is enforced both for correctness and for ecosystem trust. A specialized Registrar should not become an all-domain Registrar by accident.
Registrar scope also affects user choice. A publisher should choose a Registrar whose scope matches the resource. A domain-focused Registrar may provide better review for its domain, while an official broad-scope Registrar may be best for general early adoption.
Discovery Scope
A Discovery node should expose only resources covered by its own authorized domains. Root distribution can help by notifying only matching Discovery nodes, but Discovery should still apply local filtering. This protects users from seeing resources through a node that is not authorized for that domain.
Discovery scope also explains why two Discovery nodes may return different results for the same query. The difference may be intended if their domain authorizations differ.
This makes Discovery more like a governed view than a universal mirror. A finance-oriented Discovery node, a technology-oriented Discovery node, and a full-scope official Discovery node can all be valid while showing different result sets.
Wildcard and Empty Lists
["*"] means all-domain authorization. It should be explicit and carefully granted. [] means no domain authorization. It should not be treated as “unknown” or “all by default.” Parent-domain and child-domain coverage must be resolved consistently by Registrar, Root, Discovery, SDKs, tests, and website forms.
These details sound small, but they prevent serious authorization ambiguity.
Domain matching rules must be implemented consistently across contracts, governance tools, Root, Registrar, Discovery, SDKs, website forms, and tests. A mismatch in one layer can cause resources to be accepted in one place and rejected or hidden in another.
Authorization Is Revocable
A node’s current status matters. A revoked Registrar should not keep submitting packages because an old credential exists. A suspended Discovery node should not be treated as current merely because its endpoint is reachable. Recovery should be explicit, not assumed.
The system should make these states observable enough for operators and clients to diagnose failures.
A good node status surface should therefore show role, DID, current status, authorized domains, freshness of governance state, and endpoint reachability separately. Combining them into one “up” flag hides the most important trust information.