The flows in this chapter consistently use the state chain of “preparation, submission, verification, propagation, discovery, invocation, update or recovery.” Interface names, website buttons, and deployment addresses in the reference implementation belong to the example environment; the specification does not require every implementation to use the same interface, but it does require key facts to be independently verifiable. An end-to-end record must be associated with at least the resource DID, resource type, version, request identifier, source node, observation time, and evidence summary. “Completion” in a flow must be determined by the corresponding facts and evidence: the Registrar node returning an acceptance result, the Root platform forming a publication fact, the content distribution platform completing material transfer, and the Discovery node establishing an index are different stages and must not be merged into one success state.

This chapter assumes that the Local Identity and test resources are ready, node endpoints are accessible, and the test and production environments are isolated. It provides a reference path from resource creation, registration, trusted publication, discovery, and verification to update and fault handling. The examples show reproducible interaction relationships; they do not elevate a particular website button, current deployment address, or one successful response into a mandatory interface for all implementations. During execution, test resources, test subjects, and request identifiers should be isolated from production resources, and the associations among request materials, response summaries, DID Documents, registration credentials, Root proofs, synchronization cursors, and query results should be preserved.

Every step should record the input source, fact producer, verifier, state change, and evidence; a page prompt or a single successful HTTP response cannot represent end-to-end completion.

22.1 Create a Local Identity

The client generates the subject keys and subject DID locally, establishes a Local Identity record, and exports an identity backup file with a time identifier. When registering an agent service, skill package, MCP service, or tool API, the subject then generates or associates the resource identity and resource control proof locally. The private key remains within the publisher’s control and is not sent with an ordinary registration request; during recovery, the file structure, correspondence between the public and private keys, consistency of the subject DID, and the ability to sign again must be re-verified. Acceptance evidence includes the DID, public key, backup summary, and equivalence after recovery, rather than treating successful private-key upload as the result.

22.2 Register an Agent Service

Take as an example an agent service that declares “code repository search and project structure summarization.” The publisher first prepares the resource DID, capability tags, capability description, use cases, endpoint, protocol declaration, authentication conditions, and version, and then signs the DID Document or ResourcePackage materials with the local control key. The client submits the public registration materials and control proof to the Registrar node; the Registrar node validates the request and submits it to the Root platform, returning a registration result and a registration VC if one is available. The publisher must then wait for Root platform publication, content distribution, and Discovery node indexing, and obtain the corresponding states and evidence separately.

{
  "resourceType": "agent_service",
  "capabilityTags": ["code.repository", "analysis.summary"],
  "version": "1.0.0",
  "authorizedDomains": ["technology.software_engineering"]
}

Registration materials, request summaries, the registration VC (if any), Root platform status, ResourcePackage summary, and discovery results should be retained separately. “Submission succeeded” must not be written as “discovered across the network.” When submitting the same resource again, first determine whether the resource DID, version, or materials have changed; repeated requests for the same version should be judged by the actual response of the Registrar node as to whether they are idempotent, and a new version must not be inferred from a page prompt.

22.3 Register a Skill Package

A skill package example should provide its name, capabilities, inputs and outputs, use cases, dependencies, version, installation or invocation entry point, tags, subject DID, and resource DID, and calculate the content digest of the ResourcePackage. The publisher first normalizes and signs the materials locally, then submits them to the Registrar node; after submission, it checks the acceptance result, resource type, version, digest, and registration credential if any, and then checks Root platform publication and the Discovery node index in the order specified in 22.6. A skill package being installable or runnable locally does not mean that it has received Root platform publication or a Discovery node index.

Skill package acceptance checks two lines at the same time: the product line checks the entry point, dependencies, inputs and outputs, and use cases; the network line checks the DID, ResourcePackage version, digest, control signature, registration, publication, and index status. The results of the two lines are recorded separately. Failure of the product line means that the resource itself cannot be used as declared; failure of the network line means that the resource has not formed a verifiable network publication chain. The pass result of one line cannot replace the other.

22.4 Register an MCP Service

An MCP service example should prepare the server identity, tool or resource inventory, transport method, endpoint, authentication method, protocol version, and compatibility declaration. The publisher includes the inventory digest, service endpoint, and resource version in the resource materials and signs them locally. The Registrar node verifies the fields and control proof; after discovery, the caller must still establish a session according to the MCP flow and check the DID, ResourcePackage, publication evidence, and governance status according to OpenAgenet (OAN) rules.

22.5 Register a Tool API

A tool API takes an OpenAPI or equivalent description as input and specifies the operations, parameters, request body, responses, errors, authentication, server endpoint, and version. The publisher first determines the source and version of the description file, then binds the normalized description digest to the ResourcePackage and signs it; the Registrar node verifies the materials, and the caller can confirm through the digest that the obtained API contract has not been replaced. Digest verification cannot prove that the interface is currently available; actual business permissions are still determined by the API server.

operationId: searchRepository
source: openapi.yaml#/paths/~1repositories~1search/get
version: 1.0.0
schemaHash: sha256:<value>

The original description, normalized digest, and OAN control signature should be saved separately; being readable as a document does not mean that the interface is callable.

22.6 Publish and Distribute Resources

After a resource is accepted by the Registrar node, the Root platform verifies the control proof, node authorization, resource type, version, content digest, and publication conditions, and forms a Root proof. The content distribution platform saves and transfers the verified materials according to the publication list or cursor. The Discovery node receives, verifies signatures, validates, and establishes structured and semantic indexes according to the cursor. Each step records its result independently: successful registration must not substitute for discoverability, and material distribution must not substitute for completed indexing.

22.6.1 Registration Result

The registration result must contain at least the resource DID, resource type, version or digest, acceptance status, registration VC if the interface returns one, and an associated identifier. When the VC is empty, it can only be truthfully recorded as empty; a credential must not be fabricated. When the Registrar node rejects acceptance, the error reason should be retained, and the client may retry according to the request identifier or an idempotent method allowed by the protocol. The client should also record which node returned the registration result and the observation time, so that later asynchronous publication status is not mixed into the registration result.

{
  "resourceDid": "did:oan:AGDM:<identifier>",
  "status": "submitted",
  "registrationCredential": null,
  "observedAt": "<timestamp>"
}

submitted only represents the registration-stage result; it cannot be interpreted as Root platform publication or discovery visibility.

22.6.2 Root Platform Publication

The Root platform checks the Registrar node authorization, resource control signature, ResourcePackage integrity, version relationship, and governance conditions, then records the publication sequence and forms a Root proof after acceptance. Rejection, duplication, and asynchronous processing should each have an explicit status. When the Root platform has not accepted the resource, content distribution or local caching must not be marked as trusted publication. Publication evidence must be bound at least to the resource DID, version, and each digest; repeated processing must not produce mutually conflicting current versions.

The Root platform publication record must be associated at least with the resource DID, version, DID Document hash, metadata hash, package hash, Registrar node DID, publication sequence, and processing status; repeated processing should remain idempotent.

22.6.3 Content Distribution Platform

The content distribution platform provides the DID Document, ResourcePackage, digests, and proof materials according to the Root platform publication list or cursor. The recipient validates integrity and then records the receipt cursor. Resumable transfer and repeated delivery should be idempotent; successful distribution only means that the materials can be obtained, not that the Discovery node has established a queryable index. If the recipient finds that the digest, version, or proof is inconsistent, it should reject writing to the visible index and retain diagnostic information for the failed materials.

The distribution validation order is “list, content, digest, proof, cursor.” The sender records the batch and cursor; the recipient first verifies each version and digest and then commits the local state. Successful transfer does not mean that indexing is complete.

22.6.4 Discovery Node Indexing

After receiving the materials, the Discovery node verifies the Root proof, digest, version, governance status, and authorized domain, and then writes to the structured and semantic indexes. Completed indexing should have the resource DID, version, source, indexing time, and cursor evidence. A semantic index hit cannot override invalid proof or a revoked resource. The querying party should judge whether the result is fresh based on the indexing time and synchronization cursor, and return to the verifiable source for re-checking when the latest status is required.

The index record must contain at least resourceDid, version, source, authorized domain, lifecycle, indexedAt, and the synchronization cursor. Only verified materials enter the visible index; a semantic hit only provides a retrieval entry point.

22.7 Discover by DID

The caller submits the complete resource DID to the Discovery node as an exact query condition, for example by placing the DID in the query field when requesting /discovery/resources/query. The Discovery node returns the resource version, digest, source, lifecycle status, indexing time, and Root proof status in its current index. Pre-invocation verification must still be performed after obtaining the result. Not found, node not synchronized, stale index, and revoked resource should be handled separately; an empty result must not be directly interpreted as proof that the resource does not exist.

{
  "resourceDid": "did:oan:SKDM:<identifier>",
  "limit": 1
}

Acceptance should distinguish an exact hit, not found, not yet synchronized, stale index, suspended/revoked, and query error, and retain the querying node, request identifier, observation time, and response summary.

22.8 Discover by Structured Conditions

The caller queries by combining conditions such as resource type, subject type, tags, protocol, version, status, and authorized domain, and specifies field encoding, intersection/union relationships, filter order, pagination, and sorting. The Discovery node first applies hard conditions such as authorized domain and lifecycle, and then performs tag, protocol, or text-relevance processing; the actual filter order for each interface is subject to its protocol description. A tag match in the result only means that the retrieval condition was satisfied; the caller must still check the DID, signature, credential, publication evidence, version, and endpoint.

22.9 Discover by Natural-Language Task Description

The caller submits a task description, for example, “I need a tool that can search code repositories and summarize the project structure.” The Discovery node or its semantic component extracts capabilities, use cases, resource types, protocols, tags, and status conditions from the description, and then performs hard-condition filtering and semantic ranking. The current implementation may use a lexical, structured, vector, or hybrid path, depending on the deployment configuration. When returning results, it should retain the matched resource DID, resource version, source, and explanation fields when provided by the interface. Semantic relevance is not control or security authorization.

Task description -> capability/use-case extraction -> tags and structured conditions -> discovery query -> match rationale

The explanation result should distinguish the sources of text matching, tag matching, structured filtering, and semantic relevance.

22.10 Verify a Discovered Resource Before Invocation

The caller obtains the DID Document, ResourcePackage, Root proof, registration VC, and status information from the discovery result, verifies DID resolution, control relationship, credential, publication evidence, governance authorization, version, and endpoint in sequence, and then decides whether to invoke according to local policy. A discovery result is a candidate resource and an evidence entry point, not invocation authorization. When verification fails, status is unknown, evidence is stale, or endpoint authentication conditions are not met, high-risk invocation should be stopped and the reason recorded.

• [ ] DID and DID Document verification passed.
• [ ] ResourcePackage, version, and digest are consistent.
• [ ] The registration VC and Root proof are verifiable.
• [ ] Governance status and freshness satisfy the policy.
• [ ] Endpoint, authentication, and business permissions satisfy the invocation conditions.

The caller should not use the candidate object returned by the discovery interface directly as the final invocation object. A candidate is usually an indexed representation of ResourceDiscoveryCandidate; the complete DID Document and ResourcePackage must be obtained through the corresponding read interfaces. The content distribution platform’s resource package read returns ResourcePackage, the DID Document read returns DidDocument, and the metadata read returns ResourceMetadata. After successful reads, the caller should verify the resource DID, version, three types of hashes, registration VC, Root proof, and governance status in the same verification context.

22.10.1 DID Resolution

Resolve the complete resource DID, confirm that the method is did:oan, read the DID Document, and validate consistency among id, verification methods, control relationship, service endpoints, and resource metadata. Resolution not found, unsupported method, invalid document structure, and abnormal status should be handled separately; arbitrary same-name JSON must not be used as a substitute.

The resolution result should provide at least the following fields for continued verification in subsequent steps:

22.10.2 Control-Rights Verification

Verify the resource signature according to the verification methods and control relationships in the DID Document, confirming the normalized content covered by the signature, the resource DID, version, and predecessor relationship. Mathematical consistency between the public key and signature does not mean that the publisher is authorized to control another DID; verification must also bind the target DID and the existing control relationship. Verification inputs should come from the currently obtained DID Document and ResourcePackage, rather than only using truncated display fields in the discovery result.

Control-rights verification should be completed in the following order:

1. Obtain the verification method and public-key reference from the DID Document.
2. Confirm that the public key belongs to the control relationship of the target DID.
3. Reconstruct the signature input according to the declared normalization rules.
4. Verify that the signature covers the DID, version, ResourcePackage digest, and predecessor relationship.
5. Associate the verification result with the source information returned by the Registrar node, Root platform, and Discovery node.

22.10.3 Registration VC Verification

Verify the issuer, subject DID, resource type, version or digest, signature, validity period, and revocation/suspension status of the registration VC. When the VC is missing or the interface does not return one, handle it as unknown or incomplete as defined by the protocol; the page text “submission succeeded” must not be treated as a credential. A registration VC only proves the registration fact issued by the Registrar node; it does not automatically prove that Root platform publication and Discovery node indexing are complete.

22.10.4 Root Proof Verification

Verify the issuer, target resource DID, ResourcePackage version, package digest, metadata digest, publication sequence, and signature of the Root proof, and confirm that the Root platform’s own authorization status is valid. The proof only covers the facts it declares; it does not guarantee endpoint business quality.

The Root proof verification result should be recorded separately from the registration VC. The following is an example of a verification-result record; the status values describe the verification stage and are not fixed interface responses:

{
  "resourceDid": "did:oan:<method-specific-id>",
  "registrationCredential": "verified|missing|invalid",
  "rootPublicationProof": "verified|missing|invalid",
  "governanceStatus": "active|suspended|revoked|unknown"
}

Only when the target DID, version, and digests in the proofs are mutually consistent may the caller use “registered” and “published by the Root platform” as consecutive evidence; a missing item cannot be replaced by the other. After Root proof verification passes, the caller must also use the Discovery node’s indexing time and cursor to determine whether the resource is queryable.

22.10.5 Governance Status Check

Check node authorization, authorized domain, suspension or revocation events, and their freshness from a trusted governance-status source, and record the on-chain position, index cursor, and check time. When governance data is stale or the source is unavailable, sensitive invocations should be rejected or sent for manual review rather than being allowed by default.

The governance check must output at least the following decisions rather than only a Boolean:

22.11 Update a Resource While Retaining Its DID

The original controller generates a new DID Document or ResourcePackage version with the same DID, carries the predecessor version and content digest, and signs it using the existing control relationship. The Registrar node and Root platform re-verify it and produce new registration or publication evidence; the distribution and discovery nodes converge according to the publication sequence. Repeated submission of identical content should be idempotent, and an unauthorized new document must not overwrite the old version. Completion of an update must be determined from the new publication proof, downstream synchronization status, and query result together, rather than only from another successful registration-interface response.

22.12 Suspend, Revoke, and Recover a Resource

Resource suspension is triggered by the controller, governance, or a valid evidence status; revocation targets a resource or version; recovery requires rechecking the control proof, credential, publication proof, and endpoint. Each node should record the triggering fact, processing time, and propagation status according to its responsibility. The status in a discovery result is the status to which the node has synchronized and does not necessarily equal the time when the operation just occurred. A network timeout or temporarily offline node does not mean that the resource has been revoked. When propagation to the Discovery node is incomplete, the status and freshness should be displayed and historical evidence retained.

22.13 Connect a Third-Party Registrar Node

The third party submits the node DID Document, authorization request, authorized domain, public endpoint, and runtime configuration, and completes identity, signature, interface, resource-validation, security-boundary, and upstream-submission tests. After passing, it obtains registration eligibility within the explicitly defined scope only; while the node is running, its authorization status, versions, and failed-request retries must still be checked, and one acceptance test cannot permanently replace governance status. Connection tests should use isolated resources and retain test requests, responses, error branches, authorization scope, and validity period, so that test resources are not mistaken for formal network resources.

• [ ] The node DID Document, role, endpoint, and protocol version are consistent.
• [ ] The authorized domain is consistent with the governance authorization materials.
• [ ] Evidence exists for positive, negative, retry, and recovery cases.
• [ ] The private key and governance secrets are not included in public materials.

22.14 Connect a Third-Party Discovery Node

The third-party Discovery node obtains the node identity, authorization materials, and publication-source configuration, first completes a full synchronization to establish a baseline, and then performs incremental synchronization, digest validation, version selection, DID/structured/semantic queries, deduplication, freshness, and degradation tests. When providing results externally, it retains the source, version, indexing time, and authorized domain; local sorting must not be rewritten as a Root platform publication fact. A query interface being available does not mean that synchronized data covers the latest publication sequence.

The connection order is “establish a full baseline → incremental synchronization → inject duplicates/out-of-order/missing data → query and deduplicate → freshness and recovery verification.” Local sorting only affects display order.

22.15 Observe Governance Events Through the Network

After a governance event is produced on-chain, the off-chain trust indexer reads it in order and forms a node-authorization status read model. The Root platform and Discovery node then execute policies according to their synchronization status. An observer should record the event type, on-chain position, index cursor, projection time, and page display time, distinguishing on-chain facts from website display. Continued growth of latest_sequence only proves that the indexer is reading new events; whether the authorization status of a specific node has changed must also be checked against whether the corresponding event has entered the read model.

On-chain event -> indexer cursor -> authorization-status read model -> Root platform/Discovery node decision -> page observation

22.16 Resolve and Verify a Resource DID

The client first resolves the resource DID and DID Document, and then verifies the control relationship, resource metadata, service endpoint, version, and related publication evidence. The resolution result may be encapsulated by an SDK or local verifier, but the caller should still be able to obtain the original document, digest, and error status for auditing and review. Successful resolution only proves that the document can be read and passes structural checks; it cannot bypass checks of the ResourcePackage, credential, Root proof, and governance status.

It is recommended to output distinguishable statuses such as resolved, invalid, not-found, and status-unknown, rather than compressing every failure into an empty object.

22.17 Retrieve Historical Resource Versions

The caller requests historical ResourcePackages and their DID Documents, digests, and proofs by DID, version, or publication sequence, and explicitly identifies whether each has been superseded, revoked, or is for audit only. Historical content must not automatically become the currently discoverable or callable version merely because it can be read. When a historical version lacks the corresponding publication proof or status evidence, it should be marked as incompletely verifiable rather than supplemented with the current version’s proof.

Historical records must be associated at least with the DID, version/sequence, digest, publication proof, current status, and query time. “Readable” and “currently callable” must be two separate fields.

22.18 Handle an Unavailable or Stale Discovery Node

The caller determines whether discovery results are usable based on response errors, node health, indexing time, cursor, and declared freshness. An existing old snapshot may be displayed first to improve the experience, but its time and degraded status must be marked. For actions requiring the latest authorization or version, the caller should re-verify from a trusted source and must not rely only on an old cache.

22.18.1 Discovery Node Unavailable

When a discovery request times out, the connection fails, or an explicit service error is returned, record the node and associated identifier, and retry or switch to another authorized Discovery node according to policy. Unavailability represents infrastructure status; it does not automatically mean resource revocation, and an empty result must not be treated as proof that the resource does not exist on the network.

A retry record must contain at least the endpoint, request identifier, error type, count, backoff time, and last known indexing time. A connection failure must not be confused with a valid empty result.

22.18.2 Return an Old Snapshot

An old snapshot may be used for limited read-only display, but it must carry the generation time, source, and degraded-status marker. It may display the resource name, type, historical match results, and last indexing time, but it cannot by itself be used to determine current authorization, revocation status, endpoint availability, or invocation eligibility. If a resource in the snapshot concerns invocation, authorization, or a sensitive decision, the current DID Document, credential, publication proof, and governance status must be obtained and verified again before the action. After online evidence is obtained again, the new result should supersede the snapshot while retaining the temporal relationship between the old and new sources.

{
  "source": "discovery-node",
  "snapshotAt": "<timestamp>",
  "stale": true,
  "usableFor": "read-only-display"
}

22.18.3 Determine Data Freshness

Determine freshness from the indexing time, event cursor, latest upstream sequence, and allowed delay. A latest_sequence that does not increase may mean that there are no new events, or that synchronization has stopped; the most recent successful time and error evidence must also be considered. Unknown freshness must not default to latest.

A freshness report should provide indexedAt, lastSuccessfulSyncAt, latestSequence, cursor, and error status together; it must not display only one sequence number.

22.18.4 Switch to Another Discovery Node

Before switching, confirm the candidate node’s authorization status, endpoint, and supported query profiles, and retain the source node in the result. Results from different nodes need to be deduplicated and cross-validated by DID, version, digest, and publication proof; they must not simply be concatenated as equally trusted results.

Switching checklist:

• [ ] The candidate node DID, role, and authorization status are valid.
• [ ] The query profile and authorized domain meet the caller’s requirements.
• [ ] Results are deduplicated by DID, version, and digest.
• [ ] Conflicting results are checked against Root platform publication evidence.

22.18.5 Re-synchronize After Recovery

After the node recovers, fill gaps from the persisted cursor or trusted publication sequence, re-verify affected versions and revocation status, and then update the index projection. Recovery is complete when the cursor catches up within the allowed range, key resource queries are consistent, and error alerts have recovered; process restart alone is not sufficient.

Recovery verification should sample at least one newly added resource, one updated resource, one revoked or suspended resource, and one resource that did not change during the outage, confirming that recovery did not only restore the count while missing lifecycle states.

The recovery completion criterion can be written as:

Cursor caught up + key resource consistency + lifecycle re-filtering + error alerts recovered

References