Open Badge v2 vs v3 megmagyarázva: Melyik szabványt használd ma?

Ha 2026-ban indítasz egy hitelesítési programot, már a kutatás első órájában belefutsz ebbe a kérdésbe: Open Badge v2.0-t vagy az újabb v3.0-t bocsásd ki? Az őszinte válasz az, hogy „attól függ, ki fogja olvasni a tanúsítványaidat” — de ez nem sokat segít, ha pénteken már döntened kell. Nézzük hát végig, mi is változott ténylegesen a két szabvány között, ma ki mit támogat, és melyiket érdemes a legtöbb kibocsátónak most bevezetnie.

Mi is valójában az Open Badge v2.0

Az Open Badge v2.0 az 1EdTech (korábban IMS Global) szabványa, amely 2017 óta a digitális hitelesítés gerince. JSON-LD-re épül, és három összekapcsolt objektum köré szerveződik:

• IssuerOrg — ki bocsátotta ki a tanúsítványt (név, URL, e-mail, logó)
• BadgeClass — maga a tanúsítványtípus (név, leírás, kritériumok, kép)
• Assertion — a konkrét odaítélés egy konkrét címzettnek (címzett azonosítója, issuedOn dátum, bizonyíték, ellenőrzési módszer)

A címzett Assertionje egy BadgeClassra mutat, amely pedig vissza egy IssuerOrgra. Az ellenőrzés kétféleképpen történhet: hosted (az ellenőrző lekéri az élő Assertion JSON-t egy stabil URL-ről, és megbízik a domainben) vagy signed (az Assertion egy JWS-aláírást hordoz, amelyet az ellenőrző a kibocsátó publikált nyilvános kulcsával ellenőriz). A legtöbb platform, köztük a badges.ninja is, alapértelmezetten hosted ellenőrzést használ, a signed opcióval kiegészítve, mert a hosted egyszerűbb megvalósítani, és emberi szemmel is könnyebb gyorsan ellenőrizni.

Íme egy lecsupaszított v2.0 Assertion — nagyjából ilyet kapnál vissza egy GET /awards/{id} hívásra:

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

Ez a felépítés az oka, hogy a v2.0 lett a de facto szabvány: elég egyszerű ahhoz, hogy egy délután alatt megvalósítsd, és szinte minden jelvényadat-fogyasztó ezt várja el.

Hosted vs signed ellenőrzés a v2.0-ban

Érdemes megérteni a v2.0-n belüli két ellenőrzési módot, mert sokan összemossák azt, hogy „a v2.0 kevésbé biztonságos, mint a v3.0” azzal, hogy „a hosted ellenőrzés kevésbé biztonságos, mint a signed”. Ez a kettő nem ugyanaz.

• Hosted — a verification.type értéke "hosted", az Assertion id mezője pedig egy élő URL. Az ellenőrző lekéri ezt az URL-t, és megnézi, hogy a válasz egyezik-e; a bizalom a domain feletti kontrollból fakad (pl. csak a badges.ninja publikálhat a badges.ninja/certify-badge/award/... címre). A legtöbb felhasználó felé forduló ellenőrzőoldal ezt használja, mert egy ember egyszerűen rákattinthat a linkre.
• Signed — a verification.type értéke "signed", az Assertion pedig hordoz (vagy hivatkozik) egy JWS-aláírást a payload felett. Az ellenőrző feloldja a kibocsátó nyilvános kulcsát, és attól függetlenül ellenőrzi az aláírást, hogy bármelyik URL elérhető-e. Ez szellemiségében közelebb áll a v3.0 modelljéhez, csak a DID-réteg nélkül.

Egy minimális signed-ellenőrzés Node-ban valahogy így néz ki:

import { jwtVerify, importJWK } from 'jose';

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

Ha a programodnak fontos, hogy a tanúsítványok akkor is ellenőrizhetők maradjanak, ha az API-d karbantartás miatt átmenetileg leáll, a signed v2.0 a v3.0 tartósságból fakadó előnyeinek nagy részét megadja anélkül, hogy DID-eket kellene bevezetned.

Mit változtat az Open Badge v3.0

Az Open Badge v3.0 egy újraírás a W3C Verifiable Credentials (VC) Data Model tetején, nem pedig a v2.0 JSON-LD felépítésének inkrementális frissítése. A gyakorlatban számító különbségek:

• Alapértelmezett kriptográfiai aláírás. Minden v3.0 tanúsítvány egy aláírt VC — nincs „hosted, bízz az URL-ben” tartalék megoldás. Az ellenőrzés mindig matematikai, nem domain-alapú.
• DID-alapú kibocsátói azonosítás. Egy URL-t és e-mailt tartalmazó IssuerOrg objektum helyett a kibocsátót egy Decentralized Identifier (DID) azonosítja, amely egy nyilvánoskulcs-dokumentumra oldódik fel.
• Illeszkedés a Comprehensive Learner Record (CLR) 2.0-hoz. A v3.0-t úgy tervezték, hogy együttműködjön a CLR-rel, így egyetlen tanúsítvány hordozhatja mind a teljesítményadatokat, mind azt a strukturált átiratrészletet, amit a CLR-fogyasztók elvárnak (kompetenciák, értékelési eredmények, félév/kurzus kontextus).
• Digitális tárca kompatibilitás. Mivel a v3.0 tanúsítványok szabványos W3C VC-k, ugyanúgy tárolhatók identitástárcákban, mint egy jogosítvány vagy egy oltási igazolás — nem csupán egy weboldalon megjelenítve.

Röviden: a v2.0 arra válaszol, hogy „tudja-e egy ember vagy egy egyszerű szkript ellenőrizni ezt a tanúsítványt”, a v3.0 pedig arra, hogy „képes-e a tanúsítvány együttműködni a tágabb ellenőrizhető-tanúsítvány ökoszisztémával — tárcákkal, DID-ekkel, formális tanulói rekordokkal”.

Egymás mellett: összehasonlítás

Miért fut még mindig v2.0-n a telepített bázis

Ez az a rész, ami a legtöbb programnál eldönti a kérdést: azok a helyek, ahol a címzettjeid valójában meg akarják jeleníteni a tanúsítványaikat, még mindig v2.0-t várnak. A LinkedIn Add to Profile folyamata, a Credly, a Badgr, és az álláskereső-nyomkövető rendszerek integrációinak túlnyomó többsége a v2.0 Assertion/BadgeClass felépítését dolgozza fel. Ha a célod az, hogy „a címzettek kitehessék ezt a LinkedInre, a toborzók pedig átkattintva ellenőrizhessék”, akkor a v2.0 nem egy elavult formátum, amibe beragadtál — ez az a formátum, amit az ökoszisztéma ma beszél.

Ezt a pontos feszültséget a címzett oldaláról már körbejártuk a LinkedIn Skill Assessments vs Open Badges cikkben — egy jelvény értéke nagyrészt attól függ, mennyire egyszerűen illeszkedik azokba a helyekbe, ahová a toborzók és a kollégák amúgy is néznek, ma pedig ez túlnyomórészt v2.0-alakú infrastruktúrát jelent.

Mikor számít igazán a v3.0

A v3.0 nem csak felhajtás — valós problémákat old meg konkrét programok számára:

• Egyetemek és CLR-előírás alá tartozó kibocsátók. Ha egy formális átiratrendszerrel párhuzamosan bocsátasz ki, vagy egy állami/regionális oktatási testület CLR 2.0-kompatibilis kimenetet ír elő, a v3.0 beépített illeszkedése megkímél attól, hogy CLR-mezőket kelljen egy v2.0 Assertionra ráépítened.
• Digitálistárca-tárolást célzó programok. Ha a címzetteidnek egy tárcaappban kell tárolniuk a tanúsítványt ahelyett, hogy csak egy weboldalon jelenítenék meg, ott natívan csak egy W3C VC (azaz v3.0) fog működni.
• Kibocsátók közötti tanúsítványcsere DID-alapú bizalommal. Ha egy olyan hálózatot építesz vagy csatlakozol hozzá, ahol a kibocsátói azonosításnak kriptográfiailag hordozhatónak kell lennie ahelyett, hogy „bízz ebben az URL-ben”, a DID-ek a megfelelő építőelemek.

Ezek egyike sem tipikus eset egy képzési program, bootcamp vagy szakmai fejlesztési kibocsátó számára 2026-ban. Olyan intézményeknél gyakoriak, amelyeknek megfelelőségi vagy interoperabilitási követelményei kifejezetten CLR-t vagy W3C VC-ket nevesítenek.

Egy lecsupaszított v3.0 tanúsítvány megmutatja, mennyire más a boríték, még akkor is, ha a mögöttes teljesítményadat fogalmilag ugyanaz az elismerés:

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

Figyeld meg, hogy az issuer mező egy DID, nem egy URL, és az egész dokumentum egy proof blokkot hordoz egy verification mutató helyett. Ez a fentebb említett DID-feloldás + VC-aláírási eszköztár — valódi mérnöki munka, ami kárba vész, ha még semmi lentebb nem fogyasztja.

Gyakori tévhitek, amiket érdemes tisztázni

• „A v3.0 biztonságosabb.” Nem feltétlenül — a signed v2.0 és a v3.0 is kriptográfiai ellenőrzésre támaszkodik. A v3.0 előnye a szabványosított azonosítás (DID-ek) és a tárca-interoperabilitás, nem pedig egy biztonsági fejlesztés a signed v2.0-hoz képest.
• „A v2.0 elavult.” Nem az. Az 1EdTech mindkét szabványt karbantartja, és a v2.0 marad az a verzió, amelyre azok a platformok és integrációk hivatkoznak, amelyeket a kibocsátók a mindennapokban ténylegesen használnak.
• „Az egész programhoz egyet kell választanod.” Nem kell. Semmi sem akadályozza meg a kibocsátót abban, hogy v2.0-t publikáljon általános használatra, majd v3.0 kimenetet is hozzáadjon egy adott, azt megkövetelő partnerintegrációhoz — a mögöttes elismerésadat nem változik, csak a reprezentáció.

A migrációs út (és miért nem kell örökre döntened)

A gyakorlati lépés szinte minden kibocsátó számára: add ki most a v2.0-t, és kezeld a v3.0-t kiegészítésként, nem cseként, amikor egy konkrét lentebbi fogyasztó megköveteli. Néhány ok, amiért ez tisztán működik:

1. A BadgeClass és Assertion azonosítóidnak nem kell megváltozniuk, amikor később hozzáadod a v3.0-támogatást — egy második, más felépítésű reprezentációt adsz hozzá ugyanahhoz a mögöttes elismeréshez, nem a meglévő címzettek tanúsítványait migrálod.
2. Azok az ellenőrzők, amelyek csak a v2.0-t értik, pontosan úgy működnek tovább, mint eddig.
3. Elkerülöd, hogy DID-infrastruktúrát és VC-aláírási pipeline-okat építs, mielőtt konkrét igényed lenne rájuk.

Ugyanezt a logikát alkalmazzuk belsőleg a badges.ninja-n is: minden elismerés v2.0 Open Badge formájában megy ki — JSON-LD, hosted ellenőrzés egy stabil /certify-badge/award/{guid} URL-en, LinkedIn Add to Profile funkcióval eleve készen —, mert ez fedi le a kibocsátóktól ténylegesen elvárt kimenetek túlnyomó többségét. Ha a programodnak később v3.0/CLR kimenetre van szüksége egy konkrét intézményi partner miatt, az egy körülhatárolt kiegészítés egy már működő v2.0 pipeline-on, nem pedig egy újraírás.

Ez a sorrend egy finomabb kockázattól is megvéd: attól, hogy DID-infrastruktúra mellett kötelezd el magad, mielőtt tudnád, melyik DID-módszert várják el ténylegesen a partnereid. A VC-ökoszisztéma még nem konvergált egyetlen DID-módszerre — a did:web, a did:key és a ledger-alapú módszerek is mind felbukkannak a gyakorlatban, és ha rossz módszert választasz egy pilótapartnerhez, később újra kell csinálnod a kibocsátói azonosítás munkáját. Ha megvárod, amíg egy konkrét követelmény megnevezi az igényt, előbb megtudod, melyik módszerre van tényleg szükséged, mielőtt bármit is felépítenél.

Gyors önteszt a saját programodhoz

Tedd fel ezt a három kérdést, mielőtt mérnöki időt fektetnél a v3.0-ba:

• A tanúsítványaim bármelyik fogyasztója — egy munkáltatói ATS, egy engedélyező testület, egy partnerintézmény — kifejezetten megköveteli a CLR 2.0 vagy W3C VC kimenetet? Ha nem, a v2.0 megfelel neked.
• A címzetteimnek digitális tárcaappban kell tárolniuk ezt a tanúsítványt, nem csak egy webes profilban vagy a LinkedInen? Ha nem, a v2.0 megfelel neked.
• Kibocsátók közötti bizalmi infrastruktúrát építek, ahol az URL-alapú hosted ellenőrzés valóban nem elegendő? Ha nem, a v2.0 megfelel neked.

Ha háromszor „nem”-mel válaszoltál, nem vagy lemaradva azzal, hogy 2026-ban v2.0-t adsz ki — épp azt a szabványt választod, amely illeszkedik az azt ténylegesen fogyasztó ökoszisztémához. Térj vissza a kérdésre, amikor egy konkrét partner vagy megfelelőségi követelmény név szerint kéri a v3.0-t, ne csak azon általános érzés alapján, hogy „a v3 újabb”.

Ha bővebben érdekel, hogyan állja meg a helyét a jelvény-ellenőrzési adat a régebbi, nem szabványos tanúsítványformátumokkal szemben, nézd meg a Blockchain Certificates vs Open Badges cikket, amely más szemszögből ássa bele magát az ellenőrzési és hordozhatósági kompromisszumokba.

---

Készen állsz kiadni az első ellenőrizhető tanúsítványodat? Kezdd el ingyen a badges.ninja-n — vizuális tervező, nyilvános ellenőrzőoldal, PDF-tanúsítvány, Open Badge v2.0 kimenet. Bankkártya nem szükséges.