Registration Flow

Registration is the way a resource enters OAN’s governed publication path. It is not merely filling in a directory form. A registration request needs enough identity, metadata, package, and domain information for a Registrar and Root to decide whether the resource can become a trusted, discoverable resource.

The Registrar is the user-facing onboarding gate, but Root remains the publication authority. This separation lets OAN support friendly registration tools while preserving a verifiable trust path.

A good way to read the registration flow is to separate convenience from authority. The website, SDK, or community skill may make the form easier to complete. The Registrar may normalize fields, issue clear errors, and help construct a valid package. But the authority to make a resource part of the OAN publication set comes only after the Root-side checks succeed.

What the Publisher Prepares

A resource publisher should prepare material that answers five questions:

The exact fields vary by resource type. A Skill should point to skill package or manifest material. An MCP Server should describe its MCP-facing surface. A Tool/API resource should expose endpoint or schema references. An Agent Service should describe how a caller reaches the service after verification.

The publisher should also think about what must stay stable over time. The DID is the resource identity anchor. The package version can change. Endpoints or artifacts may change only through a new accepted package version. Capability tags and descriptions help Discovery, but they should not be used to smuggle authorization claims. authorizedDomains is the field that carries domain authorization semantics.

Registrar Checks

Registrar checks are both technical and scope-aware. A Registrar should reject malformed DID syntax, unsupported resource type, missing services, invalid hashes, inconsistent package fields, stale or replayed submission material, and domain scope outside its authorization.

Registrar can also help improve input quality. The website or community skill may suggest capability tags, normalize field names, and explain errors in plain language. That UX work is important, but it must not weaken the trust model. A helpful Registrar still has to respect its authorized domains and the resource-type requirements.

For public onboarding, Registrar checks should be strict where trust is involved and helpful where wording is involved. A vague description can be improved. A missing required endpoint can be explained. A domain outside Registrar scope must be rejected. A package hash mismatch must fail. This difference keeps the registration experience approachable without turning the Registrar into a loose approval desk.

Subject Control

OAN needs confidence that the registering party controls the resource identity it is submitting. Depending on the current implementation path, this may involve a subject-control proof bundle, DID key proof, signed request material, or Registrar-verified evidence. Root should not accept a package merely because a Registrar made an unsupported assertion.

This is a subtle but important boundary. Registrar is trusted as an authorized upstream infrastructure node, not as an oracle that can redefine identity. Root verifies the evidence that matters for package acceptance.

Subject control also protects publishers. If a resource DID can be registered without control evidence, someone else could publish a confusing package for a resource name they do not control. The exact proof mechanism can evolve, but the public meaning should remain stable: OAN registration should bind a resource identity to a party that can legitimately speak for that resource.

Registrar to Root

After local checks, Registrar submits Root-bound material in a signed upstream envelope. Root can verify the Registrar identity, request body hash, timestamp, nonce, and package content. If the Registrar is unauthorized, revoked, suspended, outside domain coverage, or using invalid request material, Root should reject the submission.

For a resource publisher, this means “accepted by Registrar” and “accepted by Root” are different lifecycle stages. A good UI should show that distinction. A successful Registrar response may mean the request entered the OAN pipeline; it does not necessarily mean the resource is already visible in Discovery.

This distinction becomes more useful as OAN grows. In a multi-Registrar environment, Root is the consistent enforcement point for upstream authorization. In a multi-Discovery environment, Root acceptance is the common evidence that different Discovery nodes can verify before indexing.

Domains During Registration

authorizedDomains is enforced during registration. If the resource declares a domain outside the Registrar’s authorized scope, the request should fail. If the resource does not declare domains, Registrar policy may fill them in, often by defaulting to a valid subset of the Registrar’s scope or by deriving scope from registration material. In every case, the final resource domains must be covered by the Registrar.

This behavior makes domain authorization testable. A Registrar lacking one narrow domain should fail to register a resource in that domain, while a Registrar with coverage should succeed. Later, Discovery nodes with and without that domain should differ in whether they expose the resource.

The special domain value ["*"] means explicit full-domain authorization. An empty list means no domain authorization and should not be treated as “all domains.” Parent domains can cover their children according to the current domain tree rules, while partial coverage can be expressed by listing the covered children. This is why OAN treats domains as validated typed data, not as free-form tags.

What Happens After Submission

Once Root accepts, the resource still moves through publication and indexing. The publisher may see states such as submitted, accepted, published, indexed, or visible. These states are not bureaucratic decoration. They make distributed publication understandable and diagnosable.

If a resource fails registration, the most useful error tells the publisher what category failed: malformed DID, invalid resource type, missing package hash, domain mismatch, subject-control failure, unauthorized Registrar, or Root rejection. That clarity helps both human users and AI-assisted workflows.

For automation, the same error categories should be stable enough for SDKs and skills to act on. A community skill can ask the user to select a supported resource type. An operational skill can detect a governance or Registrar authorization problem. A website can keep the error human-readable while preserving machine-readable codes for future tooling.

Further Reading

• Resource registration and discovery guide
• OAN TypeScript SDK repository
• OAN community skill repository