The did:nda Method Specification

A W3C DID Method for the NDA Chain Verifiable Data Registry

1. Introduction

The did:nda method identifies subjects (humans, organizations, or items) in the Verifiable Data Registry (VDR) powered by the NDA Chain blockchain. It is a hybrid architecture designed to provide secure, verifiable, and portable digital identities.

This system follows W3C DID standards, leveraging the NDA Chain's on-chain smart contract to certify the issuance of the DID on the NDAChain blockchain network. The Verifiable Data Registry (VDR) acts as the trusted off-chain storage for richer DID Documents. This hybrid approach balances decentralization with practical governance and scalability.

Resolution is handled by a dedicated resolver service, ensuring that DID Documents are retrievable without querying the blockchain directly for all data, which enhances privacy and efficiency.

2. DID Method Name

The registered method is nda.

A valid DID starts with:

did:nda:

3. DID Syntax

A did:nda DID is formed by the method prefix and a unique identifier derived from an NDA Chain blockchain address.

Regex:

^did:nda:0x[0-9a-fA-F]{40}$

ABNF:

did-nda              = "did:nda:" method-specific-id
method-specific-id   = "0x" 40*HEXDIG
HEXDIG               = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F"
DIGIT                = %x30-39

4. Method Operations (CRUD)

This method supports Create, Read, and Update operations.

Create (Register)

The creation of a did:nda Decentralized Identifier involves two phases:
First - generating the identifier and the initial document off-chain,
Second - registering the DID on the NDAChain.

Phase 1: Off-Chain Generation (Identifier & Document)

A did:nda is implicitly created when a user generates a new ECDSA secp256k1 key pair. This process is performed entirely off-chain. The DID identifier is derived deterministically from the public key using standard Ethereum address generation logic.

The Derivation Algorithm:

  1. Generate Private Key: Create a cryptographically secure 32-byte private key.
  2. Derive Public Key: Calculate the uncompressed public key (65 bytes, starting with 0x04).
  3. Hash: Apply the Keccak-256 hashing algorithm to the last 64 bytes of the public key.
  4. Truncate: Take the last (lowest-order) 20 bytes of the resulting hash.
  5. Address Generation (Encode): Convert these 20 bytes into a 42-character hexadecimal string. This string represents the Account Address and MUST include the 0x prefix (e.g., 0x3f1a...).
  6. Format: Prepend did:nda: to the Account Address to form the final DID.

Example:

Account Address: 0x3f1a5c2e8b9d7f6a4c1b9e8d7c6b5a49382716f5
Final DID: did:nda:0x3f1a5c2e8b9d7f6a4c1b9e8d7c6b5a49382716f5

Document Creation & Storage:
The DID Document associated with the DID is generated locally. The document supports the EcdsaSecp256k1VerificationKey2019 verification method. During the registration process, this Document is published to the Verifiable Data Registry (VDR) via the Register API. The Document is then stored in off-chain storage (VDR) and will be fetched from this location when resolving the DID.

Phase 2: On-Chain Registration

The issuance of the DID will be certified by the NDAChain blockchain network through the publishing of a DID registration transaction.

The transaction contains the hash of the DID Document. This transaction must be signed by the private key corresponding to the DID, proving immediate control over the DID identifier. This transaction simultaneously anchors the DID's off-chain pointer to the chain.

Once the registration transaction is confirmed on NDAChain, the DID is considered fully created and globally certified.

Read (Resolve)

A did:nda is resolved by querying the NDA DID Resolver service. The resolver fetches the DID Document associated with the DID from its off-chain storage (e.g., application cache, dedicated database) and returns it to the client. See Section 6 for resolution details.

Update (Replace)

DID Documents can be updated. The controller of the DID (who holds the associated private key) can authorize changes to the DID Document, such as rotating keys, adding or removing service endpoints, or modifying authentication methods. Updates are submitted to the DID Resolver service API and must be cryptographically signed by the controller to prove ownership.

Deactivate (Revoke)

Deactivation is achieved by performing an Update operation. The controller updates the DID Document to remove or revoke all verificationMethod and service entries. A DID Document can also be updated to point its controller to a "null" or un-ownable DID, effectively orphaning it.

5. Method-Specific Identifiers

The did:nda method-specific identifier is a blockchain address from the NDA Chain.

6. DID Resolution

Resolution is performed via an HTTP GET request to the NDA DID Resolver service.

Reference Endpoint:

GET https://resolver.ndadid.vn/1.0/identifiers/{did}

Example Request:

GET https://resolver.ndadid.vn/1.0/identifiers/did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828

Response: On success, the service returns a 200 OK with the DID Document (in application/ld+json format) as the response body.

Resolution error examples:

7. DID Document

When a did:nda is resolved, the resulting DID Document is a JSON-LD object that conforms to the W3C DID Core v1.0 specification.

The document includes multiple contexts:

Example DID Document

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/v1"
  ],
  "id": "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828",
  "controller": "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828",
  "verificationMethod": [
    {
      "id": "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828#keys-1",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828",
      "publicKeyHex": "04abf141154b386b0203f7e0e7a1c4e7f805f833b9b3e1f0e8f0c3d8e5f0a2a1a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c"
    }
  ],
  "authentication": [
    "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828#keys-1"
  ],
  "assertionMethod": [
    "did:nda:0xdfc8044a202f08b9c8df2e42f746355575816828#keys-1"
  ]
}

8. Governance

9. Privacy & Security Considerations

Security Considerations

Privacy Considerations

10. Lifecycle

11. W3C Registration

12. Test Vectors

13. References