Open Badge v2 बनाम v3 समझाया गया: आज आपको कौन सा स्पेक इस्तेमाल करना चाहिए?

अगर आप 2026 में एक credentialing प्रोग्राम सेट कर रहे हैं, तो रिसर्च के पहले घंटे में ही आपको यह सवाल मिल जाएगा: Open Badge v2.0 जारी करें या नया v3.0? ईमानदार जवाब है “यह इस पर निर्भर करता है कि आपके credentials को कौन पढ़ने वाला है” — लेकिन अगर आपको शुक्रवार तक फैसला लेना है तो यह जवाब संतोषजनक नहीं है। तो चलिए देखते हैं कि दोनों स्पेक्स के बीच असल में क्या बदला है, आज कौन क्या सपोर्ट करता है, और ज़्यादातर जारीकर्ताओं को अभी क्या शिप करना चाहिए।

Open Badge v2.0 असल में क्या है

Open Badge v2.0 वह 1EdTech (पहले IMS Global) स्पेसिफिकेशन है जो 2017 से डिजिटल credentialing की रीढ़ रहा है। यह JSON-LD पर बना है और तीन लिंक्ड ऑब्जेक्ट्स के इर्द-गिर्द structured है:

• IssuerOrg — credential किसने जारी किया (नाम, URL, ईमेल, लोगो)
• BadgeClass — credential का प्रकार खुद (नाम, विवरण, criteria, image)
• Assertion — किसी खास प्राप्तकर्ता को दिया गया विशिष्ट अवार्ड (recipient की पहचान, issuedOn date, evidence, सत्यापन का तरीका)

किसी प्राप्तकर्ता का Assertion एक BadgeClass की ओर इशारा करता है, जो वापस एक IssuerOrg की ओर इशारा करता है। सत्यापन दो तरीकों में से किसी एक से होता है: hosted (verifier एक स्थिर URL से live Assertion JSON फ़ेच करता है और डोमेन पर भरोसा करता है) या signed (Assertion में एक JWS सिग्नेचर होता है जिसे verifier issuer की पब्लिश की गई पब्लिक key के खिलाफ चेक करता है)। badges.ninja सहित ज़्यादातर प्लेटफ़ॉर्म डिफ़ॉल्ट रूप से hosted वेरिफिकेशन इस्तेमाल करते हैं और साथ में signed को एक विकल्प के तौर पर रखते हैं, क्योंकि hosted implement करना आसान है और इंसान के लिए मैन्युअली जांचना भी आसान है।

यहाँ एक trimmed v2.0 Assertion है, जैसा कुछ आपको 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" }
}

यही structure है जिसकी वजह से v2.0 de facto standard बन गया है: इसे एक दोपहर में implement किया जा सकता है, और यही वह फॉर्मेट है जिसे badge data का लगभग हर consumer देखने की उम्मीद करता है।

v2.0 में hosted बनाम signed सत्यापन

v2.0 के अंदर के दोनों वेरिफिकेशन मोड्स को समझना ज़रूरी है, क्योंकि लोग अक्सर “v2.0, v3.0 से कम सुरक्षित है” को “hosted वेरिफिकेशन, signed वेरिफिकेशन से कम सुरक्षित है” के साथ गड्डमड्ड कर देते हैं। ये दोनों एक ही मापदंड नहीं हैं।

• Hosted — verification.type, "hosted" होता है, और Assertion की id एक live URL होती है। एक verifier उस URL को फ़ेच करता है और चेक करता है कि रिस्पॉन्स मेल खाता है; भरोसा डोमेन को कंट्रोल करने से आता है (जैसे, सिर्फ badges.ninja ही badges.ninja/certify-badge/award/... पर पब्लिश कर सकता है)। ज़्यादातर consumer-facing वेरिफिकेशन पेज इसी का इस्तेमाल करते हैं क्योंकि एक इंसान बस लिंक पर क्लिक कर सकता है।
• Signed — verification.type, "signed" होता है, और Assertion में payload पर एक JWS सिग्नेचर होता है (या उसका रेफरेंस होता है)। एक verifier issuer की पब्लिक key resolve करता है और किसी भी URL के पहुंच में होने से अलग, स्वतंत्र रूप से सिग्नेचर चेक करता है। यह भावना में v3.0 के मॉडल के करीब है, बस DID लेयर के बिना।

Node में एक न्यूनतम signed-verification चेक कुछ ऐसा दिखता है:

import { jwtVerify, importJWK } from 'jose';

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

अगर आपका प्रोग्राम इस बात की परवाह करता है कि आपकी API मेंटेनेंस के लिए ऑफ़लाइन होने के बाद भी credentials सत्यापन-योग्य बने रहें, तो signed v2.0 आपको DIDs अपनाए बिना ही v3.0 का ज़्यादातर durability फ़ायदा दे देता है।

Open Badge v3.0 क्या बदलता है

Open Badge v3.0 W3C Verifiable Credentials (VC) Data Model के ऊपर एक rewrite है, v2.0 के JSON-LD shape का incremental अपडेट नहीं। जो अंतर व्यवहार में मायने रखते हैं:

• डिफ़ॉल्ट रूप से क्रिप्टोग्राफ़िक साइनिंग। हर v3.0 credential एक signed VC है — कोई “hosted, URL पर भरोसा करो” फॉलबैक नहीं है। सत्यापन हमेशा गणितीय होता है, डोमेन-आधारित नहीं।
• DID-आधारित जारीकर्ता पहचान। URL और ईमेल वाले IssuerOrg ऑब्जेक्ट की बजाय, जारीकर्ता की पहचान एक Decentralized Identifier (DID) से होती है, जो एक पब्लिक key document में resolve होता है।
• Comprehensive Learner Record (CLR) 2.0 के साथ alignment। v3.0 को CLR के साथ interoperate करने के लिए डिज़ाइन किया गया था, इसलिए एक ही credential achievement data के साथ-साथ वह structured transcript detail भी ले जा सकता है जिसकी CLR consumers को उम्मीद होती है (competencies, assessment results, term/course context)।
• डिजिटल वॉलेट कम्पैटिबिलिटी। क्योंकि v3.0 credentials स्टैंडर्ड W3C VCs हैं, उन्हें identity wallets में उसी तरह रखा जा सकता है जैसे driving license या vaccine credential — सिर्फ एक वेब पेज पर दिखाने भर तक सीमित नहीं।

संक्षेप में: v2.0 इस सवाल का जवाब देता है “क्या कोई इंसान या साधारण स्क्रिप्ट इस credential को सत्यापित कर सकती है,” और v3.0 इस सवाल का जवाब देता है “क्या यह credential बड़े verifiable-credentials इकोसिस्टम — wallets, DIDs, formal learner records — के साथ interoperate कर सकता है।“

साथ-साथ तुलना

इंस्टॉल्ड बेस अभी भी v2.0 पर क्यों चलता है

यही वह हिस्सा है जो ज़्यादातर प्रोग्राम्स के लिए फैसले को तय करता है: जहां आपके प्राप्तकर्ता असल में अपने credentials दिखाना चाहते हैं, वहां आज भी v2.0 की ही उम्मीद की जाती है। LinkedIn का Add to Profile फ़्लो, Credly, Badgr, और ज़्यादातर applicant-tracking-system इंटीग्रेशन v2.0 के Assertion/BadgeClass shape को पार्स करते हैं। अगर आपका लक्ष्य है “प्राप्तकर्ता इसे LinkedIn पर पोस्ट कर सकें और recruiters क्लिक करके सत्यापित कर सकें,” तो v2.0 कोई legacy फॉर्मेट नहीं है जिसमें आप फंसे हुए हैं — यह वह फॉर्मेट है जो इकोसिस्टम अभी बोलता है।

हमने इसी तनाव को प्राप्तकर्ता के नज़रिए से LinkedIn Skill Assessments बनाम Open Badges में कवर किया था — किसी badge की वैल्यू काफी हद तक इस बात का फंक्शन है कि यह उन जगहों में कितनी आसानी से फिट होता है जहां recruiters और साथी पहले से देखते हैं, और आज वह बहुतायत में v2.0-shaped इंफ्रास्ट्रक्चर है।

v3.0 असल में कब मायने रखता है

v3.0 सिर्फ़ हाइप नहीं है — यह खास प्रोग्रामों के लिए असली समस्याएं हल करता है:

• CLR mandates के तहत यूनिवर्सिटीज़ और जारीकर्ता। अगर आप एक formal transcript system के साथ जारी कर रहे हैं, या कोई state/regional education body CLR 2.0-compatible output की मांग करता है, तो v3.0 का बिल्ट-इन alignment आपको v2.0 Assertion पर CLR फ़ील्ड्स bolt-on करने से बचाता है।
• डिजिटल वॉलेट स्टोरेज को टारगेट करने वाले प्रोग्राम। अगर आपके प्राप्तकर्ताओं को credential को सिर्फ वेब पेज पर दिखाने की बजाय एक wallet ऐप में रखना है, तो वहां नेटिव रूप से सिर्फ एक W3C VC (यानी v3.0) ही काम करेगा।
• DID-आधारित trust के साथ क्रॉस-इश्यूअर credential exchange। अगर आप एक ऐसा नेटवर्क बना रहे हैं या उसमें शामिल हो रहे हैं जहां जारीकर्ता की पहचान “इस URL पर भरोसा करो” की बजाय क्रिप्टोग्राफ़िक रूप से portable होनी चाहिए, तो DIDs सही primitive हैं।

2026 में एक training प्रोग्राम, bootcamp, या professional-development जारीकर्ता के लिए इनमें से कोई भी आम मामला नहीं है। ये उन संस्थानों के लिए आम हैं जिनके पास compliance या interoperability आवश्यकताएं हैं जो खासतौर पर CLR या W3C VCs का नाम लेती हैं।

एक trimmed v3.0 credential दिखाता है कि envelope कितना अलग दिखता है, भले ही underlying achievement data conceptually वही अवार्ड हो:

{
  "@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 फ़ील्ड एक DID है, URL नहीं, और पूरा document एक verification pointer की बजाय एक proof ब्लॉक ले जाता है। यही ऊपर बताई गई DID resolution + VC signing टूलिंग है — असली इंजीनियरिंग काम, और अगर आगे कोई इसे consume ही नहीं कर रहा तो यह काम बेकार जाता है।

साफ़ करने लायक आम गलतफ़हमियां

• “v3.0 ज़्यादा सुरक्षित है।” ज़रूरी नहीं — signed v2.0 और v3.0 दोनों क्रिप्टोग्राफ़िक सत्यापन पर निर्भर करते हैं। v3.0 का फ़ायदा standardized पहचान (DIDs) और वॉलेट interoperability है, signed v2.0 पर कोई security अपग्रेड नहीं।
• “v2.0 deprecated हो चुका है।” ऐसा नहीं है। 1EdTech दोनों स्पेक्स को मेंटेन करता है, और v2.0 वही वर्ज़न बना हुआ है जिसे उन प्लेटफ़ॉर्म्स और इंटीग्रेशनों में रेफर किया जाता है जिन्हें जारीकर्ता रोज़मर्रा इस्तेमाल करते हैं।
• “पूरे प्रोग्राम के लिए एक ही चुनना पड़ता है।” ऐसा नहीं है। कुछ भी किसी जारीकर्ता को v2.0 को सामान्य इस्तेमाल के लिए पब्लिश करने और किसी खास partner integration के लिए, जो इसकी मांग करता है, v3.0 output जोड़ने से नहीं रोकता — underlying अवार्ड data नहीं बदलता, सिर्फ representation बदलता है।

माइग्रेशन पाथ (और हमेशा के लिए क्यों नहीं चुनना पड़ता)

लगभग हर जारीकर्ता के लिए practical कदम है: अभी v2.0 शिप करें, और v3.0 को replacement नहीं बल्कि addition की तरह ट्रीट करें, तब जब कोई खास downstream consumer इसकी मांग करे। यह साफ़ तरीके से क्यों काम करता है, इसकी कुछ वजहें:

1. जब आप बाद में v3.0 सपोर्ट जोड़ेंगे तो आपके BadgeClass और Assertion IDs बदलने की ज़रूरत नहीं है — आप उसी underlying अवार्ड का एक दूसरा, अलग-shape वाला representation जोड़ रहे हैं, मौजूदा प्राप्तकर्ताओं के credentials माइग्रेट नहीं कर रहे।
2. जो verifiers सिर्फ v2.0 समझते हैं, वे बिल्कुल पहले की तरह काम करते रहते हैं।
3. आप DID इंफ्रास्ट्रक्चर और VC signing pipelines बनाने से बचते हैं, इससे पहले कि आपके पास कोई concrete requirement हो जिसे उनकी ज़रूरत हो।

यह वही तर्क है जो हम badges.ninja में internally इस्तेमाल करते हैं: हर अवार्ड v2.0 Open Badge के तौर पर बाहर जाता है — JSON-LD, एक स्थिर /certify-badge/award/{guid} URL पर hosted सत्यापन, LinkedIn Add to Profile के लिए out of the box तैयार — क्योंकि यही उस भारी बहुमत को कवर करता है जो जारीकर्ताओं से असल में मांगा जाता है। अगर आपके प्रोग्राम को बाद में किसी खास institutional partner के लिए v3.0/CLR output चाहिए, तो वह एक काम कर रहे v2.0 पाइपलाइन के ऊपर एक scoped addition है, कोई rewrite नहीं।

यह सीक्वेंसिंग आपको एक और सूक्ष्म जोखिम से भी बचाती है: यह जाने बिना कि आपके partners असल में किस DID method की उम्मीद करते हैं, DID इंफ्रास्ट्रक्चर के लिए committed हो जाना। VC इकोसिस्टम एक DID method पर converge नहीं हुआ है — did:web, did:key, और ledger-anchored methods सभी असल दुनिया में दिखते हैं, और किसी pilot partner के लिए गलत method चुनने का मतलब है बाद में जारीकर्ता-पहचान का काम फिर से करना। किसी named requirement का इंतज़ार करने का मतलब है यह पता लगाना कि आपको असल में किस method की ज़रूरत है, इससे पहले कि आप कुछ भी बनाएं।

अपने प्रोग्राम के लिए एक झटपट gut-check

v3.0 पर इंजीनियरिंग समय खर्च करने से पहले ये तीन सवाल पूछें:

• क्या मेरे credentials का कोई consumer — कोई employer ATS, कोई licensing board, कोई partner institution — साफ़ तौर पर CLR 2.0 या W3C VC output की मांग करता है? अगर नहीं, तो v2.0 आपको कवर करता है।
• क्या मेरे प्राप्तकर्ताओं को यह credential एक डिजिटल वॉलेट ऐप में रखना है, सिर्फ एक वेब प्रोफ़ाइल या LinkedIn पर नहीं? अगर नहीं, तो v2.0 आपको कवर करता है।
• क्या मैं cross-issuer trust इंफ्रास्ट्रक्चर बना रहा हूं जहां URL-आधारित hosted वेरिफिकेशन वाकई काफ़ी नहीं है? अगर नहीं, तो v2.0 आपको कवर करता है।

अगर आपने तीन बार “नहीं” जवाब दिया, तो आप 2026 में v2.0 शिप करके पीछे नहीं हैं — आप उस स्पेक को उस इकोसिस्टम से मैच कर रहे हैं जो इसे असल में consume करता है। जब कोई खास partner या compliance requirement नाम लेकर v3.0 मांगे, तब इस सवाल पर दोबारा विचार करें, सिर्फ इस सामान्य एहसास पर नहीं कि “v3 नया है।”

पुराने, non-standard credential फॉर्मेट्स के मुकाबले badge वेरिफिकेशन data कैसा टिकता है, इस बारे में ज़्यादा जानने के लिए देखें Blockchain Certificates बनाम Open Badges, जो एक अलग एंगल से वेरिफिकेशन और portability के trade-offs में गहराई से जाता है।

---

अपना पहला verifiable credential जारी करने के लिए तैयार हैं? badges.ninja पर मुफ़्त शुरू करें — विज़ुअल डिज़ाइनर, पब्लिक वेरिफिकेशन पेज, PDF सर्टिफ़िकेट, Open Badge v2.0 output। किसी क्रेडिट कार्ड की ज़रूरत नहीं।