Open Badges: doğrulanabilir belgelerin ardındaki açık standart

Standart bir belgeyi üç parçaya ayırır ve bu ayrım ilk bakışta göründüğünden daha akıllıcadır. Issuer, kimin verdiğini anlatır: ad, web sitesi, iletişim. BadgeClass, neyin verildiğini anlatır: belgenin başlığı, açıklaması, ölçütleri, görseli. Assertion ise tekil verme işlemidir: şu kişi, şu BadgeClass'ı, şu tarihte aldı.

Böylece bir sertifika türünün tanımı yalnızca bir kez var olmak zorundadır, ister 20 ister 2.000 kişiye verin. Sistemimizden gerçek bir Assertion işte böyle görünür, yalnızca token kısaltıldı:

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

İki ayrıntı ikinci bir bakışı hak ediyor. badge alanı yalnızca bir adrestir: BadgeClass orada durur, o da Issuer'a işaret eder; bir doğrulama aracı zincirin tamamını böyle takip eder. recipient olarak ise burada sertifika sayfasının adresi yer alır; bir e-posta adresi, karması alınmış olanı bile, hiçbir yerde görünmez. Böylece herkese açık belge, doğrudan iletişim bilgisi olmadan iş görür. Kişinin adı, bağlantılı sertifika sayfasında durur; onu belgeyi alırken kendisi oraya yazmıştır.

Spesifikasyon, bir Assertion'ı doğrulanabilir kılmanın iki yolunu tanır. İmzalı rozetlerde belge, verenin kriptografik imzasını taşır, yani kendini kendisi kanıtlar; ama bunun için veren tarafında anahtar yönetimi gerekir. Barındırılan rozetlerde ise daha basit bir kural geçerlidir: Assertion, kendi id adresi altında verenin sunucusundan çağrılabildiği sürece gerçektir. Doğrulamak o zaman şu kadardır: URL'yi çağır ve karşılaştır.

Barındırılan yöntemin hafife alınan bir avantajı var: temiz iptal. Veren bir belgeyi geri çektiğinde, aynı adres o andan itibaren HTTP durum kodu 410 ve içinde „revoked: true“ satırı bulunan kısa bir belgeyle yanıt verir. Geri çekilmiş bir sertifika öylece sessizleşmez; artık geçerli olmadığını etkin biçimde bildirir. OneClickBadge'de biz de bunu böyle yaparız, örneğin bir sertifika yanlışlıkla iki kez verildiğinde.

Standardın bir ayrıntısı neredeyse şiirsel: „baking“. Rozet görseli, çoğunlukla bir PNG, kendi Assertion'ını ve doğrulama adresini doğrudan görsel dosyasının içine gömülü alır, teknik olarak openbadges anahtar sözcüğüne sahip bir iTXt metin bloğu biçiminde. Görsel sonrasında tıpatıp aynı görünür, ama doğrulama yolunu içinde taşır: dosyayı bir doğrulama aracına sürükleyen kişi, görsel kaç indirmeden ve sohbetten geçmiş olursa olsun Assertion'a ulaşır.

Sıralama önemini korur: kanıtlayabilen tek şey barındırılan Assertion'dır. Bir görsel istendiği gibi kopyalanıp değiştirilebilir; belge adresi altındaki yanıtı ise yalnızca veren denetler.

Burada, pek çok yazıda dolaşan en yaygın yanlış anlaşılmayı düzeltelim: LinkedIn, Open Badge meta verilerini okumaz. Orada bir rozet içe aktarımı, otomatik bir doğrulama, doğrulanmış rozetler için özel bir simge yoktur. LinkedIn'de olan şey, ad, veren kuruluş ve bir URL için alanları bulunan „Lisanslar ve Sertifikalar“ profil bölümüdür. Bununla LinkedIn tarafından onaylanmış ya da tanınmış olan hiçbir şey yoktur.

Yine de standart LinkedIn için işe yaramaz değildir, tam tersine: URL alanına belge adresi girer. Profilde „Belgeyi göster“e tıklayan kişi, arkasında doğrulanabilir Assertion'ın durduğu sertifika sayfasına ulaşır. Girişin kendisi, alıcılar için tek tıkla, form alanları önceden doldurulmuş olarak hazırlanabilir. Bunun katılımcıların gözünden nasıl göründüğünü profile ekleme rehberi gösteriyor.

Standardı kendiniz uygulamak çok az organizatör için değer taşır: Issuer, BadgeClass ve her bir Assertion için kalıcı olarak erişilebilir uç noktalara, üstüne iptal mantığına ve „baked“ bir görsele ihtiyacınız olurdu. Etkinlikler, webinarlar ve eğitimler için hazır bir yol var: OneClickBadge'de bir katılım sertifikası tasarlarsınız, verilen her nüsha kendiliğinden barındırılan Assertion'ını, iptal mekanizmasını ve görselle birlikte PDF'ini alır.

Çok sayıda katılımcıya dağıtım, liste yüklemeden, etkinlikten sonra paylaştığınız bir kendin-al bağlantısı üzerinden işler. Bunun neden özellikle belge konusunda aynı zamanda bir veri koruma kararı olduğunu çok sayıda katılımcı için sertifikalar sayfası anlatıyor.

3.0 sürümü standardı W3C Verifiable Credentials'a taşır; bu, kriptografik imzalar ve alıcı tarafında daha fazla denetim içeren bir modeldir. Üniversite ekosistemleri ve uzun ömürlü eğitim belgeleri için doğru yön budur. Etkinlik katılımı senaryosu içinse bugün pratik durum, barındırılan biçimiyle 2.0'dır: yaygın her doğrulama aracı onu anlar, iptal çalışır ve kimsenin cüzdan ya da anahtar yönetmesi gerekmez. Bu yüzden biz 2.0 barındırılan üzerine kuruyoruz ve 3.0'ı sakince izlemeye devam ediyoruz.