Open Badge v2 vs v3 објашњено: Коју спецификацију да користите данас?

Ако у 2026. постављате програм за издавање сертификата, наићи ћете на ово питање већ у првом сату истраживања: да ли треба да издајете Open Badge v2.0 или новији v3.0? Искрен одговор је „зависи ко треба да чита ваше сертификате” — али то није задовољавајуће ако баш ви морате да одлучите до петка. Зато хајде да прођемо кроз то шта се заправо променило између ове две спецификације, ко шта данас подржава и коју верзију већина издавалаца треба да користи управо сада.

Шта је заправо Open Badge v2.0

Open Badge v2.0 је спецификација организације 1EdTech (раније IMS Global) која је окосница дигиталног издавања сертификата још од 2017. године. Заснована је на JSON-LD и структурирана око три повезана објекта:

• IssuerOrg — ко је издао сертификат (назив, URL, е-пошта, лого)
• BadgeClass — сама врста сертификата (назив, опис, критеријуми, слика)
• Assertion — конкретна додела конкретном примаоцу (идентитет примаоца, датум издавања issuedOn, докази, метод верификације)

Assertion примаоца упућује на BadgeClass, који даље упућује на IssuerOrg. Верификација се одвија на један од два начина: hosted (верификатор преузима актуелни Assertion JSON са стабилног URL-а и верује домену) или 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 је постао де факто стандард: довољно је једноставан да се имплементира за једно поподне, и то је оно што готово сваки потрошач података о значкама очекује да види.

Hosted и signed верификација унутар v2.0

Вреди разумети два режима верификације унутар самог v2.0, јер људи често мешају тврдњу „v2.0 је мање безбедан од v3.0” са тврдњом „hosted верификација је мање безбедна од signed”. То нису исте ствари.

• Hosted — verification.type има вредност "hosted", а id Assertion-а је активан URL. Верификатор преузима тај URL и проверава да ли одговор одговара; поверење долази од контроле над доменом (нпр. само badges.ninja може да објављује на badges.ninja/certify-badge/award/...). Ово користи већина страница за верификацију намењених корисницима, јер човек једноставно може да кликне на линк.
• Signed — verification.type има вредност "signed", а Assertion носи (или референцира) JWS потпис над садржајем. Верификатор разрешава јавни кључ издаваоца и проверава потпис независно од тога да ли је икакав URL доступан. Ово је по духу ближе моделу v3.0, само без DID слоја.

Минимална провера signed верификације у Node-у изгледа овако:

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 вам доноси већину предности v3.0 у погледу трајности, без усвајања DID-ова.

Шта Open Badge v3.0 мења

Open Badge v3.0 је потпуно нова верзија изграђена на W3C Verifiable Credentials (VC) Data Model-у, а не постепена надоградња JSON-LD формата из v2.0. Разлике које су битне у пракси:

• Криптографско потписивање подразумевано. Сваки v3.0 сертификат је потписан VC — не постоји резервна опција „hosted, верујте URL-у”. Верификација је увек математичка, а не заснована на домену.
• Идентитет издаваоца заснован на DID-у. Уместо IssuerOrg објекта са URL-ом и е-поштом, издавалац се идентификује преко децентрализованог идентификатора (DID), који се разрешава у документ са јавним кључем.
• Усклађеност са Comprehensive Learner Record (CLR) 2.0. v3.0 је осмишљен да буде интероперабилан са CLR-ом, тако да један сертификат може да носи и податке о достигнућу и врсту структурираних података о преписима које CLR потрошачи очекују (компетенције, резултати процене, контекст семестра/курса).
• Компатибилност са дигиталним новчаницима. Пошто су v3.0 сертификати стандардни W3C VC-ови, могу се чувати у новчаницима за идентитет исто као возачка дозвола или потврда о вакцинацији — не само приказивати на веб страници.

Укратко: v2.0 одговара на питање „може ли човек или једноставан скрипт да верификује овај сертификат”, а v3.0 одговара на питање „може ли овај сертификат да буде интероперабилан са ширим екосистемом проверљивих сертификата — новчаницима, DID-овима, формалним евиденцијама о учењу”.

Поређење један уз други

Зашто постојећа база корисника и даље ради на v2.0

Ово је оно што код већине програма пресуђује одлуку: места на којима ваши примаоци заиста желе да се њихови сертификати појаве и даље очекују v2.0. LinkedIn-ов ток Add to Profile, Credly, Badgr и велика већина интеграција система за праћење кандидата (ATS) парсирају облик 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 вас спашава прикачињања CLR поља на v2.0 Assertion.
• Програми усмерени на чување у дигиталним новчаницима. Ако ваши примаоци треба да чувају сертификат у апликацији новчаника, а не само да га приказују на веб страници, тамо ће native да ради само W3C VC (тј. v3.0).
• Размена сертификата између издавалаца заснована на DID поверењу. Ако градите или се придружујете мрежи у којој идентитет издаваоца треба да буде криптографски преносив, а не заснован на принципу „верујте овом URL-у”, DID-ови су прави градивни елемент.

Ниједан од ових случајева није уобичајен за програм обуке, bootcamp или издаваоца сертификата за професионални развој у 2026. години. Уобичајени су за институције са захтевима усклађености или интероперабилности које изричито помињу 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" }
}

Приметите да је поље издаваоца DID, а не URL, и да цео документ носи proof блок уместо verification показивача. То је управо она 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. Ваши BadgeClass и Assertion идентификатори не морају да се мењају када касније додате подршку за v3.0 — додајете другу, другачије обликовану репрезентацију исте основне доделе, а не мигрирате постојеће сертификате примаоца.
2. Верификатори који разумеју само v2.0 настављају да раде потпуно исто као раније.
3. Избегавате изградњу DID инфраструктуре и VC линија за потписивање пре него што имате конкретан захтев који то тражи.

Ово је иста логика коју интерно користимо на badges.ninja: свака додела излази као v2.0 Open Badge — JSON-LD, hosted верификација на стабилном /certify-badge/award/{guid} URL-у, спреман 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 вас у потпуности покрива.
• Да ли градим инфраструктуру поверења између издавалаца код које hosted верификација заснована на URL-у заиста није довољна? Ако не, v2.0 вас у потпуности покрива.

Ако сте три пута одговорили „не”, објављивањем v2.0 у 2026. години нисте у заостатку — усклађујете спецификацију са екосистемом који је заиста користи. Поново размотрите питање када конкретан партнер или захтев усклађености изричито затражи v3.0 по имену, а не на основу општег осећаја да је „v3 новији”.

За више о томе како подаци о верификацији значки стоје у односу на старије, нестандардне формате сертификата, погледајте Blockchain Certificates vs Open Badges, који из другог угла улази у компромисе везане за верификацију и преносивост.

---

Спремни да издате свој први проверљиви сертификат? Почните бесплатно на badges.ninja — визуелни дизајнер, јавна страница за верификацију, PDF сертификат, Open Badge v2.0 излаз. Није потребна кредитна картица.