This chapter explains how the Root platform converts resource materials submitted by a Registrar Service Node into verifiable network-level publication facts. It covers upstream request authentication, resource DID and control-proof verification, node authorization, ResourcePackage integrity, publication policy, issuance of the Root Platform Trusted Publication Proof, version selection, distribution tasks, and failure recovery. It continuously distinguishes among “verified and queued,” “publication fact formed,” “content distributed,” and “indexed by a Discovery Service Node.”

9.1 Root Platform Publication Responsibilities

“Verified and queued,” content distribution, and discovery indexing in this flow correspond to different completion conditions. A successful response from the Root platform means only that the resource has passed Root-platform processing and entered the distribution task chain. The Content Distribution Platform and Discovery Service Node must still complete their own validation, publication, or indexing, and the caller should independently verify the DID, registration VC, Root Platform Trusted Publication Proof, and status information.

The Root platform is an independent verification boundary before a resource enters the network-level publication path. It receives registration materials submitted by an authorized Registrar Service Node, re-verifies the resource DID, DID Document, resource control proof, ResourcePackage, node authorization, version, and publication conditions, and writes the verified resource version to the publication record. Pre-validation by a Registrar Service Node is an access-layer check and cannot replace the Root platform’s independent confirmation of the publication fact.

In operational terms, Root-platform “acceptance” contains two consecutive but distinguishable facts: first, the resource materials pass Root-platform verification and are persisted; second, a publication task for the Content Distribution Platform is created. The current successful response is resource-verified-and-queued. Therefore, a Registrar Service Node or client should interpret it as “verified and queued,” not directly display it as “network-wide publication completed.”

9.2 Upstream Submission by a Registrar Service Node

A Registrar Service Node submits a resource registration request with upstream authentication, rather than uploading an unproven ResourcePackage. The request should be associated with the Registrar Service Node DID, request identifier, protocol version, target path, time, nonce, request-body hash, and signature, and should carry the resource registration submission and its control proof. The Root platform should first verify the submission source and request integrity, and only then process the resource content. A request that is duplicated, expired, or addressed to the wrong audience must not enter the publication state.

The current entry point is POST /root/resources/verify-and-publish. After receiving the request, the Root platform loads authorization materials according to the Registrar Service Node DID, verifies the SignedRequestEnvelope signature, method, path, audience, time, nonce, and request-body hash, and only then performs structural and content validation of the resource submission. The upstream signature proves “which Registrar Service Node submitted these materials.” It is neither a resource control proof nor a Root Platform Trusted Publication Proof.

The request type for this entry point is ResourceVerifyAndPublishRequest. Its minimum relationship can be represented as follows:

{
  "registrarDid": "did:oan:...",
  "submission": {
    "resourceDid": "did:oan:SKDM:...",
    "resourceType": "skill",
    "didDocument": {},
    "metadata": {},
    "packageVersion": "1.0.0",
    "didDocumentHash": "sha256:...",
    "metadataHash": "sha256:...",
    "packageHash": "sha256:...",
    "hashAlgorithm": "sha256",
    "subjectControlProof": {}
  },
  "upstreamAuth": {}
}

The current successful response is dynamic JSON. Its core result is status: resource-verified-and-queued, together with the resource DID, resource type, package version, three classes of hashes, lifecycle state, and cdnDispatchStatus: queued. This means that the Root platform has completed the current verification and created a Content Distribution Platform task. Receipt by the Content Distribution Platform and indexing by a Discovery Service Node must be confirmed through their respective status or synchronization records.

9.3 Resource DID and Control-Proof Verification

The Root platform should first resolve the resource DID and confirm that its resource type matches the DID’s semantic encoding. It should then confirm that the DID Document id, resource type, verification methods, and service declarations satisfy the method rules, and finally use the public key declared in the document to verify the control proof. The control proof must bind the current challenge, target resource DID, DID Document hash, purpose, and validity period. A verification failure must prevent the version from entering the publication record and must not overwrite an existing valid version.

A reproducible negative test is to prepare a submission that passes validation, record the Root platform’s current resource version and publication-task count, and then modify only one of resourceDid, didDocument.id, didDocumentHash, or the control challenge’s subjectDid. The Root platform should return the corresponding error, and the failed request should not add or overwrite an acceptance record or Content Distribution Platform task. This verifies that the Root platform does not mistake “the request was reachable” for “resource control was proved.”

9.4 Registrar Service Node Authorization Verification

The object of Registrar Service Node authorization is infrastructure-node qualification, not resource control. The Root platform should determine whether a node may submit the applicable resource by using the node DID, target role, authorization VC, authorization domain, stable DID Document hash, issuer, and current governance state. If authorization is expired or revoked, the role does not match, or the authorization domain does not cover the target resource, the submission should be rejected or isolated. The check must not be relaxed merely because the request came from a known address.

The Root platform’s decision contains at least two steps: whether the node remains in an available governance state, and whether the node’s authorization scope covers the resource’s authorization domain. The first handles node revocation, suspension, or authorization expiry. The second handles cases in which a Registrar Service Node may serve only part of the resource authorization domain. Even if a Registrar Service Node has successfully issued a registration VC, the Root platform must still re-evaluate the current authorization state before accepting publication. A registration VC cannot replace the Root platform’s node-authorization check.

9.5 ResourcePackage and Hash Verification

The Root platform should recompute the DID Document hash, metadata hash, and ResourcePackage hash according to the unified canonicalization rules, and check consistency among the hash-algorithm prefix, resource DID, resource type, package version, and nested fields. Any hash mismatch, inconsistent treatment of circular fields, or inconsistency between package content and its declarations is an integrity failure. Failed materials may be retained as diagnostic records, but must not enter the distributable-resource set.

After successful recomputation, the Root platform organizes the resource DID, resource type, version, three hashes, lifecycle, and authorization domain into packageClaims, and writes the Root proof into the ResourcePackage’s rootProof. A verifier should use consistency between these claims and the actual ResourcePackage fields as evidence. Merely seeing a client-submitted packageHash, or checking only its string format, is insufficient to prove ResourcePackage integrity.

9.6 Metadata and Endpoint Policy Checks

Policy checks determine whether materials that have passed identity and integrity checks are suitable for the network publication path. The Root platform should check consistency among resource type, capability tags, authorization domain, protocol bindings, service endpoints, lifecycle, and version declarations, and prevent private keys, access tokens, and internal credentials that should not be public from entering public resource materials. Passing a policy check does not guarantee endpoint quality; endpoint invocation is still authorized jointly by the caller and the resource service.

Policy-check results should be recorded separately from subsequent propagation stages. Materials that pass the checks may enter the Root platform acceptance record and Content Distribution Platform task. Whether an endpoint is online, whether the Content Distribution Platform has completed hosting, and whether a Discovery Service Node has completed indexing must be confirmed by the respective later services. If a resource contains a private key, access token, or an internal address that should not be public, it must be rejected or isolated before public distribution materials are formed; the system must not rely on a Discovery Service Node to remedy this during indexing.

9.7 Issuance of the Root Platform Trusted Publication Proof

9.7.1 Issuance Preconditions

The Root Platform Trusted Publication Proof may be issued only after the submission source, Registrar Service Node authorization, resource control proof, DID Document, three classes of hashes, resource version, and publication policy have all passed verification. Before issuing the proof, the Root platform should also confirm that the current governance state does not prevent the node or resource version from entering the publication path. Pending verification, pending review, or distribution failure must not be converted directly into published.

9.7.2 Proof Contents

The proof should bind at least the Root platform DID, resource DID, resource type, ResourcePackage version, DID Document hash, metadata hash, ResourcePackage hash, hash algorithm, lifecycle state, and issuance time. If the proof contains an authorization domain, publication cursor, or announcement reference, it must clearly state whether those fields cover a publication fact or a propagation fact. They must not include business conclusions that were not declared by the resource controller.

9.7.3 Proof Signature

The Root platform should sign the prescribed proof contents with its protected signing key and specify the cryptographic suite, signature coverage, and verification-method reference. A verifier should first confirm that the issuer belongs to the trusted Root platform, and then check that the signature input exactly matches the current ResourcePackage. Being able to parse JSON or see a Root platform DID is insufficient to prove that the signature is valid.

9.7.4 Proof Retrieval and Verification

The resource provider, Content Distribution Platform, and Discovery Service Node may obtain the proof through the Root platform publication interface, publication materials, or an associated address. A verifier should check the proof status, target resource DID, version, hashes, issuance time, and Root-platform authorization state, and retain the verification result. Successfully obtaining the proof does not mean that a Discovery Service Node has completed indexing.

The Root Platform Trusted Publication Proof should be used with one determined resource version. A verifier should at least associate the Root platform DID, resource DID, package version, DID Document hash, metadata hash, ResourcePackage hash, proof, and verification time. The verifier must recheck the hashes and proof status when retrieving the same resource again. A registration VC issued by a Registrar Service Node, the Root Platform Trusted Publication Proof, and a Discovery Service Node index record prove different stages and cannot replace one another.

9.8 Publication Sequence and Version Selection

9.8.1 Publication Sequence

The publication sequence identifies the order of resource publication facts in the distribution path. It should advance monotonically and be bound to the resource DID, resource version, and package hash. Re-reading or retrying the same publication task must not create a new logical publication fact, and a Discovery Service Node synchronization cursor must not be treated as the Root platform publication sequence.

9.8.2 Version Selection for the Same DID

Version selection for the same resource DID should consider the ResourcePackage version, predecessor-version relationship, package hash, control proof, and Root platform publication sequence. Identical materials can be confirmed idempotently. Materials with different content but no valid control proof or version relationship should be rejected or isolated, rather than allowing the arrival time to overwrite an existing published version.

9.8.3 Duplicate Submission Handling

When the Root platform receives a submission whose resource DID, package version, and package hash are exactly the same as an existing resource, it may return the existing publication result or a duplicate-submission status while keeping the original publication cursor and proof unchanged. The duplicate-submission record should still be associated with the new request identifier so that network retries can be distinguished from actual version updates during audit.

9.8.4 Conflicting-Version Handling

If the same DID has the same version with a different hash, the same publication sequence with different content, an inconsistent predecessor version, or a proof with inconsistent coverage, the submission should enter conflict or isolation handling. The system must not automatically choose the first-arriving version. The Root platform should retain a conflict summary and rejection reason. Only new materials from the controller that satisfy the version and control conditions may be verified again.

When investigating a version problem, inspect the resource DID, package version, three hashes, predecessor relationship, and publication cursor together. Do not select a version only by request arrival time. The publication cursor is ordering evidence in the Root platform publication record and distribution path; it is neither resource control nor a Discovery Service Node synchronization cursor. Even after a Discovery Service Node sees the cursor advance, it must still validate the specific ResourcePackage and Root proof.

9.9 Publication Status and Rejection Reasons

The current successful response from the Root platform is resource-verified-and-queued. It means that the resource has passed Root-platform processing and entered the Content Distribution Platform task chain; it does not mean that the Content Distribution Platform has completed publication. External processing should distinguish at least the following states:

Rejection reasons should preferentially use stable codes such as registrar_not_authorized, did_document_hash_mismatch, metadata_hash_mismatch, and package_hash_mismatch. An invalid control proof, unauthorized node, and inconsistent hash are verification failures that block publication. Event-delivery failure or temporary Content Distribution Platform unavailability is a recoverable subsequent failure. These two categories must not both be displayed only as “publication failed.”

9.10 Content Distribution Preparation

After accepting a resource, the Root platform persists the ResourcePackage, publication task, and event-publication intent, and hands the task to the Content Distribution Platform through a content-distribution event. The event may carry only replayable references such as the resource DID, package version, publication cursor, Root platform DID, and hashes; the Content Distribution Platform then retrieves the ResourcePackage from the Root platform. The current design uses a transactional outbox to keep the resource acceptance record, publication task, and event intent consistent. If event sending fails, the outbox relay retries it.

{
  "jobKey": "did:oan:SKDM:example-resource:1.0.0",
  "resourceDid": "did:oan:SKDM:example-resource",
  "packageVersion": "1.0.0",
  "publicationCursor": 123,
  "rootDid": "did:oan:ROOT:example-root",
  "packageHash": "sha256:<example-package-hash>",
  "didDocumentHash": "sha256:<example-did-document-hash>",
  "metadataHash": "sha256:<example-metadata-hash>"
}

Acceptance by the message system does not mean that content publication is complete. The Content Distribution Platform should confirm the task after retrieving the ResourcePackage, verifying the Root proof and hashes, and completing its own publication. A Discovery Service Node should also independently validate the ResourcePackage and proof after receiving propagation materials.

9.11 Root Platform Publication Audit Trail

The audit chain should trace a complete publication decision from a request identifier or task key: what the Registrar Service Node submitted, which fields the Root platform verified, what the ResourcePackage and hashes were, which publication cursor was generated, whether a Content Distribution Platform task was created, whether the event was delivered, and how the task was ultimately processed. At least the following field groups are recommended:

Audit records may retain summaries and references. They must not contain subject private keys, resource-control private keys, identity backups, or access tokens. Public resource fields and internal diagnostic fields should have separate read permissions so that an audit interface does not become a side channel for sensitive materials.

9.12 Republish, Rollback, and Recovery

When distribution fails, first retry the publication task with the same resource DID, package version, hashes, and task key. Do not generate a new resource identity merely to resend a transmission, and do not interpret a transport retry as a new version. After data recovery, restore the Root platform acceptance record, publication task, and outbox state first, and then rebuild incomplete event delivery. When rolling back to a historical version, the historical version’s DID, version, hashes, and Root Platform Trusted Publication Proof still correspond to the original fact. If the resource content changes, a new control proof must be generated, hashes recomputed, and Root-platform verification performed again.

Distribution failure
  -> Retain the original jobKey, resource DID, version, and hashes
  -> Check the task lease, retry count, and last error
  -> Retrieve the same ResourcePackage and verify the Root proof
  -> Confirm the task after the Content Distribution Platform succeeds
  -> Let Discovery Service Nodes continue synchronization by publication cursor

9.13 Same-DID Update Authorization and Version Acceptance

An update under the same DID must not be decided by comparing version strings alone. The Root platform should confirm that the new materials remain authorized by the current control relationship, that the DID Document, resource metadata, and ResourcePackage hashes correspond to the new materials, and that the new version can establish a predecessor relationship with the existing version. The same version with the same hash is handled as an idempotent retry. The same version with a different hash is a conflict. A new version whose control proof remains bound to the old DID Document hash must be rejected before the acceptance record is written.

A reproducible acceptance test can fix an accepted v1 and submit, separately, an identical v1, a v1 with a different hash, a v2 with a valid control proof, and a v2 without a predecessor relationship. The acceptance criteria are: the first case produces no second logical publication fact; the second does not overwrite v1; the third enters new-version processing; the fourth is rejected or isolated; and every result can be explained from the request, version, and hash fields.

9.14 Publication Rejection, Isolation, and Reprocessing

A clear verification failure should be rejected directly with its reason. Isolation is appropriate only when the materials cannot yet be determined, depend on external governance state, or require review. An isolation record should retain the original submission summary, resource DID, version, hashes, Registrar Service Node, failure stage, and reprocessing conditions, but must not appear in a Content Distribution Platform manifest or discovery index. Reprocessing must check current authorization, control-proof validity, hashes, and governance state again; it must not merely change the old status to “published.”

9.15 Root Platform Publication State Machine

9.15.1 Pending Verification

Pending verification means that the Root platform has received a submission or publication task but has not completed all necessary checks. This state may allow processing-status and diagnostic queries, but must not enter the trusted distribution manifest or be presented externally as registration success, Root-platform publication, or discovery visibility.

9.15.2 Verification Passed

Verification passed means that the resource materials, control proof, node authorization, and publication conditions have passed Root-platform checks. If the Root proof has not been issued or the publication record has not been persisted, however, this state is still not equivalent to published. The transition should have a clear submission identifier, verification time, and evidence reference.

9.15.3 Published

Published means that the Root platform has formed a publication fact and Root Platform Trusted Publication Proof bound to a specific resource version, and permits the related materials to enter the Content Distribution Platform path. It does not mean that the Content Distribution Platform has completed hosting, that a Discovery Service Node has completed indexing, or that the caller has obtained permission to invoke the business service.

9.15.4 Rejected, Isolated, and Recovered

Rejected means that the current submission does not satisfy a necessary condition. Isolated means that the materials require review, completion, or a change in external state. Recovery must recheck current authorization, signatures, hashes, and governance state. A distribution failure may trigger pending retry; it must not alter the existing resource version or forge a new Root Platform Trusted Publication Proof.

During recovery, use the original submission’s resource DID, version, and material summary as the association basis, and run the current authorization, control-proof, hash, and governance-state checks again. Only after passing verification may isolated materials return to the publication flow. Network retries must not change the resource version or generate a new Root Platform Trusted Publication Proof. The Root platform’s “published” state still means only that a publication fact has been formed; it does not mean that every Discovery Service Node has indexed the resource.

References