Verifiable Credentials (VC) — W3C Standard Đến DeFi KYC Thực Chiến

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

Verifiable Credential (VC) là digital credential được ký cryptographic — machine-verifiable mà không cần hỏi issuer
W3C VC Data Model 2.0 định nghĩa chuẩn: credential = claims + metadata + proof
JWT-VC: đơn giản, Web2-compatible. JSON-LD VC: phong phú ngữ nghĩa, linked data
BBS+Pairing-based signature scheme cho phép 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. với unlinkability mạnh: issuer ký một lần, holder reveal subset bất kỳ mà không thể link các lần present. Selective Disclosure: prove một thuộc tính trong credential mà không tiết lộ phần còn lại
Revocation: StatusList2021 — bitmap compressed, privacy-friendly hơn OCSP
VC + DID + ZK proof = full privacy-preserving identity stack

1. Verifiable Credential Là Gì — Khác Gì JWT Thường?

Verifiable Credential (VC) là một digital document chứa claims về một subject, được ký bởi issuer, và có thể được verify bởi bất kỳ ai — mà không cần hỏi lại issuer.

Điểm khác biệt với JWT thông thường:

Tiêu chí	JWT thường	Verifiable Credential
Verify bằng cách	Check với issuer server	Verify chữ ký offline
Revocation	Server-side blacklist	StatusList2021 (decentralized)
Semantic meaning	Tự define, không chuẩn	W3C schema, linked data
Selective disclosure	Không hỗ trợ	BBS+ hoặc 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 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 chọn làm standard.
Holder binding	Thường không	DID-based holder binding
Interoperability	Thấp (tự define)	Cao (W3C standard)

📜

📌 Key Takeaway

VC = chứng chỉ số có chữ ký cryptographic. Property quan trọng nhất: issuer unlinkability — issuer không biết khi nào, ở đâu credential được dùng. Holder own và control credential của mình — không phải platform.

2. W3C VC Data Model 2.0 — Cấu Trúc Chi Tiết

// Verifiable Credential (JSON-LD format)
{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://schema.org/"
  ],
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "id": "https://university.example/credentials/58473",

  "issuer": {
    "id": "did:ethr:0xISSUER...",
    "name": "Đại học Bách Khoa HCM"
  },

  "validFrom": "2024-06-15T00:00:00Z",
  "validUntil": "2034-06-15T00:00:00Z",

  "credentialSubject": {
    "id": "did:key:zHOLDER...",  // DID của holder
    "degree": {
      "type": "BachelorDegree",
      "name": "Kỹ thuật Máy tính",
      "gpa": "3.8"
    }
  },

  "credentialStatus": {
    "id": "https://university.example/status/94567#0",
    "type": "StatusList2021Entry",
    "statusListIndex": "0",
    "statusListCredential": "https://university.example/status/94567"
  },

  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-06-15T12:00:00Z",
    "verificationMethod": "did:ethr:0xISSUER...#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa..."
  }
}

Các trường bắt buộc và tùy chọn

@context: Bắt buộc — định nghĩa semantic của các term dùng trong VC. type: Bắt buộc — phải có "VerifiableCredential" và type cụ thể. issuer: Bắt buộc — DID của issuer. credentialSubject: Bắt buộc — chứa claims về subject. proof: Bắt buộc để trở thành "Verifiable" — chữ ký của issuer.

📜

📌 Key Takeaway

VC Data Model 2.0 (W3C): context + type + issuer + credentialSubject + proof. Proof section chứa chữ ký issuer — quyết định có thể verify offline không. Luôn dùng W3C standard, không tự invented format.

3. JWT-VC vs JSON-LD VC — Khi Nào Dùng Cái Nào?

W3C hỗ trợ hai serialization format chính cho VC:

JWT-VC (VC-JWT)

Encode VC thành JWT — format quen thuộc với Web2 developer. Dễ integrate với hệ thống có sẵn. Thư viện JWT có ở mọi ngôn ngữ.

✅

Dùng JWT-VC khi: Integrate với hệ thống enterprise đang dùng JWT, cần simplicity và developer adoption cao, không cần selective disclosure, hệ sinh thái chưa hỗ trợ JSON-LD đầy đủ.

JSON-LD VC

VC được biểu diễn dưới dạng JSON-LD — Linked Data format. Giàu semantic hơn, interoperable hơn, hỗ trợ graph queries và linked data reasoning. Cần hỗ trợ của JSON-LD library.

✅

Dùng JSON-LD VC khi: Cần semantic interoperability cao, dùng BBS+ selective disclosure, ecosystem đã hỗ trợ JSON-LD (như nhiều SSI framework), cần rich linked data queries.

SD-JWT VC (mới nhất)

Selective Disclosure JWT — format mới từ IETF cho phép selective disclosure mà không cần BBS+ pairing. Nhẹ hơn BBS+, không cần trusted setupNghi thức khởi tạo một lần cho zk-SNARK: nhiều bên generate tham số và xóa secret. An toàn nếu ít nhất 1 bên honest. Không cần cho zk-STARK.. Đang được adoption mạnh trong eIDAS 2.0 và mobile driver license (mDL).

📜

📌 Key Takeaway

Credential revocation là bài toán khó nhất: Bitstring Status List 2021 là chuẩn thực tế nhưng có privacy risk khi verifier biết holder đang dùng credential nào. Thiết kế revocation cần cân nhắc cả privacy và freshness.

4. BBS+ Selective Disclosure — Privacy-Preserving Presentation

Vấn đề: Nếu holder nhận một VC chứa nhiều claims (tên, tuổi, địa chỉ, quốc tịch, bằng cấp...) nhưng chỉ muốn prove một số claim, làm sao tránh reveal toàn bộ VC?

BBS+ Signature giải quyết điều này: issuer sign tất cả messages trong VC với một BBS+ signature. Holder có thể create một derived proof chứng minh một subset của messages đó — mà không reveal các messages khác và không reveal original signature.

// BBS+ Selective Disclosure Flow

// VC gốc chứa:
credentialSubject: {
  name: "Nguyen Van A",
  dob: "1995-03-15",       ← muốn hide
  nationality: "VN",        ← muốn prove
  creditScore: 750,         ← muốn hide exact value
  incomeRange: "50M-100M"   ← muốn prove
}

// Holder tạo derived proof chỉ reveal:
revealedAttributes: ["nationality", "incomeRange"]

// Verifier nhận:
{
  nationality: "VN",
  incomeRange: "50M-100M",
  proof: "BBS+ derived proof"  // verify rằng các attrs này thuộc VC hợp lệ
}
// Verifier KHÔNG biết: name, dob, creditScore

⚠️

Limitation của BBS+: Chỉ selective disclosure về "có hay không" — không thể prove về range (ví dụ: "age > 18 mà không reveal exact age"). Để prove về range, cần kết hợp với ZK proof. Xem bài ZK Proof để hiểu cách kết hợp.

📜

📌 Key Takeaway

Verifiable Presentation: holder wrap VC vào VP với chữ ký mới → verifier verify cả VP lẫn VC signature. Domain binding trong VP ngăn presentation replay attack — không bỏ qua bước này trong production.

5. Credential Revocation — StatusList2021

Làm sao issuer có thể revoke một VC đã issue? Không thể dùng traditional OCSP (Online Certificate Status Protocol) vì làm lộ thông tin holder.

StatusList2021 — Cách hoạt động

// StatusList2021: bitstring compressed list

1. Issuer tạo StatusList Credential chứa BITSTRING 131,072 bits
2. Mỗi VC được assign một index (0–131071)
3. Bit tại index = 0: VC valid
   Bit tại index = 1: VC revoked

4. Bitstring được GZIP compress → ~16KB cho 131K credentials
5. StatusList Credential được publish public (ai cũng có thể check)

// Privacy: verifier biết VC có bị revoke không
// Nhưng không biết index nào của holder vì:
// - Bitstring index không correlate với identity
// - Cần biết index cụ thể mới check được
// - Herd privacy: list có hàng chục ngàn entries

So sánh: OCSP yêu cầu contact issuer server mỗi lần verify (privacy leak + availability dependency). StatusList2021 là static file, cacheable, không cần real-time contact với issuer, và bảo vệ privacy tốt hơn.

📜

📌 Key Takeaway

SD-JWT đang trở thành standard thực tế toàn cầu nhờ eIDAS 2.0 chọn SD-JWT. BBS+ mạnh hơn về unlinkability nhưng phức tạp hơn nhiều. Cho hầu hết use case Việt Nam hiện tại, SD-JWT là lựa chọn đúng.

6. Verifiable Presentation — Từ VC Đến Proof

Holder không trực tiếp gửi VC cho verifier — họ tạo một Verifiable Presentation (VP): một wrapper chứa một hoặc nhiều VC, được ký bởi holder để chứng minh holder thực sự kiểm soát VC đó.

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiablePresentation"],

  "verifiableCredential": [
    { ... }  // VC gốc hoặc derived proof
  ],

  "proof": {
    "type": "Ed25519Signature2020",
    "challenge": "abc123",  // từ verifier — chống replay
    "domain": "https://defi.example.com",
    "verificationMethod": "did:key:zHOLDER...#key-1",
    "proofValue": "zHolder_signature..."
  }
}

Trường challenge và domain quan trọng để chống replay attack — verifier gửi challenge trước, holder phải include challenge vào VP signature. Điều này đảm bảo VP chỉ valid cho đúng verifier và đúng thời điểm.

Để hiểu tại sao ZK proof là bước tiếp theo tự nhiên sau VC để đạt privacy tốt hơn, xem bài ZK Proof cơ bản. Về kiến trúc DID là nền tảng để VC hoạt động, xem bài DID là gì.

📜

📌 Key Takeaway

OID4VC bridge giữa OAuth/OIDC ecosystem và VC world — không cần rewrite toàn bộ identity infrastructure. Cho phép existing identity provider issue VC ngay hôm nay với minimal changes.

7. Ứng Dụng Thực Tế: DeFiDecentralized Finance: tài chính phi tập trung dựa trên smart contract, không qua ngân hàng hay sàn tập trung. KYC, Age Verification, Employment

DeFi KYC-Gate

Protocol cần comply với regulation nhưng không muốn centralized KYC provider: user nhận VC "Non-US Resident, KYC Verified" từ third-party issuer, present ZK proof của VC để truy cập protocol mà không reveal identity.

Age verification cho content platform

Platform cần biết user đủ 18 tuổi nhưng không cần biết ngày sinh hay identity thật. User present derived proof từ VC passport "tôi đủ 18 tuổi" — với BBS+ chỉ reveal attribute "adult: true".

Employment verification

Employer issue VC "đang làm việc tại công ty X, role Y". User present đến ngân hàng để vay vốn mà không cần employer phải gửi letter hay bank phải call. Bank verify signature của employer DID offline.

📜

📌 Key Takeaway

Việt Nam thực tế: eKYC (Thông tư 09) là cửa ngõ pháp lý. did:web + SD-JWT là stack đơn giản nhất để implement VC-based KYC compliance ngay, không cần blockchain, không cần luật mới.

8. SD-JWT VC — Code Example Đầy Đủ

SD-JWT (Selective Disclosure JWT) là format được lựa chọn trong eIDAS 2.0 và ISO mDL. Đây là cách nó hoạt động trong thực tế — đơn giản hơn BBS+ nhưng đủ mạnh cho hầu hết use case:

// BƯỚC 1: Issuer tạo SD-JWT
// Mỗi claim được hash riêng lẻ → holder chọn reveal cái nào

Header: { "alg": "ES256", "typ": "vc+sd-jwt" }

Payload:
{
  "iss": "https://issuer.example.vn",
  "iat": 1709856000,
  "exp": 1741392000,
  "vct": "IdentityCredential",

  // Claims bị hash — không visible trực tiếp
  "_sd": [
    "WyJzYWx0MSIsICJuYW1lIiwgIk5ndXllbiBWYW4gQSJd",  ← H(salt + "name" + "Nguyen Van A")
    "WyJzYWx0MiIsICJkb2IiLCAiMTk5NS0wMy0xNSJd",    ← H(salt + "dob" + "1995-03-15")
    "WyJzYWx0MyIsICJuYXRpb25hbGl0eSIsICJWTiJd",    ← H(salt + "nationality" + "VN")
    "WyJzYWx0NCIsICJhZ2Vfb3Zlcl8xOCIsIHRydWVd"     ← H(salt + "age_over_18" + true)
  ],
  "_sd_alg": "sha-256"
}
// Signed by issuer → SD-JWT token

// BƯỚC 2: Holder nhận SD-JWT + disclosures
// Disclosures là base64 của [salt, claim_name, claim_value]
disclosures = {
  "name":         "WyJzYWx0MSIsICJuYW1lIiwgIk5ndXllbiBWYW4gQSJd",
  "dob":          "WyJzYWx0MiIsICJkb2IiLCAiMTk5NS0wMy0xNSJd",
  "nationality":  "WyJzYWx0MyIsICJuYXRpb25hbGl0eSIsICJWTiJd",
  "age_over_18":  "WyJzYWx0NCIsICJhZ2Vfb3Zlcl8xOCIsIHRydWVd"
}

// BƯỚC 3: Holder tạo VP — chỉ reveal nationality + age_over_18
presentation = SD_JWT + "~" + disclosures["nationality"] + "~" + disclosures["age_over_18"]
// name và dob KHÔNG được include → verifier không biết

// BƯỚC 4: Verifier nhận presentation
// 1. Verify SD-JWT signature của issuer
// 2. Compute hash của disclosures được include
// 3. Check hash có trong _sd array không
// → Verifier biết: nationality=VN, age_over_18=true
// → Verifier KHÔNG biết: name, dob

🔑

SD-JWT vs BBS+: SD-JWT đơn giản hơn, không cần pairing-based crypto, không cần trusted setup. Verifier biết holder đã reveal đúng claims nào. BBS+ mạnh hơn về unlinkability — verifier không thể biết còn claims nào khác trong credential. Cho hầu hết use case VN hiện tại, SD-JWT là lựa chọn thực tế hơn.

📜

📌 Key Takeaway

SD-JWT code flow: Issuer hash từng claim riêng → Holder chọn reveal claim nào → Verifier verify hash trong _sd array match. Đơn giản, không cần pairing-based crypto, chạy được trên browser thông thường.

9. Ứng Dụng Tại Việt Nam — Ngân Hàng Số & Chính Phủ Điện Tử

Verifiable Credential không chỉ là công nghệ của Web3. Nó đang được áp dụng (hoặc có tiềm năng lớn) ngay trong hệ sinh thái digital Việt Nam:

Ngân hàng số — KYC một lần, dùng nhiều nơi

Theo Thông tư 16/2020/TT-NHNN và các cập nhật sau, ngân hàng VN phải eKYC khách hàng khi mở tài khoản. Vấn đề hiện tại: mỗi ngân hàng làm KYC riêng — người dùng phải upload CCCD, selfie, liveness check với từng app.

Mô hình VC giải quyết điều này: NAPAS hoặc Ngân hàng Nhà Nước đóng vai trusted issuer — issue VC "KYC Verified Level 2" cho người dùng đã pass eKYC chuẩn. Các ngân hàng khác chỉ cần verify VC thay vì làm lại từ đầu. Pilot tương tự đang chạy ở Singapore (MyInfo) và đang được xem xét trong ASEAN eKYC framework.

Chứng chỉ nghề nghiệp & bằng cấp

Bộ GD&ĐT, Bộ LĐ-TB&XH issue bằng cấp dưới dạng VC — sinh viên có thể present với nhà tuyển dụng mà không cần công chứng. Nhà tuyển dụng verify chữ ký của trường/bộ offline — không cần gọi điện xác nhận, không cần certificate bản cứng. Techcombank đã thử nghiệm verified employment credential cho vay tiêu dùng nhanh.

CCCD + VC Pipeline — Tích hợp khả thi

// Pipeline: CCCD chip → VC → Service

1. User tap CCCD lên NFC reader (app VNeID)
2. App đọc data từ chip: name, dob, id_number, photo_hash
3. App tạo request đến VNeID server với chip signature
4. VNeID server verify chip → issue VC:
   {
     "issuer": "did:web:vneid.gov.vn",
     "credentialSubject": {
       "id": "did:key:zUSER_KEY",
       "citizenId_hash": "HASH(id_number)",  ← không expose raw ID
       "nationality": "VN",
       "age_over_18": true,
       "province": "HCM",
       "kyc_level": "L3"  ← đã verify chip + face
     }
   }
5. User dùng VC present với bank/service
   → SD-JWT reveal chỉ: nationality + age_over_18 + kyc_level
   → Bank không biết id_number thật

Để hiểu kiến trúc DID mà VNeID cần adopt để làm được pipeline này, xem bài DID là gì. Về SD-JWT trong eIDAS 2.0 và bài học cho VN, xem bài eIDAS 2.0 & Danh tính số Việt Nam.

📜

📌 Key Takeaway

Việt Nam cần trusted issuer registry trước khi VC ecosystem hoạt động được. Singapore MyInfo là model gần nhất: centralized nhưng consent-driven, API mở, đã chứng minh được ở production scale.

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

Verifiable Credential khác gì với certificate SSL/TLS?

SSL certificate chứng minh domain ownership cho HTTPS — machine-to-machine. VC chứa claims về người hoặc tổ chức — designed for human identity use cases. SSL cert được managed bởi CA hierarchy (centralized). VC được designed cho decentralized trust — verifier tự quyết định trust issuer nào. Format và semantic hoàn toàn khác nhau dù đều dùng chữ ký digital.

VC có thể bị giả mạo không?

Không thể giả mạo nếu: (1) Private key của issuer an toàn, (2) Verifier resolve DID của issuer đúng cách và verify chữ ký. Rủi ro thực tế: issuer key bị compromise, DID Document bị hijack, hoặc verifier skip một bước verify. Với implementation đúng, VC forgery-resistant về mặt cryptographic.

BBS+ selective disclosure khác gì ZK proof?

BBS+ reveal một subset attributes của credential — verifier biết chính xác giá trị của attributes được reveal. ZK proof prove một statement về attributes (ví dụ: 'age > 18') mà không tiết lộ giá trị thật. BBS+ đơn giản hơn, không cần circuit. ZK proof mạnh hơn cho range proofs và complex conditions nhưng cần circuit design phức tạp hơn. Trong thực tế, hay kết hợp: BBS+ select attributes, ZK prove conditions trên attributes đó.

SD-JWT VC là gì và có thay thế BBS+ không?

SD-JWT (Selective Disclosure JWT) là format mới từ IETF cho phép holder hide một số claims trong JWT mà không cần BBS+ pairing. Đơn giản hơn về cryptography, không cần trusted setup, được IETF standardize. Đang được adopt mạnh trong eIDAS 2.0 (EU Digital Identity Wallet). BBS+ mạnh hơn cho unlinkability (verifier không thể biết holder đã present những claims nào khác), nhưng SD-JWT đơn giản hơn cho adoption. Hai approach cùng tồn tại cho use case khác nhau.

VC và token blockchain khác nhau thế nào?

Token blockchain (ERC-20, NFT): fungible hoặc non-fungible asset on-chain, publicly visible, transferable, tied to address. VC: off-chain credential, private, tied to DID (không phải address), non-transferable (holder binding), machine-verifiable bằng chữ ký. Dù cả hai dùng cryptography, chúng giải quyết bài toán hoàn toàn khác nhau. NFT credential (dùng NFT như credential) là một anti-pattern — nó publicize credential data lên blockchain khi mestinya private.

Tài liệu tham khảo

W3C. Verifiable Credentials Data Model v2.0. w3.org/TR/vc-data-model-2.0/. 2024.
W3C. Verifiable Credential Use Cases. w3.org/TR/vc-use-cases/.
Boneh, D. et al. BBS: A New Pairing-Based Group Signature Scheme. IACR ePrint 2022.
IETF. SD-JWT: Selective Disclosure for JWTs. draft-ietf-oauth-selective-disclosure-jwt.
W3C CCG. Status List 2021. w3c-ccg.github.io/vc-status-list-2021/.
ZRO Research. AI & Identity Research Hub. zro.vn/wld-vn/.