Open Badge v2 vs v3: какую спецификацию выбрать сегодня?

Если вы запускаете программу цифровых значков в 2026 году, этот вопрос встанет перед вами уже в первый час исследования: выпускать Open Badge v2.0 или более новую v3.0? Честный ответ — «зависит от того, кто будет читать ваши credentials», — но это не очень утешает, если решение нужно принять к пятнице. Так что давайте разберём, что на самом деле изменилось между двумя спецификациями, кто и что поддерживает сегодня, и какую версию стоит выпускать прямо сейчас большинству издателей.

Что такое Open Badge v2.0

Open Badge v2.0 — это спецификация 1EdTech (бывший IMS Global), которая с 2017 года служит основой цифрового credentialing. Она построена на JSON-LD и состоит из трёх связанных объектов:

• IssuerOrg — кто выпустил credential (название, URL, email, логотип)
• BadgeClass — сам тип credential (название, описание, критерии, изображение)
• 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

Если для вашей программы важно, чтобы credentials оставались проверяемыми даже после того, как ваш 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. На практике имеют значение следующие отличия:

• Криптографическая подпись по умолчанию. Каждый credential v3.0 — это подписанный VC, никакого «hosted, доверяй URL» запасного варианта нет. Верификация всегда математическая, а не основанная на домене.
• Идентичность издателя на основе DID. Вместо объекта IssuerOrg с URL и email издатель идентифицируется через Decentralized Identifier (DID), который разрешается в документ с публичным ключом.
• Совместимость с Comprehensive Learner Record (CLR) 2.0. v3.0 изначально проектировалась для взаимодействия с CLR, поэтому один credential может нести данные о достижении вместе со структурированными деталями транскрипта, которые ожидают потребители CLR (компетенции, результаты оценивания, привязка к семестру/курсу).
• Совместимость с цифровыми кошельками. Поскольку credentials v3.0 — это стандартные W3C VC, их можно хранить в кошельках для идентификации точно так же, как водительские права или сертификат о вакцинации, — а не только показывать на веб-странице.

Короче: v2.0 отвечает на вопрос «может ли человек или простой скрипт проверить этот credential», а v3.0 — на вопрос «может ли этот credential взаимодействовать с более широкой экосистемой verifiable credentials — кошельками, DID, формальными learner record».

Сравнение бок о бок

Почему установленная база всё ещё работает на v2.0

Именно этот момент склоняет решение большинства программ в одну сторону: места, где ваши получатели действительно хотят показать свои credentials, по-прежнему ожидают v2.0. LinkedIn Add to Profile, Credly, Badgr и подавляющее большинство интеграций систем учёта кандидатов разбирают именно форму Assertion/BadgeClass из v2.0. Если ваша цель — «получатели могут опубликовать это в LinkedIn, а рекрутеры могут кликнуть и проверить», то v2.0 — не устаревший формат, от которого вы не можете избавиться, а формат, на котором сегодня говорит вся экосистема.

Мы уже разбирали это ровно то же напряжение со стороны получателя в статье LinkedIn Skill Assessments vs Open Badges — ценность значка во многом определяется тем, насколько легко он встраивается в места, куда и так смотрят рекрутеры и коллеги, а сегодня это преимущественно инфраструктура, построенная вокруг v2.0.

Когда v3.0 действительно важна

v3.0 — не хайп, она решает реальные проблемы для конкретных программ:

• Университеты и издатели под требования CLR. Если вы выпускаете credentials параллельно с формальной системой транскриптов, или региональный/государственный орган образования требует вывод, совместимый с CLR 2.0, встроенное соответствие v3.0 избавляет вас от необходимости прикручивать поля CLR к Assertion v2.0.
• Программы, нацеленные на хранение в цифровых кошельках. Если вашим получателям нужно держать credential в приложении-кошельке, а не просто показывать его на веб-странице, только W3C VC (то есть v3.0) будет работать здесь нативно.
• Обмен credentials между издателями с доверием на основе DID. Если вы строите или присоединяетесь к сети, где идентичность издателя должна быть криптографически переносимой, а не «доверяй этому URL», DID — правильный примитив.

Ни один из этих случаев не типичен для учебной программы, буткемпа или издателя профессионального развития в 2026 году. Они типичны для организаций с требованиями комплаенса или совместимости, которые явно называют CLR или W3C VC.

Урезанный credential 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. Это и есть та самая работа по resolution 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, — вы добавляете второе, по-другому оформленное представление той же исходной награды, а не мигрируете credentials уже существующих получателей.
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 и методы на основе леджеров, и выбор не того метода для пилотного партнёра означает, что работу по идентичности издателя придётся переделывать позже. Если дождаться конкретного требования, вы узнаете, какой метод вам действительно нужен, прежде чем что-либо строить.

Быстрая проверка для вашей программы

Задайте себе три вопроса, прежде чем тратить инженерное время на v3.0:

• Требует ли явно кто-то из потребителей ваших credentials — ATS работодателя, лицензирующий орган, партнёрское учебное заведение — вывод в формате CLR 2.0 или W3C VC? Если нет — v2.0 вам вполне подходит.
• Нужно ли вашим получателям хранить credential в приложении-кошельке, а не только в веб-профиле или LinkedIn? Если нет — v2.0 вам вполне подходит.
• Строите ли вы инфраструктуру доверия между издателями, где hosted-верификации на основе URL действительно недостаточно? Если нет — v2.0 вам вполне подходит.

Если вы трижды ответили «нет», вы не отстаёте от жизни, выпуская v2.0 в 2026 году, — вы просто подбираете спецификацию под ту экосистему, которая её реально потребляет. Вернитесь к этому вопросу, когда конкретный партнёр или требование комплаенса явно назовёт v3.0, а не когда возникнет общее ощущение, что «v3 новее».

Подробнее о том, как данные верификации значков соотносятся со старыми, нестандартными форматами credentials, читайте в статье Blockchain Certificates vs Open Badges, которая разбирает компромиссы между верификацией и переносимостью под другим углом.

---

Готовы выпустить свой первый verifiable credential? Начните бесплатно на badges.ninja — визуальный редактор, публичная страница верификации, PDF-сертификат, вывод в Open Badge v2.0. Без банковской карты.