Open Badge v2 vs v3 vysvětleno: Kterou specifikaci byste měli používat dnes?

Pokud v roce 2026 zakládáte program pro vydávání certifikací, narazíte na tuto otázku už během první hodiny průzkumu: máte vydávat Open Badge v2.0, nebo novější v3.0? Upřímná odpověď zní „záleží na tom, kdo bude vaše odznaky číst“ — což ale není moc uspokojivé, pokud se musíte rozhodnout do pátku. Pojďme si tedy projít, co se mezi oběma specifikacemi skutečně změnilo, kdo dnes co podporuje, a kterou z nich by měla většina vydavatelů nasadit hned teď.

Co Open Badge v2.0 vlastně je

Open Badge v2.0 je specifikace organizace 1EdTech (dříve IMS Global), která tvoří páteř digitálního udělování odznaků už od roku 2017. Je postavená na JSON-LD a strukturovaná kolem tří provázaných objektů:

• IssuerOrg — kdo odznak vydal (název, URL, e-mail, logo)
• BadgeClass — samotný typ odznaku (název, popis, kritéria, obrázek)
• Assertion — konkrétní udělení konkrétnímu příjemci (identita příjemce, datum vydání, důkazy, způsob ověření)

Assertion příjemce odkazuje na BadgeClass, ten zase zpět na IssuerOrg. Ověření probíhá jedním ze dvou způsobů: hostované (ověřovatel stáhne aktuální Assertion JSON ze stabilní URL a důvěřuje doméně) nebo podepsané (Assertion nese JWS podpis, který ověřovatel zkontroluje proti veřejně publikovanému klíči vydavatele). Většina platforem, včetně badges.ninja, používá jako výchozí hostované ověření s možností podepsaného, protože hostované se snáz implementuje a člověk si ho snáz rychle zkontroluje.

Tady je zjednodušená v2.0 Assertion, tedy to, co byste dostali zpět z volání 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" }
}

Právě díky téhle struktuře se z v2.0 stal de facto standard: implementujete ji za odpoledne a je to přesně to, co očekává téměř každý spotřebitel dat o odznacích.

Hostované vs. podepsané ověření uvnitř v2.0

Stojí za to pochopit oba ověřovací režimy uvnitř samotné v2.0, protože lidé si často pletou tvrzení „v2.0 je méně bezpečná než v3.0“ s tvrzením „hostované ověření je méně bezpečné než podepsané“. Nejde o stejnou osu.

• Hostované — verification.type je "hosted" a id Assertion je živá URL. Ověřovatel tuto URL stáhne a zkontroluje, že odpověď souhlasí; důvěra vychází z kontroly nad doménou (např. na badges.ninja/certify-badge/award/... může publikovat pouze badges.ninja). Tohle používá většina ověřovacích stránek zaměřených na koncové uživatele, protože člověk může prostě kliknout na odkaz.
• Podepsané — verification.type je "signed" a Assertion nese (nebo odkazuje na) JWS podpis nad obsahem. Ověřovatel získá veřejný klíč vydavatele a zkontroluje podpis nezávisle na tom, jestli je jakákoli URL dostupná. Tohle je duchem blíž modelu v3.0, jen bez vrstvy DID.

Minimální kontrola podepsaného ověření v Node vypadá takto:

import { jwtVerify, importJWK } from 'jose';

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

Pokud vašemu programu záleží na tom, aby odznaky zůstaly ověřitelné i poté, co vaše API dočasně vypadne kvůli údržbě, podepsaná v2.0 vám dá většinu výhod trvanlivosti, které nabízí v3.0 — bez nutnosti zavádět DID.

Co mění Open Badge v3.0

Open Badge v3.0 je přepis postavený na modelu W3C Verifiable Credentials (VC) Data Model, nejde tedy o postupné vylepšení JSON-LD tvaru v2.0. V praxi jsou důležité tyto rozdíly:

• Kryptografické podepisování jako standard. Každý v3.0 odznak je podepsaný VC — neexistuje žádná záchranná varianta typu „hostovaný, důvěřuj URL“. Ověření je vždy matematické, ne založené na doméně.
• Identita vydavatele založená na DID. Místo objektu IssuerOrg s URL a e-mailem je vydavatel identifikován pomocí Decentralized Identifier (DID), který se rozřeší na dokument s veřejným klíčem.
• Provázanost s Comprehensive Learner Record (CLR) 2.0. v3.0 byla navržena tak, aby spolupracovala s CLR — jeden odznak tak může nést data o dosaženém úspěchu i strukturované detaily transkriptu, které konzumenti CLR očekávají (kompetence, výsledky hodnocení, kontext předmětu/termínu).
• Kompatibilita s digitálními peněženkami. Protože v3.0 odznaky jsou standardní W3C VC, mohou být uloženy v identitních peněženkách stejně jako řidičský průkaz nebo očkovací certifikát — nejen zobrazeny na webové stránce.

Zkrátka: v2.0 odpovídá na otázku „dokáže tenhle odznak ověřit člověk nebo jednoduchý skript“, zatímco v3.0 odpovídá na otázku „dokáže tento odznak spolupracovat se širším ekosystémem ověřitelných identit — peněženkami, DID, formálními záznamy o studiu“.

Srovnání vedle sebe

Proč instalovaná základna stále běží na v2.0

Tohle je část, která u většiny programů rozhoduje: místa, kde vaši příjemci skutečně chtějí své odznaky zobrazovat, dnes stále očekávají v2.0. LinkedIn Add to Profile, Credly, Badgr a naprostá většina integrací systémů pro sledování uchazečů (ATS) zpracovávají tvar Assertion/BadgeClass podle v2.0. Pokud je vaším cílem, aby příjemci mohli odznak zveřejnit na LinkedIn a náboráři si ho mohli proklikat a ověřit, v2.0 není zastaralý formát, u kterého jste uvízli — je to formát, kterým dnes ekosystém mluví.

Stejné napětí, jen z pohledu příjemce, jsme rozebrali v článku LinkedIn Skill Assessments vs Open Badges — hodnota odznaku je z velké části daná tím, jak snadno zapadá do míst, kam se náboráři a kolegové už dívají, a dnes je to infrastruktura, která je z drtivé většiny postavená na v2.0.

Kdy na v3.0 skutečně záleží

v3.0 není jen hype — řeší reálné problémy konkrétních programů:

• Univerzity a vydavatelé pod mandátem CLR. Pokud vydáváte odznaky souběžně s formálním transkripčním systémem, nebo státní/regionální vzdělávací orgán vyžaduje výstup kompatibilní s CLR 2.0, vestavěná provázanost v3.0 vám ušetří nutnost dodatečně nabalovat CLR pole na v2.0 Assertion.
• Programy cílící na uložení v digitální peněžence. Pokud vaši příjemci potřebují mít odznak uložený v aplikaci peněženky místo pouhého zobrazení na webové stránce, tam bude nativně fungovat jen W3C VC (tedy v3.0).
• Výměna odznaků mezi vydavateli založená na důvěře přes DID. Pokud budujete nebo se připojujete k síti, kde identita vydavatele musí být kryptograficky přenositelná místo „důvěřuj téhle URL“, jsou DID správnou stavební jednotkou.

Žádný z těchto případů není v roce 2026 běžný pro školicí program, bootcamp nebo vydavatele v oblasti profesního rozvoje. Jsou běžné u institucí s požadavky na soulad s předpisy nebo interoperabilitu, které konkrétně jmenují CLR nebo W3C VC.

Zjednodušený v3.0 odznak ukazuje, jak jinak vypadá obálka, i když jsou podkladová data o výsledku koncepčně stejná:

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

Všimněte si, že pole issuer je DID, ne URL, a celý dokument nese blok proof místo ukazatele verification. To je ono zmíněné rozřešení DID a nástroje pro podepisování VC — reálná inženýrská práce, a práce, která je zbytečná, pokud ji zatím nikdo po proudu skutečně nekonzumuje.

Mylné představy, které stojí za vyvrácení

• „v3.0 je bezpečnější.“ Ne nutně — podepsaná v2.0 i v3.0 obě spoléhají na kryptografické ověření. Výhodou v3.0 je standardizovaná identita (DID) a interoperabilita s peněženkami, ne bezpečnostní upgrade oproti podepsané v2.0.
• „v2.0 je zastaralá.“ Není. 1EdTech udržuje obě specifikace a v2.0 zůstává verzí, na kterou odkazují platformy a integrace, jež vydavatelé den co den skutečně používají.
• „Musíte si vybrat jednu pro celý program.“ Nemusíte. Nic nebrání vydavateli publikovat v2.0 pro obecné použití a přidat výstup v3.0 pro konkrétní partnerskou integraci, která to vyžaduje — podkladová data o odznaku se nemění, mění se jen reprezentace.

Migrační cesta (a proč se nemusíte rozhodovat navždy)

Praktický krok pro téměř každého vydavatele: vydávejte teď v2.0 a k v3.0 přistupujte jako k doplňku, ne náhradě, ve chvíli, kdy si ho konkrétně vyžádá downstream konzument. Funguje to hladce z několika důvodů:

1. ID vašich objektů BadgeClass a Assertion se při pozdějším přidání podpory v3.0 nemusí měnit — přidáváte druhou, jinak tvarovanou reprezentaci stejného podkladového odznaku, nemigrujete existující odznaky příjemců.
2. Ověřovatelé, kteří rozumí jen v2.0, fungují dál přesně jako dřív.
3. Vyhnete se budování DID infrastruktury a pipeline pro podepisování VC dřív, než máte konkrétní požadavek, který je vyžaduje.

Přesně tuhle logiku používáme interně v badges.ninja: každý odznak jde ven jako v2.0 Open Badge — JSON-LD, hostované ověření na stabilní URL /certify-badge/award/{guid}, hned připravené na LinkedIn Add to Profile — protože to pokrývá naprostou většinu toho, co jsou vydavatelé skutečně žádáni produkovat. Pokud váš program později potřebuje výstup v3.0/CLR pro konkrétního institucionálního partnera, je to ohraničené doplnění nad funkční v2.0 pipeline, ne přepis od základu.

Tohle pořadí vás navíc chrání před subtilnějším rizikem: zavázat se k DID infrastruktuře dřív, než víte, jakou DID metodu vaši partneři vlastně očekávají. Ekosystém VC se zatím neshodl na jedné DID metodě — did:web, did:key i metody kotvené na ledgeru se v praxi objevují všechny, a zvolit špatnou pro pilotního partnera znamená později přepracovávat identitu vydavatele. Když počkáte na konkrétně pojmenovaný požadavek, zjistíte, kterou metodu opravdu potřebujete, dřív, než cokoli začnete stavět.

Rychlá kontrola pro váš vlastní program

Než investujete inženýrský čas do v3.0, položte si tyto tři otázky:

• Vyžaduje explicitně nějaký konzument vašich odznaků — ATS zaměstnavatele, licenční komise, partnerská instituce — výstup CLR 2.0 nebo W3C VC? Pokud ne, v2.0 vás pokrývá.
• Potřebují vaši příjemci mít odznak uložený v aplikaci digitální peněženky, ne jen na webovém profilu nebo LinkedIn? Pokud ne, v2.0 vás pokrývá.
• Budujete infrastrukturu důvěry mezi vydavateli, kde hostované ověření založené na URL skutečně nestačí? Pokud ne, v2.0 vás pokrývá.

Pokud jste třikrát odpověděli „ne“, nejste v roce 2026 pozadu tím, že vydáváte v2.0 — přizpůsobujete specifikaci ekosystému, který ji skutečně konzumuje. K otázce se vraťte, až si v3.0 konkrétně vyžádá pojmenovaný partner nebo požadavek na soulad s předpisy, ne na základě obecného pocitu, že „v3 je novější“.

Více o tom, jak si data pro ověřování odznaků stojí oproti starším, nestandardním formátům certifikátů, najdete v článku Blockchain Certificates vs Open Badges, který se z jiného úhlu ponoří do kompromisů mezi ověřitelností a přenositelností.

---

Připraveni vydat svůj první ověřitelný odznak? Začněte zdarma na badges.ninja — vizuální editor, veřejná stránka pro ověření, PDF certifikát, výstup ve formátu Open Badge v2.0. Bez nutnosti platební karty.