Open Badge v2 vs v3 Dijelaskan: Spesifikasi Mana yang Harus Anda Gunakan Sekarang?

Jika Anda sedang menyiapkan program kredensial pada 2026, pertanyaan ini akan muncul dalam satu jam pertama riset Anda: sebaiknya menerbitkan Open Badge v2.0 atau v3.0 yang lebih baru? Jawaban jujurnya adalah “tergantung siapa yang harus membaca kredensial Anda” — tapi jawaban itu kurang memuaskan jika Anda harus mengambil keputusan sebelum hari Jumat. Jadi mari kita telusuri apa sebenarnya yang berubah di antara kedua spesifikasi ini, siapa yang mendukung apa saat ini, dan mana yang sebaiknya digunakan oleh sebagian besar penerbit sekarang juga.

Apa sebenarnya Open Badge v2.0 itu

Open Badge v2.0 adalah spesifikasi dari 1EdTech (dulunya IMS Global) yang telah menjadi tulang punggung kredensial digital sejak 2017. Spesifikasi ini dibangun di atas JSON-LD dan terstruktur dalam tiga objek yang saling terhubung:

• IssuerOrg — siapa yang menerbitkan kredensial (nama, URL, email, logo)
• BadgeClass — jenis kredensial itu sendiri (nama, deskripsi, kriteria, gambar)
• Assertion — penghargaan spesifik untuk penerima spesifik (identitas penerima, tanggal issuedOn, bukti, metode verifikasi)

Assertion milik penerima menunjuk ke sebuah BadgeClass, yang kemudian menunjuk kembali ke sebuah IssuerOrg. Verifikasi terjadi melalui salah satu dari dua cara: hosted (verifikator mengambil JSON Assertion langsung dari URL yang stabil dan mempercayai domain tersebut) atau signed (Assertion membawa tanda tangan JWS yang diperiksa verifikator terhadap kunci publik penerbit yang dipublikasikan). Sebagian besar platform, termasuk badges.ninja, menggunakan verifikasi hosted sebagai default dengan signed sebagai opsi, karena hosted lebih sederhana diimplementasikan dan lebih mudah diperiksa secara manual oleh manusia.

Berikut contoh Assertion v2.0 yang dipersingkat, seperti yang akan Anda terima dari 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 inilah yang membuat v2.0 menjadi standar de facto: cukup sederhana untuk diimplementasikan dalam waktu satu sore, dan inilah yang diharapkan hampir semua konsumen data lencana.

Verifikasi hosted vs signed dalam v2.0

Penting untuk memahami dua mode verifikasi di dalam v2.0 itu sendiri, karena orang sering mencampuradukkan “v2.0 kurang aman dibanding v3.0” dengan “verifikasi hosted kurang aman dibanding signed.” Keduanya bukan sumbu yang sama.

• Hosted — verification.type bernilai "hosted", dan id milik Assertion adalah URL yang aktif. Verifikator mengambil URL tersebut dan memeriksa apakah responsnya cocok; kepercayaan berasal dari kontrol atas domain (misalnya, hanya badges.ninja yang bisa mempublikasikan ke badges.ninja/certify-badge/award/...). Inilah yang digunakan sebagian besar halaman verifikasi yang menghadap konsumen karena manusia bisa langsung mengklik tautannya.
• Signed — verification.type bernilai "signed", dan Assertion membawa (atau mereferensikan) tanda tangan JWS atas payload-nya. Verifikator me-resolve kunci publik penerbit dan memeriksa tanda tangan tersebut secara independen dari apakah URL-nya bisa diakses atau tidak. Ini lebih dekat secara konsep dengan model v3.0, hanya saja tanpa lapisan DID.

Pemeriksaan verifikasi signed yang minimal di Node terlihat 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 peduli agar kredensial tetap dapat diverifikasi bahkan setelah API Anda offline untuk pemeliharaan, v2.0 dengan signed memberi Anda sebagian besar manfaat daya tahan dari v3.0 tanpa harus mengadopsi DID.

Apa yang diubah Open Badge v3.0

Open Badge v3.0 adalah penulisan ulang di atas W3C Verifiable Credentials (VC) Data Model, bukan pembaruan bertahap dari bentuk JSON-LD milik v2.0. Perbedaan yang benar-benar berdampak dalam praktik:

• Penandatanganan kriptografis secara default. Setiap kredensial v3.0 adalah VC yang ditandatangani — tidak ada opsi cadangan “hosted, percayai URL”-nya. Verifikasi selalu bersifat matematis, bukan berbasis domain.
• Identitas penerbit berbasis DID. Alih-alih objek IssuerOrg dengan URL dan email, penerbit diidentifikasi lewat Decentralized Identifier (DID), yang me-resolve ke dokumen kunci publik.
• Selaras dengan Comprehensive Learner Record (CLR) 2.0. v3.0 dirancang agar dapat beroperasi bersama CLR, sehingga satu kredensial bisa membawa data pencapaian sekaligus detail transkrip terstruktur yang diharapkan konsumen CLR (kompetensi, hasil penilaian, konteks term/mata kuliah).
• Kompatibilitas dengan dompet digital. Karena kredensial v3.0 adalah VC W3C standar, kredensial ini bisa disimpan di dompet identitas (identity wallet) dengan cara yang sama seperti SIM atau kredensial vaksin — tidak hanya ditampilkan di halaman web.

Singkatnya: v2.0 menjawab “bisakah manusia atau skrip sederhana memverifikasi kredensial ini,” sementara v3.0 menjawab “bisakah kredensial ini beroperasi bersama ekosistem verifiable-credentials yang lebih luas — dompet, DID, learner record formal.”

Perbandingan berdampingan

Mengapa basis instalasi saat ini masih berjalan di v2.0

Inilah bagian yang menentukan keputusan bagi sebagian besar program: tempat-tempat di mana penerima kredensial Anda benar-benar ingin menampilkannya masih mengharapkan v2.0. Alur Add to Profile milik LinkedIn, Credly, Badgr, dan sebagian besar integrasi applicant-tracking-system mem-parsing bentuk Assertion/BadgeClass milik v2.0. Jika tujuan Anda adalah “penerima bisa memposting ini ke LinkedIn dan perekrut bisa mengklik untuk memverifikasi,” v2.0 bukan format usang yang membuat Anda terjebak — ini adalah format yang saat ini digunakan ekosistem tersebut.

Kami membahas ketegangan yang sama persis ini dari sisi penerima di LinkedIn Skill Assessments vs Open Badges — nilai sebuah lencana sebagian besar merupakan fungsi dari seberapa mudah lencana itu terhubung ke tempat-tempat yang sudah dilihat perekrut dan rekan sejawat, dan saat ini itu sangat didominasi oleh infrastruktur berbentuk v2.0.

Kapan v3.0 benar-benar relevan

v3.0 bukan sekadar tren — spesifikasi ini menyelesaikan masalah nyata untuk program-program tertentu:

• Universitas dan penerbit yang terikat mandat CLR. Jika Anda menerbitkan kredensial bersamaan dengan sistem transkrip formal, atau badan pendidikan negara bagian/regional mewajibkan output yang kompatibel dengan CLR 2.0, keselarasan bawaan v3.0 menghindarkan Anda dari harus menambal field CLR ke Assertion v2.0.
• Program yang menyasar penyimpanan di dompet digital. Jika penerima Anda perlu menyimpan kredensial di aplikasi dompet, bukan sekadar menampilkannya di halaman web, hanya VC W3C (yaitu v3.0) yang bekerja secara native di sana.
• Pertukaran kredensial lintas-penerbit dengan kepercayaan berbasis DID. Jika Anda sedang membangun atau bergabung dengan jaringan di mana identitas penerbit perlu bisa dibawa secara kriptografis, bukan sekadar “percayai URL ini,” DID adalah primitif yang tepat.

Tak satu pun dari kasus-kasus ini umum bagi program pelatihan, bootcamp, atau penerbit pengembangan profesional pada 2026. Kasus-kasus ini umum bagi institusi dengan persyaratan kepatuhan atau interoperabilitas yang secara khusus menyebut CLR atau VC W3C.

Kredensial v3.0 yang dipersingkat menunjukkan betapa berbedanya amplop datanya, meskipun data pencapaian yang mendasarinya secara konsep 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 bahwa field issuer adalah DID, bukan URL, dan seluruh dokumen membawa blok proof, bukan penunjuk verification. Itulah resolusi DID + tooling penandatanganan VC yang disebutkan di atas — pekerjaan rekayasa yang sungguhan, dan pekerjaan yang sia-sia jika belum ada yang benar-benar mengonsumsinya.

Kesalahpahaman umum yang perlu diluruskan

• “v3.0 lebih aman.” Belum tentu — v2.0 dengan signed dan v3.0 sama-sama mengandalkan verifikasi kriptografis. Keunggulan v3.0 terletak pada standarisasi identitas (DID) dan interoperabilitas dompet, bukan peningkatan keamanan dibanding v2.0 yang signed.
• “v2.0 sudah usang.” Tidak. 1EdTech tetap merawat kedua spesifikasi, dan v2.0 tetap menjadi versi yang dirujuk oleh platform dan integrasi yang benar-benar digunakan penerbit sehari-hari.
• “Anda harus memilih satu untuk seluruh program.” Tidak harus. Tidak ada yang menghalangi penerbit untuk mempublikasikan v2.0 untuk penggunaan umum sekaligus menambahkan output v3.0 untuk integrasi mitra tertentu yang mewajibkannya — data penghargaan yang mendasarinya tidak berubah, hanya representasinya.

Jalur migrasi (dan mengapa Anda tak perlu memilih selamanya)

Langkah praktis bagi hampir semua penerbit: rilis v2.0 sekarang, dan perlakukan v3.0 sebagai tambahan, bukan pengganti, ketika ada konsumen hilir tertentu yang memintanya. Ada beberapa alasan mengapa pendekatan ini berjalan mulus:

1. ID BadgeClass dan Assertion Anda tidak perlu berubah saat Anda menambahkan dukungan v3.0 nanti — Anda menambahkan representasi kedua dengan bentuk berbeda dari penghargaan yang sama, bukan memigrasikan kredensial penerima yang sudah ada.
2. Verifikator yang hanya memahami v2.0 tetap bekerja persis seperti sebelumnya.
3. Anda terhindar dari membangun infrastruktur DID dan pipeline penandatanganan VC sebelum ada kebutuhan konkret yang memerlukannya.

Ini adalah logika yang sama yang kami gunakan secara internal di badges.ninja: setiap penghargaan diterbitkan sebagai Open Badge v2.0 — JSON-LD, verifikasi hosted di URL /certify-badge/award/{guid} yang stabil, siap untuk LinkedIn Add to Profile langsung dari awal — karena itulah yang mencakup sebagian besar dari apa yang benar-benar diminta dari penerbit. Jika program Anda nantinya membutuhkan output v3.0/CLR untuk mitra institusional tertentu, itu adalah tambahan bertarget di atas pipeline v2.0 yang sudah berjalan, bukan penulisan ulang total.

Urutan ini juga melindungi Anda dari risiko yang lebih halus: berkomitmen pada infrastruktur DID sebelum Anda tahu metode DID mana yang sebenarnya diharapkan mitra Anda. Ekosistem VC belum berkonvergensi pada satu metode DID — did:web, did:key, dan metode berbasis ledger semuanya muncul di lapangan, dan memilih metode yang salah untuk mitra uji coba berarti Anda harus mengulang pekerjaan identitas-penerbit nanti. Menunggu adanya kebutuhan yang jelas berarti Anda mengetahui metode mana yang sebenarnya Anda perlukan sebelum membangun apa pun.

Pemeriksaan cepat untuk program Anda sendiri

Ajukan tiga pertanyaan ini sebelum Anda menghabiskan waktu rekayasa untuk v3.0:

• Apakah ada konsumen kredensial saya — ATS pemberi kerja, badan lisensi, institusi mitra — yang secara eksplisit mewajibkan output CLR 2.0 atau VC W3C? Jika tidak, v2.0 sudah cukup untuk Anda.
• Apakah penerima saya perlu menyimpan kredensial ini di aplikasi dompet digital, bukan sekadar profil web atau LinkedIn? Jika tidak, v2.0 sudah cukup untuk Anda.
• Apakah saya sedang membangun infrastruktur kepercayaan lintas-penerbit di mana verifikasi hosted berbasis URL benar-benar tidak memadai? Jika tidak, v2.0 sudah cukup untuk Anda.

Jika Anda menjawab “tidak” tiga kali, Anda tidak tertinggal dengan merilis v2.0 pada 2026 — Anda sedang menyelaraskan spesifikasi dengan ekosistem yang benar-benar mengonsumsinya. Tinjau kembali pertanyaan ini ketika ada mitra atau persyaratan kepatuhan tertentu yang meminta v3.0 secara eksplisit, bukan hanya karena kesan umum bahwa “v3 lebih baru.”

Untuk lebih lanjut tentang bagaimana data verifikasi lencana dibandingkan dengan format kredensial non-standar yang lebih lama, lihat Blockchain Certificates vs Open Badges, yang membahas trade-off verifikasi dan portabilitas dari sudut pandang berbeda.

---

Siap menerbitkan kredensial terverifikasi pertama Anda? Mulai gratis di badges.ninja — desainer visual, halaman verifikasi publik, sertifikat PDF, output Open Badge v2.0. Tanpa kartu kredit.