Open Badge v2 vs v3 Açıklaması: Bugün Hangi Spesifikasyonu Kullanmalısınız?

2026’da bir kimlik bilgisi (credentialing) programı kuruyorsanız, araştırmanızın ilk saatinde şu soruyla karşılaşırsınız: Open Badge v2.0 mı yoksa daha yeni v3.0 mı yayınlamalısınız? Dürüst cevap “bu, kimlik bilgilerinizi kimin okuyacağına bağlı” ama cuma gününe kadar karar vermeniz gerekiyorsa bu pek tatmin edici değil. O yüzden iki spesifikasyon arasında gerçekte neyin değiştiğine, bugün kimin neyi desteklediğine ve çoğu düzenleyicinin şu anda hangisini kullanması gerektiğine bakalım.

Open Badge v2.0 aslında nedir

Open Badge v2.0, 2017’den beri dijital kimlik belgelendirmenin (credentialing) omurgası olan 1EdTech (eski adıyla IMS Global) spesifikasyonudur. JSON-LD üzerine kuruludur ve birbirine bağlı üç nesne etrafında yapılandırılmıştır:

• IssuerOrg — kimlik bilgisini kimin verdiği (ad, URL, e-posta, logo)
• BadgeClass — kimlik bilgisinin türü (ad, açıklama, kriterler, görsel)
• Assertion — belirli bir alıcıya verilen belirli ödül (alıcı kimliği, issuedOn tarihi, kanıt, doğrulama yöntemi)

Bir alıcının Assertion’ı bir BadgeClass’a, o da geriye doğru bir IssuerOrg’a işaret eder. Doğrulama iki şekilden birinde gerçekleşir: hosted (doğrulayıcı, canlı Assertion JSON’unu sabit bir URL’den çeker ve alan adına güvenir) veya signed (Assertion, doğrulayıcının düzenleyicinin yayınladığı genel anahtara göre kontrol ettiği bir JWS imzası taşır). badges.ninja dahil çoğu platform, hosted doğrulamayı varsayılan olarak kullanır ve signed’ı bir seçenek olarak sunar; çünkü hosted uygulaması daha basittir ve bir insanın gözle kontrol etmesi daha kolaydır.

İşte kısaltılmış bir v2.0 Assertion — bir GET /awards/{id} çağrısından geri alacağınız türden bir şey:

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

Bu yapı, v2.0’ın fiilen standart haline gelmesinin nedenidir: bir öğleden sonrada uygulanacak kadar basittir ve rozet verisini tüketen hemen herkesin görmeyi beklediği şey budur.

v2.0’da hosted ve signed doğrulama

v2.0’ın kendi içindeki iki doğrulama modunu anlamakta fayda var; çünkü insanlar sık sık “v2.0, v3.0’dan daha az güvenli” ifadesiyle “hosted doğrulama, signed’dan daha az güvenli” ifadesini birbirine karıştırıyor. Bunlar aynı eksen değil.

• Hosted — verification.type değeri "hosted"dir ve Assertion’ın id’si canlı bir URL’dir. Doğrulayıcı bu URL’yi çeker ve yanıtın eşleştiğini kontrol eder; güven, alan adının kontrolünden gelir (ör. sadece badges.ninja, badges.ninja/certify-badge/award/... altına yayın yapabilir). Bir insan sadece bağlantıya tıklayabildiği için çoğu tüketiciye yönelik doğrulama sayfası bunu kullanır.
• Signed — verification.type değeri "signed"dir ve Assertion, yük (payload) üzerinde bir JWS imzası taşır (veya buna referans verir). Doğrulayıcı, düzenleyicinin genel anahtarını çözer ve herhangi bir URL’nin erişilebilir olmasından bağımsız olarak imzayı kontrol eder. Bu, ruh itibarıyla v3.0’ın modeline daha yakındır, sadece DID katmanı olmadan.

Node’da minimal bir signed doğrulama kontrolü şöyle görünür:

import { jwtVerify, importJWK } from 'jose';

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

Programınız, API’niz bakım için çevrimdışı olsa bile kimlik bilgilerinin doğrulanabilir kalmasını önemsiyorsa, signed v2.0 size DID’leri benimsemeden v3.0’ın dayanıklılık avantajının çoğunu sağlar.

Open Badge v3.0 neyi değiştiriyor

Open Badge v3.0, v2.0’ın JSON-LD şeklinin kademeli bir güncellemesi değil, W3C Doğrulanabilir Kimlik Bilgileri (VC) Veri Modeli üzerine yapılmış bir yeniden yazımdır. Pratikte önemli olan farklar:

• Varsayılan olarak kriptografik imzalama. Her v3.0 kimlik bilgisi imzalı bir VC’dir — “hosted, URL’ye güven” yedek seçeneği yoktur. Doğrulama her zaman alan adı tabanlı değil, matematikseldir.
• DID tabanlı düzenleyici kimliği. URL ve e-posta içeren bir IssuerOrg nesnesi yerine, düzenleyici bir genel anahtar belgesine çözümlenen bir Merkeziyetsiz Kimlik (DID) ile tanımlanır.
• Comprehensive Learner Record (CLR) 2.0 ile uyum. v3.0, CLR ile birlikte çalışacak şekilde tasarlandı; böylece tek bir kimlik bilgisi başarı verisiyle birlikte CLR tüketicilerinin beklediği türden yapılandırılmış transkript ayrıntılarını (yetkinlikler, değerlendirme sonuçları, dönem/ders bağlamı) taşıyabilir.
• Dijital cüzdan uyumluluğu. v3.0 kimlik bilgileri standart W3C VC’ler olduğu için, sadece bir web sayfasında gösterilmek yerine bir ehliyet veya aşı kimlik bilgisi gibi kimlik cüzdanlarında tutulabilir.

Kısacası: v2.0, “bir insan ya da basit bir betik bu kimlik bilgisini doğrulayabilir mi” sorusuna cevap verir; v3.0 ise “bu kimlik bilgisi daha geniş doğrulanabilir kimlik bilgileri ekosistemiyle — cüzdanlar, DID’ler, resmi öğrenci kayıtları — birlikte çalışabilir mi” sorusuna cevap verir.

Yan yana karşılaştırma

Mevcut altyapı neden hâlâ v2.0 üzerinde çalışıyor

Çoğu program için kararı belirleyen kısım burası: alıcılarınızın kimlik bilgilerinin gerçekten görünmesini istediği yerler hâlâ v2.0 bekliyor. LinkedIn’in Profile’a Ekle akışı, Credly, Badgr ve başvuru takip sistemi (ATS) entegrasyonlarının büyük çoğunluğu v2.0’ın Assertion/BadgeClass şeklini ayrıştırır. Amacınız “alıcılar bunu LinkedIn’de paylaşabilsin ve işe alım uzmanları tıklayıp doğrulayabilsin” ise, v2.0 takılıp kaldığınız eski bir format değil — ekosistemin şu anda konuştuğu formattır.

Bu tam gerilimi alıcı tarafından LinkedIn Skill Assessments’a Karşı Open Badges yazımızda ele almıştık — bir rozetin değeri büyük ölçüde, işe alım uzmanlarının ve meslektaşların zaten baktığı yerlere ne kadar kolay entegre olduğuna bağlıdır ve bugün bu, ezici biçimde v2.0 şeklindeki altyapıdır.

v3.0 gerçekten ne zaman önemli

v3.0 sadece hype değil — belirli programlar için gerçek sorunları çözüyor:

• CLR zorunluluğu olan üniversiteler ve düzenleyiciler. Resmi bir transkript sistemiyle birlikte belge düzenliyorsanız veya bir eyalet/bölgesel eğitim kurumu CLR 2.0 uyumlu çıktı gerektiriyorsa, v3.0’ın yerleşik uyumu, CLR alanlarını bir v2.0 Assertion’a sonradan eklemekten sizi kurtarır.
• Dijital cüzdan depolamayı hedefleyen programlar. Alıcılarınızın kimlik bilgisini sadece bir web sayfasında göstermek yerine bir cüzdan uygulamasında tutması gerekiyorsa, orada yerel olarak yalnızca bir W3C VC (yani v3.0) çalışır.
• DID tabanlı güvenle düzenleyicilerarası kimlik bilgisi alışverişi. Düzenleyici kimliğinin “bu URL’ye güven” yerine kriptografik olarak taşınabilir olması gereken bir ağ kuruyor veya buna katılıyorsanız, DID’ler doğru ilkel yapı taşıdır.

Bunların hiçbiri 2026’da bir eğitim programı, bootcamp veya mesleki gelişim düzenleyicisi için yaygın durumlar değil. Bunlar, özellikle CLR veya W3C VC’leri adlandıran uyumluluk veya birlikte çalışabilirlik gereksinimleri olan kurumlar için yaygın.

Kısaltılmış bir v3.0 kimlik bilgisi, altta yatan başarı verisi kavramsal olarak aynı ödül olsa bile zarfın ne kadar farklı göründüğünü gösterir:

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

issuer alanının bir URL değil bir DID olduğuna ve tüm belgenin bir verification işaretçisi yerine bir proof bloğu taşıdığına dikkat edin. Bu, yukarıda bahsedilen DID çözümleme + VC imzalama araçlarıdır — gerçek bir mühendislik işi ve henüz alt akışta hiçbir şey bunu tüketmiyorsa boşa giden bir iş.

Netleştirilmeye değer yaygın yanlış anlamalar

• “v3.0 daha güvenlidir.” Mutlaka değil — signed v2.0 ve v3.0’ın ikisi de kriptografik doğrulamaya dayanır. v3.0’ın avantajı standartlaştırılmış kimlik (DID’ler) ve cüzdan birlikte çalışabilirliğidir, signed v2.0’a göre bir güvenlik yükseltmesi değildir.
• “v2.0 kullanımdan kaldırıldı.” Hayır, kaldırılmadı. 1EdTech her iki spesifikasyonu da sürdürüyor ve v2.0, düzenleyicilerin günlük olarak gerçekten kullandığı platform ve entegrasyonların referans aldığı sürüm olmaya devam ediyor.
• “Tüm program için birini seçmeniz gerekir.” Gerekmez. Bir düzenleyicinin genel kullanım için v2.0 yayınlamasını ve bunu gerektiren belirli bir ortak entegrasyonu için v3.0 çıktısı eklemesini engelleyen hiçbir şey yok — altta yatan ödül verisi değişmez, yalnızca temsil şekli değişir.

Geçiş yolu (ve neden sonsuza kadar seçim yapmanız gerekmediği)

Neredeyse her düzenleyici için pratik hamle şudur: şimdi v2.0’ı yayınlayın ve belirli bir alt akış tüketicisi talep ettiğinde v3.0’ı bir değiştirme değil, bir ek olarak ele alın. Bunun sorunsuz çalışmasının birkaç nedeni var:

1. Daha sonra v3.0 desteği eklediğinizde BadgeClass ve Assertion ID’lerinizin değişmesi gerekmez — mevcut alıcıların kimlik bilgilerini taşımıyorsunuz, aynı altta yatan ödülün ikinci, farklı şekilli bir temsilini ekliyorsunuz.
2. Sadece v2.0’ı anlayan doğrulayıcılar tam olarak öncekiyle aynı şekilde çalışmaya devam eder.
3. Somut bir ihtiyaç ortaya çıkmadan önce DID altyapısı ve VC imzalama iş hatları kurmaktan kaçınırsınız.

Bu, badges.ninja’da dahili olarak kullandığımız aynı mantık: her ödül bir v2.0 Open Badge olarak çıkar — JSON-LD, sabit bir /certify-badge/award/{guid} URL’sinde hosted doğrulama, kutudan çıktığı gibi LinkedIn Profile’a Ekle’ye hazır — çünkü bu, düzenleyicilerden gerçekte istenen şeylerin ezici çoğunluğunu karşılıyor. Programınız daha sonra belirli bir kurumsal ortak için v3.0/CLR çıktısına ihtiyaç duyarsa, bu bir yeniden yazım değil, çalışan bir v2.0 hattının üzerine kapsamı belirlenmiş bir ek olur.

Bu sıralama sizi daha ince bir riskten de korur: ortaklarınızın gerçekte hangi DID yöntemini beklediğini bilmeden DID altyapısına bağlanmak. VC ekosistemi henüz tek bir DID yöntemi üzerinde birleşmedi — did:web, did:key ve deftere bağlı (ledger-anchored) yöntemlerin hepsi gerçek dünyada karşınıza çıkıyor ve bir pilot ortak için yanlışını seçmek, düzenleyici kimliği işini daha sonra baştan yapmak anlamına gelir. Adı konmuş bir gereksinimi beklemek, herhangi bir şey inşa etmeden önce gerçekte hangi yönteme ihtiyacınız olduğunu öğrenmeniz demektir.

Kendi programınız için hızlı bir öz-değerlendirme

v3.0’a mühendislik zamanı harcamadan önce şu üç soruyu sorun:

• Kimlik bilgilerimin herhangi bir tüketicisi — bir işveren ATS’i, bir lisans kurulu, bir ortak kurum — açıkça CLR 2.0 veya W3C VC çıktısı gerektiriyor mu? Cevap hayırsa, v2.0 sizi kapsar.
• Alıcılarımın bu kimlik bilgisini sadece bir web profilinde veya LinkedIn’de değil, bir dijital cüzdan uygulamasında tutması gerekiyor mu? Cevap hayırsa, v2.0 sizi kapsar.
• URL tabanlı hosted doğrulamanın gerçekten yeterli olmadığı düzenleyicilerarası bir güven altyapısı mı kuruyorum? Cevap hayırsa, v2.0 sizi kapsar.

Üç kez de “hayır” cevabı verdiyseniz, 2026’da v2.0 yayınlayarak geride kalmıyorsunuz — spesifikasyonu, onu gerçekten tüketen ekosistemle eşleştiriyorsunuz. Bu soruyu, genel bir “v3 daha yeni” hissiyle değil, belirli bir ortak veya uyumluluk gereksinimi v3.0’ı ismen istediğinde yeniden ele alın.

Rozet doğrulama verisinin daha eski, standart olmayan kimlik bilgisi formatlarına karşı nasıl bir performans gösterdiği hakkında daha fazlası için, doğrulama ve taşınabilirlik ödünleşimlerini farklı bir açıdan inceleyen Blockchain Certificates’a Karşı Open Badges yazımıza bakın.

---

İlk doğrulanabilir kimlik bilgisini düzenlemeye hazır mısınız? badges.ninja’da ücretsiz başlayın — görsel tasarımcı, herkese açık doğrulama sayfası, PDF sertifika, Open Badge v2.0 çıktısı. Kredi kartı gerekmez.