Authorization Domains and Governance

Authorized domains are not only resource metadata. They are also part of infrastructure governance. A Registrar can be approved for some domains and not others. A Discovery node can expose resources for some domains and not others. Governance should make that scope explicit before Root enforces it.

This is how OAN turns domain scope from a label into an operational boundary.

That boundary is visible in both directions. Infrastructure nodes receive domain scope through governance. Resources declare domain scope through their DID Document and package material. Root checks that the resource scope is covered by the Registrar, and Discovery checks that its own scope covers what it exposes.

Domain Scope Through the Lifecycle

This makes scope visible at every stage. It also lets third-party nodes specialize without claiming universal authority.

The lifecycle also creates useful accountability. If a node requested one domain set, governance approved another, and Root recognizes a third, that mismatch should be detectable. Public documentation and status surfaces should make the approved scope clear enough to review.

Node Applications Should Include Domains

A node application should include requested domains. That request gives reviewers something concrete to evaluate. A team applying to operate a Registrar for developer tooling should not receive implicit authority over every healthcare or financial resource. A Discovery operator focused on a domain community can request the scope it intends to serve.

The application material can include endpoint information, DID identity, operator description, domain rationale, and operational commitments. The exact public process may evolve, but domain scope should not be an afterthought.

For applicants, the best domain request is specific and defensible. A team should explain why it is qualified to operate in the requested scope, what kind of resources it expects to handle, and whether it seeks Registrar authority, Discovery authority, or both.

Approved Scope Must Be Enforced

Once governance approves a role and domain list, Root and services should enforce it. A Registrar with partial domain coverage should reject out-of-scope resources. A Discovery node with partial coverage should not expose out-of-scope packages. Root distribution can also use domain scope to decide which Discovery nodes receive package notifications.

This is stronger than merely displaying a node’s specialty. It affects whether actions are accepted.

Because enforcement crosses modules, tests should include negative cases. A resource in an excluded domain should fail at an under-scoped Registrar and should not appear through an under-scoped Discovery node. Resources in covered domains should continue to register and appear normally.

Parent, Child, Wildcard, Empty

The same domain semantics apply in governance:

• parent domain covers its children;
• child domain covers only that subdomain unless another rule covers more;
• ["*"] means all-domain authority;
• [] means no domain authority.

Large domain lists are sometimes necessary when a node covers almost everything except a few narrow areas. The contract and tooling should support realistic domain lists rather than forcing broad wildcard use.

This is why implementation limits should reflect the real domain tree. If the system supports many parent and child domains, governance contracts, validation libraries, config files, and UI controls must allow realistic partial-coverage lists. Otherwise operators will be pushed toward overbroad wildcard authorization.

Resource Domains Must Fit Node Domains

Resource authorizedDomains are checked against node scope. If a resource declares a domain outside the Registrar’s authorization, registration should fail. If a Discovery node does not cover a resource’s domain, the resource should not be visible through that Discovery node.

This is why authorized domains are not simply a UX field. They are part of a cross-module enforcement path: DID material, Registrar validation, Root acceptance, package distribution, Discovery indexing, SDK validation, and tests all need consistent semantics.

Domain governance will likely evolve over time. Adding, renaming, splitting, or merging domains affects registered resources and infrastructure scope. Production governance should keep domain versions, migration guidance, and compatibility rules so old packages and new policies can be interpreted safely.

Further Reading

• Resource registration and discovery guide
• OAN yellow paper
• OAN trial network repository