This chapter defines the stable rules for did:oan as the resource identity method of OpenAgenet (OAN). The method layer answers “whether an identifier is valid, what object it identifies, how to obtain the corresponding DID Document, and who can prove control.” It does not answer whether a resource has been registered, whether the Root platform has published it, or whether a Discovery Service Node has indexed it. Registration, publication, distribution, and discovery states in the resource network should refer to the objects and evidence defined in other chapters of this manual.

An implementation of the did:oan method must simultaneously satisfy four conditions: syntactic parsability, explainable semantic encoding, verifiable DID Document structure, and verifiable control signatures. Its DID Document also uses oanMetadata to place resource identity and capability semantics in one parsable object: capability tags provide governed classification keys, capability descriptions explain the tasks that the resource can perform, use cases describe typical usage contexts, and protocol bindings and service references explain how to connect to the resource. This design allows the core descriptions required for semantic discovery to be obtained immediately after resolving the DID. It also binds semantic declarations to resource identity and version through the document hash, control proof, and ResourcePackage, making this an important innovation of did:oan for intelligent-agent resource discovery.

5.1 Method Purpose and Identifier Scope

did:oan can identify Agent Services, Skills, MCP Servers, and Tool APIs. It can also identify subjects, organizations, and infrastructure nodes when these objects are permitted by the method definition. The first two positions of the method-specific semantic code distinguish the object category, while the latter two positions represent the application or semantic domain. Resource DIDs, subject DIDs, Registrar Service Node DIDs, Discovery Service Node DIDs, and Root platform DIDs serve different purposes and must not be conflated merely because they use the same DID method.

Uniqueness first means string uniqueness within the method namespace. Random generation depends on cryptographically secure random numbers, while deterministic derivation is jointly determined by semantic encoding, control material, and a nonce. When a resource is propagated through different Registrar Service Nodes or Discovery Service Nodes, its resource DID does not change because the entry point changes. Historical versions of the same DID should be associated through versions, hashes, publication sequences, and historical DID Documents rather than by arbitrarily generating a new DID for every update.

In the OAN network topology, the entry node and the identity object are two different relationships. A client may submit a resource through one Registrar Service Node and query the same resource from multiple Discovery Service Nodes, but the DIDs of those service nodes identify the nodes themselves. The resource DID is still generated or held by the resource controller. A resolver should obtain the corresponding DID Document from the resource DID instead of embedding the submission entry point into the DID.

5.2 DID Syntax and Method-Specific Identifier

The method-specific identifier uses the form did:oan:<semantic-code>:<suffix>. semantic-code must contain 4 ASCII uppercase letters or digits. Its first two positions are the subject code, and its last two positions are the application-domain code. suffix must contain 32 Base58 characters and must use the Base58 character set defined by OAN. Easily confused characters such as 0, O, I, and l are not permitted. A method implementation validates the complete DID, the number of segments, the semantic code, and the suffix separately.

For example, did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu is a syntactically parsable Skill DID. A string with incorrect case, a suffix whose length is not 32, an illegal Base58 character, or a missing segment must be rejected. SDK normalization only converts the semantic code to uppercase according to the method rules and leaves the suffix unchanged. Normalization cannot repair invalid characters or change the object category of a DID.

The method library separates the parsing result into the complete value, semantic code, subject code, application-domain code, and suffix, so that subsequent resource-type checks do not require callers to guess meanings from string positions:

{
  "input": "did:oan:skfi:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "normalized": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "semanticCode": "SKFI",
  "subjectCode": "SK",
  "appDomainCode": "FI",
  "suffixLength": 32,
  "parseResult": "valid"
}

This normalization applies only when the case of the semantic code can be converted according to the implementation rules. If the number of segments is wrong, the suffix length is invalid, or an illegal character is present, parsing must fail directly. The implementation must not generate another DID through “best-effort repair.”

5.3 Relationship Between Resource DID and Subject/Controller

The method-specific code can indicate only the object category to which a DID belongs. It cannot independently prove the legal or business relationship among the subject, controller, provider, or operator. The control relationship of a resource should be expressed in the DID Document’s verification methods, oanMetadata.controllerDid, publisherDid, issuerDid, and the resource control proof. A verifier must check the correspondence among these fields and the signature.

A subject may control multiple resource DIDs, and the resource provider may differ from the controller. The DID of a Registrar Service Node represents infrastructure qualification and cannot replace the resource DID. When an update uses the same resource DID, it must include an update proof that can be verified against the current control relationship. The DID string itself does not carry ownership, and public resolution of a DID does not transfer control.

5.3.1 Subject DID

A subject DID identifies the subject that controls resources or represents an organization or developer. It establishes the context of the control relationship and signing subject. It is not the DID of a specific resource and is not equivalent to a user login account. The DID Document of a subject DID should expose the public keys and service information required for verification. The private key is kept by the subject in the Local Identity.

5.3.2 Resource DID

A resource DID establishes an identity boundary for a resource that can be registered, published, discovered, updated, and revoked independently. Each of the four product resource types can have an independent resource DID. The resource type must be consistent with the DID semantic code and with oanMetadata.resourceType and subjectType in the DID Document. Otherwise, the Registrar Service Node and Root platform should reject the material.

5.3.3 Control and Signature Relationships

The control relationship is jointly supported by the verification methods in the DID Document and verifiable control proofs for specific operations. A verifier should check the signer, verification method, target DID, purpose, challenge, time, and DID Document hash in the proof. It must not ignore purpose, target, or freshness checks merely because the proof’s public key is identical to a public key in the document.

5.3.4 Separation of Subject, Resource, and Provider

The subject controls the identity and resource operations, the resource provider is responsible for capabilities, content, and service endpoints, and the operator is responsible for the runtime environment and availability. These roles may belong to one subject or may be separate. publisherDid or subjectDid is only a relationship declaration; the truth of the relationship still requires corresponding credentials, delegation materials, and control proofs.

5.4 DID Document Structure

An OAN DID Document is based on the DID Core data model and must at least contain @context, id, verificationMethod, authentication, assertionMethod, service, and the OAN-resource-oriented oanMetadata. id must be the normalized did:oan. The controller of each verification method, service-endpoint references, and resource identity in the metadata must be mutually verifiable. For Agent Services, Skills, MCP Servers, and Tool APIs, oanMetadata is the structured carrier for the resource type, capability semantics, protocol relationships, and publication references.

oanMetadata.resourceDescription and oanMetadata.agentDescription can express capability descriptions, capability tags, and use cases. A resource description can also carry input and output schemas, examples, audiences, domains, languages, and versions. Top-level authorizedDomains, protocolBindings, implementationLinks, credentialRequirements, and packageInfo supplement visibility scope, interaction protocols, composition relationships, invocation credential requirements, and publication materials respectively. A Discovery Service Node can use these fields to build tag, lexical, and vector indexes that map natural-language tasks to candidate resources. After obtaining a candidate, a caller can continue checking the DID control relationship, resource version, and publication proof.

The following is a minimal DID Document that illustrates the relationships among fields. The public key, service address, and resource DID in the example are placeholder values. An actual document must use a real public key and proof materials matching the controller:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/oan/v1"
  ],
  "id": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "verificationMethod": [
    {
      "id": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu#key-1",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
      "cryptoSuite": "Ed25519Sha256",
      "publicKeyMultibase": "zExamplePublicKey"
    }
  ],
  "authentication": [
    "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu#key-1"
  ],
  "assertionMethod": [
    "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu#key-1"
  ],
  "service": [],
  "oanMetadata": {
    "subjectType": "skill",
    "resourceType": "skill",
    "controllerDid": "did:oan:DVFI:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
    "capabilityTags": ["code-repository", "project-structure-summary"],
    "resourceDescription": {
      "name": "Repository structure analyzer",
      "description": "Searches code repositories and summarizes project structure.",
      "capabilityDescription": "Locate repository content, identify modules and summarize their relationships.",
      "capabilityTags": ["code-repository", "project-structure-summary"],
      "useCaseExamples": [
        "Inspect an unfamiliar repository before development",
        "Summarize modules, entry points and dependencies"
      ]
    },
    "lifecycleState": "active"
  }
}

A verifier should at least check that id, the controller of verification methods, and the authentication and assertion references belong to the same document. It should also check that the resource type is consistent with the SK subject code. Capability tags, capability descriptions, and use cases should describe the same resource capability. A Discovery Service Node can use them respectively for category filtering, semantic retrieval, and result explanation. Because these semantic properties are located in the DID Document, the resource controller can generate a control proof over a document containing the semantic declarations. The ResourcePackage can also lock this version through didDocumentHash, preventing the discovery index from combining the identity with an external description of unknown origin.

5.4.1 DID Identifier and Method Metadata

id is the subject identifier of the DID Document and must exactly match the resource DID in the request or ResourcePackage. @context should include the DID Core context and the OAN method context. A parser may interpret the method-specific semantic code to determine the resource category, but it must not use that code alone to replace consistency checks for oanMetadata and the ResourcePackage.

5.4.2 verificationMethod

verificationMethod describes public-key methods that can be used to verify signatures. Each item must contain at least a method ID, type, controller, and one public-key representation. OAN core types support representations such as publicKeyMultibase and publicKeyJwk, and can use cryptoSuite and publicKeyFormat to specify the cryptographic suite and encoding. A private key must never appear in a DID Document.

5.4.3 authentication and assertionMethod

authentication identifies verification methods that can be used for identity authentication or request proofs. assertionMethod identifies verification methods that can be used to issue or verify assertions. Each reference must resolve to a method ID in the same DID Document. A key used only for assertions must not automatically be treated as an authentication key, and a public key present in verificationMethod must not automatically be considered valid for every purpose.

5.4.4 service Endpoint

Each service item in service should contain a unique service ID, service type, and serviceEndpoint. It may also specify a version, protocol, server type, and port. An endpoint may point to a resource business service, resolution service, ResourcePackage, or another protocol description. The fact that an endpoint can be resolved proves only that an address exists; it does not prove that the business is available or that the caller is authorized.

5.4.5 Resource Metadata and Extension Fields

oanMetadata carries OAN resource type, subject type, controller, publisher, capabilities, authorization domains, protocol bindings, implementation links, credential requirements, package information, lifecycle, and other semantics. Extension fields must not override the identity and verification meanings of DID Core. If the DID, type, version, authorization domain, or hash conflicts among resource metadata, the ResourcePackage, and the registration submission, the material should be rejected or isolated according to the conflict-handling rules.

The relationship between oanMetadata and DID Core fields can be understood as follows:

Therefore, a parser may preserve unknown OAN extension fields, but it must not allow extension fields to change the meaning of id, verification methods, or purpose references. After successful method resolution, a resource-network verifier should continue checking consistency between metadata and the ResourcePackage.

5.5 Verification Methods and Public Keys

The id of a verification method should belong to the corresponding DID, and its controller should match the control relationship. The public-key representation and cryptographic suite must be parsable by the verifier. A control signature should specify proofPurpose, verificationMethod, the target object, and the signature coverage. The verifier first resolves the public key from the DID Document, and then checks the signature, purpose, hash, and time conditions.

Multiple verification methods may separately serve authentication, assertion, update, or recovery purposes. Key rotation must be authorized by the currently valid control relationship and must preserve the state required for historical verification or old-key invalidation. An old key must not continue issuing valid new updates. Merely writing an attacker’s public key into a DID Document that has not been accepted by the current control relationship does not grant control of the DID.

The acceptability of a verification method is not the single condition that “a public key exists.” It is the joint result of multiple fields:

{
  "verificationMethod": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu#key-1",
  "expectedController": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "proofPurpose": "authentication",
  "targetDid": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "documentHash": "sha256:example-did-document",
  "signatureVerification": "required"
}

The verifier should first confirm that verificationMethod can be resolved from the target DID Document, and then confirm that its controller, purpose, target DID, and signed document hash match. If the public key belongs to another DID, the method is not referenced for the applicable purpose, or the document has been replaced, verification fails. Comparing only whether public-key bytes are identical is insufficient.

5.6 Service Endpoints and Discovery References

Service endpoints in a DID Document provide location information for resources or protocols. Typical uses include business services, Registrar Services, Discovery Services, DID resolution, and ResourcePackage retrieval. The id of a service item should be associable with the resource DID, and serviceEndpoint should conform to the declared address or object format. A discovery response may reference an endpoint, but the caller must still verify the Root publication fact, endpoint freshness, and business authentication requirements.

The interfaces of Registrar Service Nodes, Discovery Service Nodes, and resolvers describe network-component behavior. They do not change their authorization boundaries merely because an endpoint is written into a DID Document. If an endpoint is missing, its protocol is incompatible, its address is unreachable, or the referenced object is incompatible, resolution may still successfully return the DID Document. Before discovery or invocation, however, the verifier must clearly mark the corresponding problem.

Resolution results should distinguish “the document was retrieved successfully” from “the endpoint is available.” A client-oriented result summary may contain:

{
  "did": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "resolution": {
    "status": "resolved",
    "documentRetrieved": true,
    "methodSyntaxValid": true,
    "documentIdMatchesRequest": true
  },
  "services": [
    {
      "id": "#resource",
      "type": "OANResource",
      "serviceEndpoint": "https://example.invalid/resource",
      "availability": "not_checked"
    }
  ],
  "nextVerification": ["control-proof", "publication-proof", "endpoint-authentication"]
}

availability: not_checked means that the resolution phase did not assess business-endpoint availability. A resolver must not rewrite the existence of an HTTP address or successful DID Document retrieval into endpoint health, published-resource status, or invocation authorization.

5.7 Resource Metadata Binding

The resource DID Document is associated with resource metadata and the ResourcePackage through oanMetadata and package information. For the same resource version, the resource DID, resource type, capability tags, capability description, use cases, authorization domains, protocol bindings, version, and hashes should remain verifiably consistent across the DID Document, registration submission, and ResourcePackage. The ResourcePackage’s didDocumentHash binds the exact document content; binding only the DID string is insufficient. Semantic discovery can therefore refer simultaneously to a stable DID, governed semantic declarations, and a published version instead of building an index only over free text separated from identity.

After a resolver returns the DID Document and oanMetadata, a Discovery Service Node can extract capability tags, capability descriptions, use cases, input and output schemas, and protocol bindings. It can combine the shared capability vocabulary with a local semantic search engine to build an index. During a query, a natural-language task is used for semantic retrieval, capability tags and resource types for structured filtering, and use cases and capability descriptions for explaining the match. Authorization-domain, lifecycle, and publication-status checks are then applied. This chain connects the semantic extension of the DID method with OAN semantic governance and the discovery protocol.

The binding relationship for one resource version can be checked through the following summary. The three hashes serve different purposes: a resource DID only locates an object and cannot replace integrity checks on the document and content:

{
  "resourceDid": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "packageVersion": "1.0.0",
  "didDocumentHash": "sha256:example-did-document",
  "metadataHash": "sha256:example-metadata",
  "packageHash": "sha256:example-package",
  "checks": {
    "didDocumentIdMatchesResourceDid": true,
    "resourceTypeMatchesSemanticCode": true,
    "metadataHashRecomputed": true,
    "packageHashRecomputed": true
  }
}

If the DID Document changes, didDocumentHash should change even when the resource DID remains the same, and a new control proof and resource-network verification should be triggered. If the caller queries only the DID string and does not compare the document hash, it cannot determine which document version it has received.

5.8 Control Proofs and DID Document Proofs

A resource control proof is generated by the controller using the private key corresponding to a verification method in the DID Document. It proves control over a particular DID, document hash, operation purpose, and challenge. The Registrar Service Node verifies this proof, and the Root platform verifies it again before accepting a resource version. A registration credential proves the fact that registration was processed; a Root proof proves the fact of network publication. These three kinds of evidence cannot replace one another.

A DID Document proof should cover the normalized document content or a prescribed document hash, and should include a locatable verification method, creation time, proof purpose, and signature value. Verification must fail if the proof is absent or expired, the target DID does not match, the document hash does not match, the purpose does not match, or the signature cannot be verified. No published state may be produced from such a failure.

The verification input for an OAN control challenge should bind the request context to the signature instead of verifying only a context-free signature. The key checks of a security library can be abstracted as follows:

{
  "challenge": {
    "challengeId": "challenge-example",
    "draftId": "draft-example",
    "subjectDid": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
    "registrarDid": "did:oan:INRG:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
    "purpose": "register_resource",
    "verificationMethod": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu#key-1",
    "didDocumentHash": "sha256:example-did-document",
    "expiresAt": "2026-09-09T09:00:00Z"
  },
  "verification": {
    "signatureValid": true,
    "challengeMatchesRequest": true,
    "notExpired": true,
    "proofPurposeMatches": true
  }
}

The Registrar Service Node should compare the subject DID, target Registrar Service Node, purpose, document hash, and validity period in the challenge with the current request item by item. Passing the challenge proves only that the controller authorized this particular operation with its associated context. It does not mean that the Registrar Service Node has formed a registration record or that the Root platform has published the resource.

5.9 DID Generation and Local Key Handling

The client is the primary generation and custody boundary for DIDs and control keys. A random DID is generated from cryptographically secure random numbers, while a deterministic DID is derived from semantic encoding, control material, and a nonce. In either case, the result must pass method parsing and resource-type consistency checks. A Registrar Service Node should receive only the public DID Document, signatures, and proofs required for verification. It should not obtain subject or resource-control private keys.

A Local Identity backup is sensitive material for restoring a control relationship, not a public credential. During import, the DID, keys, public keys, control relationships, and file structure must be checked for consistency. A newly generated control proof after restoration must be rebound to the current operation and document hash; a historical signature cannot be treated as unconditional authorization for every future version.

When handling Local Identity materials, the client can reduce key-leakage and binding errors through the following sequence:

1. Generate or import subject and resource-control keys locally, and check that public and private keys match.
2. Generate or resolve did:oan according to the resource type, and check that the semantic code matches resourceType.
3. Construct the DID Document and confirm that verification methods, purpose references, and oanMetadata point to the same resource DID.
4. Generate a new challenge control proof for the current document and operation instead of reusing a signature bound to an old document.
5. Submit only the public DID Document, proof, and necessary resource metadata to the Registrar Service Node; never upload private keys.

A Local Identity backup downloaded by a browser is user-side recovery material and cannot be replaced by storing keys on the server. A page indicating “created” or “download complete” only means that the client completed the file operation. The user must still verify that the file is complete and keep it according to local security requirements.

5.9.1 DID Generation

The client can call a method library’s random-generation or deterministic-derivation interface to create a DID. The semantic code in the generation parameters must be valid. Deterministic derivation produces the same result only when the control material and nonce are identical and the implementation uses the same method version. The derivation algorithm must not be treated as a mechanism for recovering a private key from a DID.

5.9.2 Key Generation and Storage

Control keys should be generated or imported in a client environment controlled by the user, with private keys stored through local secure storage or encrypted backup. DID Documents, registration requests, and discovery responses expose only public keys and materials required for verification. Server logs, request bodies, and error responses must not contain private keys or plaintext materials from which private keys can be recovered.

5.9.3 Local Identity Backup

A Local Identity backup may contain a subject DID, resource DIDs, key materials, resource configuration, and necessary credentials. It should clearly state its sensitivity level, creation time, and recovery purpose. The backup filename, download location, and page text do not provide identity authentication. The user must independently protect the backup and prevent unauthorized copying.

5.9.4 Import, Recovery, and Key-Use Boundaries

After import or recovery, the client should confirm that public and private keys correspond, that the DID Document subject is consistent, and that the resource type is consistent. It should regenerate the current challenge and hash before signing. A Registrar Service Node, Root platform, or Discovery Service Node may verify public proofs, but should not obtain private keys from the import process. Node-runtime private keys must also be separated from user resource-control private keys.

5.10 DID Resolution Requirements

A resolution request first validates the DID method and syntax, and then uses a resolution service to obtain the currently available DID Document or an explicitly requested historical version. A successful response should contain the document and its verifiable metadata. “Not found,” unsupported method, invalid format, inactive resource, and unavailable historical version should use distinguishable errors or statuses instead of returning an empty document and making the caller guess the cause.

Successful resolution means only that the resolver can return a DID Document. It does not mean that the resource is registered, the Root platform has published it, the credential remains valid, or the business endpoint is available. The return type of the current resource-detail or DID Document HTTP interface is determined by the specific node. The content distribution platform’s GET /cdn/documents/{did} directly returns DidDocument, while some directory interfaces place the DID in a did field and the document in a document field. Clients must parse according to the actual interface contract and must not assume that every DID read interface uses the same wrapper structure. The caller should continue judging based on resource-network evidence, governance status, version, and local policy.

Resolution errors should allow the caller to distinguish input errors, method capability, and network status. The following result categories can be used; the specific HTTP mapping is determined by the resolution-service interface:

A resolver must not conceal not_found or method_not_supported by returning an empty object. It must not treat an old snapshot from a Discovery Service Node as the current result of DID method resolution.

Interoperability with external protocols such as A2A and MCP is a matter of consuming and adapting resolution results. It does not change the identifier, DID Document, or control-relationship rules of did:oan. A resolver may preserve oanMetadata, service endpoints, and protocol bindings for an adapter to map them into an external protocol description. The caller must still independently verify the DID, ResourcePackage, control proof, and Root publication evidence.

5.11 DID Update, Version Management, Suspension, Recovery, and Deactivation

An update to the same resource normally keeps the resource DID unchanged and expresses the change through a new DID Document version, ResourcePackage version, hash, and control proof. The updater must sign with the currently valid control relationship. The Root platform and relevant nodes should check version order, reference to the previous version, document hash, and resource lifecycle state. The method library itself provides DID resolution and type validation only; it does not replace the network update protocol.

The minimum decision for an update to the same DID can be summarized as follows:

current DID + current control proof + new document hash
    -> verify current control and version relation
    -> accept a new resource version or reject the update

If the DID in an update request differs from the existing record, it should be treated as a new resource or an invalid replacement. The object to be overwritten must not be determined by receipt time. If the DID is the same but the control proof is invalid, the old document must not be overwritten merely because the resource name, endpoint, or submitter is the same.

Suspension, recovery, and deactivation are resource-network state actions. They must be bound to explicit control proofs, governance facts, or authorization conditions. Historical documents may be retained for auditing and historical verification, but current-state resolution must not treat an old document or old publication proof as the latest state.

5.11.1 Update with the Same DID

An update using the same DID requires the new material’s id to equal the existing resource DID and requires the current control key to sign the new document or prescribed document hash. If the control relationship changes, the key-rotation or recovery rules must be satisfied first. Submitting the same DID with only a new public key cannot overwrite the existing document.

5.11.2 Version Selection

The current version should be determined jointly by the resource version, document hash, package hash, and publication sequence. A resolver or Discovery Service Node should select the latest version according to trusted publication facts and lifecycle status, not solely according to receipt time or an auto-incrementing local database number. Historical-version queries require an explicit version identifier or publication reference.

5.11.3 Suspension and Recovery

Suspension should prevent discovery, publication, or pre-call verification within the specified scope from treating the resource as active. Recovery requires new valid status evidence and a renewed check of the version and publication evidence. A cached old document may be used for historical display, but it must not bypass the current suspension state.

5.11.4 Deactivation and Historical State

Deactivation means that the DID or resource no longer accepts new valid use within the specified scope. Historical documents and proofs may still be retained for auditing. Deactivation, resource revocation, registration-credential revocation, and endpoint shutdown should be recorded separately. One page-status field cannot replace all of these facts.

The basic control path for same-DID updates, suspension, recovery, and deactivation is shown below. The diagram expresses the verification order between the method layer and the resource-network layer; it does not mean that the method library completes registration or publication by itself:

5.12 DID Method Security and Privacy Considerations

Security comes from private-key confidentiality, signature coverage, DID Document public-key binding, challenge, and freshness checks, not from a DID string being hidden or complicated. An attacker can copy a public DID Document and public key, but without a valid control private key, current challenge, and corresponding authorization, the attacker cannot produce an acceptable update proof. A random nonce, request time, document hash, and purpose field should participate in replay protection.

A method implementation should avoid unconditionally exposing subject relationships, resource content, and endpoint privacy. A DID Document should contain only the information required for public verification and discovery. Sensitive credentials, private keys, and internal addresses should be handled through controlled endpoints or external authorization mechanisms. Failed verification must not write a published state, and error logs should retain sufficient audit information without revealing private materials.

5.13 DID Method Conformance Requirements and Test Vectors

Conformance tests should at least cover valid DID resolution; rejection of incorrect prefixes, segment counts, semantic codes, suffix lengths, and illegal characters; mapping of the four resource codes; random-generation results that can be parsed again; deterministic derivation that is stable for identical inputs and changes when control material or nonce changes; rejection of mismatches between DID and resource type; and semantic preservation before and after normalization.

Signature tests should also cover a verification-method purpose mismatch, target-DID mismatch, document-hash mismatch, expired challenge, reused nonce, wrong public key, and update with an old key. Test evidence should record fixed inputs, method version, expected errors, and actual outputs. Passing method-layer tests does not mean that the registration, publication, or discovery chain has passed.

The method implementation can use the following minimum test vectors as examples of input classification:

The DIDs and suffixes in the test vectors are used only to verify the method implementation and must not be used directly as production resource identities. Tests should also record the resolver version, input before and after normalization, error type, and whether any persistent side effect was produced. Returning an error string alone is insufficient to prove that publication state was not modified.

5.14 DID Method Interoperability and Resolver Behavior

did:oan should follow the basic data model of DID Core for DIDs, DID Documents, verification methods, and services, while the method implementation defines its method-specific identifier and resolution behavior. An external resolver should at least recognize the method name and reject identifiers that do not conform to the method syntax. A resolver supporting the OAN method should also preserve oanMetadata and its extension fields; it must not lose resource type, capabilities, or publication references during conversion. When consuming public information, an external system must still verify the control relationship, ResourcePackage, and Root publication evidence according to OAN rules.

A did:oan identifier consists of the method name and a method-specific identifier. The following example illustrates the structure and field relationships only. The example values do not represent real network objects and must not be treated as control materials that can be published directly.

did:oan:<subject-type-or-resource-type-code>:<method-specific-identifier>

{
  "id": "did:oan:SKDM:example-resource-id",
  "verificationMethod": [
    {
      "id": "did:oan:SKDM:example-resource-id#key-1",
      "type": "JsonWebKey2020",
      "controller": "did:oan:SKDM:example-resource-id",
      "publicKeyJwk": { "kty": "OKP", "crv": "Ed25519", "x": "..." }
    }
  ],
  "authentication": ["did:oan:SKDM:example-resource-id#key-1"],
  "service": [
    {
      "id": "#resource",
      "type": "OANResource",
      "serviceEndpoint": "https://example.invalid/resource"
    }
  ]
}

Method-layer conformance testing should separately record valid resolution, invalid-input rejection, DID-type mapping, document binding, signature purpose, challenge freshness, and update control. Passing method tests proves only that DID-method behavior matches the test vectors. It does not replace business-chain verification by the Registrar Service Node, Root platform, or Discovery Service Node. The specific generation, signing, verification, and rejection paths are described in Sections 5.9, 5.10, 5.11, and 5.13; this section only specifies that cross-resolver consumption must not discard method semantics.

References