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 — конкретна нагорода конкретному отримувачу (ідентичність отримувача, дата видачі issuedOn, докази, метод верифікації)

Assertion отримувача посилається на BadgeClass, який своєю чергою посилається на IssuerOrg. Верифікація відбувається одним із двох способів: hosted (перевіряльник отримує актуальний JSON Assertion зі стабільного URL і довіряє домену) або signed (Assertion містить підпис JWS, який перевіряльник звіряє з опублікованим публічним ключем емітента). Більшість платформ, зокрема badges.ninja, за замовчуванням використовують hosted-верифікацію, а signed пропонують як опцію, оскільки hosted простіше реалізувати і легше перевірити вручну.

Ось скорочений приклад Assertion v2.0 — те, що ви отримаєте у відповідь на виклик 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/certify-badge/award/... може лише badges.ninja). Саме цей підхід використовує більшість сторінок верифікації, орієнтованих на людей, — адже достатньо просто перейти за посиланням.
• 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 — це не поступове оновлення JSON-LD формату v2.0, а переписана з нуля специфікація на основі W3C Verifiable Credentials (VC) Data Model. Ось відмінності, які мають практичне значення:

• Криптографічний підпис за замовчуванням. Кожен креденціал 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 для більшості програм: місця, де ваші отримувачі насправді хочуть показувати свої креденціали, досі очікують v2.0. Процес LinkedIn Add to Profile, 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 безпечніша». Не обов’язково — і 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: кожна нагорода видається як Open Badge v2.0 — 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 і методи, прив’язані до реєстрів (ledger), — усі трапляються на практиці, а вибір неправильного методу для пілотного партнера означає, що роботу з ідентичністю емітента доведеться переробляти пізніше. Очікування конкретної вимоги означає, що ви дізнаєтеся, який метод вам справді потрібен, ще до того, як почнете щось будувати.

Швидка перевірка для вашої власної програми

Поставте собі ці три запитання, перш ніж витрачати час розробників на 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. Кредитна картка не потрібна.