Authorized Domains

authorizedDomains is OAN’s typed field for domain scope. It is used to describe what a resource, Registrar, or Discovery node is authorized to cover. It is not a capability tag, not a semantic code, not a ranking hint, and not a loose keyword list.

This distinction matters because OAN’s trust model depends on enforcement. If a Registrar is authorized only for certain domains, it should not onboard resources outside those domains. If a Discovery node is authorized only for certain domains, it should not expose resources outside those domains. If a resource declares a domain, Root and downstream nodes should be able to check that the resource was registered and distributed through infrastructure whose scope covers it.

The Field and Its Values

authorizedDomains is a list. The current semantics are intentionally explicit:

The field name should stay the same across subject types because it describes the same kind of data: domain scope. What changes is the role-specific enforcement. A Registrar uses it as onboarding authority. A Discovery node uses it as visibility authority. A resource uses it as publication scope.

Scope, Not Search

The most common mistake is to treat authorized domains like tags. They are not. A resource can have capabilityTags such as contract-review, summarization, or mcp-server. Those tags help retrieval. They do not grant permission. A resource can mention “finance” in a description. That does not authorize it for a finance domain. A semantic search model may infer that a query relates to healthcare. That inference does not override domain scope.

Authorization domains are governance-facing. Capability tags and query text are discovery-facing. Good OAN clients should display both, but they should never mix their meaning.

Node Scope

Registrar and Discovery nodes receive authorized-domain scope through governance and Root authorization. In the implementation model, Root obtains infrastructure authorization state from the governed trust path and applies it when processing submissions and distribution.

For Registrars, the rule is direct: a Registrar must not register a resource whose authorizedDomains are outside the Registrar’s scope. If a resource does not explicitly provide domains, a Registrar may fill them according to policy, often by defaulting to the Registrar’s scope or to a valid subset derived from registration material. The important property is that the resulting resource domains must be covered by the Registrar.

For Discovery nodes, the rule is also direct: Discovery should expose only resources whose domains are covered by its own authorized scope. Root distribution can help by notifying only matching Discovery nodes, and Discovery should still enforce scope locally when indexing or serving results.

Resource Scope

Resource DID material carries authorizedDomains so the resource’s publication scope is typed and visible. This allows website forms, SDK validators, Registrar checks, Root acceptance, Discovery filtering, and client verification to reason about the same field.

For resource publishers, domain choice should be honest and narrow enough to be useful. A skill that helps with sports analytics should not list broad unrelated domains. A general developer tool might belong under a technology parent domain. A cross-domain workflow may list multiple domains if it truly covers them and the registering infrastructure is authorized to onboard them.

Parent and Child Coverage

OAN supports parent-domain coverage and subdomain coverage. Listing a parent such as technology means the subject covers that parent and its child domains. Listing a child such as sports_and_fitness.sports_technology is narrower. This lets operators choose compact lists when they cover whole areas and precise lists when they cover only selected subdomains.

Wildcard scope ["*"] is useful for official or special-purpose nodes, but it should not become the default for every operator. The point of the domain system is to make delegated authority meaningful. A specialized Registrar can be valuable precisely because it is authorized and competent in a narrower area.

Why The List Size Matters

The domain model must support realistic partial coverage. A node may cover most domains but intentionally exclude one sensitive or specialized subdomain. In that case, listing only broad parents may be too coarse, while forcing a wildcard would hide the exclusion. The implementation therefore needs enough capacity and tooling to represent parent-plus-child combinations without making operators choose between overbroad authority and unusable configuration.

This is not a minor schema detail. If the domain list is too small or too hard to manage, operators will drift toward wildcard scope. That would weaken the governance value of authorized domains.

Why This Was Refined

The current model refines an existing OAN authorization-domain idea rather than inventing a decorative field. Earlier designs already needed infrastructure authorization and domain-aware distribution. The refactor makes the concept more regular: typed field, clear empty-list and wildcard semantics, consistent naming in DID material, governance-derived node scope, resource-domain coverage checks, and Discovery filtering.

That means the architecture and trust model do not fundamentally change. Registrar, Root, Discovery, and clients still play the same roles. The improvement is that domain scope is more precise and harder to confuse with tags or free-form metadata.

Practical Examples

A Registrar with ["*"] can onboard a resource in legal, technology, or sports_and_fitness.sports_technology, subject to validation. A Registrar with ["technology"] can onboard resources in the technology parent domain and its subdomains, but not a resource that only belongs to healthcare. A Discovery node with all domains except one narrow subdomain should not expose resources from that excluded subdomain, even if the query text matches them.

This is testable. A good integration test registers a resource in a deliberately excluded domain through two Registrars: one without coverage and one with coverage. The first should fail; the second should succeed. Then Discovery nodes with and without the domain should produce different visibility. That is how the feature proves it is real authorization rather than a label.

Governance And User Experience

Domain scope should be understandable to both operators and resource publishers. Operators need to request and maintain scope. Publishers need to choose honest resource domains. Users need to see enough domain information to understand why a result is visible or absent. Good UX does not hide domain logic; it presents it without making users read a contract.

The website, SDK, and community skill should therefore use the same domain IDs and explanations. If a registration fails because of domain mismatch, the error should identify the missing coverage rather than only saying “invalid request.”

Further Reading

• Resource registration and discovery guide
• did:oan DID Method Specification
• OAN yellow paper