This chapter specifies the temporal, state, and evidence relationships of resources in the OpenAgenet (OAN) network. Resources such as Agent Services, Skill packages, MCP services, and Tool APIs use DIDs to identify subjects, use DID Documents to describe control relationships, capabilities, and service endpoints, and use resource packages to carry publishable content. A registration VC proves that a Registrar node has accepted a registration, while a Root proof proves that a specific resource package has passed Root platform verification and entered the publication pipeline. “Registered”, “published”, “indexed”, and “currently callable” are different facts and must be proved separately.

The state relationships in this chapter can be understood by using a resource version as the association key:

Resource DID
  -> DID Document version
  -> Resource package version + document/metadata/package hashes
  -> Registration VC
  -> Root proof
  -> Distribution cursor and discovery index version

The chain above represents the association between pieces of evidence. It does not mean that all steps complete synchronously, nor does it mean that a response from a Registrar node means that the resource is already visible to a Discovery node.

18.1 Resource Lifecycle State Machine

States must be triggered by events, proofs, or persistent records. They cannot be inferred from a page button or a single successful HTTP response. Registration success indicates, at most, that the Registrar node has completed acceptance. The resource can enter the Published state only after Root platform verification, authorization checks, resource package digest verification, and completion of the publication task. It can enter the Discoverable state only after a Discovery node has completed verification and indexing. Failures must preserve the reason, associated identifiers, and retry boundaries; they must not all be described simply as completion of network-wide registration.

18.2 Initial Registration

The publisher creates or imports a local identity in the browser and uses a local private key to sign the DID Document and registration request; the private key should not be uploaded to the Registrar node. The Registrar node verifies the format, control relationship, resource type, required metadata, and node authorization. After successful acceptance, it records the registration and returns a registration VC according to the interface contract. The Root platform then independently verifies the resource package, Registrar node authorization, and publication conditions. The content distribution platform and Discovery nodes subsequently receive and index the content asynchronously. Missing local identity, invalid signatures, missing fields, network failures, an empty VC, and propagation delays must be reported separately and must not be summarized as completion of network-wide registration.

18.3 Updating a Resource with the Same DID

The basis for an update with the same DID is continuity of the control relationship, not equality of the DID string. An update request should include the preceding version, resource DID, version, and content digest, and should be signed by the existing control public key or an explicitly authorized update key. The Registrar node verifies control authority and the version relationship. The Root platform re-verifies the resource package and publication authorization. A Discovery node accepts only versions that have passed through the Root platform publication process. Repeated submission of identical content and the same preceding version should be handled idempotently; a content change must advance the version and digest. Requests without authorization, with a version rollback, or with a fork must be rejected. Before the new version has completed propagation, the old valid version may continue to be returned.

18.4 DID Document Version Management

DID Document versions express changes to the identity document, control keys, service endpoints, or capability metadata. They are not equivalent to the did:oan method version or the resource package version. The current version should be determined jointly by the stable DID, the predecessor relationship, a sequence or equivalent version rule, and the controller’s signature; timestamps are for audit purposes only. A resolver must not resolve a fork at the same predecessor version solely according to arrival time. By default, a Discovery node returns the highest-sequence version that is published and has a valid state, and supports querying historical versions by version or content digest.

The order of version determination should remain deterministic:

Lifecycle state filtering -> Proof verification -> Publication sequence comparison -> Version comparison -> Query ordering

Resource package versioning and interface compatibility are different dimensions. A Skill package may update only its documentation or examples, while a Tool API may change its input/output schema and endpoint at the same time. An MCP service may also change its protocol binding or exposed capabilities. Therefore, a version number cannot replace a change description. The packageVersion, packageHash, metadataHash, and lifecycleState in a resource package should be consistent with the corresponding values in the DID Document metadata and the Root proof.

A minimal binding record for audit purposes can be represented as follows:

{
  "resourceDid": "did:oan:SKDM:example-resource-did",
  "packageVersion": "1.2.0",
  "didDocumentHash": "sha256:example-did-document-hash",
  "metadataHash": "sha256:example-metadata-hash",
  "packageHash": "sha256:example-package-hash",
  "lifecycleState": "active",
  "previousVersion": "1.1.0"
}

The DID, version, and digest values above are illustrative placeholders. They express the binding relationship between fields, not an official resource or fixed version.

18.5 Resource Package Version Management

A resource package is the publication unit verified by the Root platform, stored by the content distribution platform, and indexed by Discovery nodes. A version must point to a set of normalized metadata, entry points, protocol bindings, dependencies, and content digests. The Root proof should bind the resource DID, resource type, resource package version, and package digest. A resource DID may remain unchanged during a normal upgrade. An old resource package may be marked as superseded while its audit evidence is retained. By default, a Discovery node returns the latest valid package; when a caller requests a specific version, its publication proof and credential status must still be verified.

The update target can be selected according to the scope of the change. If only the published package content changes, at least the resource package version and package hash must be updated. If service endpoints, public keys, or resource metadata in the DID Document change, the DID Document and its digest should be updated together. If capability tags, authorization domains, or lifecycle state change, semantic governance and visibility must also be checked again. Any change that affects a field bound by the Root proof cannot be made only by modifying a local index at a Discovery node.

18.6 Metadata and Endpoint Changes

Changes to capability tags, descriptions, use cases, protocol bindings, endpoints, authentication requirements, and dependencies that affect discovery or invocation decisions should produce a new DID Document version, a new resource package version, or a combination of both, followed by re-signing, verification, and indexing. An endpoint change must also check TLS, authentication, protocol compatibility, and actual capabilities. Taking an old endpoint offline does not mean that the resource DID has been revoked; the caller should decide whether to invoke the resource according to the new version and state.

18.7 Registration VC Lifecycle

A registration VC proves that a Registrar node accepted a registration. It is not a guarantee of resource quality and does not replace the Root proof. A verifier should check the issuer’s authorization, subject DID, resource type, version or content digest, issuance time, validity period, and revocation status. When the VC is missing or invalid, the issuer is unauthorized, or the status is unknown, the resource must not be marked as a trusted registration. Credential revocation affects only the fact proved by that credential and does not automatically rewrite the DID Document. Deactivation of a DID does not mean that historical credentials disappear.

When processing credentials, the querying party should record “credential exists” and “credential is currently valid” separately. Even if the registration VC for resource version v1 has a valid signature, it cannot directly prove that v2 has been registered. Likewise, the Root proof for v2 cannot replace the Registrar node’s evidence for the registration fact. After a resource update, credential revocation, or subject deactivation, a Discovery node should filter results according to the latest verifiable state while retaining historical credentials as audit material.

18.8 Resource Suspension and Recovery

Suspension is a reversible state. Its causes should distinguish controller action, governance restrictions, temporarily unverifiable evidence, endpoint maintenance, and node synchronization failures. A network timeout or missing metrics must not directly change the resource lifecycle state. Suspension should have a control signature, governance event, or other verifiable evidence. Before recovery, the control proof, VC, Root proof, endpoint, and governance conditions must be checked again, and the Discovery node must resynchronize according to the publication sequence rather than merely changing its local state.

18.9 Resource Revocation and Deactivation

Resource revocation targets publication eligibility or a version. DID deactivation targets the resource subject. Credential revocation targets a particular proof. Endpoint withdrawal targets a service entry point. Revocation and deactivation should record the initiator, basis, target DID or version, reason, effective time, and propagation scope. Historical materials may be retained for audit, but must not be returned as currently callable resources. Before propagation converges, a node must label the state and freshness instead of claiming that revocation has taken effect across the entire network immediately.

The handling of node authorization changes and resource states can be checked using the following relationships:

18.10 Node Suspension and Resource Visibility

Node authorization is a governance object, while resource control belongs to the resource DID. After a Registrar node loses authorization, the Root platform should stop accepting new trusted publication inputs from it and re-evaluate existing publications according to governance rules. After a Discovery node loses authorization, it should not continue publishing results as a normally authorized node, although its data may be retained for recovery and audit. Node recovery must first restore identity and authorization and then use the cursor to fill in missing data. Clients should distinguish node failure, synchronization in progress, and resource revocation.

Version selection is not simply “last write wins”. For example, if a Discovery node receives 1.1.0 and 1.2.0 for the same resource at the same time, it should first confirm that both have verifiable publication sources and valid states, and then select the current result according to the publication sequence, predecessor relationship, and version rules. If the digest or proof for 1.2.0 fails verification, it cannot overwrite 1.1.0 merely because its version number is larger. The selection result should also retain the adopted version and the reasons for excluding other versions, so that propagation delays and version conflicts can be diagnosed.

18.11 Version Selection by a Discovery Node

A Discovery node first filters by state, signatures, registration VC, Root proof, version validity, and index freshness, and then performs semantic and structured ranking. By default, for the same DID it returns the version that is published, has a valid state, and has the highest publication sequence. When there is a version conflict, a sequence gap, or unknown proof status, it should report an anomaly instead of selecting randomly. Both exact DID queries and semantic queries should return the version, digest, source, evidence status, and indexing time.

18.12 Historical Versions and Auditability

Audit records should associate the DID, document version, resource package version, digest, control signature, registration VC, Root proof, publication sequence, node receipt time, and indexing time. Historical queries should distinguish current valid, superseded, revoked, archived, and not-yet-synchronized-by-the-node states. Historical evidence is used to reconstruct publication facts and must not bypass current-state checks. Node reconstruction or database migration must not silently discard evidence that the specification requires to be retained.

Historical records should be able to answer at least three questions: who controlled and signed a particular version; whether the Root platform accepted and published that version; and when and in what state a specified Discovery node observed that version. If only a resource package file can be found, without a control signature, publication proof, or index observation record, it proves only that the material was once stored. It does not prove that the material was once a valid version in the network.

18.13 Resource VC and Publication Evidence Lifecycle

Registration VCs and Root proofs have different issuers and factual scopes. The former proves registration acceptance, while the latter proves that a specific resource package passed Root platform verification and entered the publication pipeline. Both must bind an explicit DID, version, and digest. When an update produces a new digest, the corresponding evidence should be produced again. Revocation, deactivation, expiration, and authorization loss must be checked separately. A proof file downloaded to the publisher’s local environment does not change the server-side validity judgment.

The evidence association can be checked item by item by version:

Same resource DID
  -> Same resource package version
  -> Corresponding DID Document/metadata/package digest
  -> Registration fact in the registration VC
  -> Root proof
  -> Receipt and indexing observation by a Discovery node

If any link points to a different DID, version, or digest, it should be treated as a binding inconsistency. File names or download times must not be used to infer that the evidence belongs to the same publication.

18.14 Update Propagation and Stale Index Convergence

Registrar node -> Root platform verification and publication -> Content distribution platform -> Discovery node receipt -> Verification, indexing, and visibility

Each segment is associated using the DID, version, digest, publication sequence, or event cursor. Repeated delivery must be idempotent, and interrupted retries must continue from the confirmed cursor. When there is a sequence gap, digest mismatch, invalid proof, or unknown governance state, a Discovery node must not update its valid projection. Convergence of an old index is determined by completion of verification and projection of the new version, not by the fact that a request has been sent.

Propagation checks should record the state observed by each node rather than comparing only resource counts. Equal counts may mean that an old version is still indexed, or that a new version has replaced the old one. The resource DID, version, digest, lifecycle state, publication sequence, and observation time must be compared. When an anomaly occurs, retain the last successful cursor and the original response so that missing or out-of-order events are not concealed by resetting the index.

18.15 Resource Ownership Transfer Strategy

An ownership transfer must be authorized by the former controller, confirmed by the new controller, and made effective after verification by the Root platform or a governance process. Resubmitting the same DID or presenting a new registration VC is not sufficient to prove a transfer. Operational maintenance authority and publication delegation may be authorized separately, but their scope, duration, and revocation method should be recorded separately from control authority. If the original private key is lost, control must not be forcibly taken over by bypassing signatures; an auditable governance recovery process should be used. Where the current implementation does not provide a complete transfer interface, this section is a protocol design requirement.

Before the control transfer is completed, the former controller remains the key source of evidence for resource updates and revocation decisions. A statement from the new controller, operational authorization, or resource package signature cannot independently override the old control relationship. After the transfer is completed, maintenance records should retain the former controller’s authorization, the new controller’s confirmation, the effective fact established by the Root platform or governance process, and the observation that the Discovery node has completed the update. This distinguishes “transfer proposed”, “transfer approved”, and “nodes converged”.

References