This chapter provides a unified description of the semantic boundaries of OpenAgenet (OAN) identity materials and cryptographic proofs. Identity materials answer who an object is and who can represent the object in making a statement; a signature answers whether specified content was produced by the corresponding private key; a verifiable credential (VC) answers which facts an issuer has made a verifiable statement about; and a verifiable presentation (VP) answers which credentials a holder presents for a specific verification purpose. These four concepts are related, but they cannot substitute for one another.

Resource registration commonly involves a subject DID, a resource DID, a resource control key, a Registrar node key, a node authorization VC, a resource control proof, a registration VC, and a Root proof. A client can generate and hold private keys, a node can verify public keys and proofs, and the Root platform can verify node authorization and publication conditions; these verification capabilities do not mean that a node or the Root platform obtains the resource control private key, nor do they mean that the resource has obtained permission for business invocation.

7.1 Subject Identity and Resource Identity

A subject is an identity object capable of managing one or more resource control relationships. A resource identity is an object boundary that can be registered, published, discovered, updated, and revoked independently. The subject DID, resource DID, Registrar node DID, Discovery node DID, and Root platform DID may all use the did:oan method, but their object categories, key purposes, and trust sources differ. They must not be mixed merely because they use the same method.

At registration time, the minimum public materials required for verification should be disclosed, such as the resource DID Document, public key, resource metadata, hash, and control proof. The subject’s name, contact information, local identity backup, and private key are not public fields required for resource discovery. Registration submission must not by default place them in node logs, indexes, or public responses.

Identity materials in the same registration request can be divided into three layers according to their purposes:

A verifier should start from the identity layer and check the control layer and network-fact layer in sequence. Taking the resource DID text, a registration VC, or a signature from a particular node alone cannot reconstruct the complete control and publication relationship.

7.2 Key Generation, Custody, Backup, and Recovery

Keys should be generated, imported, and used in a client or node secure execution environment managed by the controller. The current oan-crypto provides Ed25519 and SM2/SM3-related key processing and supports multiple public-key encodings and JWK public-key representations. The cryptographic suite, public-key representation, and proof type must be identifiable by the recipient. When materials are unknown, truncated, or incompatible, the operation should fail explicitly rather than silently switching to another algorithm suite.

A local identity backup may contain subject configurations, resource configurations, public keys, private keys, and credentials at the same time, and is therefore sensitive material. During import or recovery, the client should check the file structure, the correspondence between DIDs, public keys, and private keys, the resource type, and the control relationship. Successful recovery only means that the client has regained local control materials; it does not mean that the resource has been registered, published, or re-indexed.

The boundary between a local identity backup and a public DID Document can be represented by the following minimal structure:

{
  "publicIdentity": {
    "did": "did:oan:DVFI:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
    "verificationMethod": "did:oan:DVFI:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz#key-1",
    "publicKey": "public-key-material"
  },
  "localSecret": {
    "privateKey": "private-key-material",
    "storage": "browser-local-backup"
  },
  "controlledResources": ["did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu"]
}

This structure is for illustrating the boundary only; the actual backup fields are determined by the client implementation. Public identity materials can be sent to a verifier, while localSecret must remain within the local secure boundary managed by the controller. Obtaining a public key from a server does not allow a private key to be derived.

7.3 Resource Control Signatures

A resource control signature must be bound to a specific operation rather than being an isolated signature over arbitrary text. DidControlChallenge combines a challenge identifier, draft identifier, target resource DID, DID Document hash, Registrar node DID, operation purpose, verification method, nonce, and validity period. SubjectControlProofBundle then associates the control proof, verification time, actual verification method, and proof hash. Both the Registrar node and the Root platform should check these bindings.

At minimum, the following conditions should be checked:

1. subjectDid is consistent with the submitted resource DID.
2. didDocumentHash is consistent with the submitted DID Document.
3. verificationMethod belongs to the target DID Document and its purpose permits the current operation.
4. purpose is consistent with the current registration, update, or publication operation.
5. nonce, issuance time, and expiration time satisfy freshness and replay-prevention requirements.

Successful proof verification only shows that the corresponding private key signed the specified payload. Whether the resource provider is authorized to represent an organization, whether the endpoint is secure, and whether the caller has obtained business authorization must still be determined separately through delegation materials, governance state, and business policies.

The core of a control proof is not the signature value itself, but the context covered by the signature. A verifier can check a registration operation according to the following relationship:

{
  "operation": "register_resource",
  "subjectDid": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "registrarDid": "did:oan:INRG:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
  "didDocumentHash": "sha256:example-did-document",
  "challengeId": "challenge-example",
  "nonce": "nonce-example",
  "proofPurpose": "assertionMethod",
  "signature": "signature-example"
}

The DID, target Registrar node, document hash, purpose, and nonce are all binding relationships to be checked. The example values do not represent a real request. If any binding field differs from the current request, registration or update must not be accepted merely because the signature algorithm verification succeeds.

7.4 Infrastructure Node Identity Keys and Node Signing Keys

The node DID Document expresses the node identity. A communication signing key proves that a request comes from the corresponding node execution boundary. A node authorization VC proves the node’s role and authorization domain. Runtime credentials support service startup, key loading, or access to controlled infrastructure. A deployment may host multiple categories of materials within the same security boundary, but protocol semantics should still separate them by purpose.

When sending a resource verification request to the Root platform, SignedRequestEnvelope binds requestId, protocol version, purpose, HTTP method, path, audience, request time, request nonce, request-body hash, and proof. The recipient should check the audience, path, time window, nonce replay, node DID Document, public key, and node authorization before processing the business content.

The verification sequence for SignedRequestEnvelope can be summarized as follows:

1. Read the node DID, audience, HTTP method, path, and request-body hash from the request.
2. Parse the node DID Document and locate the verification method and public key used by the request.
3. Verify the purpose, creation time, request ID, nonce, and signature payload of the proof.
4. Check the role, authorization domain, and current status of the node authorization VC.
5. Process resource verification, registration, or publication business only after the checks pass.

This separates the question of whether “the request comes from a particular node” from the question of whether “the node is authorized to perform the current action.”

7.5 Root Platform Authorization VC for Infrastructure Nodes

The core relationships in a node authorization VC are as follows: issuer is the Root platform or a governance-approved issuer, subject is the authorized node DID, role indicates the node role, claims carries the authorization domain and capability scope, and status, issuedAt, and expiresAt describe status and the validity window. The proof of NodeAuthorizationCredential must be issued by the issuer over the credential content without a proof. The verifier should obtain the public key from the issuer DID Document and verify the proof.

Node DID Document -> obtain node verification public key
      -> verify authorization VC proof
      -> check issuer, subject, role, status, issuedAt, expiresAt
      -> check authorization domain and capability scope
      -> decide whether the current node action is authorized

When the proof is absent, the issuer cannot be resolved, the subject does not match, the role is not permitted, the authorization has expired, the status is not active, or the authorization domain does not cover the requested scope, the restricted action must be rejected. A node authorization VC proves infrastructure eligibility; it does not prove resource control.

The relationships among node authorization VC fields can be checked using the following example:

{
  "type": "NodeAuthorizationCredential",
  "issuer": "did:oan:INRT:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
  "subject": "did:oan:INRG:8LcR3Vn5YpQw2Tx7Mb9Zd4Fa6GhKsEuJ",
  "role": "registrar",
  "status": "active",
  "issuedAt": "2026-09-09T08:30:00Z",
  "expiresAt": null,
  "claims": {
    "authorizedDomains": ["public"],
    "capabilities": ["resource_registration"]
  },
  "proof": {
    "type": "DataIntegrityProof",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:oan:INRT:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz#key-1",
    "proofValue": "signature-example"
  }
}

The role, authorization domain, and capability values in this example are used to illustrate the validation relationships. The verifier must confirm that the issuer, subject, proof, and governance state match one another, and then compare the authorization scope with the current request. The validity of a node authorization VC does not change the controller of a resource DID.

7.6 Registration VC Issued to the Resource Controller

In the current Registrar node flow, the Registrar node first calls the Root platform resource verification and publication interface. After the upstream operation succeeds, the Registrar node issues a registration VC and writes the registration record to storage. The credential contains the OAN credential context, credential type, issuer, resource credential subject, resource DID, resource type, DID Document hash, metadata hash, resource package hash, ResourcePackage version, hash algorithm, authorization domain, lifecycle state, and credential status.

The following is an illustrative structure; field order has no additional semantic meaning:

{
  "type": ["VerifiableCredential", "OANResourceRegistrationCredential"],
  "issuer": "did:oan:...",
  "issuanceDate": "2026-09-06T00:00:00Z",
  "credentialSubject": {
    "id": "did:oan:SKFI:...",
    "resourceDid": "did:oan:SKFI:...",
    "resourceType": "skill",
    "didDocumentHash": "sha256:...",
    "metadataHash": "sha256:...",
    "packageHash": "sha256:...",
    "packageVersion": "1.0.0",
    "hashAlgorithm": "sha256",
    "lifecycleState": "active"
  },
  "credentialStatus": {"status": "active"},
  "proof": {"type": "DataIntegrityProof", "proofValue": "..."}
}

A registration VC proves that the Registrar node processed the specified registration materials and the registration facts explicitly listed in the credential. It does not independently prove that the Root platform has completed network-wide publication, that a Discovery node has completed indexing, or that the caller has obtained permission for business invocation.

The most important binding relationships in a registration VC are issuer, subject, the resource version, and the three classes of hashes. A verifier should compare the credential claims again with the received DID Document, resource metadata, and ResourcePackage:

{
  "type": "AgentRegistrationCredential",
  "issuer": "did:oan:INRG:8LcR3Vn5YpQw2Tx7Mb9Zd4Fa6GhKsEuJ",
  "subject": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
  "status": "active",
  "issuedAt": "2026-09-09T08:31:00Z",
  "claims": {
    "resourceDid": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
    "resourceType": "skill",
    "packageVersion": "1.0.0",
    "didDocumentHash": "sha256:example-did-document",
    "metadataHash": "sha256:example-metadata",
    "packageHash": "sha256:example-package",
    "hashAlgorithm": "sha256",
    "lifecycleState": "active"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "proofPurpose": "assertionMethod",
    "proofValue": "signature-example"
  }
}

The example values do not represent a real credential. If subject, resourceDid, the version, or any hash differs from the current materials, the registration VC cannot be used to prove that the current materials have been registered. Even when the credential signature itself is valid, it only shows that the issuer signed another set of claims.

7.7 Governance and Authorization Evidence

A verifier must combine evidence according to the type of fact being established. A valid registration VC only means that registration processing was completed. Without a Root proof, the registration result must not be described as globally discoverable. When the resource control proof does not match, a valid node authorization VC is not sufficient to accept a resource update.

7.8 VC and VP Structural Requirements

A VC is a verifiable expression of facts asserted by an issuer. A VP is a presentation organized by a holder for a verification purpose. The current core code directly models node authorization VCs and resource registration VCs. When a VP is used, it should add a holder, presentation purpose, challenge, validity period, and presentation proof. An arbitrary collection of VC JSON objects must not be called a VP directly.

7.8.1 Basic VC Structure

A VC should be able to identify its context, type, issuer, credentialSubject, issuance time, optional expiration time, status, and proof at minimum. OAN’s Rust credential structures use type, issuer, subject, status, issuedAt, expiresAt, claims, and proof. An HTTP JSON structure may use interoperability names such as credentialSubject and issuanceDate, but the serialization mapping must be stable and must not change the meaning of the claims.

7.8.2 Basic VP Structure

A VP should contain a presentation type, holder, one or more verifiableCredential objects, a presentation purpose, and a proof for the current verification. When replay prevention is required, it should also bind a challenge or nonce provided by the verifier. A collection of credentials without holder proof, purpose binding, or the current verification context should not be accepted as a fresh VP.

The minimum VP example can be represented as follows:

{
  "type": ["VerifiablePresentation"],
  "holder": "did:oan:DVFI:7YpQm9Kx2VnRb6Ts3WfHa4Cd5Ej8LgNz",
  "verifiableCredential": [
    {
      "type": ["VerifiableCredential", "AgentRegistrationCredential"],
      "issuer": "did:oan:INRG:8LcR3Vn5YpQw2Tx7Mb9Zd4Fa6GhKsEuJ",
      "subject": "did:oan:SKFI:5HkPq7Vm3RdT9Ya2WcX8Ns4Bf6GjLeZu",
      "status": "active",
      "claims": { "packageVersion": "1.0.0" },
      "proof": { "proofValue": "credential-signature-example" }
    }
  ],
  "purpose": "resource_verification",
  "challenge": "verifier-challenge-example",
  "proof": {
    "proofPurpose": "authentication",
    "proofValue": "presentation-signature-example"
  }
}

This example distinguishes the issuer proof of a VC from the holder presentation proof of a VP. The verifier must still validate issuer, subject, the VC proof, holder, the VP proof, challenge, and status according to the actual credential structure. The credential object in the example must not be used directly as an available credential.

7.8.3 Issuer, Holder, and Subject

The issuer is responsible for the facts asserted by the VC, credentialSubject is the object described by the assertion, the holder is the party currently controlling the presentation materials, and the controller is the party controlling verification methods in a DID Document. These four roles may be the same or different. A Registrar node may be the issuer of a registration VC, the resource DID may be its credentialSubject, and the resource controller may be the holder; the node operator therefore does not automatically become the resource controller.

7.8.4 Credential Status and Verification

Verification must not stop at proof verification. It should also check the credential type, issuer and DID Document, public key, subject, purpose, validity period, status, and required claims. When the status source is unavailable, the verifier should apply an explicit failure or degradation policy according to the credential purpose. “Temporarily unable to query” must not be interpreted as active.

For different materials, the verification result should preserve two levels: “signature valid” and “business fact valid”.

7.9 Relationship among Issuer, Holder, Controller, and Credential Subject

These fields express different relationships. The complete ownership and authorization chain cannot be inferred merely from the presence of a field. Verification should check the field relationships, DID Document, public key, proof purpose, governance policy, and business policy together.

7.9.1 Issuer

The issuer signs the credential content without a proof using the issuance key and bears traceable responsibility for the claims. The verifier should obtain the verification method from the issuer DID Document and check the consistency of the proof creator, verification method, and issuer.

7.9.2 Holder

The holder is the party currently controlling the credential presentation materials. It may be a resource controller, client, or delegated user assistant agent. Holding a public VC does not mean that the holder has obtained control of the credentialSubject; the relationship of representation still requires control proof, delegation, or business authorization.

7.9.3 Resource Controller

The resource controller controls registration, update, or other protected operations for the resource identified by the resource DID. The controller may differ from the resource provider, registration VC holder, or endpoint operator. Its permission decision depends on the target DID, verification method, operation-bound proof, and current version rules.

7.9.4 Credential Subject

credentialSubject is the object described by the VC. The subject of a node authorization VC is normally an infrastructure node DID, while the subject of a registration VC is normally a resource DID. If the subject is replaced, the DID Document does not match, or the claims conflict with the subject type, the credential must not be used for the corresponding decision.

7.10 Signature Verification and Status Verification

After a verification service receives JSON, it should first parse it according to the type or field structure declared by the interface, and then separately verify the signature coverage and the status source. The upstreamAuth of an inter-node request proves that the request comes from a node with the corresponding authorization. subjectControlProof in resource registration proves that the resource controller authorized the current registration or update. A registration VC describes the registration fact produced by the Registrar node. A Root proof describes that a specific resource version passed Root platform verification. These materials may appear consecutively in the same HTTP business flow, but they must not be conflated into one credential object.

Request can be parsed
  -> request signature and audience are valid
  -> resource control proof is valid
  -> registration VC issuer and subject match
  -> Root publication proof matches the version and hashes
  -> governance state and freshness are acceptable

Any failure must terminate the flow before a side effect such as publication, authorization, or invocation occurs, and should return a locatable failure reason. Verification records may retain the verification object, proof type, verification method, verification time, status source, and error code, but must not retain private keys or materials from which private keys can be recovered.

7.11 Credential Privacy and Disclosure Boundaries

The resource DID, public key, capability tags, resource description, endpoint, version, hash, and Root publication evidence required for resource discovery may enter a public ResourcePackage or discovery response. Subject personal information, private keys, local identity backups, undisclosed delegation materials, and unnecessary internal configuration should remain within a controlled boundary.

Minimal disclosure must not remove binding fields required for verification. If hiding a field prevents the verifier from confirming the issuer, subject, version, hash, or proof, controlled presentation or a verifiable digest should be used instead of unverifiable display text.

7.12 Key Rotation and Compromise Response

Key rotation should first establish a verifiable control relationship between the new public key and the existing DID, and only then make the old public key unavailable for new operations. A resource DID update should describe the new verification method, its purpose, and its effective version in the new DID Document. Node key rotation must also synchronize the node authorization VC, node configuration, and upstream trust materials. Root platform key rotation must take downstream caches, historical proofs, and verification windows into account.

When a key is compromised, the affected key should be suspended, the old public key and status required to verify historical materials should be retained, and the revocation, replacement, or recovery fact should be published through a new control relationship. If the control private key is completely lost and no recovery key or transfer mechanism exists, the system cannot restore control merely from the DID string; it must enter a governance intervention or re-registration process.

7.13 Registration VC and Resource Publication Evidence

Two types of proof form a continuous but independent fact layer. After the Registrar node receives a successful response from the Root platform interface, it generates a registration VC. The Root platform produces a Root proof after verifying the resource control proof, metadata, ResourcePackage, version, hashes, and publication conditions. An HTTP success code or rootResponse is only a transport result and cannot replace verification of proof content and status.

Resource control proof -> Registrar node accepts the registration
       -> Root platform verifies resource, version, hashes, and publication conditions
       -> Root proof
       -> Content distribution platform distributes the material
       -> Discovery node verifies and indexes it
       -> Caller verifies it again and invokes it according to policy

Registration acceptance, Root platform acceptance, material distribution, Discovery node indexing, and caller authorization must be expressed separately. No single VC or publication proof may compress these states into “the resource is already trusted and available.”

7.14 Node Authorization VC and Infrastructure Permissions

Node actions are jointly constrained by role, authorization domain, capability scope, and governance state. A Registrar node may process only resources covered by its authorization domain, and a Discovery node may only synchronize and return resources within its permitted scope. A node’s ability to verify a material does not mean that the node is authorized to perform every network action. The authorization domain should be checked for format, ordering, duplicates, hierarchical coverage, and consistency with the node VC.

allow(action) = valid(node authorization VC)
             && active(governance status)
             && role permits(action)
             && granted domains cover(requested domains)
             && freshness is acceptable

This expression represents a decision relationship rather than fixed implementation code. Errors should distinguish node authorization failure, resource control failure, resource content failure, and upstream service failure so that auditing, client handling, and operations diagnosis remain possible.

7.15 Credential Revocation, Suspension, and Status Propagation

A credential with a valid signature may still be unusable for a new authorization decision because of a governance event, a status record, or expiresAt. Status propagation may pass through on-chain governance events, Root platform status, the off-chain trust indexer, and node caches. Therefore, the verification result should carry the status source, observation time, and freshness information.

7.15.1 Credential Status Changes

Every status change should be associated with the credential identifier, subject, old status, new status, reason, event sequence, and time, and should be produced by an authorized party. Restoring a suspended credential and issuing a new credential are different operations. Whether a new credential may be issued after revocation should be determined by governance and issuance policies.

7.15.2 Node Authorization VC Status

After a node authorization VC is suspended or revoked, a Registrar node or Discovery node must not continue to perform new restricted actions. Whether existing materials may continue to be provided can only be determined according to cache freshness and risk policy. A historical VC must not be used to infer that the node still has permission to submit or index new content.

7.15.3 Resource Registration VC Status

A change in registration VC status affects the current validity of the registration proof, but does not necessarily mean that the resource DID must be deleted. Historical Documents and audit materials may be retained while the current version is marked suspended, revoked, or undiscoverable. The verifier should check the VC status, resource lifecycle, and Root publication status separately.

7.15.4 Status Propagation and Cache Updates

When a node receives a newer governance event or status cursor, it should verify sequence continuity, event completeness, and proof before updating its local cache. When the cursor is behind, events are missing, the status source is unavailable, or the cache exceeds the allowed freshness, sensitive actions should be suspended or return an indeterminate status rather than continuing to use the old active judgment.

7.16 Signature Formats, Normalization, and Verification Test Vectors

Cross-language implementations must unify the signed source text, field names, field ordering, null handling, time format, hash algorithm, public-key encoding, and proof fields. signature_input, build_data_integrity_proof, and verify_payload_with_proof in the reference implementation show the boundaries for payload construction, proof generation, and verification. Other language implementations should produce an equivalent byte sequence rather than compare only in-memory objects.

Test vectors should be versioned and should cover the Rust reference implementation, TypeScript SDK, and node HTTP layer. Test private keys must use dedicated materials; production private keys must not enter test files or logs. Logs may retain non-sensitive evidence such as public keys, hashes, request IDs, and error codes.

Reference Sources