ResourcePackage and Root Proof
A ResourcePackage is the versioned publication object that Root can stand behind. It is the object Discovery indexes, CDN distributes, and clients verify. It binds the resource DID, DID Document, metadata, hashes, lifecycle facts, authorized domains, and Root proof into one coherent publication unit.
The Root proof is the trust bridge attached to that unit. It lets a downstream node or consumer verify that the package facts match what Root accepted. Without the package and proof, a Discovery result would be only a search hit. With them, the result can be checked against a concrete evidence chain.
Why OAN Needs a Package Object
A resource is more than one field. It has identity, keys, services, package references, tags, domains, resource type, version, and sometimes external artifacts. If every downstream component copied those fields independently, they would drift. Discovery might index one description, CDN might host another object, and a consumer might fetch a third version from a repository.
The ResourcePackage avoids that ambiguity. It says: this is the publication unit Root accepted; these are the hashes of the accepted DID Document and metadata; this is the package version; this is the resource type; these are the domains; this is the proof that binds the claims.
That package object gives OAN a stable unit for distribution. CDN does not need to become a trust authority. Discovery does not need to ask users to trust its local database. SDKs can verify the package facts against proof and hashes.
What the Package Binds
The exact implementation can evolve, but the important binding rules are stable.
| Binding | Purpose |
|---|---|
| Resource DID | Identifies the subject being published. |
| Resource type | Distinguishes Agent Service, Skill, MCP Server, Tool/API, or later types. |
| DID Document hash | Detects changes to identity-facing material after acceptance. |
| Metadata hash | Detects drift in descriptions, tags, domains, examples, or searchable facts. |
| Package hash | Binds the publication unit as a whole. |
| Version and lifecycle | Lets clients distinguish current, superseded, revoked, or pending states. |
| Authorized domains | Makes governance scope part of the accepted resource facts. |
| Root proof | Shows Root accepted this exact package claim set. |
This is why a ResourcePackage is not merely “metadata in JSON.” It is the compact evidence object that lets OAN scale from a demo to multiple Registrars, multiple Discovery nodes, CDN distribution, SDK verification, and third-party clients.
Root Proof in Plain Language
Root proof answers the question: “Did Root accept these facts, or did someone only claim them?”
The proof should be checked against the Root identity and accepted claim set. A consumer should be able to verify that the returned DID Document, metadata, and package version correspond to the Root-accepted hashes. Discovery can make this easy by returning package references and proof material with candidates. SDKs can make it easier still by exposing verification helpers instead of asking application developers to assemble every check by hand.
Root proof does not say the resource is morally safe, best ranked, bug-free, always reachable, or authorized for every possible use. It says Root accepted this package version under the OAN trust model. That narrower meaning is exactly what makes it useful.
How It Moves Through the System
The package usually appears after Root admission. Registrar submits resource material upstream. Root verifies the Registrar, resource DID, DID Document shape, subject-control evidence, hashes, authorized-domain coverage, and package consistency. If accepted, Root records the package and proof, publishes package artifacts, and notifies relevant Discovery nodes after publication is available.
Discovery then fetches or receives package references, verifies proof and hashes, applies its own domain scope, indexes searchable fields, and exposes candidates through its query API. A client receiving a Discovery response should still verify the returned candidate. In well-integrated clients, this becomes a normal verification step rather than a manual forensic task.
Version Updates
ResourcePackage is also the place where version evolution becomes manageable. A resource identifier can remain stable while the package version changes. A skill can publish a new package. An MCP server can update its service metadata. An API can update schema references. The accepted package version records what changed and gives consumers a way to reason about current versus previous material.
This matters for real adoption. Agent resources are not static documents. Many of them update frequently. OAN’s versioned package model supports updates without throwing away identity continuity.
Why Packages Help Caching And Migration
ResourcePackage also helps with caching, replication, and low-downtime migration. If the package facts are hash-bound and Root-accepted, CDN, Discovery, SDKs, and clients can cache material while still checking whether the bytes match the accepted version. During a server move or software upgrade, operators can rebuild derived state from accepted packages rather than treating a local database as the only source of truth.
This is important for OAN’s practical maturity. A trusted network cannot depend on one live process always having perfect memory. Packages and proofs make state portable, inspectable, and recoverable.
Proof Is Narrow By Design
Root proof is intentionally narrow. It proves acceptance of a claim set, not every future property of the running service. That narrowness is what keeps verification precise. A client should not interpret Root proof as a service-level agreement, security audit, legal approval, or guarantee of output quality.
When proof remains narrow, other controls can compose with it. Enterprises can add policy. SDKs can add runtime checks. Protocols such as MCP or HTTP can enforce their own authentication and authorization.
What Can Go Wrong Without Package Checks
Several common trust errors become visible once you think in package terms:
- A Discovery result points to a resource whose metadata no longer matches the Root-accepted hash.
- A CDN copy is stale or corrupted.
- A service endpoint claims to be a resource but lacks Root proof for the current package.
- A client uses a DID Document from one source and metadata from another without checking that Root accepted the combination.
- A resource appears in search even though its lifecycle status has changed.
These are not exotic failures. They are ordinary distributed-system drift. ResourcePackage and Root proof are OAN’s answer: bind the accepted facts, distribute them, and let clients verify.