Digital Identity: The DID System
What it is
The Elastos DID (Decentralized Identifier) system gives people a digital identity that no single company or government controls. It follows the W3C DID standard so that identities are interoperable and verifiable in a predictable way.
An Elastos DID looks like this:
did:elastos:icJ4z2DULrHEzYSvjKNJpKyhqFDxvYV7pN
The method name is did:elastos:. The method-specific id is an EID-sidechain-style string (often starting with i) derived from cryptographic material, not assigned by a signup desk.
Three roles: holder, issuer, verifier
Real-world identity flows involve three kinds of participant:
| Role | Plain-language role |
|---|---|
| Holder | The person (or device) that owns the DID and stores credentials. |
| Issuer | A party that signs claims about the holder (school, employer, KYC provider). |
| Verifier | A service that checks proofs (signatures, chain records, and revocation) before trusting a claim. |
You might be holder and verifier on different days: you hold your own DID, but you also verify someone else’s credential when your app checks their age or membership.
DID document: what gets published
When a DID is registered on the EID chain, a DID document describes how to use and verify that identity. Documents align with W3C ideas and typically include:
@context: JSON-LD context links so terms like “public key” and “credential” have unambiguous meaning on the open web.id: The DID itself (the subject of the document).publicKey: One or more keys others can use to check signatures.authentication: Which keys prove control for login-style actions.service: Endpoints for messaging, storage, or other services (for example a Hive vault URL).verifiableCredential: Optional embedded credentials when you want some claims publicly visible.
Timestamps for creation and updates often come from blockchain transactions rather than only from the JSON file, so everyone agrees on ordering and history.
A verifiable presentation is the bundle you show to a verifier: it can carry one or more credentials, proofs that you hold them, and sometimes a realm and nonce so the proof cannot be replayed on a different website or at a different time.
How keys relate to your phrase (high level)
Behind the scenes, software derives keys from a BIP-39 mnemonic (often 12 words). From the seed, wallets use a defined HD path. For Elastos DID the common pattern is along the lines of m/44'/0'/0'/0/<index> to obtain a P-256 (secp256r1) key pair. The visible address side used in the did:elastos:i… string is built from hashes of the public key material (for example SHA-256 and RIPEMD-160), a version prefix such as 0x67, and Base58Check encoding so humans can copy it safely.
You do not need to memorize the math. What matters is: your mnemonic controls the keys, the keys control the DID, and the DID document on-chain is the public side others verify against.
JSON-LD contexts: speaking the same language
The Elastos.DID.Contexts repository hosts 30+ JSON-LD context definitions: files that map short field names to global semantics. They cover core DID terms, credential types, profile fields (name, email, avatar, …), social accounts, and specialized types such as Hive node ownership. Wallets and verifiers load these contexts so a credential issued in one app still means the same thing in another.
Contexts are published under namespaces such as https://ns.elastos.net/ so resolvers worldwide can fetch stable definitions, similar to how schema.org gives shared meaning to “email” or “name” on the web.
What you can do in practice
Create an identity: Generate keys locally from a mnemonic; no central “register your email” step is required to create keys.
Publish and update: Put the DID document on EID so anyone can resolve your keys and services.
Collect credentials: Store verifiable credentials issued by others or self-asserted claims you vouch for yourself.
Present selectively: Share only the fields a verifier needs (for example prove you are over 18 without revealing your birthdate).
Customized DIDs: The ecosystem supports registering human-readable custom names that point at your DID, so you can share something memorable where the system allows it.
Transfer DID: Ownership of a DID can be transferred using on-chain mechanisms (for example transfer tickets), so control can move to a new keyholder when policy and tooling allow.
Multi-controller DIDs: Multiple keys can be listed as controllers, enabling shared custody, organizational accounts, or recovery patterns where several parties must cooperate.
Credential revocation: An issuer can revoke credentials it issued. Verifiers are expected to check revocation status (and chain history) so outdated attestations are not trusted forever.
If a university credential should no longer count because a degree was withdrawn, the issuer publishes revocation information. Your wallet might still hold the old file, but services that check the chain will refuse to rely on it.
Rotate keys: If a device is lost, you can move to new keys while keeping continuity according to the rules of your DID setup.
Deactivate: A DID can be deactivated on-chain when you want it to stop being valid for new interactions.
KYC and real-world identity
The Elastos.DID.App.KYC project illustrates how DID meets regulated checks: an Angular frontend talks to a Node.js backend that integrates Passbase (or similar providers) for document and liveness checks, then can issue credentials tied to the user’s DID. That pattern separates who verified you from every app re-scanning your passport.
One specification, many SDKs
Official SDKs exist for JavaScript/TypeScript, Java, Swift, and a native C core. They implement the same rules: a DID created with the JS SDK can be resolved and verified by the Java SDK, and vice versa, as long as chain endpoints and credential formats match.
Pick the SDK that fits your platform; you are not locked into one language for your whole stack, only into compatible publishing and verification behavior.
Runtime Identity: did:key
The ElastOS Runtime uses a separate, local identity format: did:key:z6Mk... based on Ed25519 keypairs. This did:key identity is generated locally on the device and used for:
- Signing messages over Carrier P2P
- Capsule identity and capability token binding
- Presence announcements
A bridge from the runtime's local did:key to on-chain did:elastos is planned but not yet available. When implemented, this will allow runtime identities to anchor to the EID chain, connecting local device identity with globally verifiable on-chain identity.
The did:key to did:elastos bridge is listed in the Runtime Roadmap as a planned feature. The existing did:elastos DID system described on this page remains the standard for on-chain identity.
Summary
Elastos DID is standards-based identity (did:elastos:i...), with clear roles for holders, issuers, and verifiers, rich DID documents (including @context, keys, services, and credentials), careful key derivation from a mnemonic, shared JSON-LD contexts for dozens of claim types, optional KYC-style issuance, cross-SDK compatibility, and advanced lifecycle features such as custom names, transfer, multi-controller setups, and issuer revocation, all anchored on EID for global verification without a central identity provider.