DID Là Gì? Decentralized Identifier — Kiến Trúc Kỹ Thuật Đầy Đủ

TL;DR — Tóm tắt trong 60 giây

DID (Decentralized Identifier) là URI được kiểm soát bởi chính chủ thể — không phụ thuộc centralized registry như ICANN
Cấu trúc: did:method:method-specific-id — ví dụ did:ethr:0x1234...abcd
DID Document chứa: public keys, authentication methods, service endpoints
DID Resolution: universal resolver tìm DID Document từ DID URI qua DID method
5 DID methods phổ biến: did:ethr, did:key, did:web, did:ion, did:pkh — mỗi cái có trade-off khác nhau
DID + Verifiable Credential = nền tảng của toàn bộ Self-Sovereign Identity stack

1. DID Là Gì — Định Nghĩa Kỹ Thuật

Decentralized Identifier (DID) là một loại identifier mới được W3C chuẩn hóa (DID Core v1.0, 2022). DID được thiết kế để giải quyết vấn đề cốt lõi của identifier truyền thống: phụ thuộc vào bên thứ ba để cấp và kiểm soát.

Username bạn có trên Twitter, email Google, hay domain name — tất cả đều có thể bị revoke, suspend, hoặc transfer mà không cần sự đồng ý của bạn. DID được tạo ra để thay đổi điều này: DID là identifier mà chỉ controller của DID mới có thể cập nhật hoặc revoke.

🔑

Định nghĩa W3C: "A DID is a URI that associates a DID subject with a DID document allowing trustable interactions associated with that subject." Controller của DID chứng minh quyền kiểm soát bằng cryptographic proof — không cần tin tưởng trung gian.

So sánh với identifier truyền thống

Loại	Kiểm soát bởi	Có thể revoke?	Phụ thuộc internet?	Privacy
Email (Gmail)	Google	Google có thể	Có	Thấp
Domain name	Registrar + ICANN	Registrar có thể	Có	Trung bình
Username (Twitter)	Twitter/X	Platform có thể	Có	Thấp
DID	Controller (bản thân)	Chỉ controller	Tùy method	Cao (có thể)

🔑

📌 Key Takeaway

DID = identifier bạn tự control, không cần ICANN hay Google. Resolve qua protocol, không qua centralized registry. Giống DNS nhưng không ai "own" root và không ai có thể revoke DID của bạn.

2. Cấu Trúc DID URI

DID là URI tuân theo format chuẩn gồm 3 phần:

// DID URI Syntax
did:method:method-specific-id

// Ví dụ thực tế:
did:ethr:0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
did:web:example.com
did:ion:EiClkZMDxPKqC9c-umQfTkR8vvZ9JPhl_xLDI9Nfk38w3Q
did:pkh:eip155:1:0x1f9090aaE28b8a3dCeaDf281B0F12828e676c326

// DID + Fragment (reference đến verification method cụ thể)
did:ethr:0x1234...#key-1

Mỗi DID method định nghĩa cách tạo method-specific-id và cách resolve DID Document từ id đó. W3C không prescribe method cụ thể — bất kỳ ai có thể define một DID method mới (và submit lên DID Method Registry).

🔑

📌 Key Takeaway

DID Document là "identity card metadata": public keys, service endpoints, authentication methods. Không chứa personal data. Verifier dùng DID Document để verify signature, không cần hỏi issuer — offline verifiable.

3. DID Document — Trung Tâm Của DID

DID Document là một JSON-LD document chứa thông tin cần thiết để interact với DID subject. DID Document không phải profile — không chứa tên, địa chỉ, hay thông tin cá nhân. Nó chỉ chứa cryptographic material và service endpoints.

// DID Document mẫu (JSON-LD)
{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:ethr:0x1f9090...326",

  "verificationMethod": [{
    "id": "did:ethr:0x1f9090...326#key-1",
    "type": "EcdsaSecp256k1VerificationKey2020",
    "controller": "did:ethr:0x1f9090...326",
    "publicKeyMultibase": "zQ3shokFTS3brGDhHhiLkJpzFnbU6D1BKXJLV..."
  }],

  "authentication": [
    "did:ethr:0x1f9090...326#key-1"
  ],

  "assertionMethod": [
    "did:ethr:0x1f9090...326#key-1"
  ],

  "keyAgreement": [{
    "id": "did:ethr:0x1f9090...326#key-2",
    "type": "X25519KeyAgreementKey2020",
    "controller": "did:ethr:0x1f9090...326",
    "publicKeyMultibase": "z6LSbysY2xFMRpGMhb7tFTLMpeuPRaqaWM1yE..."
  }],

  "service": [{
    "id": "did:ethr:0x1f9090...326#linked-domain",
    "type": "LinkedDomains",
    "serviceEndpoint": "https://example.com"
  }]
}

Các trường quan trọng

verificationMethod: Danh sách public key với type và encoding. Mỗi key có một ID riêng (dùng fragment).
authentication: Keys dùng để chứng minh bạn là controller của DID (sign authentication challenge).
assertionMethod: Keys dùng để ký Verifiable Credential.
keyAgreement: Keys dùng cho encrypted communication (thường là X25519).
service: Endpoints để interact với DID subject — có thể là messaging endpoint, credential endpoint, linked domain, v.v.

🔑

📌 Key Takeaway

DID method quyết định security model: did:key (local, ephemeral) vs did:web (domain trust, centralized) vs did:ethr (blockchain permanence). Chọn method sai = security model không phù hợp use case — không có method nào tốt cho mọi trường hợp.

4. DID Resolution — Từ DID Đến DID Document

DID Resolution là quá trình lấy DID Document từ một DID URI. Mỗi DID method có resolver riêng, nhưng Universal DID Resolver (do DIF phát triển) hỗ trợ nhiều method thông qua một API thống nhất.

// Universal Resolver API
GET https://dev.uniresolver.io/1.0/identifiers/{DID}

// Response structure
{
  "didDocument": { ... },           // DID Document
  "didDocumentMetadata": {
    "created": "2024-01-15T...",
    "updated": "2024-11-20T...",
    "deactivated": false,
    "versionId": "12345"
  },
  "didResolutionMetadata": {
    "contentType": "application/did+ld+json",
    "duration": 42                  // ms
  }
}

Resolution ≠ DNS lookup

DID Resolution phức tạp và chậm hơn DNS vì: (1) Không có centralized cache như DNS resolver; (2) Mỗi method có cơ chế resolve khác nhau (blockchain, P2P, HTTPS, v.v.); (3) Cần verify tính hợp lệ của DID Document; (4) Latency thường 100ms–5 giây tùy method.

⚠️

DID Dereferencing: Ngoài Resolution (lấy DID Document), còn có DID Dereferencing — resolve một fragment cụ thể trong DID Document (ví dụ: lấy một public key cụ thể). Hai khái niệm này hay bị nhầm lẫn.

🔑

📌 Key Takeaway

DID + VC separation of concerns: DID là identifier, VC là credential. Issuer không cần biết DID của holder khi issue VC. Holder quyết định link DID với VC khi nào và với ai — privacy by design ở kiến trúc layer.

5. So Sánh 5 DID Methods Phổ Biến

Method	Storage	Resolution	Privacy	Phù hợp với
did:ethr	Ethereum blockchain	On-chain lookup	Thấp (public)	Enterprise identity, on-chain credential
did:key	Không cần (embedded)	Instant (từ key)	Cao (ephemeral)	Short-lived, P2P, testing
did:web	HTTPS server	HTTPS GET	Trung bình	Domain-linked identity, organization DID
did:ion	Bitcoin + IPFS	ION node	Cao (Sidetree)	Long-lived, high-assurance identity
did:pkh	Chain account	Chain lookup	Trung bình	Wallet-as-identity, Web3 sign-in

did:key — Không cần registry

did:key là DID method đặc biệt: DID Document được derive trực tiếp từ public key — không cần lookup bất kỳ registry nào. Đây là lựa chọn tốt nhất cho ephemeral identity (ví dụ: một session giao tiếp) nhưng không phù hợp cho long-lived identity vì không thể update key.

did:ion — Microsoft Sidetree trên Bitcoin

ION (Identity Overlay Network) dùng Bitcoin blockchain như layer 1 ordering layer, lưu DID Document trên IPFS, và dùng Sidetree protocol để batch nhiều DID operation. Đây là approach phù hợp nhất cho high-assurance identity vì kế thừa security của Bitcoin mà không phải trả fee Bitcoin cho mỗi operation.

Để hiểu cách DID tích hợp với Verifiable Credential trong toàn bộ SSI stack, xem bài phân tích Verifiable Credentials. Để hiểu kiến trúc tổng thể, xem bài nghiên cứu chính về danh tính phi tập trung tại WLD.VN.

🔑

📌 Key Takeaway

DID rotation và key recovery là UX challenge chưa giải quyết tốt. Lost private key = lost DID trừ khi có recovery mechanism. Threshold signature, guardian, hoặc hardware wallet là 3 hướng giải quyết thực tế hiện tại.

6. Pipeline DID + VC — End-to-End Flow

DID và Verifiable Credential không tồn tại độc lập — chúng hoạt động cùng nhau trong một pipeline SSI hoàn chỉnh.

// Full SSI Flow

// === ISSUER ===
1. Issuer có DID: did:ethr:0xISSUER...
2. Issuer issue VC:
   {
     "issuer": "did:ethr:0xISSUER...",
     "credentialSubject": {
       "id": "did:key:zUSER...",    // DID của holder
       "age": 25,
       "nationality": "VN"
     },
     "proof": {
       "type": "Ed25519Signature2020",
       "verificationMethod": "did:ethr:0xISSUER...#key-1",
       "proofValue": "z58DAdFfa..."
     }
   }

// === HOLDER ===
3. Holder lưu VC trong wallet
4. Khi cần present, holder tạo VP (Verifiable Presentation):
   - Chọn VC liên quan
   - Ký VP bằng DID key của mình
   - Optional: tạo ZK proof (selective disclosure)

// === VERIFIER ===
5. Resolve DID của issuer → lấy DID Document
6. Verify chữ ký VC dùng public key từ DID Document
7. Verify chữ ký VP của holder
8. Check credential không bị revoke
9. → Trust hoặc reject

Trust chain trong DID/VC

Khác với PKI truyền thống (Certificate Authority chain), DID/VC trust là web of trust: verifier tự quyết định trust issuer nào. Không có root CA trung tâm. Điều này vừa là điểm mạnh (decentralized) vừa là thách thức (làm sao discover issuer tin cậy?).

🔑

📌 Key Takeaway

did:web là pragmatic choice cho enterprise hôm nay: deploy trên domain có sẵn, không cần blockchain. Nhược điểm: centralized, có thể bị taken down. Phù hợp regulated industry cần control và auditability.

7. Giới Hạn & Trade-off Thực Tế Của DID

Latency và UX

DID Resolution chậm hơn DNS 10–100x. User experience hiện tại còn phức tạp — wallet management, key backup, rotation chưa có UX tốt cho người dùng thông thường.

DID không phải identity

DID là identifier, không phải identity. DID chứng minh bạn kiểm soát một key — không chứng minh bạn là ai. Đó là việc của Verifiable Credential. Sự khác biệt này thường bị nhầm lẫn trong các bài viết.

Method fragmentation

Có hơn 100 DID method đã đăng ký. Không phải tất cả đều hoạt động tốt hoặc được maintain. Lựa chọn method sai có thể khóa identity vào một hệ sinh thái cụ thể.

Key loss = identity loss

Nếu mất private key và không có backup/recovery mechanism, identity bị mất vĩnh viễn. Social recovery và guardian-based recovery (như Argent wallet) đang được phát triển nhưng chưa phổ biến với DID.

Để hiểu tại sao Sybil resistanceKhả năng của hệ thống chống lại Sybil attack — đảm bảo một thực thể không thể kiểm soát hệ thống bằng cách tạo nhiều identity giả. — không phải DID — là vấn đề khó hơn trong identity, xem bài Sybil Attack. Để hiểu ZK proof giúp DID/VC system đạt privacy thật sự như thế nào, xem bài ZK Proof.

🔑

📌 Key Takeaway

did:jwk cho ephemeral AI agent hoặc short-lived session — không cần resolver. did:tdw thêm cryptographic audit log cho did:web — hướng đi của regulated industry khi cần immutable history. Cả hai tăng adoption mạnh năm 2025.

7. DID Mới Nhất — did:jwk, did:tdw & Xu Hướng 2025

W3C DID ecosystem đang phát triển nhanh. Ngoài 5 method phổ biến đã phân tích, một số method mới đang được adopt rộng rãi:

did:jwk — Đơn Giản Nhất Có Thể

did:jwk encode toàn bộ public key vào DID identifier dưới dạng base64url-encoded JWK. Không cần resolver, không cần registry, không cần blockchain — DID Document được derive trực tiếp từ DID string.

// did:jwk — toàn bộ public key nằm trong DID URI
DID: did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6Ii4uLiIsInkiOiIuLi4ifQ
     // base64url({"kty":"EC","crv":"P-256","x":"...","y":"..."})

// DID Document — derived trực tiếp, không cần resolve
{
  "id": "did:jwk:eyJrdHkiOi...",
  "verificationMethod": [{
    "id": "did:jwk:eyJrdHkiOi...#0",
    "type": "JsonWebKey2020",
    "publicKeyJwk": {"kty":"EC","crv":"P-256","x":"...","y":"..."}
  }]
}
// Use case: ephemeral agent identity, short-lived credential
// Không rotate được — chỉ dùng cho single-use identifier

did:tdw — Trust DID Web (2024)

did:tdw (Trust DID Web) là evolution của did:web — thêm cryptographic audit log bất biến cho DID Document history. Mỗi update phải được ký và chứa hash của version trước — không thể retroactively thay đổi lịch sử.

// did:tdw adds tamper-proof history to did:web
DID: did:tdw:example.com:user:alice

// Mỗi version trong log:
{
  "versionId": "1-HASH_OF_THIS_VERSION",
  "versionTime": "2026-03-07T00:00:00Z",
  "parameters": {"updateKeys": ["ED25519_PUBKEY"]},
  "state": { /* DID Document content */ },
  "proof": [{
    "type": "DataIntegrityProof",
    "previousVersionId": "0-GENESIS_HASH",   ← chain log
    "proofValue": "SIGNATURE"
  }]
}
// Use case: long-lived identity với auditable history
// Phù hợp hơn did:web cho regulated industry

DID vs OpenID Connect — Không Phải Đối Thủ

Aspect	OpenID Connect	DID + VC
Identity provider	Bắt buộc (Google, Azure...)	Không cần — self-sovereign
Credential portability	Không — gắn với IdP	Có — holder owns credential
Offline verify	Không — cần IdP online	Có — chỉ cần public key
Adoption hiện tại	Rất cao (OAuth2 ecosystem)	Đang tăng
Interop path	OIDC4VP — present VC qua OIDC protocol (bridge)

Thực tế tốt nhất: dùng OIDC4VP (OpenID for Verifiable Presentations) như bridge — giữ OIDC flow quen thuộc cho developer, nhưng payload là VC thay vì JWT claims. Đây là hướng eIDASElectronic IDentification, Authentication and trust Services: khung pháp lý EU về định danh số. eIDAS 2.0 (2024) yêu cầu digital wallet cho 400M+ công dân EU. 2.0 đang đi.

8. DID Tại Việt Nam — Tích Hợp VNeID & CCCD

DID không cần blockchain hay radical change của hạ tầng hiện tại. Ngay với stack hiện tại, VN có thể bắt đầu với did:web:

Scenario thực tế: VNeID dùng did:web

// VNeID adopt did:web — không cần thay đổi hạ tầng lớn
DID issuer: did:web:vneid.gov.vn

// → Resolve: GET https://vneid.gov.vn/.well-known/did.json
{
  "id": "did:web:vneid.gov.vn",
  "verificationMethod": [{
    "id": "did:web:vneid.gov.vn#signing-key-2026",
    "type": "JsonWebKey2020",
    "publicKeyJwk": { "kty": "EC", "crv": "P-256", ... }
  }]
}

// VNeID issue VC cho công dân:
{
  "issuer": "did:web:vneid.gov.vn",
  "credentialSubject": {
    "id": "did:key:zUSER_KEYPAIR",   ← mỗi user có DID riêng
    "nationality": "VN",
    "province": "HCM",
    "kyc_level": "L2",
    "age_over_18": true
  }
}
// Không cần expose id_number hay full name trong VC
// Bank verify: GET vneid.gov.vn/.well-known/did.json → check sig

Đây không phải viễn cảnh xa — VNeID đã có PKI infrastructure, chỉ cần expose DID Document endpoint và chuẩn hóa VC format. Về Verifiable Credential format và selective disclosureChia sẻ có chọn lựa: từ một credential nhiều thuộc tính, chỉ reveal đúng những gì verifier cần — không lộ thêm bất kỳ thông tin nào., xem bài Verifiable Credentials. Về tổng quan ecosystem, xem bài nghiên cứu chính.

🔑

📌 Key Takeaway

Việt Nam chưa có DID standard chính thức — đây là gap governance, không phải gap kỹ thuật. did:web + SD-JWTSelective Disclosure JWT: chuẩn chia sẻ có chọn lựa. Issuer hash từng claim riêng — holder chọn reveal claim nào. Được eIDAS 2.0 chọn làm standard. là stack triển khai được ngay, compatible với eIDAS direction, không cần blockchain, không cần luật mới.

Câu hỏi thường gặp

DID có thể bị hack không?

DID bản thân là identifier — không bị hack. Nhưng private key kiểm soát DID có thể bị đánh cắp. Khi đó, attacker có thể update DID Document, thêm key của họ vào, và effectively chiếm quyền kiểm soát DID. Đây là lý do key management và backup là critical. Một số DID method hỗ trợ multi-sig controller để giảm single key risk.

DID khác username thế nào?

Username: được tạo bởi platform, platform có thể xóa, transfer, hay suspend bất kỳ lúc nào. DID: được tạo bởi controller, chỉ controller có quyền update hay deactivate. DID cũng là globally unique — không có 'DID collision' giữa các system khác nhau vì format DID bao gồm method (namespace).

DID và domain name khác nhau thế nào?

Domain name được quản lý bởi centralized registry (ICANN) và registrar — có renewal fee, có thể bị seized bởi chính phủ, có thể expire. DID không có central authority, không có renewal fee. Nhưng DID resolution phức tạp và chậm hơn DNS nhiều. did:web là trường hợp đặc biệt: dùng domain name làm DID — kế thừa cả ưu và nhược điểm của cả hai.

Làm sao biết DID Document có hợp lệ không?

DID Document hợp lệ khi: (1) Được lấy thông qua DID method resolution đúng quy trình, (2) Không bị tamper (integrity check tùy method — blockchain immutability hoặc HTTPS TLS), (3) DID không bị deactivated (check didDocumentMetadata.deactivated). Với blockchain-based method như did:ethr, DID Document hash được stored on-chain, đảm bảo integrity.

Một người có thể có nhiều DID không?

Có — và thường nên có nhiều DID cho mục đích khác nhau (như có nhiều email). DID khác nhau cho: work identity, personal identity, pseudonymous identity, short-lived session. Điều này tăng privacy — verifier không thể correlate các DID với nhau nếu không có shared context. Nhưng credential phải được issue cho từng DID riêng, và management phức tạp hơn.

Tài liệu tham khảo

W3C. Decentralized Identifiers (DIDs) v1.0. w3.org/TR/did-core/. 2022.
W3C. DID Use Cases and Requirements. w3.org/TR/did-use-cases/.
DIF. Universal DID Resolver. dev.uniresolver.io.
Microsoft. ION — Identity Overlay Network on Bitcoin. identity.foundation/ion/.
Ethereum DID Registry. did:ethr Method Specification. github.com/decentralized-identity/ethr-did-resolver.
ZRO Research. AI & Identity Research Hub. zro.vn/wld-vn/.