Open Badge v2 vs v3 vysvetlené: Ktorú špecifikáciu použiť dnes?

Ak v roku 2026 nastavujete program na vydávanie digitálnych odznakov, na túto otázku narazíte už v prvej hodine prieskumu: mali by ste vydávať Open Badge v2.0, alebo novšiu v3.0? Úprimná odpoveď znie „záleží na tom, kto bude vaše odznaky čítať” — čo vás však príliš neuspokojí, ak sa musíte rozhodnúť do piatku. Poďme sa teda pozrieť na to, čo sa medzi oboma špecifikáciami skutočne zmenilo, kto ich dnes podporuje a ktorú by mala väčšina vydavateľov nasadiť práve teraz.

Čo je Open Badge v2.0 v skutočnosti

Open Badge v2.0 je špecifikácia 1EdTech (predtým IMS Global), ktorá je od roku 2017 chrbtovou kosťou digitálneho vydávania odznakov. Je postavená na JSON-LD a štruktúrovaná okolo troch prepojených objektov:

• IssuerOrg — kto odznak vydal (názov, URL, e-mail, logo)
• BadgeClass — samotný typ odznaku (názov, popis, kritériá, obrázok)
• Assertion — konkrétne udelenie konkrétnemu príjemcovi (identita príjemcu, dátum vydania, dôkazy, spôsob overenia)

Assertion príjemcu odkazuje na BadgeClass, ktorý zase odkazuje späť na IssuerOrg. Overenie prebieha jedným z dvoch spôsobov: hostované (overovateľ si stiahne živý JSON Assertion zo stabilnej URL adresy a dôveruje danej doméne) alebo podpísané (Assertion nesie podpis JWS, ktorý overovateľ skontroluje voči zverejnenému verejnému kľúču vydavateľa). Väčšina platforiem vrátane badges.ninja štandardne používa hostované overenie s možnosťou podpísaného, pretože hostované sa jednoduchšie implementuje a človek si ho ľahšie manuálne skontroluje.

Tu je skrátený v2.0 Assertion — presne to, čo by ste dostali späť pri volaní 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áve táto štruktúra je dôvodom, prečo sa v2.0 stala de facto štandardom: dá sa implementovať za jedno popoludnie a je to práve to, čo očakáva takmer každý, kto dáta o odznakoch spracúva.

Hostované vs podpísané overenie vo v2.0

Oplatí sa pochopiť oba spôsoby overenia v rámci samotnej v2.0, pretože ľudia si často zamieňajú tvrdenie „v2.0 je menej bezpečná ako v3.0” s tvrdením „hostované overenie je menej bezpečné ako podpísané”. Nejde o tú istú os porovnania.

• Hostované — verification.type má hodnotu "hosted" a id v Assertion je živá URL adresa. Overovateľ si túto URL stiahne a skontroluje, či odpoveď sedí; dôvera pochádza z kontroly nad doménou (napr. len badges.ninja môže publikovať na badges.ninja/certify-badge/award/...). Toto využíva väčšina overovacích stránok určených bežným používateľom, pretože stačí kliknúť na odkaz.
• Podpísané — verification.type má hodnotu "signed" a Assertion nesie (alebo odkazuje na) podpis JWS nad obsahom. Overovateľ získa verejný kľúč vydavateľa a skontroluje podpis nezávisle od toho, či je nejaká URL vôbec dostupná. Tento model je bližšie k princípu v3.0, len bez vrstvy DID.

Minimálna kontrola podpísaného overenia v Node.js vyzerá 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

Ak vášmu programu záleží na tom, aby odznaky zostali overiteľné aj po tom, čo vaše API ide do údržby, podpísaná v2.0 vám dá väčšinu výhod trvácnosti, ktoré ponúka v3.0 — bez toho, aby ste museli prijať DID.

Čo mení Open Badge v3.0

Open Badge v3.0 je prepísaná verzia postavená na W3C Verifiable Credentials (VC) Data Model, nie iba postupné rozšírenie JSON-LD tvaru z v2.0. Rozdiely, na ktorých v praxi záleží:

• Kryptografické podpisovanie ako predvolený stav. Každý v3.0 credential je podpísaný VC — neexistuje „hostovaná, dôveruj URL” alternatíva. Overenie je vždy matematické, nie založené na doméne.
• Identita vydavateľa cez DID. Namiesto objektu IssuerOrg s URL a e-mailom je vydavateľ identifikovaný decentralizovaným identifikátorom (DID), ktorý sa preloží na dokument s verejným kľúčom.
• Zosúladenie s Comprehensive Learner Record (CLR) 2.0. v3.0 bola navrhnutá tak, aby spolupracovala s CLR — jeden credential tak môže niesť dáta o dosiahnutom výsledku aj štruktúrované detaily transkriptu, ktoré konzumenti CLR očakávajú (kompetencie, výsledky hodnotení, kontext semestra/kurzu).
• Kompatibilita s digitálnymi peňaženkami. Keďže credentials vo v3.0 sú štandardné W3C VC, dajú sa ukladať v identitných peňaženkách rovnako ako vodičský preukaz alebo doklad o očkovaní — nielen zobrazovať na webovej stránke.

Skrátka: v2.0 odpovedá na otázku „dokáže človek alebo jednoduchý skript tento credential overiť” a v3.0 na otázku „dokáže tento credential spolupracovať so širším ekosystémom overiteľných poverení — peňaženkami, DID, formálnymi záznamami o vzdelávaní”.

Porovnanie vedľa seba

Prečo existujúca infraštruktúra stále beží na v2.0

Toto je časť, ktorá pre väčšinu programov rozhoduje: miesta, kde vaši príjemcovia chcú svoje odznaky skutočne zobraziť, dodnes očakávajú v2.0. Tok LinkedIn Add to Profile, Credly, Badgr aj drvivá väčšina integrácií systémov ATS spracúvajú tvar Assertion/BadgeClass z v2.0. Ak je vaším cieľom, aby si príjemcovia mohli odznak zverejniť na LinkedIn a náboroví pracovníci si ho preklikom overili, v2.0 nie je zastaraný formát, s ktorým ste uviazli — je to formát, ktorým ekosystém aktuálne hovorí.

Presne toto napätie sme z pohľadu príjemcu rozobrali v článku LinkedIn Skill Assessments vs Open Badges — hodnota odznaku je do veľkej miery funkciou toho, ako ľahko zapadne do miest, kam sa náboroví pracovníci a kolegovia už aj tak pozerajú, a dnes je to prevažne infraštruktúra tvarovaná podľa v2.0.

Kedy na v3.0 skutočne záleží

v3.0 nie je len marketingová bublina — rieši reálne problémy pre konkrétne programy:

• Univerzity a vydavatelia s povinnosťou CLR. Ak vydávate odznaky popri formálnom systéme transkriptov, alebo štátny/regionálny vzdelávací orgán vyžaduje výstup kompatibilný s CLR 2.0, zabudované zosúladenie vo v3.0 vám ušetrí prácu s dolepovaním polí CLR na Assertion z v2.0.
• Programy zamerané na ukladanie v digitálnej peňaženke. Ak vaši príjemcovia potrebujú mať credential uložený v aplikácii typu peňaženka, nielen zobrazený na webovej stránke, natívne tam bude fungovať iba W3C VC (teda v3.0).
• Výmena poverení medzi vydavateľmi s dôverou založenou na DID. Ak budujete alebo sa pripájate k sieti, kde identita vydavateľa musí byť kryptograficky prenosná namiesto princípu „dôveruj tejto URL”, DID sú tu správnym stavebným prvkom.

Nič z toho nie je bežný prípad pre školiaci program, bootcamp či vydavateľa profesijného rozvoja v roku 2026. Bežné je to pre inštitúcie s požiadavkami na súlad alebo interoperabilitu, ktoré konkrétne pomenúvajú CLR alebo W3C VC.

Skrátený credential vo v3.0 ukazuje, aký odlišný je obal, hoci ide koncepčne o rovnaké udelenie:

{
  "@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šimnite si, že pole issuer je DID, nie URL, a celý dokument nesie blok proof namiesto ukazovateľa verification. To je spomínané riešenie DID a nástroje na podpisovanie VC — reálna inžinierska práca, ktorá príde nazmar, ak ju zatiaľ nikto na druhej strane vôbec nespracúva.

Bežné mylné predstavy, ktoré stojí za to vyvrátiť

• „v3.0 je bezpečnejšia.” Nie nevyhnutne — podpísaná v2.0 aj v3.0 sa spoliehajú na kryptografické overenie. Výhoda v3.0 spočíva v štandardizovanej identite (DID) a interoperabilite s peňaženkami, nie v bezpečnostnom vylepšení oproti podpísanej v2.0.
• „v2.0 je zastaraná.” Nie je. 1EdTech udržiava obe špecifikácie a v2.0 zostáva verziou, na ktorú odkazujú platformy a integrácie, ktoré vydavatelia bežne používajú.
• „Pre celý program si musíte vybrať jednu z nich.” Nemusíte. Nič nebráni vydavateľovi publikovať v2.0 pre bežné použitie a zároveň pridať výstup vo v3.0 pre konkrétnu partnerskú integráciu, ktorá si to vyžaduje — samotné dáta o udelení sa nemenia, mení sa len reprezentácia.

Migračná cesta (a prečo si nemusíte vyberať natrvalo)

Praktický postup pre takmer každého vydavateľa: nasaďte v2.0 teraz a v3.0 pridajte neskôr ako doplnok, nie ako náhradu, keď si ju vyžiada konkrétny konzument na strane príjemcu. Prečo to funguje bez problémov:

1. Vaše ID pre BadgeClass a Assertion sa pri neskoršom pridaní podpory v3.0 nemusia meniť — pridávate druhú, inak tvarovanú reprezentáciu toho istého udelenia, nemigrujete existujúce odznaky príjemcov.
2. Overovatelia, ktorí rozumejú iba v2.0, budú fungovať naďalej presne tak ako predtým.
3. Vyhnete sa budovaniu infraštruktúry pre DID a pipeline na podpisovanie VC skôr, než máte konkrétnu požiadavku, ktorá ich vyžaduje.

Rovnakú logiku používame interne aj v badges.ninja: každý odznak ide von ako Open Badge v2.0 — JSON-LD, hostované overenie na stabilnej URL /certify-badge/award/{guid}, hneď pripravené na LinkedIn Add to Profile — pretože to pokrýva drvivú väčšinu toho, o čo sú vydavatelia skutočne žiadaní. Ak váš program neskôr potrebuje výstup v3.0/CLR pre konkrétneho inštitucionálneho partnera, ide o ohraničené rozšírenie nad funkčným pipeline v2.0, nie o prepísanie od základu.

Toto poradie vás chráni aj pred jemnejším rizikom: záväzkom voči infraštruktúre DID skôr, než viete, ktorú metódu DID vaši partneri vlastne očakávajú. Ekosystém VC sa zatiaľ nezhodol na jednej metóde DID — did:web, did:key aj metódy ukotvené v ledgeri sa v praxi vyskytujú všetky, a voľba nesprávnej pre pilotného partnera znamená neskôr prerábať prácu na identite vydavateľa odznova. Počkať na konkrétnu pomenovanú požiadavku znamená, že zistíte, ktorú metódu naozaj potrebujete, ešte predtým, než čokoľvek postavíte.

Rýchla kontrola pre váš vlastný program

Skôr než investujete inžiniersky čas do v3.0, položte si tieto tri otázky:

• Vyžaduje niektorý konzument vašich odznakov — firemný ATS, licenčná komisia, partnerská inštitúcia — výslovne výstup CLR 2.0 alebo W3C VC? Ak nie, v2.0 vám stačí.
• Potrebujú vaši príjemcovia mať tento credential v aplikácii digitálnej peňaženky, nielen na webovom profile alebo LinkedIn? Ak nie, v2.0 vám stačí.
• Budujete infraštruktúru dôvery medzi vydavateľmi, kde hostované overenie založené na URL naozaj nestačí? Ak nie, v2.0 vám stačí.

Ak ste trikrát odpovedali „nie”, nezaostávate tým, že v roku 2026 nasadíte v2.0 — práve naopak, prispôsobujete špecifikáciu ekosystému, ktorý ju skutočne konzumuje. K otázke sa vráťte, keď si v3.0 menovite vyžiada konkrétny partner alebo požiadavka na súlad, nie na základe všeobecného pocitu, že „v3 je novšia”.

Viac o tom, ako obstoja dáta o overení odznakov oproti starším, neštandardným formátom poverení, nájdete v článku Blockchain Certificates vs Open Badges, ktorý sa na kompromisy medzi overením a prenositeľnosťou pozerá z iného uhla.

---

Pripravení vydať svoj prvý overiteľný credential? Začnite zadarmo na badges.ninja — vizuálny dizajnér, verejná stránka na overenie, PDF certifikát, výstup Open Badge v2.0. Bez potreby kreditnej karty.