did:oan Identity
did:oan is the identity anchor for OAN subjects. It gives a resource or infrastructure node a portable identifier that can remain stable while endpoints, package versions, metadata, and protocol bindings change. Without that stable identity layer, Discovery would quickly become a collection of URLs and descriptions that are hard to verify over time.
OAN uses DID concepts because agent resources need more than a name. They need key material, service references, verification methods, metadata, and a document shape that can be bound to package hashes and Root proof. did:oan gives OAN a method-specific identity surface while still fitting into the broader DID family of ideas.
What a did:oan Subject Can Be
A did:oan subject can identify a resource or an infrastructure participant. Resource subjects include Agent Services, Skills, MCP Servers, and Tool/API resources. Infrastructure subjects include nodes such as Registrars and Discovery services. Root and governance material also rely on stable identities and keys, although not every identity participates in the same way.
The same field name, authorizedDomains, can appear for different DID subjects, but the meaning is interpreted by role. For a Registrar, it describes the domains it may onboard. For a Discovery node, it describes what it may expose. For a resource, it describes the resource’s own authorized publication scope. The name can stay consistent while the enforcement logic stays role-aware.
DID Document as Public Resource Surface
The DID Document is the structured public surface that OAN components inspect and bind to evidence. It can include:
id, identifying the DID subject;- verification methods and authentication or assertion relationships;
- services and endpoints;
- OAN-specific metadata such as resource type, protocol binding, package references, and lifecycle-related hints;
authorizedDomains, when the subject has domain scope;capabilityTags, when the subject is a discoverable resource;- references to artifacts, manifests, schemas, examples, or other public material.
Discovery does not need to invent an unrelated search record if the DID Document already carries the public metadata. Instead, the Discovery node can index resource-facing DID material and package metadata that Root has accepted. This keeps search closer to the identity object and reduces drift between “what was registered” and “what is searchable.”
Identity Is Not the Whole Trust Model
A DID Document says something important, but not everything. It can show key material and service references. It can describe a resource. It can give software a stable object to hash and verify. But a DID Document alone does not prove that a resource is currently accepted by Root, visible through a valid Discovery node, or safe to invoke in a particular context.
OAN deliberately separates these facts:
| Fact | Where it comes from |
|---|---|
| Subject identifier and keys | did:oan DID Document |
| Registrar authorization | Governance-derived Root authorization state |
| Resource acceptance | Root verification and Root proof |
| Package integrity | ResourcePackage hashes |
| Discovery visibility | Authorized Discovery indexing and signed response |
| Runtime safety | Consumer-side policy, sandboxing, access control, and protocol checks |
This separation prevents identity from being treated as a universal stamp of trust. A resource can have a valid DID but not yet be accepted. A Discovery node can return a candidate, but the client should still verify the package and proof. A service endpoint can be listed in a DID Document, but the consumer still needs to confirm that the endpoint matches the verified package facts.
Stable Identity for Evolving Resources
Resource evolution is normal. A skill may be upgraded often. An MCP server may add tools. An Agent Service may move endpoints or update supported tasks. A Tool/API resource may publish a new schema version. did:oan lets the subject remain stable while each accepted package version records what changed.
This is why the DID and ResourcePackage are complementary. The DID names the subject and exposes current identity-facing material. The ResourcePackage captures a versioned, hash-bound publication unit. Root proof shows which package facts were accepted. Consumers can reason about continuity without pretending that all resource details are immutable forever.
The DID Is The Anchor, Not The Verdict
In decentralized identity systems, it is easy to over-read the DID. A DID can anchor control and service descriptions, but OAN still needs Root acceptance, package proof, current lifecycle, and Discovery provenance. The DID is the subject around which evidence is organized; it is not the final verdict that the resource should be used.
This distinction matters when a DID Document changes. A client should not simply fetch the latest DID Document from anywhere and assume it is the version Root accepted. The package and hashes say which identity material belongs to a specific accepted version.
Identity Continuity And Rotation
Real systems need key rotation, endpoint changes, and version updates. OAN’s identity model should allow continuity without making every field permanent. The DID subject can remain stable while verification methods, services, and package facts evolve through controlled updates.
Good tooling should make this lifecycle understandable. A resource holder should know when an update requires a new package version, when a DID Document hash changes, and how clients will verify the new state. Without that clarity, identity continuity can become a source of accidental drift.
What Good DID Material Looks Like
Good did:oan material is boring in the best way: fields are typed, endpoints are explicit, keys are controlled by the subject or operator, metadata is precise, and resource-type expectations are satisfied. A skill should not be described like a hosted API. An MCP server should include enough MCP-facing information for a client to know what it is connecting to. An Agent Service should expose the relevant service binding rather than only a human-readable description.
The DID Document should also avoid hiding governance concepts in arbitrary extra fields when the concept is part of the trust model. authorizedDomains, for example, is a typed and enforced property. Capability tags are descriptive matching signals. Keeping those fields explicit lets the website, SDK, Registrar, Root, Discovery, and tests all validate the same concept.