Open Badge v2 và v3: So Sánh Chi Tiết — Bạn Nên Dùng Chuẩn Nào Ngay Hôm Nay?

Nếu bạn đang xây dựng một chương trình cấp chứng chỉ vào năm 2026, chỉ sau một giờ tìm hiểu bạn sẽ gặp ngay câu hỏi này: nên phát hành Open Badge v2.0 hay bản v3.0 mới hơn? Câu trả lời thành thật là “còn tùy ai sẽ là người đọc chứng chỉ của bạn” — nhưng câu trả lời đó không giúp ích gì nếu bạn phải quyết định trước thứ Sáu này. Vậy hãy cùng xem điều gì thực sự thay đổi giữa hai chuẩn này, ai đang hỗ trợ gì ngay lúc này, và phần lớn tổ chức cấp nên chọn chuẩn nào ngay bây giờ.

Open Badge v2.0 thực sự là gì

Open Badge v2.0 là đặc tả của 1EdTech (trước đây là IMS Global), đã là nền tảng của việc cấp chứng chỉ số kể từ năm 2017. Nó được xây dựng trên JSON-LD và cấu trúc quanh ba đối tượng liên kết với nhau:

• IssuerOrg — tổ chức cấp huy hiệu (tên, URL, email, logo)
• BadgeClass — bản thân loại chứng chỉ (tên, mô tả, tiêu chí, hình ảnh)
• Assertion — lần trao cụ thể cho một người nhận cụ thể (danh tính người nhận, ngày cấp, bằng chứng, phương thức xác minh)

Assertion của một người nhận trỏ tới một BadgeClass, và BadgeClass lại trỏ ngược về IssuerOrg. Việc xác minh diễn ra theo một trong hai cách: hosted (bên xác minh lấy dữ liệu JSON của Assertion trực tiếp từ một URL cố định và tin tưởng vào tên miền đó) hoặc signed (Assertion mang theo chữ ký JWS mà bên xác minh kiểm tra dựa trên khóa công khai đã công bố của tổ chức cấp). Hầu hết các nền tảng, kể cả badges.ninja, mặc định dùng xác minh hosted và có tùy chọn signed, vì hosted dễ triển khai hơn và con người cũng dễ kiểm tra nhanh hơn.

Dưới đây là một Assertion v2.0 đã được rút gọn, kiểu dữ liệu bạn sẽ nhận được từ lệnh gọi GET /awards/{id}:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://badges.ninja/certify-badge/award/9f2a1c...",
  "recipient": {
    "type": "email",
    "hashed": true,
    "salt": "a1b2c3",
    "identity": "sha256$8f14e45..."
  },
  "badge": "https://badges.ninja/certify-badge/badge/7d3e...",
  "issuedOn": "2026-08-01T00:00:00Z",
  "verification": { "type": "hosted" }
}

Chính cấu trúc đó là lý do vì sao v2.0 đã trở thành chuẩn mực trên thực tế: đủ đơn giản để triển khai trong một buổi chiều, và đó cũng là thứ mà hầu hết mọi bên tiêu thụ dữ liệu huy hiệu đều mong đợi thấy.

Xác minh hosted và signed trong v2.0

Điều đáng hiểu rõ là hai chế độ xác minh bên trong chính v2.0, vì mọi người thường nhầm lẫn giữa “v2.0 kém an toàn hơn v3.0” với “xác minh hosted kém an toàn hơn signed.” Đây là hai trục hoàn toàn khác nhau.

• Hosted — verification.type là "hosted", và id của Assertion là một URL sống. Bên xác minh lấy URL đó và kiểm tra phản hồi có khớp không; sự tin tưởng đến từ việc kiểm soát tên miền (ví dụ: chỉ badges.ninja mới có thể xuất bản lên badges.ninja/certify-badge/award/...). Đây là cách mà hầu hết các trang xác minh hướng tới người dùng cuối sử dụng vì con người chỉ cần bấm vào liên kết.
• Signed — verification.type là "signed", và Assertion mang theo (hoặc tham chiếu tới) chữ ký JWS trên toàn bộ payload. Bên xác minh giải quyết khóa công khai của tổ chức cấp và kiểm tra chữ ký độc lập với việc URL có truy cập được hay không. Cách này gần với tinh thần của mô hình v3.0 hơn, chỉ là không có lớp DID.

Một đoạn kiểm tra xác minh signed tối giản trong Node trông như thế này:

import { jwtVerify, importJWK } from 'jose';

const publicKey = await importJWK(issuerJwk, 'RS256');
const { payload } = await jwtVerify(assertionJws, publicKey);
// payload now contains the verified Assertion claims

Nếu chương trình của bạn quan tâm đến việc chứng chỉ vẫn xác minh được ngay cả khi API của bạn tạm ngừng để bảo trì, thì signed v2.0 mang lại cho bạn phần lớn lợi ích về độ bền của v3.0 mà không cần áp dụng DID.

Open Badge v3.0 thay đổi những gì

Open Badge v3.0 là một bản viết lại dựa trên mô hình dữ liệu W3C Verifiable Credentials (VC), chứ không phải một bản nâng cấp dần từ cấu trúc JSON-LD của v2.0. Những khác biệt thực sự quan trọng:

• Ký mã hóa theo mặc định. Mọi chứng chỉ v3.0 đều là một VC đã được ký — không còn phương án dự phòng “hosted, tin tưởng URL.” Việc xác minh luôn dựa trên toán học, không dựa trên tên miền.
• Danh tính tổ chức cấp dựa trên DID. Thay vì một đối tượng IssuerOrg với URL và email, tổ chức cấp được xác định bằng một Decentralized Identifier (DID), tương ứng với một tài liệu khóa công khai.
• Đồng bộ với Comprehensive Learner Record (CLR) 2.0. v3.0 được thiết kế để tương tác với CLR, nên một chứng chỉ duy nhất có thể mang cả dữ liệu thành tích lẫn các chi tiết bảng điểm có cấu trúc mà các hệ thống tiêu thụ CLR mong đợi (năng lực, kết quả đánh giá, ngữ cảnh học kỳ/khóa học).
• Tương thích ví số. Vì chứng chỉ v3.0 là VC chuẩn W3C, chúng có thể được lưu trong các ứng dụng ví danh tính giống như bằng lái xe hay chứng nhận tiêm chủng — chứ không chỉ hiển thị trên trang web.

Tóm lại: v2.0 trả lời câu hỏi “con người hoặc một đoạn script đơn giản có thể xác minh chứng chỉ này không,” còn v3.0 trả lời câu hỏi “chứng chỉ này có thể tương tác với hệ sinh thái verifiable-credentials rộng lớn hơn không — ví, DID, bảng điểm học tập chính thức.”

So sánh song song

Vì sao nền tảng đang được dùng rộng rãi vẫn chạy trên v2.0

Đây chính là phần quyết định đối với hầu hết các chương trình: những nơi mà người nhận chứng chỉ của bạn thực sự muốn hiển thị chứng chỉ vẫn đang mong đợi v2.0. Luồng Add to Profile của LinkedIn, Credly, Badgr, và phần lớn các tích hợp hệ thống theo dõi ứng viên (ATS) đều phân tích cấu trúc Assertion/BadgeClass của v2.0. Nếu mục tiêu của bạn là “người nhận có thể đăng chứng chỉ này lên LinkedIn và nhà tuyển dụng có thể bấm vào để xác minh,” thì v2.0 không phải là một định dạng lỗi thời mà bạn bị mắc kẹt — đó chính là định dạng mà hệ sinh thái đang sử dụng.

Chúng tôi đã đề cập chính xác sự căng thẳng này từ góc độ người nhận trong bài LinkedIn Skill Assessments vs Open Badges — giá trị của một huy hiệu phần lớn phụ thuộc vào việc nó dễ dàng kết nối với những nơi mà nhà tuyển dụng và đồng nghiệp đã sẵn tìm đến ra sao, và ngày nay đó vẫn chủ yếu là hạ tầng theo cấu trúc v2.0.

Khi nào v3.0 thực sự quan trọng

v3.0 không phải là trào lưu nhất thời — nó giải quyết những vấn đề thực sự cho các chương trình cụ thể:

• Các trường đại học và tổ chức cấp chịu ràng buộc bởi CLR. Nếu bạn cấp chứng chỉ song song với một hệ thống bảng điểm chính thức, hoặc một cơ quan giáo dục cấp bang/khu vực yêu cầu đầu ra tương thích CLR 2.0, thì tính đồng bộ tích hợp sẵn của v3.0 giúp bạn khỏi phải gắn thêm các trường CLR vào một Assertion v2.0.
• Các chương trình hướng tới lưu trữ trong ví số. Nếu người nhận của bạn cần giữ chứng chỉ trong một ứng dụng ví thay vì chỉ hiển thị trên trang web, thì chỉ có VC chuẩn W3C (tức v3.0) mới hoạt động được theo cách bản địa ở đó.
• Trao đổi chứng chỉ liên tổ chức dựa trên niềm tin theo DID. Nếu bạn đang xây dựng hoặc tham gia một mạng lưới nơi danh tính tổ chức cấp cần có thể mang theo và xác minh bằng mã hóa thay vì “tin tưởng URL này,” thì DID chính là nền tảng phù hợp.

Không trường hợp nào trong số này phổ biến đối với một chương trình đào tạo, bootcamp, hay tổ chức cấp chứng chỉ phát triển nghề nghiệp vào năm 2026. Chúng phổ biến đối với các tổ chức có yêu cầu tuân thủ hoặc tương tác cụ thể nêu đích danh CLR hoặc W3C VC.

Một chứng chỉ v3.0 rút gọn cho thấy rõ vỏ bọc khác biệt đến mức nào, ngay cả khi dữ liệu thành tích bên dưới về mặt khái niệm vẫn là cùng một huy hiệu:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://purl.imsglobal.org/spec/ob/v3p0/context.json"
  ],
  "type": ["VerifiableCredential", "OpenBadgeCredential"],
  "issuer": { "id": "did:web:issuer.example.edu" },
  "credentialSubject": {
    "type": "AchievementSubject",
    "achievement": { "type": "Achievement", "name": "Developer Associate" }
  },
  "proof": { "type": "DataIntegrityProof", "cryptosuite": "eddsa-2022" }
}

Hãy để ý trường issuer là một DID, không phải URL, và toàn bộ tài liệu mang theo một khối proof thay vì một con trỏ verification. Đó chính là công cụ giải quyết DID và ký VC đã nhắc ở trên — công việc kỹ thuật thực sự, và là công sức bị lãng phí nếu chưa có gì phía sau thực sự tiêu thụ nó.

Những hiểu lầm phổ biến cần làm rõ

• “v3.0 an toàn hơn.” Không hẳn — cả signed v2.0 lẫn v3.0 đều dựa vào xác minh mã hóa. Lợi thế của v3.0 nằm ở danh tính được chuẩn hóa (DID) và khả năng tương tác với ví, chứ không phải là một nâng cấp về bảo mật so với signed v2.0.
• “v2.0 đã lỗi thời.” Không phải vậy. 1EdTech duy trì song song cả hai chuẩn, và v2.0 vẫn là phiên bản được các nền tảng và tích hợp mà tổ chức cấp thực sự sử dụng hằng ngày tham chiếu tới.
• “Bạn phải chọn một chuẩn cho toàn bộ chương trình.” Không hề. Không có gì ngăn cản một tổ chức cấp phát hành v2.0 cho mục đích chung và bổ sung đầu ra v3.0 cho một tích hợp đối tác cụ thể yêu cầu điều đó — dữ liệu huy hiệu bên dưới không thay đổi, chỉ có cách biểu diễn thay đổi.

Lộ trình chuyển đổi (và vì sao bạn không cần chọn mãi mãi)

Bước đi thực tế cho hầu hết mọi tổ chức cấp: phát hành v2.0 ngay bây giờ, và xem v3.0 như một bổ sung, không phải một sự thay thế, khi có một bên tiêu thụ cụ thể ở phía sau yêu cầu. Có vài lý do khiến cách này hoạt động trơn tru:

1. ID của BadgeClass và Assertion của bạn không cần thay đổi khi bạn bổ sung hỗ trợ v3.0 sau này — bạn đang thêm một cách biểu diễn thứ hai, khác về cấu trúc, cho cùng một huy hiệu bên dưới, chứ không phải di chuyển chứng chỉ của những người nhận hiện có.
2. Các bên xác minh chỉ hiểu v2.0 vẫn tiếp tục hoạt động y như trước.
3. Bạn tránh được việc phải xây dựng hạ tầng DID và pipeline ký VC trước khi có một yêu cầu cụ thể thực sự cần đến chúng.

Đây cũng chính là logic mà chúng tôi áp dụng nội bộ tại badges.ninja: mọi huy hiệu đều được phát hành dưới dạng Open Badge v2.0 — JSON-LD, xác minh hosted tại một URL cố định /certify-badge/award/{guid}, sẵn sàng cho LinkedIn Add to Profile ngay từ đầu — vì đó là những gì đáp ứng phần lớn tuyệt đối những gì các tổ chức cấp thực sự được yêu cầu tạo ra. Nếu chương trình của bạn sau này cần đầu ra v3.0/CLR cho một đối tác thể chế cụ thể, đó là một bổ sung có phạm vi rõ ràng trên nền một pipeline v2.0 đang hoạt động, chứ không phải một cuộc viết lại.

Trình tự đó cũng bảo vệ bạn khỏi một rủi ro tinh vi hơn: cam kết với hạ tầng DID trước khi bạn biết đối tác của mình thực sự mong đợi phương thức DID nào. Hệ sinh thái VC vẫn chưa hội tụ về một phương thức DID duy nhất — did:web, did:key, và các phương thức neo trên sổ cái đều xuất hiện trong thực tế, và chọn sai phương thức cho một đối tác thí điểm nghĩa là bạn phải làm lại công việc danh tính tổ chức cấp sau này. Chờ đợi một yêu cầu cụ thể được nêu tên nghĩa là bạn biết chính xác mình cần phương thức nào trước khi bắt tay xây dựng bất cứ thứ gì.

Kiểm tra nhanh cho chương trình của chính bạn

Hãy tự hỏi ba câu này trước khi bỏ thời gian kỹ thuật vào v3.0:

• Có bên tiêu thụ nào của chứng chỉ tôi — một ATS của nhà tuyển dụng, một hội đồng cấp phép, một tổ chức đối tác — yêu cầu rõ ràng đầu ra CLR 2.0 hoặc W3C VC không? Nếu không, v2.0 đã đủ đáp ứng.
• Người nhận của tôi có cần giữ chứng chỉ này trong một ứng dụng ví số, chứ không chỉ trên hồ sơ web hoặc LinkedIn không? Nếu không, v2.0 đã đủ đáp ứng.
• Tôi có đang xây dựng hạ tầng niềm tin liên tổ chức cấp mà việc xác minh hosted dựa trên URL thực sự không đủ đáp ứng không? Nếu không, v2.0 đã đủ đáp ứng.

Nếu bạn trả lời “không” cả ba lần, bạn không hề tụt hậu khi phát hành v2.0 vào năm 2026 — bạn đang khớp đúng chuẩn với hệ sinh thái thực sự đang tiêu thụ nó. Hãy xem xét lại câu hỏi này khi có một đối tác cụ thể hoặc yêu cầu tuân thủ nêu đích danh v3.0, chứ không phải dựa trên cảm giác chung chung rằng “v3 mới hơn.”

Để biết thêm về cách dữ liệu xác minh huy hiệu so sánh với các định dạng chứng chỉ cũ, không chuẩn hóa, hãy xem Blockchain Certificates vs Open Badges, bài viết đào sâu vào sự đánh đổi giữa khả năng xác minh và tính di động từ một góc nhìn khác.

---

Sẵn sàng phát hành chứng chỉ có thể xác minh đầu tiên của bạn? Bắt đầu miễn phí tại badges.ninja — trình thiết kế trực quan, trang xác minh công khai, chứng chỉ PDF, đầu ra Open Badge v2.0. Không cần thẻ tín dụng.