ওপেন ব্যাজ v2 বনাম v3 ব্যাখ্যা করা হলো: আজ আপনার কোন স্পেসিফিকেশন ব্যবহার করা উচিত?

আপনি যদি ২০২৬ সালে একটি ক্রেডেনশিয়ালিং প্রোগ্রাম সেট আপ করছেন, তাহলে আপনার রিসার্চের প্রথম ঘণ্টার মধ্যেই এই প্রশ্নে আপনি ধাক্কা খাবেন— আপনি কি Open Badge v2.0 নাকি নতুন v3.0 ইস্যু করবেন? সৎ উত্তর হলো, “এটা নির্ভর করে আপনার ক্রেডেনশিয়াল কাকে পড়তে হবে তার উপর” — কিন্তু আপনি যদি শুক্রবারের মধ্যে সিদ্ধান্ত নিতে বাধ্য হন, তাহলে এই উত্তর একদমই সন্তোষজনক নয়। তাই চলুন দেখি, দুটি স্পেসিফিকেশনের মধ্যে আসলে কী বদলেছে, আজ কে কী সাপোর্ট করে, এবং এখন বেশিরভাগ ইস্যুয়ারের কোনটা শিপ করা উচিত।

Open Badge v2.0 আসলে কী

Open Badge v2.0 হলো 1EdTech-এর (আগে IMS Global) স্পেসিফিকেশন, যা ২০১৭ সাল থেকে ডিজিটাল ব্যাজ ইকোসিস্টেমের মেরুদণ্ড হিসেবে কাজ করে আসছে। এটি JSON-LD-এর উপর তৈরি এবং তিনটি সংযুক্ত অবজেক্টের চারপাশে গঠিত—

• IssuerOrg — কে ব্যাজ ইস্যু করেছে (নাম, URL, ইমেইল, লোগো)
• BadgeClass — ক্রেডেনশিয়াল টাইপ নিজেই (নাম, বর্ণনা, মানদণ্ড, ছবি)
• Assertion — নির্দিষ্ট প্রাপকের জন্য নির্দিষ্ট অ্যাওয়ার্ড (প্রাপকের পরিচয়, issuedOn তারিখ, প্রমাণ, ভেরিফিকেশন পদ্ধতি)

একজন প্রাপকের Assertion একটি BadgeClass-কে নির্দেশ করে, যা আবার একটি IssuerOrg-কে নির্দেশ করে। যাচাই দুইভাবে হতে পারে— hosted (ভেরিফায়ার একটি স্থিতিশীল URL থেকে লাইভ Assertion JSON আনে এবং ডোমেইনকে বিশ্বাস করে) অথবা signed (Assertion-এ একটি JWS সিগনেচার থাকে, যা ভেরিফায়ার ইস্যুয়ারের প্রকাশিত পাবলিক কী দিয়ে যাচাই করে)। badges.ninja সহ বেশিরভাগ প্ল্যাটফর্ম ডিফল্ট হিসেবে hosted ভেরিফিকেশন ব্যবহার করে, signed অপশন হিসেবে রেখে, কারণ hosted ইমপ্লিমেন্ট করা সহজ এবং মানুষের পক্ষে স্পট-চেক করা সহজ।

এখানে একটি সংক্ষিপ্ত 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" }
}

এই স্ট্রাকচারের কারণেই v2.0 ডি ফ্যাক্টো স্ট্যান্ডার্ড হয়ে উঠেছে— এটা এতটাই সহজ যে এক বিকেলেই ইমপ্লিমেন্ট করা যায়, আর প্রায় প্রতিটি ব্যাজ ডেটা কনজিউমারই এটা দেখতে চায়।

v2.0-এ hosted বনাম signed ভেরিফিকেশন

v2.0-এর ভেতরের এই দুই ভেরিফিকেশন মোড বোঝাটা জরুরি, কারণ মানুষ প্রায়ই “v2.0, v3.0-এর চেয়ে কম সিকিউর” আর “hosted ভেরিফিকেশন, signed-এর চেয়ে কম সিকিউর”— এই দুটোকে গুলিয়ে ফেলে। এগুলো একই ব্যাপার না।

• Hosted — verification.type হলো "hosted", আর Assertion-এর id একটি লাইভ URL। একজন ভেরিফায়ার সেই URL আনে এবং রেসপন্স মিলছে কিনা চেক করে; বিশ্বাস আসে ডোমেইন নিয়ন্ত্রণ করা থেকে (যেমন, শুধু badges.ninja-ই badges.ninja/certify-badge/award/...-এ পাবলিশ করতে পারে)। বেশিরভাগ কনজিউমার-ফেসিং ভেরিফিকেশন পেজ এটাই ব্যবহার করে, কারণ একজন মানুষ শুধু লিংকে ক্লিক করলেই হয়।
• Signed — verification.type হলো "signed", আর Assertion-এ পুরো পেলোডের উপর একটা JWS সিগনেচার থাকে (বা তার রেফারেন্স থাকে)। একজন ভেরিফায়ার ইস্যুয়ারের পাবলিক কী রিজলভ করে এবং কোনো URL রিচেবল কিনা তার উপর নির্ভর না করে সিগনেচার চেক করে। এটা স্পিরিটে v3.0-এর মডেলের কাছাকাছি, শুধু DID লেয়ার ছাড়া।

Node-এ একটা মিনিমাল signed-ভেরিফিকেশন চেক এমন দেখায়—

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 অফলাইন হয়ে গেলেও ক্রেডেনশিয়াল ভেরিফায়েবল থাকে, তাহলে signed v2.0 আপনাকে DID অ্যাডপ্ট না করেই v3.0-এর বেশিরভাগ ডিউরেবিলিটি বেনিফিট দেয়।

Open Badge v3.0 কী বদলায়

Open Badge v3.0 হলো W3C Verifiable Credentials (VC) Data Model-এর উপর একটা পুরো রিরাইট, v2.0-এর JSON-LD শেপের কোনো ইনক্রিমেন্টাল আপডেট না। প্র্যাকটিসে যেসব পার্থক্য গুরুত্বপূর্ণ—

• ডিফল্টে ক্রিপ্টোগ্রাফিক সাইনিং। প্রতিটি v3.0 ক্রেডেনশিয়ালই একটা signed VC— কোনো “hosted, URL-কে বিশ্বাস করো” ফলব্যাক নেই। ভেরিফিকেশন সবসময় ম্যাথমেটিক্যাল, ডোমেইন-বেসড না।
• DID-বেসড ইস্যুয়ার আইডেন্টিটি। URL আর ইমেইল সহ একটা IssuerOrg অবজেক্টের বদলে, ইস্যুয়ারকে একটা Decentralized Identifier (DID) দিয়ে চিহ্নিত করা হয়, যা একটা পাবলিক কী ডকুমেন্টে রিজলভ হয়।
• Comprehensive Learner Record (CLR) 2.0-এর সাথে অ্যালাইনমেন্ট। v3.0 ডিজাইন করা হয়েছে CLR-এর সাথে ইন্টারঅপারেট করার জন্য, তাই একটা মাত্র ক্রেডেনশিয়াল অ্যাচিভমেন্ট ডেটার পাশাপাশি সেই ধরনের স্ট্রাকচার্ড ট্রান্সক্রিপ্ট ডিটেইলও বহন করতে পারে যা CLR কনজিউমাররা আশা করে (কম্পিটেন্সি, অ্যাসেসমেন্ট রেজাল্ট, টার্ম/কোর্স কনটেক্সট)।
• ডিজিটাল ওয়ালেট কম্প্যাটিবিলিটি। যেহেতু v3.0 ক্রেডেনশিয়াল স্ট্যান্ডার্ড W3C VC, এগুলো আইডেন্টিটি ওয়ালেটে রাখা যায়, ঠিক যেমন একটা ড্রাইভিং লাইসেন্স বা ভ্যাকসিন ক্রেডেনশিয়াল রাখা যায়— শুধু একটা ওয়েব পেজে দেখানো না।

সংক্ষেপে বলতে গেলে: v2.0 উত্তর দেয় “একজন মানুষ বা সাধারণ স্ক্রিপ্ট কি এই ক্রেডেনশিয়াল ভেরিফাই করতে পারে,” আর v3.0 উত্তর দেয় “এই ক্রেডেনশিয়াল কি বৃহত্তর verifiable-credentials ইকোসিস্টেমের সাথে— ওয়ালেট, DID, ফরমাল লার্নার রেকর্ডের সাথে— ইন্টারঅপারেট করতে পারে।“

পাশাপাশি তুলনা

কেন ইন্সটল্ড বেস এখনও v2.0-তেই চলছে

বেশিরভাগ প্রোগ্রামের জন্য সিদ্ধান্তটা এই অংশেই ঘুরে যায়— যেসব জায়গায় আপনার প্রাপকরা আসলেই চান তাদের ক্রেডেনশিয়াল দেখাক, সেগুলো এখনও v2.0 আশা করে। LinkedIn-এর Add to Profile ফ্লো, Credly, Badgr, আর বেশিরভাগ applicant-tracking-system ইন্টিগ্রেশন v2.0-এর Assertion/BadgeClass শেপ পার্স করে। আপনার লক্ষ্য যদি হয় “প্রাপকরা এটা LinkedIn-এ পোস্ট করতে পারবে আর রিক্রুটাররা ক্লিক করে ভেরিফাই করতে পারবে,” তাহলে v2.0 কোনো লিগ্যাসি ফরম্যাট না যাতে আপনি আটকে আছেন— এটাই সেই ফরম্যাট যা ইকোসিস্টেম এখন বলে।

আমরা এই একই টেনশন প্রাপকের দিক থেকে কভার করেছি LinkedIn Skill Assessments vs Open Badges-এ— একটা ব্যাজের ভ্যালু অনেকাংশে নির্ভর করে এটা কত সহজে সেসব জায়গায় ফিট করে যেখানে রিক্রুটার আর সহকর্মীরা ইতিমধ্যে খোঁজে, আর আজ তা মূলত v2.0-শেপড ইনফ্রাস্ট্রাকচার।

v3.0 আসলে কখন গুরুত্বপূর্ণ

v3.0 কোনো হাইপ না— এটা নির্দিষ্ট প্রোগ্রামের জন্য বাস্তব সমস্যা সমাধান করে—

• CLR ম্যান্ডেটের অধীনে থাকা ইউনিভার্সিটি আর ইস্যুয়ার। আপনি যদি একটা ফরমাল ট্রান্সক্রিপ্ট সিস্টেমের পাশাপাশি ইস্যু করেন, বা কোনো স্টেট/রিজিওনাল এডুকেশন বডি CLR 2.0-কম্প্যাটিবল আউটপুট দাবি করে, তাহলে v3.0-এর বিল্ট-ইন অ্যালাইনমেন্ট আপনাকে একটা v2.0 Assertion-এর উপর CLR ফিল্ড জোড়া লাগানো থেকে বাঁচায়।
• ডিজিটাল ওয়ালেট স্টোরেজ টার্গেট করা প্রোগ্রাম। আপনার প্রাপকদের যদি এই ক্রেডেনশিয়াল শুধু ওয়েব পেজে দেখানোর বদলে একটা ওয়ালেট অ্যাপে রাখতে হয়, তাহলে শুধু একটা W3C VC (মানে v3.0)-ই সেখানে নেটিভলি কাজ করবে।
• DID-বেসড ট্রাস্ট সহ ক্রস-ইস্যুয়ার ক্রেডেনশিয়াল এক্সচেঞ্জ। আপনি যদি এমন একটা নেটওয়ার্ক বানাচ্ছেন বা তাতে যোগ দিচ্ছেন যেখানে ইস্যুয়ার আইডেন্টিটিকে “এই URL-কে বিশ্বাস করো”-র বদলে ক্রিপ্টোগ্রাফিক্যালি পোর্টেবল হতে হবে, তাহলে DID-ই সঠিক প্রিমিটিভ।

২০২৬ সালে একটা ট্রেনিং প্রোগ্রাম, বুটক্যাম্প, বা প্রফেশনাল-ডেভেলপমেন্ট ইস্যুয়ারের জন্য এগুলোর কোনোটাই কমন কেস না। এগুলো কমন সেসব ইনস্টিটিউশনের জন্য যাদের কমপ্লায়েন্স বা ইন্টারঅপারেবিলিটি রিকোয়ারমেন্ট আছে যা স্পেসিফিকভাবে CLR বা W3C VC-এর নাম নেয়।

একটা সংক্ষিপ্ত v3.0 ক্রেডেনশিয়াল দেখায় এনভেলপটা কতটা আলাদা দেখতে, যদিও আন্ডারলাইং অ্যাচিভমেন্ট ডেটা কনসেপচুয়ালি একই অ্যাওয়ার্ড—

{
  "@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 না, আর পুরো ডকুমেন্টে একটা verification পয়েন্টারের বদলে একটা proof ব্লক থাকে। উপরে উল্লেখিত DID রেজোলিউশন + VC সাইনিং টুলিং— এটাই সেটা— আসল ইঞ্জিনিয়ারিং কাজ, আর এমন কাজ যা নষ্ট হয় যদি ডাউনস্ট্রিমে এখনও কেউ এটা আসলে কনজিউম না করে।

পরিষ্কার করা দরকার এমন কিছু কমন ভুল ধারণা

• “v3.0 বেশি সিকিউর।” সবসময় না— signed v2.0 আর v3.0 দুটোই ক্রিপ্টোগ্রাফিক ভেরিফিকেশনের উপর নির্ভর করে। v3.0-এর সুবিধা হলো স্ট্যান্ডার্ডাইজড আইডেন্টিটি (DID) আর ওয়ালেট ইন্টারঅপারেবিলিটি, signed v2.0-এর তুলনায় সিকিউরিটি আপগ্রেড না।
• “v2.0 ডিপ্রিকেটেড।” না, এটা না। 1EdTech দুটো স্পেসিফিকেশনই মেইনটেইন করে, আর v2.0 এখনও সেই ভার্শন যা ইস্যুয়াররা দিনে দিনে আসলেই ব্যবহার করা প্ল্যাটফর্ম আর ইন্টিগ্রেশনগুলো রেফারেন্স করে।
• “পুরো প্রোগ্রামের জন্য একটাই বেছে নিতে হবে।” না, তা করতে হবে না। কোনো কিছুই একজন ইস্যুয়ারকে জেনারেল ইউজের জন্য v2.0 পাবলিশ করা আর যে নির্দিষ্ট পার্টনার ইন্টিগ্রেশনে দরকার সেখানে v3.0 আউটপুট যোগ করা থেকে আটকায় না— আন্ডারলাইং অ্যাওয়ার্ড ডেটা বদলায় না, শুধু রিপ্রেজেন্টেশন বদলায়।

মাইগ্রেশন পাথ (আর কেন চিরদিনের জন্য বেছে নেওয়ার দরকার নেই)

প্রায় প্রতিটি ইস্যুয়ারের জন্য প্র্যাকটিক্যাল মুভ হলো: এখন v2.0 শিপ করুন, আর v3.0-কে রিপ্লেসমেন্ট না ভেবে অ্যাডিশন হিসেবে ট্রিট করুন, যখন কোনো নির্দিষ্ট ডাউনস্ট্রিম কনজিউমার এটা দাবি করে। এটা কেন এত ক্লিনলি কাজ করে তার কয়েকটা কারণ—

1. পরে v3.0 সাপোর্ট যোগ করার সময় আপনার BadgeClass আর Assertion ID বদলানোর দরকার নেই— আপনি একই আন্ডারলাইং অ্যাওয়ার্ডের দ্বিতীয়, ভিন্নভাবে শেপড একটা রিপ্রেজেন্টেশন যোগ করছেন, বিদ্যমান প্রাপকদের ক্রেডেনশিয়াল মাইগ্রেট করছেন না।
2. শুধু v2.0 বোঝা ভেরিফায়ারগুলো আগের মতোই একদম ঠিকঠাক কাজ করতে থাকে।
3. আপনার কাছে একটা কংক্রিট রিকোয়ারমেন্ট থাকার আগেই DID ইনফ্রাস্ট্রাকচার আর VC সাইনিং পাইপলাইন বানানো এড়িয়ে যেতে পারেন।

badges.ninja-এ আমরা ইন্টার্নালি এই একই লজিক ব্যবহার করি— প্রতিটা অ্যাওয়ার্ড একটা v2.0 Open Badge হিসেবে বের হয়— JSON-LD, একটা স্থিতিশীল /certify-badge/award/{guid} URL-এ hosted ভেরিফিকেশন, বক্স থেকে বের করলেই LinkedIn Add to Profile-এর জন্য রেডি— কারণ এটা কভার করে ইস্যুয়ারদের আসলে যা তৈরি করতে বলা হয় তার সিংহভাগ। আপনার প্রোগ্রামের যদি পরে কোনো নির্দিষ্ট ইনস্টিটিউশনাল পার্টনারের জন্য v3.0/CLR আউটপুট দরকার হয়, সেটা একটা কার্যকরী v2.0 পাইপলাইনের উপর একটা স্কোপড অ্যাডিশন, কোনো রিরাইট না।

এই সিকোয়েন্সিং আপনাকে একটা সূক্ষ্ম ঝুঁকি থেকেও রক্ষা করে— আপনার পার্টনাররা আসলে কোন DID মেথড আশা করে তা না জেনেই DID ইনফ্রাস্ট্রাকচারে কমিট করা। VC ইকোসিস্টেম এখনও একটা DID মেথডে কনভার্জ করেনি— did:web, did:key, আর লেজার-অ্যাঙ্কর্ড মেথড— সবই বাস্তবে দেখা যায়, আর একটা পাইলট পার্টনারের জন্য ভুল মেথড বেছে নেওয়ার মানে হলো পরে ইস্যুয়ার-আইডেন্টিটি কাজটা আবার করতে হবে। একটা নামকরণ করা রিকোয়ারমেন্টের জন্য অপেক্ষা করার মানে হলো, কোনো কিছু বানানোর আগেই আপনি জানতে পারবেন আসলে কোন মেথড দরকার।

আপনার নিজের প্রোগ্রামের জন্য একটা দ্রুত গাট-চেক

v3.0-তে ইঞ্জিনিয়ারিং সময় খরচ করার আগে এই তিনটা প্রশ্ন জিজ্ঞেস করুন—

• আমার ক্রেডেনশিয়ালের কোনো কনজিউমার— একটা এমপ্লয়ার ATS, একটা লাইসেন্সিং বোর্ড, একটা পার্টনার ইনস্টিটিউশন— কি স্পষ্টভাবে CLR 2.0 বা W3C VC আউটপুট চায়? না হলে, v2.0-ই যথেষ্ট।
• আমার প্রাপকদের কি এই ক্রেডেনশিয়াল একটা ডিজিটাল ওয়ালেট অ্যাপে রাখতে হবে, শুধু একটা ওয়েব প্রোফাইল বা LinkedIn-এ না? না হলে, v2.0-ই যথেষ্ট।
• আপনি কি এমন ক্রস-ইস্যুয়ার ট্রাস্ট ইনফ্রাস্ট্রাকচার বানাচ্ছেন যেখানে URL-বেসড hosted ভেরিফিকেশন সত্যিকার অর্থেই যথেষ্ট না? না হলে, v2.0-ই যথেষ্ট।

আপনি যদি তিনবারই “না” উত্তর দেন, তাহলে ২০২৬ সালে v2.0 শিপ করে আপনি পিছিয়ে নেই— আপনি স্পেসিফিকেশনটাকে সেই ইকোসিস্টেমের সাথে মেলাচ্ছেন যা এটা আসলেই কনজিউম করে। কোনো নির্দিষ্ট পার্টনার বা কমপ্লায়েন্স রিকোয়ারমেন্ট যখন নাম ধরে v3.0 চাইবে, তখন এই প্রশ্নে আবার ফিরে আসুন, “v3 নতুন” এমন একটা জেনারেল ফিলিং থেকে না।

ব্যাজ ভেরিফিকেশন ডেটা পুরনো, নন-স্ট্যান্ডার্ড ক্রেডেনশিয়াল ফরম্যাটের বিপরীতে কীভাবে টিকে থাকে, তা নিয়ে আরও জানতে দেখুন Blockchain Certificates vs Open Badges, যা একটা ভিন্ন অ্যাঙ্গেল থেকে ভেরিফিকেশন আর পোর্টেবিলিটির ট্রেড-অফ নিয়ে গভীরে যায়।

---

আপনার প্রথম ভেরিফায়েবল ক্রেডেনশিয়াল ইস্যু করতে প্রস্তুত? badges.ninja-তে ফ্রি শুরু করুন — ভিজ্যুয়াল ডিজাইনার, পাবলিক ভেরিফিকেশন পেজ, PDF সার্টিফিকেট, Open Badge v2.0 আউটপুট। কোনো ক্রেডিট কার্ড লাগবে না।