Decentralized Identifier / Verifiable Credential

Posted byNhat TruongPosted inBlockchain security, nhattruong.blog, Security SolutionsTags:, , , , , , , ,

I. Khái niệm DID và VC

Mô hình Self-Sovereign Identity (SSI)

Mô hình W3C và Decentralized Identity Foundation (DIF)

Một DID là một URI có dạng:

did:<method>:<method-specific-id>

Trong đó:

  • did → tiền tố cố định (scheme).
  • method → tên phương thức DID (ví dụ: web, ethr, ion, sov).
  • method-specific-id → định danh duy nhất theo phương thức đó (có thể là chuỗi hex, base58, UUID, hoặc đường dẫn web).

Một ví dụ DID rút gọn:

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:example:123456789abcdefghi",
  "verificationMethod": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2018",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyBase58": "H3C2...xyz"
  }],
  "authentication": [
    "did:example:123456789abcdefghi#keys-1"
  ],
  "service": [{
    "id": "did:example:123456789abcdefghi#vc",
    "type": "VerifiableCredentialService",
    "serviceEndpoint": "https://example.com/vc/"
  }]
}

Đặc tính quan trọng của DID:

  • Decentralized → không phụ thuộc vào cơ quan trung gian (CA, nhà phát hành tập trung).
  • Self-controlled → chủ sở hữu quản lý khóa riêng của chính mình.
  • Resolvable → bất kỳ ai cũng có thể “resolve” DID ra DID Document thông qua DID Resolver.
  • Cryptographically verifiable → DID Document chứa khóa công khai và proof.
  • Extensible → cho phép mở rộng với các trường, service mới.

Sự khác nhau giữa JOSE/JWS (JSON) và COSE (CBOR)

Định đạng CBOR, đặc trung là nhỏ gọn, nhị phân -> tối ưu cho các thiết bị IoT, mobile.

Một ví dụ COSE_Sign1 (dạng CBOR hex):

d28443a10126a1044234567890
   54686520636f6e74656e74
   58206d1c62f356f5ec...

Sự khác nhau giữa JSON thường và JSON-D

Json thường thì ai cũng biết rồi, với Json-d, là json có ngữ cảnh (context), dùng trường @context để ánh xạ key trong JSON sang IRI (Internationalized Resource Identifier), giúp máy tính hiểu rõ ngữ nghĩa. Điều này cho phép Liên thông dữ liệu giữa nhiều hệ thống khác nhau, Tự động kiểm chứng tính hợp lệ schema (vì mỗi trường ánh xạ tới một vocab chuẩn), Hỗ trợ các Data Integrity Proofs (Linked Data Proofs).

II. Kiến trúc tổng thể

Quy trình triển khai

  1. Chọn method DID
  2. Xây dựng dựng issuer node
  3. Tạo DID & DID document và ghi lên blockchain
  4. Issuer phát hành VC cho Holder
  5. Holder lưu VC trong DID Wallet
  6. Verifier kiểm tra VC bằng cách đối chiếu chữ ký và hash trên blockchain.

Lưu ý: VC thường không lưu toàn bộ trên blockchain để tránh lộ dữ liệu cá nhân, tiết kiệm phí gas. Chỉ lưu hash hoặc proof trên blockchain để kiểm chứng tính toàn vẹn.

Tạo/cập nhật/thu hồi DID:

Tạo DID:

  • Holder sinh cặp khóa.
  • Tạo DID Document chứa public key.
  • Đăng ký DID Document lên blockchain/registry (tùy method).

Cập nhật DID:

  • Thay đổi public key, thêm/bỏ service endpoint.
  • Ghi lại bản DID Document mới lên registry.

Thu hồi DID:

  • Ghi trạng thái thu hồi vào registry (tùy method hỗ trợ).
  • Khi resolve, verifier sẽ thấy DID đã không còn hợp lệ.

VC Data Model 2.0

Mô hình 3 bên:

Issuer: tổ chức phát hành credential (ví dụ: trường đại học, công ty).

Holder: cá nhân/tổ chức nhận credential và lưu trong ví DID Wallet.

Verifier: bên kiểm tra credential (vd: nhà tuyển dụng, cơ quan quản lý).

Luồng:
Issuer → cấp VC → Holder → trình VC → Verifier → kiểm chứng bằng DID + chữ ký số.

Quá trình convert DID thành DID Document, ví DID chỉ là một chuỗi nhãn, cung cấp tính động và quản trị vòng đời, cho phép cập nhật khóa khi bị rò rỉ, thêm dịch vụ mới và thu hồi DID. W3C DID Core cũng quy định rõ: Mọi DID phải có thể được resolve thành DID Document, DID Document mới là “tài nguyên” dùng trong xác minh mật mã.

So sánh giữa các method did:web và did:ion -> một cái did được ánh xạ tới một tên miền, một cái dùng sidetree protocol để ghi thông tin DID.

Giao thức phát hành & trình bày VC qua OIDC (OpenID Connect)

Đây là các chuẩn mới từ OpenID Foundation:

a) Issuance (OID4VCI – OpenID for Verifiable Credential Issuance)

  • Quy trình:
    1. Holder mở ví DID Wallet → quét QR hoặc deep link từ Issuer.
    2. Ví thiết lập kết nối OIDC với Issuer (giống login OAuth2).
    3. Issuer xác thực Holder (ví dụ qua OIDC login, hoặc E-KYC).
    4. Issuer phát hành VC, ký bằng DID của Issuer.
    5. VC được gửi về ví Holder (ở dạng JSON-LD, JWT, hoặc COSE).

Giống như quá trình “đăng nhập Google” nhưng thay vì token, bạn nhận credential để lưu vào ví.

b) Presentation (OID4VP – OpenID for Verifiable Presentations)

  • Quy trình:
    1. Verifier (website, app) hiển thị QR code chứa một Presentation Request.
    2. Holder quét bằng ví DID Wallet.
    3. Ví tạo Verifiable Presentation (VP) từ VC đã lưu, ký bằng DID của Holder.
    4. VP được gửi cho Verifier qua OIDC flow.
    5. Verifier kiểm tra:
      • Chữ ký Issuer trong credential.
      • Chữ ký Holder trong presentation.
      • Trạng thái credential (revoked hay không).

Tương tự “đăng nhập bằng Google”, nhưng thay vì Google nói “user này là A”, chính bạn (Holder) tự trình bằng chứng từ một Issuer tin cậy.

c) SIOPv2 (Self-Issued OpenID Provider v2)

  • Cho phép Holder dùng ví của mình như một Identity Provider (IdP).
  • Khi đăng nhập, thay vì redirect đến Google/Facebook, app sẽ kết nối với DID Wallet của Holder.
  • Holder chứng minh danh tính bằng cách ký bằng private key của mình.

Mô hình thu hồi/trạng thái Credential

Trong W3C VC Data Model, ngoài việc phát hành và xác minh, Issuer phải có cách thông báo rằng một VC đã:

  • bị thu hồi (revoked),
  • hoặc tạm ngưng (suspended),
  • hoặc vẫn đang valid.

Nếu không có cơ chế này, một credential bị lộ key hay bị sai sót sẽ mãi mãi hợp lệ → nguy cơ bảo mật lớn.

Cơ chế chính hiện nay:

  • StatusList2021 / Bitstring Status List (W3C)
    • Issuer công bố một “status list” dạng bitstring (rất gọn, có thể chứa trạng thái cho hàng triệu credential).
    • Mỗi credential khi phát hành kèm theo chỉ số (index) trong status list.
    • Khi verifier kiểm tra, họ sẽ tra index đó trong status list → xem credential còn hợp lệ hay đã revoked.
    • Ưu điểm: bảo toàn quyền riêng tư (không cần lộ danh sách holder).
  • Alternative models (ít dùng hơn):
    • CRL/OCSP-style (giống PKI), liệt kê ID các credential bị thu hồi.
    • On-chain revocation: ghi hash credential lên blockchain kèm trạng thái revoked.

Truyền thông giữa các Agent (DIDComm) (Optional)

Trong hệ sinh thái Self-Sovereign Identity (SSI), ba vai trò chính (Issuer, Holder, Verifier) thường chạy dưới dạng agent (software agent). Các agent cần một giao thức nhắn tin để:

  • Holder nhận credential từ Issuer.
  • Holder trình credential cho Verifier.
  • Issuer/Verifier gửi challenge–response để xác minh.

Giao thức chuẩn: DIDComm v2

  • Dựa trên DID: mỗi agent có một DID, trong DID Document có endpoint dịch vụ.
  • Mật mã đầu-cuối (E2E): thông điệp được mã hoá bằng public key trong DID Document, chỉ agent sở hữu private key mới đọc được.
  • Kiểu message: JSON + JWM (JSON Web Message).
  • Khả năng nhúng: DIDComm có thể chạy qua HTTP(S), WebSocket, Bluetooth, NFC, v.v.

Luồng điển hình:

  1. Verifier gửi một presentation request qua DIDComm tới Holder.
  2. Holder dùng credential đã lưu → tạo Verifiable Presentation (VP), ký bằng DID của mình.
  3. Holder gửi VP lại qua DIDComm.
  4. Verifier xác minh chữ ký và trạng thái VC (qua Status List).

Ưu điểm của DIDComm:

  • Không phụ thuộc hạ tầng trung gian (broker, CA).
  • Bảo mật mặc định (sign + encrypt end-to-end).
  • Tương tác realtime giữa các agent.
  • Được dùng trong hệ sinh thái Hyperledger Aries.

Published by Nhat Truong

Hi

Leave a comment