Open Badge v2 vs v3 Dijelaskan: Spesifikasi Mana Perlu Anda Gunakan Hari Ini?

Jika anda sedang menyediakan program pensijilan pada 2026, anda akan terserempak dengan soalan ini dalam jam pertama kajian anda: patutkah anda mengeluarkan Open Badge v2.0 atau v3.0 yang lebih baharu? Jawapan jujurnya ialah “ia bergantung kepada siapa yang perlu membaca kelayakan anda” — tetapi itu tidak memuaskan jika andalah orang yang perlu membuat keputusan menjelang hari Jumaat. Jadi mari kita lihat apa yang sebenarnya berubah antara kedua-dua spesifikasi ini, siapa menyokong apa hari ini, dan yang mana patut digunakan oleh kebanyakan pengeluar sekarang.

Apakah Sebenarnya Open Badge v2.0

Open Badge v2.0 ialah spesifikasi 1EdTech (dahulunya IMS Global) yang menjadi tulang belakang pensijilan digital sejak 2017. Ia dibina di atas JSON-LD dan distruktur di sekeliling tiga objek yang saling berkaitan:

• IssuerOrg — siapa yang mengeluarkan lencana (nama, URL, e-mel, logo)
• BadgeClass — jenis lencana itu sendiri (nama, penerangan, kriteria, imej)
• Assertion — anugerah khusus kepada penerima tertentu (identiti penerima, tarikh issuedOn, bukti, kaedah pengesahan)

Assertion penerima menunjuk kepada BadgeClass, yang menunjuk semula kepada IssuerOrg. Pengesahan berlaku dengan salah satu daripada dua cara: hosted (pengesah mengambil JSON Assertion secara langsung daripada URL yang stabil dan mempercayai domain tersebut) atau signed (Assertion membawa tandatangan JWS yang disemak oleh pengesah terhadap kunci awam yang diterbitkan oleh pengeluar). Kebanyakan platform, termasuk badges.ninja, secara lalai menggunakan pengesahan hosted dengan signed sebagai pilihan, kerana hosted lebih mudah dilaksanakan dan lebih mudah untuk disemak secara manual oleh manusia.

Berikut ialah Assertion v2.0 yang dipendekkan, seperti yang akan anda terima daripada panggilan 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" }
}

Struktur ini adalah sebab v2.0 telah menjadi standard de facto: ia cukup mudah untuk dilaksanakan dalam satu petang, dan itulah yang hampir setiap pengguna data lencana harapkan untuk dilihat.

Pengesahan hosted vs signed dalam v2.0

Adalah penting untuk memahami dua mod pengesahan dalam v2.0 itu sendiri, kerana orang sering mengelirukan “v2.0 kurang selamat daripada v3.0” dengan “pengesahan hosted kurang selamat daripada signed.” Itu bukan paksi yang sama.

• Hosted — verification.type ialah "hosted", dan id Assertion ialah URL langsung. Pengesah mengambil URL tersebut dan menyemak sama ada respons sepadan; kepercayaan datang daripada mengawal domain (contohnya, hanya badges.ninja boleh menerbitkan ke badges.ninja/certify-badge/award/...). Ini digunakan oleh kebanyakan halaman pengesahan menghadap pengguna kerana manusia boleh terus klik pautan.
• Signed — verification.type ialah "signed", dan Assertion membawa (atau merujuk) tandatangan JWS ke atas muatan tersebut. Pengesah menyelesaikan kunci awam pengeluar dan menyemak tandatangan tanpa bergantung sama ada mana-mana URL boleh dicapai. Ini lebih hampir dari segi semangat dengan model v3.0, cuma tanpa lapisan DID.

Semakan pengesahan signed yang minimum dalam Node kelihatan seperti ini:

import { jwtVerify, importJWK } from 'jose';

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

Jika program anda mengambil berat tentang kelayakan yang kekal boleh disahkan walaupun selepas API anda luar talian untuk penyelenggaraan, signed v2.0 memberikan anda sebahagian besar manfaat ketahanan v3.0 tanpa perlu menggunakan DID.

Apa yang Diubah oleh Open Badge v3.0

Open Badge v3.0 ialah penulisan semula di atas W3C Verifiable Credentials (VC) Data Model, bukan kemas kini berperingkat kepada bentuk JSON-LD v2.0. Perbezaan yang penting dalam praktiknya:

• Tandatangan kriptografi secara lalai. Setiap kelayakan v3.0 ialah VC yang signed — tiada fallback “hosted, percayakan URL.” Pengesahan sentiasa matematik, bukan berasaskan domain.
• Identiti pengeluar berasaskan DID. Selain objek IssuerOrg dengan URL dan e-mel, pengeluar dikenal pasti melalui Pengenal Terdesentralisasi (DID), yang menyelesaikan kepada dokumen kunci awam.
• Penjajaran dengan Comprehensive Learner Record (CLR) 2.0. v3.0 direka untuk berinteroperasi dengan CLR, jadi satu kelayakan boleh membawa data pencapaian ditambah jenis butiran transkrip berstruktur yang diharapkan oleh pengguna CLR (kompetensi, keputusan penilaian, konteks semester/kursus).
• Keserasian dompet digital. Kerana kelayakan v3.0 adalah VC W3C standard, ia boleh disimpan dalam dompet identiti sama seperti lesen memandu atau sijil vaksin — bukan sekadar dipaparkan pada laman web.

Ringkasnya: v2.0 menjawab “bolehkah manusia atau skrip mudah mengesahkan kelayakan ini,” dan v3.0 menjawab “bolehkah kelayakan ini berinteroperasi dengan ekosistem verifiable credentials yang lebih luas — dompet, DID, rekod pelajar formal.”

Perbandingan Bersebelahan

Mengapa Asas Sedia Ada Masih Berjalan pada v2.0

Inilah bahagian yang menentukan keputusan bagi kebanyakan program: tempat di mana penerima anda benar-benar mahu kelayakan mereka dipaparkan masih mengharapkan v2.0. Aliran Add to Profile LinkedIn, Credly, Badgr, dan majoriti besar integrasi sistem penjejakan pemohon menghurai bentuk Assertion/BadgeClass v2.0. Jika matlamat anda ialah “penerima boleh menyiarkan ini di LinkedIn dan perekrut boleh klik untuk mengesahkannya,” v2.0 bukanlah format lapuk yang anda terperangkap dengannya — ia format yang sedang digunakan oleh ekosistem sekarang.

Kami membincangkan ketegangan yang sama ini dari sudut penerima dalam LinkedIn Skill Assessments vs Open Badges — nilai sesuatu lencana sebahagian besarnya bergantung kepada betapa mudah ia menyesuaikan diri dengan tempat yang sudah dilihat oleh perekrut dan rakan sekerja, dan hari ini itu kebanyakannya infrastruktur berbentuk v2.0.

Bila v3.0 Benar-Benar Penting

v3.0 bukan hype — ia menyelesaikan masalah sebenar bagi program tertentu:

• Universiti dan pengeluar di bawah mandat CLR. Jika anda mengeluarkan bersama sistem transkrip formal, atau badan pendidikan negeri/serantau memerlukan output serasi CLR 2.0, penjajaran terbina dalam v3.0 menjimatkan anda daripada perlu menambah medan CLR pada Assertion v2.0.
• Program yang menyasarkan penyimpanan dompet digital. Jika penerima anda perlu menyimpan kelayakan dalam aplikasi dompet dan bukan sekadar memaparkannya pada laman web, hanya VC W3C (iaitu v3.0) akan berfungsi secara native di sana.
• Pertukaran kelayakan merentas pengeluar dengan kepercayaan berasaskan DID. Jika anda membina atau menyertai rangkaian di mana identiti pengeluar perlu boleh dipindah secara kriptografi berbanding “percayakan URL ini,” DID adalah primitif yang betul.

Tiada satu pun daripada ini biasa bagi program latihan, bootcamp, atau pengeluar pembangunan profesional pada 2026. Ia biasa bagi institusi dengan keperluan pematuhan atau interoperabiliti yang secara khusus menamakan CLR atau VC W3C.

Kelayakan v3.0 yang dipendekkan menunjukkan betapa berbezanya bentuk sampul itu, walaupun data pencapaian yang mendasarinya secara konsepnya adalah anugerah yang sama:

{
  "@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" }
}

Perhatikan medan issuer ialah DID, bukan URL, dan keseluruhan dokumen membawa blok proof dan bukannya penunjuk verification. Itulah resolusi DID + alat tandatangan VC yang disebut di atas — kerja kejuruteraan sebenar, dan kerja yang membazir jika tiada apa-apa di hiliran benar-benar menggunakannya lagi.

Salah Faham Biasa yang Perlu Diperjelaskan

• “v3.0 lebih selamat.” Tidak semestinya — signed v2.0 dan v3.0 kedua-duanya bergantung pada pengesahan kriptografi. Kelebihan v3.0 ialah identiti piawai (DID) dan interoperabiliti dompet, bukan peningkatan keselamatan berbanding signed v2.0.
• “v2.0 sudah lapuk.” Tidak. 1EdTech mengekalkan kedua-dua spesifikasi, dan v2.0 kekal sebagai versi yang dirujuk oleh platform dan integrasi yang benar-benar digunakan oleh pengeluar setiap hari.
• “Anda perlu pilih satu untuk keseluruhan program.” Tidak perlu. Tiada apa yang menghalang pengeluar daripada menerbitkan v2.0 untuk kegunaan umum sambil menambah output v3.0 untuk integrasi rakan kongsi tertentu yang memerlukannya — data anugerah yang mendasarinya tidak berubah, hanya perwakilannya.

Laluan Migrasi (dan Mengapa Anda Tidak Perlu Memilih Selama-lamanya)

Langkah praktikal bagi hampir semua pengeluar: lancarkan v2.0 sekarang, dan anggap v3.0 sebagai tambahan, bukan penggantian, apabila pengguna hiliran tertentu memerlukannya. Beberapa sebab ini berfungsi dengan lancar:

1. ID BadgeClass dan Assertion anda tidak perlu berubah apabila anda menambah sokongan v3.0 kemudian — anda menambah perwakilan kedua yang berbeza bentuk bagi anugerah asas yang sama, bukan memindahkan kelayakan penerima sedia ada.
2. Pengesah yang hanya memahami v2.0 terus berfungsi seperti biasa.
3. Anda mengelakkan pembinaan infrastruktur DID dan saluran tandatangan VC sebelum anda mempunyai keperluan konkrit yang memerlukannya.

Ini logik yang sama yang kami gunakan secara dalaman di badges.ninja: setiap anugerah dikeluarkan sebagai Open Badge v2.0 — JSON-LD, pengesahan hosted pada URL /certify-badge/award/{guid} yang stabil, sedia untuk LinkedIn Add to Profile terus dari awal — kerana itu meliputi majoriti besar apa yang sebenarnya diminta daripada pengeluar. Jika program anda kemudian memerlukan output v3.0/CLR untuk rakan kongsi institusi tertentu, itu adalah tambahan terhad di atas saluran v2.0 yang sudah berfungsi, bukan penulisan semula.

Penjujukan itu juga melindungi anda daripada risiko yang lebih halus: komited kepada infrastruktur DID sebelum anda tahu kaedah DID mana yang benar-benar diharapkan oleh rakan kongsi anda. Ekosistem VC belum menumpu kepada satu kaedah DID — did:web, did:key, dan kaedah berjangkar ledger semuanya muncul di dunia sebenar, dan memilih yang salah untuk rakan kongsi rintis bermakna anda perlu mengulang kerja identiti pengeluar kemudian. Menunggu keperluan yang dinamakan bermakna anda mengetahui kaedah mana yang sebenarnya anda perlukan sebelum anda membina apa-apa.

Semakan Pantas untuk Program Anda Sendiri

Tanya tiga soalan ini sebelum anda membelanjakan masa kejuruteraan untuk v3.0:

• Adakah mana-mana pengguna kelayakan saya — ATS majikan, badan pelesenan, institusi rakan kongsi — secara jelas memerlukan output CLR 2.0 atau VC W3C? Jika tidak, v2.0 sudah mencukupi.
• Adakah penerima saya perlu menyimpan kelayakan ini dalam aplikasi dompet digital, bukan sekadar profil web atau LinkedIn? Jika tidak, v2.0 sudah mencukupi.
• Adakah anda membina infrastruktur kepercayaan merentas pengeluar di mana pengesahan hosted berasaskan URL sememangnya tidak mencukupi? Jika tidak, v2.0 sudah mencukupi.

Jika anda menjawab “tidak” sebanyak tiga kali, anda tidak ketinggalan dengan melancarkan v2.0 pada 2026 — anda memadankan spesifikasi dengan ekosistem yang benar-benar menggunakannya. Semak semula soalan ini apabila rakan kongsi atau keperluan pematuhan tertentu meminta v3.0 secara khusus, bukan berdasarkan tanggapan umum bahawa “v3 lebih baharu.”

Untuk lebih lanjut tentang bagaimana data pengesahan lencana bertahan berbanding format kelayakan lama yang tidak piawai, lihat Blockchain Certificates vs Open Badges, yang mendalami pertukaran antara pengesahan dan mudah alih dari sudut yang berbeza.

---

Bersedia untuk mengeluarkan kelayakan boleh sah pertama anda? Mula percuma di badges.ninja — pereka visual, halaman pengesahan awam, sijil PDF, output Open Badge v2.0. Tiada kad kredit diperlukan.