This chapter explains how OpenAgenet (OAN) uniformly models capability units that can be registered, published, distributed, and discovered as resources. The current core resource types include agent services, skill packages, MCP services, and tool APIs; infrastructure nodes, organizations, and developers may also appear as identity or subject types in associated relationships, but this chapter focuses on the four discoverable resource types. Each resource has, at minimum, an independent resource DID, resource type, description, capability tags, use cases, protocol bindings, service endpoints, version, and lifecycle state, and may use a resource package to carry a verifiable representation of a particular version.

The resource model unifies only the common elements required for cross-type interoperability; it does not force the four resource types into the same business object. The resource type determines field interpretation, endpoint shape, protocol binding, and invocation method; the resource DID establishes the control and registration boundary; resource metadata is used for registration and discovery; and the resource package binds the DID document, metadata, hashes, and the root platform’s trusted publication proof into a distributable object. Subsequent chapters specify identity, registration, discovery, publication, and invocation separately, avoiding a duplicate definition of all protocol behavior in this chapter.

4.1 Resource Model Overview

The common identity fields of the resource model include the resource DID, resource type, and subject type, as well as optional controller DID, publisher DID, and issuer DID; common descriptive fields include the name, description, capability description, capability tags, and use cases; common connectivity fields include protocol bindings, service endpoints, and authentication or credential requirements; and common state fields include the version, lifecycle state, authorization domain, network scope, and update time. oanMetadata is the primary metadata object in a DID document for carrying OAN resource semantics and lifecycle information, while the resource metadata in a resource package provides a versioned representation for publication and discovery.

The resource type enumeration includes at least agent_service, skill, mcp_server, and tool_api. The method-specific encoding of a resource DID should remain consistent with the resource type, and the resource type, subject type, oanMetadata in the DID document, and resource package metadata must be mutually verifiable. When a field is absent, empty, or present only in the web presentation layer, it must not be used to infer that the resource has the corresponding capability; actual invocation permission is not automatically granted by an endpoint or description field in the resource model.

The four resource types share the common models of resource DID, resource metadata, version, and lifecycle, while using different protocol bindings, endpoints, and package contents according to their capability forms:

The following example shows only how common fields are composed. A specific resource must still add protocol, endpoint, package, and credential information according to its type. resourceType, subjectType, and resourceDid are the fields used by machines to determine the resource boundary, while the name, description, and capability tags serve human understanding and discovery queries:

{
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "subjectType": "skill",
  "publisherDid": "did:oan:ORLG:example-publisher",
  "name": "Repository Structure Summary",
  "description": "Summarizes the structure of a code repository.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "authorizedDomains": ["public"],
  "lifecycleState": "active",
  "packageVersion": "1.0.0",
  "hashAlgorithm": "sha256",
  "updatedAt": "2026-09-09T08:30:00Z"
}

This object can serve as a minimal reading example of resource metadata, but it cannot independently replace the DID document, control proof, resource package hash, or the root platform’s trusted publication proof. A discovery service node can use its structured fields to build an index, while the caller must still obtain the corresponding evidence and perform subsequent verification according to the resource type.

4.2 Agent Services

An agent service is a resource type that provides callable agent capabilities, with the resource type value agent_service. It expresses an independent control and publication boundary through its resource DID, describes capabilities, capability tags, use cases, inputs and outputs, and applicable scenarios through its resource description, and expresses how to establish a connection through service endpoints and protocol bindings. An agent service may declare A2A, MCP, or other business protocols, but declaring a protocol only identifies the resource’s interface context; it does not mean that the caller has already obtained business authorization.

The relationship with an A2A Agent Card is an interoperability mapping relationship. OAN capability descriptions, capability tags, use cases, service endpoints, protocol bindings, version, and authentication declarations can provide trusted identity and publication provenance for corresponding A2A Agent Card information; A2A Agent Card fields can also be mapped to OAN resource metadata through an adapter. OAN additionally provides the resource DID, control proof, registration credential, root platform publication proof, governance status, and authorization domain, allowing a capability description to be associated with provenance, version, and network governance facts without changing the interaction semantics of A2A itself.

4.3 Skill Packages

A skill package is a capability unit that can be published, installed, loaded, or reused independently, with the resource type value skill. It should describe its capabilities, inputs and outputs, use cases, dependencies, and usage conditions through its resource description, and explain its acquisition and usage entry points through service endpoints, package information, or implementation links. A skill package may be composed by an agent service or another orchestration system, but its discoverability, version, and provenance should still be based on its own resource DID, resource package, and root platform publication facts.

The “reusable” property of a skill package means that a caller can use it repeatedly after satisfying its dependency, version, and authorization conditions; it does not mean that the caller can bypass resource control, installation security, or business permissions. Installation commands, download addresses, scripts, or dependencies in the skill package description are public declarations only. The caller must still verify the resource package hash, publication proof, version state, and local execution policy.

For example, public metadata for a skill package can place its capability, applicable tasks, dependencies, and version within the same resource boundary:

{
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "subjectType": "skill",
  "name": "Repository Structure Summary",
  "description": "Summarizes a code repository and its project structure.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "implementationLinks": [
    {
      "relation": "depends_on",
      "targetDid": "did:oan:TLFI:example-tool-api",
      "targetType": "tool_api",
      "versionConstraint": ">=1.0.0"
    }
  ],
  "lifecycleState": "active",
  "packageVersion": "1.0.0",
  "hashAlgorithm": "sha256",
  "updatedAt": "2026-09-09T08:30:00Z"
}

Here, implementationLinks expresses a verifiable resource relationship, and the version constraint expresses a composition condition; it does not mean that the target tool API has been installed or that the caller has obtained access permission. When the actual resource package is published, this metadata must also be bound to the DID document hash, metadata hash, and resource package hash.

4.4 MCP Services

An MCP service is a service resource that provides tool or resource access capabilities through the Model Context Protocol, with the resource type value mcp_server. Its resource DID identifies the service’s publication and control boundary; its resource metadata describes capability tags, use cases, protocol version, transport method, service endpoint, and authentication requirements; and its MCP capability description can be expressed through protocol bindings or a dedicated capability object. A tool list or resource list is a capability declaration and cannot independently replace endpoint authentication, invocation authorization, or runtime status checks.

The mapping between OAN and MCP metadata should preserve two boundaries: MCP is responsible for tool, resource, and interaction semantics at the protocol layer, while OAN provides the MCP service with resource identity, control proof, trusted publication, governance status, and a discovery entry point. An MCP service endpoint being reachable does not mean that the endpoint has been published by the root platform or is open to every caller; discovery results should not interpret an MCP capability declaration directly as invocation permission.

The resource description of an MCP service can provide protocol bindings and service endpoints together, for example:

{
  "resourceType": "mcp_server",
  "subjectType": "mcp_server",
  "protocolBindings": [
    {
      "id": "mcp-http",
      "protocol": "MCP",
      "version": "2025-06-18",
      "transport": "streamable-http",
      "serviceRef": "#mcp-service"
    }
  ],
  "services": [
    {
      "id": "#mcp-service",
      "type": "MCPServer",
      "serviceEndpoint": "https://example.invalid/mcp",
      "protocol": "MCP"
    }
  ]
}

The address, version, and identifiers in this example are illustrative values. protocolBindings specifies the protocol through which the resource is accessed, while services specifies the network entry point; both still need to be associated with the resource DID, publication version, hashes, and authentication requirements. A discovery service node should not mark a resource as directly callable merely because an MCP tool list exists.

4.5 Tool APIs

A tool API is a resource that provides a specific operation capability through a network interface, with the resource type value tool_api. It should describe the interface address, operation or capability name, input parameters, output results, protocol, version, authentication method, and invocation constraints; complex parameters may be expressed through input and output schemas, protocol schema references, or external documentation. A tool API can be referenced by an agent service, skill package, or MCP service, but a reference relationship does not mean that the caller has passed authentication and authorization at the target endpoint.

The resource description of a tool API and the actual service implementation should maintain a verifiable association. The resource controller is responsible for declaring the interface and version; the publication path is responsible for binding the DID document, metadata, hashes, and root platform proof; and the caller is responsible for checking the endpoint, version, evidence, and its own policy before connecting. The existence of an interface, a normal HTTP response, or the presence of a discovery index entry cannot independently prove that the tool’s business result is correct or that invocation is permitted.

The capability description of a tool API can separate “what it can do” from “how to invoke it” by using input and output schemas and authentication requirements:

{
  "resourceType": "tool_api",
  "resourceDescription": {
    "name": "Repository Structure Summary API",
    "capabilityDescription": "Accepts a repository reference and returns a project structure summary.",
    "inputSchema": {
      "type": "object",
      "required": ["repository"],
      "properties": {
        "repository": { "type": "string" }
      }
    },
    "outputSchema": {
      "type": "object",
      "required": ["summary"],
      "properties": {
        "summary": { "type": "string" }
      }
    }
  },
  "credentialRequirements": [
    {
      "credentialType": "Bearer",
      "presentationMode": "header",
      "required": true
    }
  ]
}

The schema constrains the shape of inputs and outputs, while the credential requirements describe the authentication material that must be prepared before invocation. Actual permission decisions, rate limiting, business validation, and result quality remain the responsibility of the target API and the caller’s policy. The resource model provides the identity boundary within which these declarations can be registered, published, and discovered.

4.6 Resource Relationships and Composition

Resource relationships express verifiable dependencies, provision, invocation, containment, or composition between resources. The current implementation uses structured links such as implementationLinks to carry relationships. A link should include at least the relationship type and target resource DID, and may include the target resource type, target service, and version constraint. The credibility of a relationship comes from the identities, publication evidence, and current states of both resources, not from an uncheckable natural-language statement.

Before runtime, a composition system should verify the DID, resource type, version or package hash, root platform’s trusted publication proof, lifecycle state, and authorization domain of every referenced resource. If a referenced resource is undiscoverable, does not satisfy the version constraint, lacks proof, has been revoked, or has been suspended, the caller or orchestration system should choose according to risk among rejecting the composition, waiting for synchronization, or displaying it only without invocation eligibility. It must not treat the existence of an index summary as proof of composition integrity.

A resource relationship can be represented in the data as an explicit link object rather than embedding a dependency in free text:

{
  "relation": "provides",
  "targetDid": "did:oan:TLFI:example-tool-api",
  "targetType": "tool_api",
  "targetService": "#repository-summary",
  "versionConstraint": "^1.0.0"
}

Relationship verification should check at least the target DID, relationship type, target type, version constraint, and current publication state of the target resource. targetService is only a reference for locating the target service; it cannot replace endpoint reachability and authentication. When the target resource’s version or package hash changes, the original relationship must be matched and verified again.

4.6.1 Dependencies Between Resources

A dependency relationship means that normal use of one resource requires another resource or external capability. The dependency declaration should point to the target resource DID and, where necessary, provide the target type, service reference, and version constraint; the business meaning, installation method, and runtime authorization of the dependency can be supplemented through the resource description or protocol binding, but the identity and version boundaries must be expressed structurally. When the dependency target is updated, the caller should recheck the version constraint and publication state.

4.6.2 Composition of Agent Services and Skill Packages

An agent service may depend on or compose multiple skill packages, using them as reusable capabilities for task execution, information processing, or tool orchestration. The composition record should distinguish the agent service DID, skill package DID, skill package version or package hash, and relationship type; publication of the agent service does not automatically extend the control and publication facts of the skill package. The caller must verify the evidence and compatibility conditions of both the agent service and the skill package.

4.6.3 Invocation Relationships Between MCP Services and Tool APIs

An MCP service may provide a collection of tools or reference one or more tool APIs through protocol bindings; a tool API may also be called directly by an agent service or skill package. The relationship declaration should specify the target DID, target service or operation, protocol, and version, avoiding a statement that only says “supports a particular tool.” Tools discoverable at the MCP protocol layer still require OAN resource identity, publication state, endpoint authentication, and the caller’s authorization decision.

4.6.4 Composition Integrity and Version Constraints

Composition integrity requires at least that the DIDs, resource types, versions or package hashes, relationship declarations, root platform trusted publication proofs, and current lifecycle states of both sides of a relationship are consistent, and that the target resource is within the authorization domain visible to the caller. When a version constraint is not satisfied, the package hash changes, the proof expires, or the resource is suspended, the old composition declaration must not be used as an unconditional basis for invocation; where necessary, the caller should rediscover, reverify, or fall back to a clearly compatible version.

4.7 Resources as Independently Identifiable Objects

Each of the four resource types can have an independent resource DID, using that DID as the identity boundary for creation, registration, publication, discovery, and update. A subject DID can express the control relationship of a resource, and a publisher DID can express the registration or operational provenance, but neither can replace the resource’s own DID. The method-specific encoding of the resource DID should be consistent with the resource type, and the public keys, service endpoints, and oanMetadata in the DID document should jointly support verification of the resource identity and capability declaration.

An independent DID allows a skill package, MCP service, or tool API to be discovered and reused independently of a particular agent service, and also allows it to be updated, suspended, revoked, and versioned independently. When resources have composition relationships, each resource must still be verified separately through its own DID and publication evidence; the trusted state of one resource does not automatically transfer to its dependencies.

There is a code-level validation relationship between resource types and the method-specific encoding of did:oan. The current common library uses AG, SK, MC, and TL for agent services, skill packages, MCP services, and tool APIs, respectively. The following DIDs are provided only to illustrate the form:

The encoding prefix is an identifier currently used by the implementation to check consistency with the resource type. It should not be understood as an independent DID method outside the rules of the did:oan method. When the resource type is inconsistent with oanMetadata.resourceType in the DID document, a node should reject further processing of the object as that resource type.

4.8 Resource Metadata and Capability Descriptions

Resource metadata is a structured description used for registration, publication, and discovery in addition to resource identity. Common fields include the resource DID, resource type, subject type, controller or publisher DID, name, description, capability description, capability tags, authorization domain, protocol bindings, service endpoints, credential requirements, package information, network scope, lifecycle state, version, and update time. oanMetadata in the DID document and the resource metadata in the resource package should remain consistent in key fields such as resource DID, resource type, version, hash, authorization domain, and state.

The capability description answers what the resource can do; capability tags answer which governed capability categories the resource belongs to; and use cases answer in which tasks those capabilities are used. Names and free text help people and semantic engines understand a resource, but cannot replace structured tags, protocol bindings, endpoints, or control proofs. Metadata is a declaration made by the resource provider. The root platform and discovery service nodes can verify its structure, hash, and publication provenance, but complete fields do not replace an independent assessment of business quality.

Capability fields in oanMetadata.resourceDescription can be organized into a minimal object for retrieval:

{
  "name": "Repository Structure Summary",
  "description": "A reusable capability for examining code repositories.",
  "capabilityDescription": "Finds repository files and summarizes the project structure.",
  "capabilityTags": ["code-repository", "project-structure-summary"],
  "useCaseExamples": [
    "I need a tool that can search code repositories and summarize the project structure."
  ],
  "version": "1.0.0"
}

Natural-language fields are suitable for semantic discovery and user understanding, tags are suitable for structured filtering, and the version associates the description with the resource package and publication evidence. Together they describe the resource’s capabilities, but do not mean that a node has verified runtime behavior, nor do they replace identity, publication, and authorization checks before invocation.

4.8.1 Basic Identity and Description Fields

The basic fields should be sufficient to identify the resource DID, resource type, subject type, name, description, and controller or publisher relationship, and should be consistent with id, oanMetadata.resourceType, oanMetadata.subjectType, and related DID fields in the DID document. Resource type values should use the protocol-defined enumeration; a Chinese display name or alias in the presentation layer must not be the sole basis for machine judgment.

4.8.2 Capability Tags, Capability Descriptions, and Use Cases

Capability tags should preferably use canonical identifiers from the capability tag tree maintained by the root platform. Extension tags may also be retained when their source is clearly identified. Capability descriptions and use cases should explain executable capabilities, inputs and outputs, and applicable tasks. A registration service node may recommend tags based on a description, and a discovery service node may combine tags, aliases, descriptions, and use cases for structured or semantic search, but relevance results still require identity, publication, and authorization-domain verification.

4.8.3 Protocol, Endpoint, and Authentication Information

Protocol bindings should specify the protocol name, version, transport method, service reference, or schema reference, and associate these with one or more service endpoints. A service endpoint should specify its address, type, version, protocol, and any necessary port or server information. Authentication information should express the public authentication method, credential requirements, or prerequisites for invocation. Endpoint and authentication declarations are part of the resource capability description; they do not mean that the caller has already obtained access permission.

4.8.4 State, Version, and Governance Information

Resource metadata should distinguish the resource lifecycle state, resource package version, update time, expiration time, previous version or version constraint, authorization domain, and network scope. The lifecycle state expresses facts such as whether the resource is active, suspended, revoked, or replaced; propagation progress is expressed by root platform publication, content distribution, and discovery synchronization records. These concepts must not be conflated in a single available field.

4.9 Use Cases, Protocol Bindings, Endpoints, and Authentication Declarations

Use cases, protocol bindings, service endpoints, and authentication declarations together form the public explanation of “how to understand and use this resource.” A resource may have multiple use cases, protocol bindings, and endpoints. Each binding should, as far as possible, specify the applicable capability, protocol version, transport method, service reference, and schema; authentication declarations should, as far as possible, be associated with a target endpoint, operation, or version. If an endpoint is unavailable, the protocol version is incompatible, or authentication information is incomplete, a discovery service node may return a result with the corresponding state, but should not describe it as directly callable.

4.9.1 Use Case Descriptions

A use case description should state the task objective, input conditions, expected output, and applicable resource capabilities, and should preferably correspond to the capability description and capability tags. A natural-language use case can support semantic retrieval and user understanding, but cannot independently prove that the resource has the capability; precise constraints should be combined with input and output schemas, protocol bindings, and version information.

4.9.2 Protocol Bindings

Protocol bindings should record the protocol name, protocol version, transport or interaction method, and references to endpoints or schemas. A2A and MCP may enter the resource description as external protocol contexts. OAN binding fields only express how the resource connects to these protocols; they should not turn OAN resource registration state into a mandatory clause of an external protocol.

4.9.3 Service Endpoints

A service endpoint is the network entry point through which a resource provides capabilities or obtains materials. It may contain an endpoint identifier, endpoint type, address, version, protocol, server type, and port. When a resource has multiple endpoints, the protocol or version differences between them should be stated. When an endpoint is unreachable, its certificate is invalid, or the service is inactive, the discovery result should preserve that fact or freshness information rather than considering only the static address.

4.9.4 Authentication and Invocation Requirements

Authentication and invocation requirements explain what identity, credential, signature, permission, or protocol context a caller must provide. A resource may publicly declare the credential type, issuer, scope, and presentation method, but final business authorization is jointly determined by the resource endpoint and the caller’s policy. OAN VCs, the root platform’s trusted publication proof, and node governance status are materials for verification before invocation; they are not automatic authorization for every business operation.

Authentication declarations in the resource model primarily answer “what must the caller prepare,” such as credential type, issuer, scope, and presentation method. The endpoint must still check credential validity, request subject, business permissions, and runtime policy after receiving a request. The public declaration of the same resource can be understood in two layers:

4.10 Resource Packages and Publication Artifacts

A resource package is a distributable object bound to a particular resource version. It usually contains the resource DID, resource type, resource version, DID document, DID document hash, metadata hash, resource package hash, hash algorithm, resource metadata, the root platform’s trusted publication proof, and creation time. The DID document expresses identity, public keys, service endpoints, and OAN metadata; resource metadata expresses capabilities, use cases, protocols, endpoints, authorization domain, and lifecycle; the control proof expresses the resource controller’s authorization for an operation; the registration VC expresses the registration fact processed by the registration service node; and the root platform’s trusted publication proof expresses that the root platform has verified and accepted that resource version.

At node interfaces, the resource model corresponds to different payload types. The client submits ResourceRegistrationSubmission, whose metadata remains dynamic JSON because the registration service node must validate its structure according to the current resource metadata rules. After root platform verification succeeds, these fields are organized into a ResourcePackage, which is then carried and distributed by ResourceCdnPublishRequest or a batch request. Therefore, a “resource object,” a “registration request,” and a “distributable resource package” are not the same JSON object; a client must not treat a registration request as a resource package that already has a root platform proof.

These objects form a layered verification path rather than parallel attachments. A caller or discovery service node should first resolve the DID document and verify the control relationship; then check consistency of the resource type, DID, authorization domain, and version between the metadata and DID document; recompute the DID document hash, metadata hash, and resource package hash; and verify the registration credential, the root platform’s trusted publication proof, and the current governance state. Registration acceptance, root platform publication, and discovery indexing are produced by different components, and success at any one stage cannot replace the others.

A resource package can be understood through the following structure. The hashes, DIDs, times, and proof contents in this example are placeholders used to show the reference relationships between objects and do not represent official fixed values:

{
  "packageVersion": "1.0.0",
  "resourceDid": "did:oan:SKLG:example-skill",
  "resourceType": "skill",
  "didDocument": {
    "@context": ["https://www.w3.org/ns/did/v1"],
    "id": "did:oan:SKLG:example-skill",
    "verificationMethod": [],
    "authentication": [],
    "assertionMethod": [],
    "service": [],
    "oanMetadata": {
      "subjectType": "skill",
      "resourceType": "skill",
      "capabilityTags": ["code-repository", "project-structure-summary"],
      "authorizedDomains": ["public"],
      "lifecycleState": "active"
    }
  },
  "didDocumentHash": "sha256:example-did-document",
  "metadataHash": "sha256:example-metadata",
  "packageHash": "sha256:example-package",
  "hashAlgorithm": "sha256",
  "metadata": {
    "resourceDid": "did:oan:SKLG:example-skill",
    "resourceType": "skill",
    "subjectType": "skill",
    "name": "Repository Structure Summary",
    "description": "Summarizes a code repository.",
    "capabilityTags": ["code-repository", "project-structure-summary"],
    "authorizedDomains": ["public"],
    "services": [],
    "lifecycleState": "active",
    "packageVersion": "1.0.0",
    "packageHash": "sha256:example-package",
    "metadataHash": "sha256:example-metadata",
    "hashAlgorithm": "sha256",
    "updatedAt": "2026-09-09T08:30:00Z"
  },
  "rootProof": {
    "rootDid": "did:oan:INLG:example-root",
    "packageClaims": {
      "resourceDid": "did:oan:SKLG:example-skill",
      "resourceType": "skill",
      "version": "1.0.0",
      "didDocumentHash": "sha256:example-did-document",
      "metadataHash": "sha256:example-metadata",
      "packageHash": "sha256:example-package",
      "hashAlgorithm": "sha256",
      "lifecycleState": "active",
      "authorizedDomains": ["public"]
    }
  },
  "createdAt": "2026-09-09T08:30:00Z"
}

The verifier can first use resourceDid and resourceType to determine the object’s ownership, then recompute the three types of hashes, check consistency of key fields between metadata and the DID document, and finally verify that rootProof.packageClaims is consistent with the current package declaration. This order helps distinguish “content is complete,” “resource is controllable,” “registration was accepted,” and “root platform publication was completed,” rather than interpreting a downloaded file as the complete network fact.

4.10.1 ResourcePackage Contents

The resource package content should be organized around one resource version and bind at least resourceDid, resourceType, packageVersion, the DID document, DID document hash, metadata hash, resource package hash, hash algorithm, resource metadata, and the root platform’s trusted publication proof. The rootProof in the resource package should associate the resource DID, type, version, hashes, lifecycle state, authorization domain, and necessary governance or publication references through its claims.

4.10.2 Metadata and Resource Content

Metadata is a structured description of the resource content, capabilities, and runtime entry points. The resource content may be skill package files, a service description, a tool interface, or an MCP capability declaration. Package information, download addresses, manifest addresses, implementation links, and version fields in the metadata should point to or describe the current resource version; historical metadata must not override the identity and hash of the current resource package.

4.10.3 Hashes and Integrity Proofs

The resource package should express the DID document hash, metadata hash, and resource package hash separately, and declare the hash algorithm used. The verifier should recompute the corresponding hashes according to the canonical representation, and check whether the internal fields of the resource package are consistent with the declarations in the root platform proof. A matching hash proves content integrity only; it does not independently prove control, node authorization, or trustworthiness of the business endpoint.

4.10.4 Publication, Download, and Verification Artifacts

A registration service node may return a registration result, registration credential, or downloadable material; the root platform produces an acceptance record and the root platform’s trusted publication proof; the content distribution platform provides downloadable resource packages and related materials; and a discovery service node stores a verified index object. Downloading a resource package does not mean that invocation authorization has been completed. The caller should reverify it according to provenance, version, freshness, governance state, and local policy.

4.11 Resource Lifecycle and Visibility State

The resource lifecycle describes the state of the resource version itself, while network propagation progress describes whether that version has passed registration acceptance, root platform acceptance, content distribution, and discovery indexing. A resource may be registered but not yet published by the root platform, published but not yet synchronized by a particular discovery service node, or present in a discovery index but no longer visible to a particular caller because of a change in authorization domain or governance state. State judgments should cite both the component that produced the state and the corresponding evidence.

Resource updates should distinguish an idempotent retry of the same version from publication of a new version. A repeated submission with the same resource DID, version, and hashes may reuse the existing result; content changes, version changes, control-key changes, or lifecycle changes must enter a new verification and publication decision. An old snapshot may be used for limited display, but must not override current revocation, suspension, replacement, or authorization-domain restrictions.

Resource version and propagation state can be viewed along two dimensions:

4.11.1 Registration State

A local draft means that the resource materials have not been accepted by a registration service node; submitted means that the registration service node has received and processed the request; and registered means that the registration service node has formed a registration record or registration credential. These states do not directly indicate that the root platform has published the resource or that a discovery service node has indexed it. The resource controller should preserve the local DID document, keys, and submission materials so that they can be reverified after a failure or during an update.

4.11.2 Publication and Indexing State

Root-platform published means that the root platform has accepted a particular resource version and formed a publication proof; content distributed means that the resource package has entered the serving scope of the content distribution platform; and indexed by a discovery service node means that a particular discovery service node has verified the resource package and written it to its local read model. These three states progress asynchronously and may be temporarily inconsistent, so they should be expressed through cursors, state, and freshness.

4.11.3 Suspension, Revocation, and Recovery State

Suspension means that a resource or its version may temporarily no longer be propagated or invoked as active within a specified scope; revocation means that the corresponding resource, credential, publication fact, or node authorization is no longer valid; and recovery means that a new governance or publication decision has again permitted the corresponding action. A state change should be associated with the version, resource DID, governance fact, or publication record, rather than merely changing web display text. A discovery service node should update its index and query results after the state has propagated.

4.11.4 Publicly Visible and Trustfully Discoverable State

Publicly visible means that a portal or node can return resource information to a particular query party; trustfully discoverable means that the discovery service node has verified the resource identity, publication proof, hashes, lifecycle, and authorization domain and permits the resource to be returned within its authorized scope. A resource may be displayed publicly without being trustfully discoverable, or may have been published by the root platform but be invisible to a particular authorization domain. The caller must still perform its own verification before connecting.

4.12 Resource Ownership, Control, and Delegation Relationships

Resource ownership is a rights relationship at the business or organizational layer; DID control is a cryptographic relationship in which keys and signatures prove the ability to represent a resource DID and perform prescribed operations; operational management is responsibility for an endpoint, content, or runtime environment; publication delegation is the qualification for a registration service node or another authorized participant to submit or process materials on behalf of someone else; and invocation authorization is a business permission jointly determined by the resource endpoint and the caller’s policy. These roles may be held by the same subject or by different subjects.

Resource metadata may express some relationships through controllerDid, publisherDid, subjectDid, implementationLinks, or credential requirements, but the fields themselves are not sufficient proof that the relationships are genuine. The verifier should separately check the resource DID control proof, credentials of the publisher or registration service node, the root platform publication proof, governance state, and business endpoint authentication. It must not infer other permissions merely because a party can upload a file, provide an address, or issue a registration result.

4.13 Resource Dependencies and Composition Integrity

Dependency integrity requires every resource in a composition to be independently identifiable, locatable, verifiable, and usable according to its version. The minimum check set includes the target resource DID, resource type, relationship type, target version or package hash, consistency between the DID document and metadata, the root platform’s trusted publication proof, lifecycle state, authorization domain, and necessary protocol compatibility conditions. When a discovery service node returns only an index summary, the caller should obtain the complete resource package or verifiable proof before establishing a high-risk composition.

When a discovery node is behind, the target resource is temporarily unavailable, or proof is temporarily missing, the composition may be marked as pending synchronization or unverifiable. When the target resource has version drift, is suspended, revoked, outside the authorization domain, or has an inconsistent hash, the composition should not continue to be used unless a clearly constraint-satisfying alternative version exists. Composition integrity is a pre-invocation verification condition, not an incidental result of registration or search ranking.

The four resource types share common information such as resource DID, resource type, capability description, version, endpoint, protocol binding, and lifecycle, but differ in content form and invocation method. The goal of the resource model is to provide a common registration, publication, and discovery framework, not to force the four resource types into the same runtime object.

Resource relationships must explicitly state the target DID, relationship type, and version or package hash. A name, search relevance score, or reachable endpoint alone cannot prove dependency integrity. When a referenced resource is suspended, revoked, has version drift, or falls outside the authorization domain, the composition party should refuse further use or move it to a pending-verification state.

Boundary of the resource model: OAN is responsible for the identity, description, publication, discovery, and verification associations of resources. Model inference, business workflows, tool execution, and final business authorization inside a resource remain the responsibility of the corresponding resource and the caller’s policy.

References