This chapter explains how the security boundaries of OpenAgenet (OAN) cover resource control, node authorization, root-platform publication, discovery results, governance state, invocation endpoints, and users’ local identities. An attacker may send public requests, submit forged or low-quality resources, issue repeated requests, observe public DIDs and VCs, or operate a compromised node. Security controls must state the protected object, attack preconditions, control point, failure result, verification evidence, and recovery action. The trustworthiness of discovery results does not imply the security of the business endpoint.

Security requirements uniformly use the following decision chain. The tables and checklists in the subsequent sections should all be traceable to this chain:

Attack preconditions -> Protected object -> Verification or control point -> Failure result -> Audit evidence -> Recovery action

17.1 Threat Model and Trust Assumptions

The threat model treats the resource provider, Registrar node, Root platform, content distribution platform, Discovery node, off-chain trust indexer, browser, and invocation endpoint separately. The resource-control private key is held by the controlling party, governance keys are used only for governance actions, and the indexer is a read-side projection of on-chain facts. The protocol cannot automatically repair a leaked key, a fully compromised host, or a vulnerability in a business endpoint.

Trust assumptions should be recorded separately by component and material:

17.1.1 Resource-Control Threats

Resource-control threats include copying a public DID, DID Document, and VC to impersonate the controller, or using a new document to overwrite the same DID. The control points are the verification method, control challenge, signature, and version relationship. An incorrect public key, incorrect challenge, forged signature, or overwrite by an old version must be rejected.

17.1.2 Node-Trust Threats

Node-trust threats include an unauthorized node impersonating a Registrar node, an authorized node exceeding its privileges, and continued operation after suspension or revocation. The control points are the node DID, node authorization VC, governance events, authorized domain, and capability scope. Network reachability or historical success cannot replace current authorization.

17.1.3 Data-Poisoning and Abuse Threats

Data poisoning includes batches of fake resources, duplicate DIDs, low-quality descriptions, malicious tags, false endpoints, and forged ranking signals. Control points include control proofs, idempotency rules, lifecycle, independent root-platform verification, tag boundaries, review, and rate limiting. Rejection records should distinguish specific reasons.

17.1.4 Availability Threats

Availability threats include registration flooding, complex semantic queries, oversized ResourcePackages, concurrent synchronization, database lock contention, and unavailable external dependencies. Control points are size limits, timeouts, concurrency quotas, pagination, query degradation, queue isolation, and backoff. Retries must not be unlimited.

17.1.5 Invocation-Endpoint Security Threats

Invocation-endpoint threats include malicious URLs, internal-network callbacks, insecure protocols, redirect bypasses, and compromised endpoints. Control points are protocol, domain, resolved address, port, redirect, and authentication validation. When validation fails, high-risk access must be blocked and the redacted reason recorded.

17.2 Resource Impersonation and DID Control Protection

The control relationship of a resource DID is established by the public key and control proof in the DID Document. A public DID, DID Document, registration VC, or Root proof cannot independently grant update authority. An update to the same DID must use the original control relationship or a control-transfer process permitted by the method; it must not be accepted merely because a new document is internally self-consistent.

The resource-control relationship can be checked item by item as follows:

“A signature with a valid format” alone is insufficient to prove control. The verifier must confirm that the signing public key is declared by the target DID Document and that the signature covers this specific operation.

17.3 Protection Against Forged Registration and Unauthorized Updates

Registration and update requests separately validate the source, node authorization, control proof, document hash, metadata hash, ResourcePackage hash, version, and idempotency state. An old version, old nonce, or incorrect hash must not overwrite the current record. Tests cover missing proofs, invalid signatures, invalid versions, incorrect hashes, and duplicate submissions.

Rejection conditions for registration and updates should be distinguishable to clients:

17.4 Malicious or Compromised Registrar Nodes

The Root platform must not trust only the conclusion forwarded by a Registrar node. It should re-verify the node identity, authorization, control proof, DID Document, ResourcePackage, and request signature. If the node exceeds its authority or the materials have been altered, publication is rejected. A Registrar node’s historical record does not automatically become a root-platform publication fact.

17.5 Malicious or Compromised Discovery Nodes

Callers should verify the source of the discovery response, the identity of the query node, index version, resource DID, DID Document, version, Root proof, lifecycle, authorized domain, and governance state. High relevance or HTTP success cannot replace verification. If a Discovery node is compromised, its authorization can be revoked and its index can be stopped from being used.

17.6 Root-Platform Compromise and Key Protection

A compromised Root platform may alter materials pending publication, forge Root proof, block propagation, or expose configuration. Publication keys and databases should be isolated, with least privilege, controlled signing, hashes, auditing, backup validation, and node resynchronization. Recovery must not change resource-control private keys or on-chain facts.

17.7 Spam Registration and Resource-Catalog Poisoning

Catalog-poisoning governance focuses on resource authenticity, availability, and semantic quality. The registration entry retains the control proof and subject, the Root platform independently verifies and isolates suspicious resources, and Discovery nodes filter by lifecycle, governance state, and publication evidence. Cleanup must distinguish rejection, suspension, revocation, and node-authorization revocation.

Spam-registration governance should not rely on a single score. Before processing, it should combine the control proof, resource type, tag namespace, endpoint verifiability, duplication, source node, and governance state. After processing, it should record the action and propagation scope.

• [ ] Apply multidimensional rate limits by subject, node, interface, and time window to batch requests.
• [ ] Distinguish network retries, idempotent submissions, and actual version updates for duplicate DIDs.
• [ ] Preserve the distinctions among normative tags, aliases, and inferred matches for low-quality or malicious tags.
• [ ] Distinguish suspension, revocation, taking offline, and node-authorization revocation for published resources.
• [ ] After cleanup, verify convergence of the Root platform, content distribution platform, and Discovery nodes.

17.7.1 Fake Resource Registration

Fake registrations are identified by signals such as missing control proofs, inconsistent DID Documents, unverifiable endpoints, or forged metadata, and are rejected before entering publication. Public errors must not echo private keys or complete signature materials.

17.7.2 Duplicate Registration and Version Poisoning

Duplicate registration may be a network retry, an update to the same DID, or a malicious submission. The system distinguishes these cases using the resource DID, version, document and ResourcePackage hashes, and request ID. A duplicate valid request returns a stable result, while a real update follows control and version rules.

17.7.3 Semantic-Tag Poisoning

Tag poisoning includes occupying popular tags, disguising non-normative tags as normative tags, cross-type mismatches, and misleading keywords. Registration validates tag IDs, vocabulary versions, type relationships, and namespaces. Discovery distinguishes normative tags, aliases, original text, and semantically inferred matches.

17.7.4 Rate Limiting, Review, and Cleanup

Rate limiting, review, and cleanup are applied by source, subject, node DID, resource DID, interface, and risk level, while retaining the reason, operator, and impact scope. After cleanup, convergence of the Root platform, content distribution platform, and discovery index should be verified.

17.8 Denial of Service and Resource Exhaustion

Registration, discovery, synchronization, health, and governance queries are configured with separate resource budgets. Limits apply to request bodies, batches, decompression expansion, query depth, concurrency, database connections, and external-call time. A semantic backend failure may fall back to a constrained path, but must not relax trusted filtering. Degradation must be marked as incomplete or unconfirmed.

Resource budgets should be isolated by path so that high-cost discovery queries do not bring down registration and health checks:

17.8.1 Registration-Interface Attacks

Registration attacks include high-frequency submissions, oversized JSON, duplicate DIDs, expensive signature verification, and dependency calls. The entry point first performs size, rate, idempotency, and format checks, and then performs high-cost validation. Failed requests must not trigger continuous publication retries.

17.8.2 Discovery-Query Attacks

Discovery attacks include unbounded broad queries, complex semantic retrieval, duplicate queries, and result amplification. Limit input length, page size, candidate count, execution time, and concurrency, and use stable cursors and caching. Degradation must not bypass governance filtering.

17.8.3 Inter-Node Synchronization Pressure

Synchronization pressure includes large batches, cursor replay, excessive parallelism, retry storms, and unavailable distribution. The synchronizing party uses batch and concurrency limits, exponential backoff, and cursor idempotency. A duplicate batch must not be written or advance state again.

17.8.4 Database and Index Resource Exhaustion

Database and index exhaustion includes connection-pool depletion, locks, disk exhaustion, and index bloat. Field and batch limits, index maintenance, timeouts, isolated queues, retention policies, and capacity alerts should be provided. When resources are insufficient, valid data and health queries should be protected first.

17.9 Replay, Duplicate Submission, and Expired Publication

Replay protection distinguishes requests, registrations, publications, synchronization batches, and old caches. Request IDs, nonces, time windows, and signatures prevent a request from being accepted again. DID, version, preceding version, and hashes determine business updates, while cursors and batch sequences ensure idempotent synchronization.

The decision order for replay and duplicate submissions should prioritize idempotency and handle state updates cautiously:

17.10 Endpoint Abuse and Unsafe Resource Invocation

Before invocation, check the endpoint protocol, certificate, domain, resolved address, authentication, version, lifecycle, governance state, and publication evidence. Where necessary, negotiate business permissions, sign requests, and validate responses. OAN does not guarantee that a business endpoint is free of vulnerabilities or malicious behavior.

Before using discovery results, the caller should complete at least the following checks:

• [ ] The resource DID, DID Document, public key, and version digest are consistent.
• [ ] The Root proof, lifecycle, and governance state remain verifiable.
• [ ] The endpoint protocol, domain, certificate, resolved address, port, and redirects comply with local policy.
• [ ] The authentication, authorized domain, request signature, and response validation required for invocation are defined.
• [ ] The freshness and source of the Discovery node’s result are not mistaken for a guarantee of the business service.

17.11 Sensitive Metadata and Credential Exposure

Private keys, Local Identity backups, internal endpoints, database paths, administrative tokens, unpublished resources, complete signature originals, and log fields that can be associated with individuals are sensitive information. Public interfaces must not return Local Identity backups. Server logs require allowlisting, redaction, and access control.

17.12 Logging, Auditing, and Incident Response

Security logs correlate the request ID, resource DID, node DID, version, event or cursor, source, result, error code, and time, and distinguish on-chain evidence, service logs, and manual records. Log-write permissions should be restricted. Alerts should locate isolation, revocation, rate limiting, compensation, and recovery verification actions.

Incident response should retain the minimum evidence that remains correlatable:

request_id / resource_did / node_did / version / event_or_cursor
source / result / error_code / observed_at / operator_action

17.13 Security Requirements for Third-Party Nodes

Third-party nodes protect their own hosts, node private keys, authorization VCs, configurations, databases, dependencies, and ports, and connect through the node DID, DID Document, node authorization, and request signature. In an abnormal situation, authorization may be suspended or revoked. A resource provider must not be required to surrender a subject or resource-control private key.

Before a third-party node connects, an auditable minimum inspection record should be created containing the node DID, DID Document, node authorization VC, authorized domain, validity period, public endpoint, software version, key custody method, and revocation contact. A resource provider submits only the resource control proof and should not surrender a subject or resource-control private key.

17.14 Endpoint Validation, Callback Security, and SSRF Considerations

Before reading or invoking an endpoint, callback, or synchronization address, validate the protocol, host, port, resolved address, redirect, and authentication. Private, loopback, link-local, and cloud-metadata addresses are blocked according to policy. DNS rebinding must be prevented between resolution and connection. Rejection reasons must be auditable without exposing topology.

SSRF protection should cover four points: before resolution, after resolution, before connection, and after each redirect. Checking a URL only at the string level is not sufficient. When rejecting a request, record the policy-match category and request ID, but do not echo internal addresses, network topology, or resolution details.

17.14.1 Endpoint Format and Protocol Validation

Allow only supported protocols and permitted port ranges. Reject endpoints with a missing host, invalid encoding, embedded credentials, or an incompatible type. HTTPS certificates and host names are validated according to risk. HTTP in a development environment must not become the default public security configuration.

17.14.2 Internal and Loopback Address Restrictions

Before every connection, check IPv4, IPv6, loopback, private, link-local, reserved, and cloud-metadata addresses. Use standard resolution and network policies rather than relying only on a string blacklist.

17.14.3 Callback Request Security

Bind callbacks to a one-time request ID, source context, and target. Limit methods, request headers, response size, and timeout. A callback must not change authorization or governance state. Failed retries must be limited.

17.14.4 Redirect and DNS-Resolution Risks

DNS resolution results, connection targets, and the redirect chain are evaluated as one decision. Revalidate after a redirect to a different host, protocol, or restricted address. Timeouts, certificate changes, or inconsistent resolution should fail closed.

17.15 Package and Dependency Supply-Chain Integrity

Source code, Cargo/npm dependencies, lock files, build artifacts, and ResourcePackages form the supply-chain boundary. Builds use locked dependencies, controlled sources, hash or signature verification, and traceable commits. ResourcePackages are hashed again before entering the Root platform or a Discovery node.

Supply-chain verification covers the “source-lock-build-artifact-deployment” chain:

1. Check the source commit, dependency lock files, and controlled package sources.
2. Build Rust, TypeScript, and community Skill artifacts in a reproducible or controlled environment.
3. Save a digest or signature for binaries, npm packages, ResourcePackages, and distribution materials.
4. Compare artifact digests before deployment, and record the version and rollback materials after deployment.
5. If a dependency or artifact is abnormal, stop publication, preserve evidence, and rebuild.

17.16 Availability Objectives and Graceful Degradation

Security state and availability are expressed separately. An old snapshot may support a read-only result with a freshness marker, but must not approve registration, publication, authorization, or high-risk invocation. Dependency failure, index lag, unknown governance state, and resource exhaustion should have different states and recovery actions.

The acceptance focus for graceful degradation is not merely that “the page still has content.” Users and callers must be able to see the freshness, source, and uncertainty of the content, and old data must not automatically execute registration, publication, authorization, or high-risk business invocation.

References