Open Badges: standar terbuka di balik kredensial yang dapat diverifikasi

Standar ini memecah sebuah kredensial menjadi tiga bagian, dan pemisahan itu lebih cerdas daripada yang terlihat pada awalnya. Issuer menjelaskan siapa yang menerbitkan: nama, situs web, kontak. BadgeClass menjelaskan apa yang diberikan: judul kredensial, deskripsi, kriteria, gambar. Terakhir, Assertion adalah pemberian yang satu itu: orang inilah yang menerima BadgeClass ini pada tanggal ini.

Dengan begitu deskripsi sebuah jenis sertifikat cukup ada satu kali saja, entah kamu memberikannya kepada 20 atau 2.000 orang. Beginilah bentuk sebuah Assertion asli dari sistem kami, hanya tokennya yang dipendekkan:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

Ada dua detail yang layak dilihat sekali lagi. Kolom badge hanyalah sebuah alamat: di situlah BadgeClass berada, yang selanjutnya menunjuk ke Issuer, sehingga alat verifikasi menyusuri seluruh rantainya. Lalu sebagai recipient yang tertera di sini adalah alamat halaman sertifikat; alamat email, bahkan yang di-hash sekalipun, tidak muncul di mana pun. Dengan demikian dokumen publik ini tidak memerlukan data kontak langsung. Nama orangnya tertera di halaman sertifikat yang ditautkan, tempat ia mengisikannya sendiri saat mengambil sertifikat.

Spesifikasi ini mengenal dua cara membuat sebuah Assertion dapat diverifikasi. Pada badge bertanda tangan, dokumennya membawa tanda tangan kriptografis dari penerbit, jadi ia membuktikan dirinya sendiri, tetapi untuk itu dibutuhkan pengelolaan kunci di sisi penerbit. Pada badge yang dihosting berlaku aturan yang lebih sederhana: Assertion itu asli selama masih bisa diakses di alamat id miliknya sendiri di server penerbit. Memverifikasi berarti cukup memanggil URL lalu membandingkannya.

Metode yang dihosting punya satu kelebihan yang kerap diremehkan: pencabutan yang bersih. Kalau penerbit menarik sebuah kredensial, alamat yang sama akan langsung menjawab dengan status HTTP 410 dan sebuah dokumen ringkas berisi baris “revoked: true”. Jadi sertifikat yang ditarik tidak sekadar menghilang, ia secara aktif menyatakan dirinya tidak lagi berlaku. Begitu juga cara kami di OneClickBadge, misalnya ketika sebuah sertifikat tak sengaja diterbitkan dua kali.

Satu detail dari standar ini nyaris puitis: “baking”. Grafik badge, biasanya berupa PNG, mendapat Assertion-nya beserta alamat verifikasi yang ditanamkan langsung ke dalam berkas gambar, secara teknis sebagai blok teks iTXt dengan kata kunci openbadges. Setelah itu gambarnya tampak persis sama, tetapi membawa jalur verifikasinya di dalam dirinya: siapa yang menyeret berkas itu ke sebuah alat verifikasi akan tiba di Assertion, tak peduli sudah melewati berapa banyak unduhan dan obrolan.

Yang tetap penting adalah urutan bobotnya: hanya Assertion yang dihosting yang bisa membuktikan sesuatu. Sebuah gambar bisa disalin dan diubah sesuka hati, sedangkan jawaban di alamat kredensial hanya dikendalikan oleh penerbitnya.

Di sini kami meluruskan salah paham yang paling sering menghantui banyak artikel: LinkedIn tidak membaca metadata Open Badge. Di sana tidak ada impor badge, tidak ada pemeriksaan otomatis, tidak ada ikon khusus untuk badge yang terverifikasi. Yang dimiliki LinkedIn adalah bagian profil “Lisensi & Sertifikasi” dengan kolom untuk nama, organisasi penerbit, dan sebuah URL. Karena itu tidak ada yang tersertifikasi atau diakui oleh LinkedIn.

Meski begitu standar ini bukannya tak berguna bagi LinkedIn, malah sebaliknya: alamat kredensiallah yang mestinya masuk ke kolom URL. Siapa yang mengeklik “Tampilkan kredensial” di profil akan tiba di halaman sertifikat, tempat Assertion yang dapat diverifikasi berada di baliknya. Entri itu sendiri bisa disiapkan bagi penerima hanya dengan satu klik, lengkap dengan kolom formulir yang sudah terisi. Bagaimana tampilannya dari sudut pandang peserta ditunjukkan di panduan mencantumkannya ke profil.

Mengimplementasikan standar ini sendiri hanya sepadan bagi segelintir penyelenggara: kamu akan butuh endpoint yang selalu bisa dijangkau untuk Issuer, BadgeClass, dan setiap Assertion, ditambah logika pencabutan serta gambar hasil baking. Untuk acara, webinar, dan pelatihan, semuanya sudah tersedia jadi: di OneClickBadge kamu merancang sertifikat kehadiran, dan setiap salinan yang diterbitkan otomatis mendapat Assertion yang dihosting, mekanisme pencabutan, dan PDF beserta gambarnya.

Pembagiannya ke banyak peserta berlangsung tanpa unggah daftar, lewat tautan swalayan yang kamu bagikan setelah acara. Mengapa untuk urusan kredensial hal ini sekaligus menjadi keputusan soal privasi dibahas di halaman Sertifikat untuk banyak peserta.

Versi 3.0 memindahkan standar ini ke W3C Verifiable Credentials, sebuah model dengan tanda tangan kriptografis dan kendali yang lebih besar di sisi penerima. Untuk ekosistem perguruan tinggi dan bukti pendidikan yang berumur panjang, itulah arah yang tepat. Untuk kasus pemakaian kehadiran acara, versi 2.0 dalam bentuk yang dihosting adalah kondisi paling praktis saat ini: setiap alat verifikasi umum memahaminya, pencabutannya berfungsi, dan tak seorang pun perlu mengelola wallet atau kunci. Karena itu kami memakai 2.0 hosted dan terus mengamati 3.0 dengan tenang.