The Neuralkey DID Method (did:neuralkey) Specification Page

W3C Member Submission: 30 April 2026

Authors: SEREYVUTH KIM, M.Phil.(IT), AIGP, Mr. MENGFONG HEAN, Mr. CHANCHHAYA YUN

Abstract

This specification defines the {method} Decentralized Identifier (DID) method. {method} introduces an asymmetric, role-based architecture designed specifically for Verifiable Credential ecosystems.

It unifies two distinct resolution paradigms under a single method: a zero-latency, cryptographically derived profile (based on {did_key}) for regular network users (Holders/Subjects), and a domain-anchored, highly discoverable profile (based on {did_web}) restricted to credential Issuers. This separation optimizes user privacy and offline verification while ensuring organizational trust and revocation capabilities for Issuers.

Status of This Document

CAUTION: This section describes the status of this document at the time of its publication. By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not a W3C Recommendation and is not a standard. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

I. Introduction

In standard decentralized trust networks, entities play different roles that require vastly different identity properties.

1. Regular Users (Holders)

Require privacy, ephemeral interactions, zero-latency verification, and the ability to operate in offline environments. They do not need complex routing or discoverability.

2. Issuers (Organizations/Authorities)

Require high public trust, discoverability, key rotation, and strict revocation mechanisms. Their identities must be explicitly tied to their real-world organizational domains.

Forcing both roles to use the same DID method often results in compromises. The {method} method solves this by routing the DID resolution process based on the structural syntax of the identifier itself, granting Users the privacy of did:key and Issuers the authority of did:web.

II. Method Name & Identifier Format

The namestring that identifies this DID method is {neuralkey}.

The method-specific identifier structurally branches into two distinct formats: the User Profile and the Issuer Profile. A compliant did:neuralkey resolver MUST determine the profile type by inspecting the identifier string.

The format of the DID is defined by the following ABNF:

neuralkey-did = "did:neuralkey:" (user-profile / issuer-profile)
• user-profile = multibase-base58-btc-encoded-value
• issuer-profile = fully-qualified-domain-name *(":" path-segment)

1 Identifier Generation Rules

1.1 User Profile

If the identifier begins with the characters ‘z6Mk’ and strictly conforms to a Base58BTC encoded multicodec payload, it MUST be treated as a User Profile.

Example: did:neuralkey:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

1.2 Issuer Profile

If the identifier consists of a valid Fully Qualified Domain Name (FQDN), optionally followed by path segments separated by colons, it MUST be treated as an Issuer Profile.

Example: did:neuralkey:university.example.com

III. CRUD Operations

1 Create (Register)

1.1 User Profile

Creation is purely cryptographic and localized.

  1. The User generates a cryptographic key pair locally.
  2. The User prefixes the public key with the appropriate multicodec identifier (0xed01 for Ed25519) and encodes it via Base58BTC.
  3. The User appends the resulting string to {method_prefix}. No network registration is required.

1.2 Issuer Profile

Creation requires domain administration.

  1. The Issuer generates a key pair.
  2. The Issuer creates a valid JSON-LD DID Document.
  3. The Issuer provisions this document on their web server via HTTPS at the .well-known path or specified subdirectory (e.g., https://university.example.com/.well-known/did.json).

2 Read (Resolve)

A compliant resolver MUST execute a branching logic check to resolve a did:neuralkey:

Branch A: User Profile Resolution (Offline)

If the parser identifies a User Profile (multibase string):

  1. Check If the identifier starts with z6Mk (which is the multibase Base58BTC prefix for an Ed25519 public key), the system identifies it as a User Profile.
  2. It artificially constructs a standard did:key string ({did_key_example}).
  3. Passes it to the keyDriver.
  4. The did-method-key usually just returns the raw JSON document.
  5. Latency: 0 network required.
{
 "@context": [
  "https://www.w3.org/ns/did/v1",
  "https://w3id.org/security/suites/ed25519-2020/v1",
  "https://w3id.org/security/suites/x25519-2020/v1"
  ],
 "id": "did:neuralkey:z6MkwAkLNUmKBRha3s2NzRWFFsDSXJ2QF44w9AT4CmSBuU41",
 "verificationMethod": [{
  "id": "did:neuralkey:z6Mkw...4CmSBuU41#z6Mkw...4CmSBuU41",
  "type": "Ed25519VerificationKey2020",
  "controller": "did:neuralkey:z6MkwAkLNUmKBRha3s2NzRWFFsDSXJ2QF44w9AT4CmSBuU41",
  "publicKeyMultibase": "z6MkwAkLNUmKBRha3s2NzRWFFsDSXJ2QF44w9AT4CmSBuU41"
 }],
 "authentication": [
  "did:neuralkey:z6Mkw...4CmSBuU41#z6Mkw...4CmSBuU41"
 ],
 "assertionMethod": [
  "did:neuralkey:z6Mkw...4CmSBuU41#z6Mkw...4CmSBuU41"
 ]
}

Branch B: Issuer Profile Resolution (Online)

If the parser identifies an Issuer Profile (domain string):

  1. If it does not start with z6Mk, resolver assumes it is a domain name (Issuer Profile).
  2. It artificially constructs a standard did:web string ({did_web_example}).
  3. Delegates the network request to an existing didResolver.
  4. The resolver performs the standard HTTPS fetch to retrieve the did.json file.
  5. Latency: Standard HTTPS request round-trip time.
{
 "@context": [
  "https://www.w3.org/ns/did/v1",
  "https://www.w3.org/ns/cid/v1",
  "https://w3id.org/security/jwk/v1"
  ],
 "id": "did:neuralkey:neuralkey.neuralsh.com",
 "verificationMethod": [{
  "id": "did:neuralkey:neuralkey.neuralsh.com#key-0",
  "type": "JsonWebKey2020",
  "controller": "did:neuralkey:neuralkey.neuralsh.com",
  "publicKeyJwk": {
   "kty": "OKP",
   "crv": "Ed25519",
   "x": "ADTXUVoRZP9A0Lzt5lw8LGK0MLSmuhftNCZh5aQPXMc"
  }
 }],
 "authentication": [ "did:neuralkey:neuralkey.neuralsh.com#key-0"],
 "assertionMethod": ["did:neuralkey:neuralkey.neuralsh.com#key-0"],
 "deactivated": true
}

3 Update

User Profile

Updates are {not_supported}. The DID Document is deterministically bound to the private key. If a User loses their key or wishes to rotate it, they MUST generate a new did:neuralkey User Profile.

Issuer Profile

Updates are {supported}. The Issuer modifies the did.json file hosted on their domain. Relying parties will fetch the updated keys, service endpoints, or metadata upon their next HTTPS resolution request. To rotate keys, it simply update this file. To avoid service disruption, it implement follow this three-stage update process:

Stage A: The Overlap (Addition)

Generate new key (Key 2), but keep the old key (Key 1) active. This ensures that any credentials signed with Key 1 while the file was being cached are still valid.

// https://example.com/.well-known/did.json
{
 "@context": [
  "https://www.w3.org/ns/did/v1",
  "https://www.w3.org/ns/cid/v1",
  "https://w3id.org/security/jwk/v1"
  ],
 "id": "did:neuralkey:neuralkey.neuralsh.com",
 "verificationMethod": [
 {
  "id": "did:neuralkey:neuralkey.neuralsh.com#key-1", // OLD KEY
  "type": "JsonWebKey2020",
  "controller": "did:neuralkey:neuralkey.neuralsh.com",
  "publicKeyJwk": { ... }
 },
 {
  "id": "did:neuralkey:neuralkey.neuralsh.com#key-2", // NEW KEY
  "type": "JsonWebKey2020",
  "controller": "did:neuralkey:neuralkey.neuralsh.com",
  "publicKeyJwk": { ... }
 }
 ],
 "authentication": [
  "did:neuralkey:neuralkey.neuralsh.com#key-1",
  "did:neuralkey:neuralkey.neuralsh.com#key-2"
 ],
 "assertionMethod": [
  "did:neuralkey:neuralkey.neuralsh.com#key-1",
  "did:neuralkey:neuralkey.neuralsh.com#key-2"
 ]
}
Stage B: The Switch
  1. Upload the updated did.json to server.
  2. Wait for the Transition Period (usually 24–48 hours).
  3. Configure internal systems to start signing new messages with Key 2.
Stage C: The Cleanup (Removal)

Inform to all identifies who were issued by key 1 immediately sign new proof with key 2. When it's certain no active sessions or unverified credentials rely on Key 1, remove Key 1 from the verificationMethod, assertionMethod and authentication arrays in the did.json file.

4 Deactivate

User Profile

Deactivation is {not_supported} on a network level. Users effectively deactivate their DID by deleting their local private key material.

Issuer Profile

Deactivation is {supported}. The Issuer MUST update their hosted did.json file to include the exact property {deactivated_true} at the root level of the JSON object.

IV. Security & Privacy

1 Issuer Domain Hijacking

The trust in the Issuer Profile is entirely dependent on the integrity of the DNS and web server hosting the did.json. If an attacker compromises the web server of an Issuer, they can replace the public key in the DID Document and issue fraudulent credentials that relying parties will accept as cryptographically valid. Issuers MUST employ strict TLS requirements, DNSSEC, and secure server access controls.

2 Ephemeral User Security

Because User Profiles cannot be formally revoked, a compromised private key allows an attacker to indefinitely impersonate the User. Users MUST utilize secure hardware enclaves (TEEs, Secure Enclaves, or physical security keys) to store their private key material. Wallet software implementing did:neuralkey SHOULD encourage frequent rotation of User DIDs to minimize the lifespan of any potential key compromise.

Clear Separation of Identity Tracking

This asymmetric architecture inherently protects regular users from the "phone home" tracking risks of did:web. Because a User Profile requires zero network requests to resolve, an Issuer or Verifier cannot track a User's IP address or frequency of verification by monitoring a centralized resolution server. Conversely, Issuers are public entities where discoverability is a feature, not a privacy flaw.

Sources

© 2026 NeuralKey / PRESTIGE ALLIANCE CO., LTD. Decentralized Identity (DID) Platform

Last Updated: June 3, 2026