Open Badge v2 срещу 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 — конкретното присъждане на конкретен получател (идентичност на получателя, дата на издаване, доказателства, метод за верификация)

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-a“. Верификацията винаги е математическа, не базирана на домейн.
• Идентичност на издателя, базирана на 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. Функцията Add to Profile на LinkedIn, Credly, Badgr и по-голямата част от интеграциите с ATS системи за проследяване на кандидати парсват формата Assertion/BadgeClass на v2.0. Ако целта ви е „получателите да могат да публикуват значката в LinkedIn, а рекрутърите да могат да кликнат и да я верифицират“, v2.0 не е остарял формат, в който сте заклещени — тя е форматът, на който екосистемата говори в момента.

Разгледахме точно това напрежение от гледна точка на получателя в LinkedIn Skill Assessments срещу Open Badges — стойността на една значка до голяма степен зависи от това колко лесно се вписва в местата, където рекрутърите и колегите вече гледат, а днес това е предимно инфраструктура във формат v2.0.

Кога v3.0 наистина има значение

v3.0 не е просто шум около нещо ново — тя решава реални проблеми за конкретни програми:

• Университети и издатели под мандат за CLR. Ако издавате удостоверения заедно с официална система за академични справки, или ако държавен/регионален образователен орган изисква съвместим с CLR 2.0 изход, вграденото съответствие на v3.0 ви спестява прикачването на CLR полета към Assertion от v2.0.
• Програми, насочени към съхранение в дигитален портфейл. Ако получателите ви трябва да съхраняват удостоверението в приложение-портфейл, а не просто да го показват на уеб страница, само W3C VC (т.е. v3.0) работи нативно за тази цел.
• Обмен на удостоверения между издатели с доверие, базирано на DID. Ако изграждате или се присъединявате към мрежа, в която идентичността на издателя трябва да бъде криптографски преносима, а не „доверявай се на този URL“, DID-ите са правилният примитив.

Никой от тези случаи не е обичаен за програма за обучение, бууткамп или издател на професионално развитие през 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" }
}

Забележете, че полето issuer е DID, не URL, а целият документ носи блок proof вместо указател verification. Това е споменатата по-горе резолюция на DID-и плюс инструментариум за подписване на VC — реална инженерна работа, и работа, която е пропиляна, ако все още нищо надолу по веригата реално не я консумира.

Разпространени погрешни представи, които си струва да изясним

• „v3.0 е по-сигурна.“ Не непременно — подписаната v2.0 и v3.0 разчитат и двете на криптографска верификация. Предимството на v3.0 е стандартизираната идентичност (DID-и) и оперативната съвместимост с портфейли, а не по-висока сигурност спрямо подписана 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 верификация на стабилен URL от типа /certify-badge/award/{guid}, готова за 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 срещу Open Badges, който разглежда компромисите между верификация и преносимост от друг ъгъл.

---

Готови ли сте да издадете първото си верифицируемо удостоверение? Започнете безплатно в badges.ninja — визуален дизайнер, публична страница за верификация, PDF сертификат, изход в Open Badge v2.0. Не се изисква кредитна карта.