Choose Authorized Domains
Choosing authorized domains is one of the most important parts of registration. The field does not describe what words should match in search. It describes the governance scope under which the resource is published and later exposed by Discovery nodes.
A good domain choice is honest, canonical, and no broader than needed. It should help Registrars, Root, Discovery nodes, SDKs, and users interpret the resource consistently.
Think of domains as delegated publication scope. They are not a popularity category and not a search-engine trick. They decide which Registrar may onboard the resource and which Discovery node may expose it. That is why OAN treats them more strictly than ordinary labels.
What You Are Choosing
authorizedDomains is a list. The list can be empty, wildcard, a parent domain, a child domain, or a mixture that follows the current domain rules.
| Pattern | Meaning | Use with care |
|---|---|---|
[] |
No domain authorization. | Usually not useful for normal scoped publication. |
["*"] |
All domains. | Appropriate only when full-scope authorization is intended. |
["technology"] |
Parent-domain coverage. | Good for broad technology resources. |
["sports_and_fitness.sports_technology"] |
Specific subdomain. | Good for narrow specialized resources. |
| Parent plus selected children | Mixed coverage. | Useful when most coverage is broad but some areas are explicit. |
For ordinary resource registration, you should almost never use wildcard unless the workflow explicitly allows and justifies it. Wildcard is mainly meaningful for full-scope infrastructure or exceptional resources.
A parent domain can be useful when the resource legitimately covers the whole parent area. A child domain is better when the resource is specialized. A mixed list is useful when coverage is broad in some areas and narrow in others. The list should express actual coverage rather than the shortest possible text.
Domains Versus Tags
Domains and tags answer different questions.
| Field | Question answered | Example |
|---|---|---|
authorizedDomains |
Where is this resource authorized to be published or exposed? | technology, legal, sports_and_fitness.sports_technology |
capabilityTags |
What can this resource do? | summarization, contract-review, mcp-server |
A resource can have a capability tag that sounds like a domain, but the tag does not grant scope. A finance-analysis tag helps matching. A finance authorized domain affects whether the Registrar can onboard it and whether Discovery can expose it.
This distinction is especially important for semantic search. A high semantic score for a finance query does not make a resource finance-authorized. Conversely, a resource may be authorized in a domain but still rank poorly if its description and tags do not explain its capability clearly.
Choose the Narrowest Honest Scope
If your resource clearly belongs to one subdomain, choose that subdomain. If it naturally covers a whole parent area, choose the parent. If it spans several areas, list the relevant domains rather than forcing it into one. Avoid choosing a broad domain just because it might attract more search traffic; overbroad domains weaken trust and may be rejected by Registrar policy.
For example, a general code-review skill may belong under technology. A sports training analytics tool may belong under a sports-specific subdomain. A legal contract review tool should not use technology only because it is implemented as software; its resource purpose is legal-domain work.
When a resource spans multiple domains, be explicit. A healthcare scheduling API and a general calendar API are not the same resource from a governance perspective. A document summarization skill may be general technology if it is domain-neutral, but a contract-risk analyzer should use a legal scope even though it uses language technology internally.
Registrar Coverage Matters
The Registrar you use must be authorized for the domains in your resource. If the Registrar lacks coverage, registration should fail. This is not a nuisance; it is the domain authorization model doing its job.
Official services may have broad or full-scope coverage. Third-party Registrars may be specialized. A healthcare-focused Registrar, for example, might be appropriate for healthcare resources but not for unrelated media tools. SDKs and skills should surface domain mismatch errors clearly.
This is one reason third-party nodes can be valuable. A specialized Registrar can apply domain-specific onboarding expectations while still publishing resources through the shared OAN trust path. The specialization happens in review and policy; compatibility comes from the common identity, package, and proof model.
When the Registrar Helps Choose
A Registrar or AI-assisted skill may recommend domains after reading your description, manifest, schema, or examples. This can be useful, especially for new users. But the recommendation should not be hidden. You should be able to inspect the final domain list before submission.
The final DID Document and package material should carry the resulting authorizedDomains, whether the user selected them manually, the Registrar filled a default, or a tool recommended a subset.
If a Registrar fills domains automatically, the resulting domains should be shown to the publisher before or immediately after submission. Hidden domain assignment makes later Discovery behavior confusing. A user should be able to understand why a resource appears in one Discovery node but not another.
How Discovery Uses Domains
Discovery nodes also have authorized-domain scope. A resource registered in a domain should be visible only through Discovery nodes that cover that domain. If a Discovery node excludes a narrow subdomain, resources in that subdomain should not appear there, even if the semantic query matches well.
This makes domain scope visible in practice. If a resource does not appear in one Discovery node but does appear in another, the reason may be node authorization rather than ranking.
For testing, a narrow excluded domain is useful because it proves that authorization is actually enforced. A Registrar without that domain should reject registration, and a Discovery node without that domain should not expose the resource. Other resources in covered domains should continue to work normally.