Open Badge v2 kontra v3: którą specyfikację wybrać już dziś?

Jeśli w 2026 roku uruchamiasz program certyfikacji, to pytanie pojawi się już w pierwszej godzinie researchu: wystawiać Open Badge w wersji v2.0, czy nowszej v3.0? Szczera odpowiedź brzmi: „zależy, kto ma czytać twoje poświadczenia” — ale to mało satysfakcjonujące, gdy musisz podjąć decyzję do piątku. Przejdźmy więc przez to, co faktycznie zmieniło się między tymi dwiema specyfikacjami, kto dziś co obsługuje i którą wersję powinna wdrożyć większość wystawców już teraz.

Czym naprawdę jest Open Badge v2.0

Open Badge v2.0 to specyfikacja 1EdTech (dawniej IMS Global), która od 2017 roku stanowi kręgosłup cyfrowego poświadczania kompetencji. Bazuje na JSON-LD i opiera się na trzech powiązanych ze sobą obiektach:

• IssuerOrg — kto wystawił poświadczenie (nazwa, URL, e-mail, logo)
• BadgeClass — sam typ poświadczenia (nazwa, opis, kryteria, obrazek)
• Assertion — konkretne przyznanie odznaki konkretnemu odbiorcy (tożsamość odbiorcy, data issuedOn, dowody, metoda weryfikacji)

Assertion odbiorcy wskazuje na BadgeClass, ten z kolei wskazuje z powrotem na IssuerOrg. Weryfikacja odbywa się na jeden z dwóch sposobów: hosted (weryfikujący pobiera aktualny JSON Assertion spod stałego adresu URL i ufa domenie) albo signed (Assertion zawiera podpis JWS, który weryfikujący sprawdza względem publicznego klucza opublikowanego przez wystawcę). Większość platform, w tym badges.ninja, domyślnie stosuje weryfikację hosted, z opcją signed do wyboru — bo hosted jest prostsza we wdrożeniu i łatwiejsza do ręcznego sprawdzenia przez człowieka.

Oto uproszczony Assertion w wersji v2.0 — coś, co dostaniesz w odpowiedzi na wywołanie 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" }
}

Ta struktura jest powodem, dla którego v2.0 stała się faktycznym standardem: da się ją wdrożyć w jedno popołudnie, a niemal każdy odbiorca danych o odznakach właśnie takiej struktury oczekuje.

Weryfikacja hosted kontra signed w v2.0

Warto zrozumieć te dwa tryby weryfikacji w obrębie samej v2.0, bo ludzie często mylą stwierdzenie „v2.0 jest mniej bezpieczna niż v3.0” ze stwierdzeniem „weryfikacja hosted jest mniej bezpieczna niż signed”. To nie jest ta sama oś porównania.

• Hosted — pole verification.type ma wartość "hosted", a id Assertion jest aktywnym adresem URL. Weryfikujący pobiera ten URL i sprawdza, czy odpowiedź się zgadza; zaufanie wynika z kontroli nad domeną (np. tylko badges.ninja może publikować pod adresem badges.ninja/certify-badge/award/...). Tego trybu używa większość stron weryfikacyjnych skierowanych do odbiorców, bo człowiek może po prostu kliknąć w link.
• Signed — pole verification.type ma wartość "signed", a Assertion zawiera (lub wskazuje) podpis JWS nałożony na dane. Weryfikujący pobiera klucz publiczny wystawcy i sprawdza podpis niezależnie od tego, czy jakikolwiek URL jest w danej chwili osiągalny. Duchem jest to bliższe modelowi v3.0 — tylko bez warstwy DID.

Minimalna weryfikacja signed w Node wygląda tak:

import { jwtVerify, importJWK } from 'jose';

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

Jeśli twojemu programowi zależy na tym, by poświadczenia dało się zweryfikować nawet wtedy, gdy twoje API zejdzie na chwilę w ramach konserwacji, signed v2.0 daje ci większość korzyści trwałościowych v3.0 — bez konieczności wdrażania DID.

Co zmienia Open Badge v3.0

Open Badge v3.0 to przepisanie specyfikacji od podstaw na bazie modelu danych W3C Verifiable Credentials (VC), a nie przyrostowa aktualizacja struktury JSON-LD znanej z v2.0. Różnice, które mają znaczenie w praktyce:

• Podpis kryptograficzny domyślnie. Każde poświadczenie v3.0 to podpisane VC — nie ma tu wariantu zapasowego „hosted, zaufaj URL-owi”. Weryfikacja jest zawsze matematyczna, nie oparta na domenie.
• Tożsamość wystawcy oparta na DID. Zamiast obiektu IssuerOrg z adresem URL i e-mailem, wystawca jest identyfikowany przez Decentralized Identifier (DID), który rozwiązuje się do dokumentu z kluczem publicznym.
• Zgodność z Comprehensive Learner Record (CLR) 2.0. v3.0 została zaprojektowana pod kątem współpracy z CLR, dzięki czemu pojedyncze poświadczenie może nieść zarówno dane o osiągnięciu, jak i ten rodzaj ustrukturyzowanego szczegółu transkryptu, jakiego oczekują odbiorcy CLR (kompetencje, wyniki oceny, kontekst semestru/kursu).
• Zgodność z cyfrowymi portfelami. Ponieważ poświadczenia v3.0 są standardowymi W3C VC, można je przechowywać w portfelach tożsamości tak samo jak prawo jazdy czy certyfikat szczepienia — a nie tylko wyświetlać na stronie internetowej.

Krótko mówiąc: v2.0 odpowiada na pytanie „czy człowiek lub prosty skrypt może zweryfikować to poświadczenie”, a v3.0 odpowiada na pytanie „czy to poświadczenie może współpracować z szerszym ekosystemem weryfikowalnych poświadczeń — portfelami, DID, formalnymi rejestrami osiągnięć ucznia”.

Porównanie bezpośrednie

Dlaczego istniejąca baza wciąż działa na v2.0

To właśnie ten element przeważa szalę w większości programów: miejsca, w których twoi odbiorcy naprawdę chcą pokazywać swoje poświadczenia, wciąż oczekują v2.0. Proces Add to Profile na LinkedIn, Credly, Badgr i zdecydowana większość integracji z systemami ATS parsuje strukturę Assertion/BadgeClass z v2.0. Jeśli twoim celem jest to, żeby „odbiorcy mogli opublikować to na LinkedIn, a rekruterzy mogli kliknąć i zweryfikować”, to v2.0 nie jest przestarzałym formatem, w którym utknąłeś — to format, którym dziś mówi cały ekosystem.

Dokładnie to napięcie, tym razem z perspektywy odbiorcy, omówiliśmy w tekście LinkedIn Skill Assessments kontra Open Badges — wartość odznaki w dużej mierze zależy od tego, jak łatwo wpasowuje się w miejsca, gdzie rekruterzy i inni ludzie już patrzą, a dziś to zdecydowanie infrastruktura zbudowana wokół v2.0.

Kiedy v3.0 faktycznie ma znaczenie

v3.0 to nie tylko szum medialny — rozwiązuje realne problemy konkretnych programów:

• Uczelnie i wystawcy objęci wymogami CLR. Jeśli wystawiasz poświadczenia równolegle z formalnym systemem transkryptów albo stanowa/regionalna instytucja edukacyjna wymaga wyjścia zgodnego z CLR 2.0, wbudowana zgodność v3.0 oszczędza ci doklejania pól CLR do Assertion z v2.0.
• Programy nastawione na przechowywanie w cyfrowych portfelach. Jeśli twoi odbiorcy muszą trzymać poświadczenie w aplikacji-portfelu, a nie tylko wyświetlać je na stronie internetowej, natywnie zadziała tam wyłącznie W3C VC, czyli v3.0.
• Wymiana poświadczeń między wystawcami z zaufaniem opartym na DID. Jeśli budujesz sieć albo do niej dołączasz, a tożsamość wystawcy musi być kryptograficznie przenośna, a nie oparta na „zaufaj temu URL-owi”, DID to właściwy prymityw.

Żaden z tych przypadków nie jest typowy dla programu szkoleniowego, bootcampu czy wystawcy poświadczeń rozwoju zawodowego w 2026 roku. Są za to typowe dla instytucji z wymogami compliance lub interoperacyjności, które wprost wskazują na CLR albo W3C VC.

Uproszczone poświadczenie v3.0 pokazuje, jak inaczej wygląda sama koperta danych, nawet jeśli leżące u podstaw dane o osiągnięciu koncepcyjnie opisują tę samą odznakę:

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

Zwróć uwagę, że pole issuer to DID, a nie URL, a cały dokument niesie blok proof zamiast wskaźnika verification. To właśnie te wspomniane wyżej narzędzia do rozwiązywania DID i podpisywania VC — realna praca inżynierska, i praca zmarnowana, jeśli nic po stronie odbiorczej jeszcze z niej nie korzysta.

Powszechne nieporozumienia, które warto wyjaśnić

• „v3.0 jest bezpieczniejsza.” Niekoniecznie — zarówno signed v2.0, jak i v3.0 opierają się na weryfikacji kryptograficznej. Przewagą v3.0 jest ustandaryzowana tożsamość (DID) i interoperacyjność z portfelami, a nie skok bezpieczeństwa względem signed v2.0.
• „v2.0 jest przestarzała.” Nie jest. 1EdTech utrzymuje obie specyfikacje, a v2.0 pozostaje wersją, do której odwołują się platformy i integracje, z jakich wystawcy faktycznie korzystają na co dzień.
• „Musisz wybrać jedną wersję dla całego programu.” Wcale nie. Nic nie stoi na przeszkodzie, żeby wystawca publikował v2.0 do ogólnego użytku i dodał wyjście v3.0 dla konkretnej integracji partnerskiej, która tego wymaga — leżące u podstaw dane o przyznanej odznace się nie zmieniają, zmienia się tylko ich reprezentacja.

Ścieżka migracji (i dlaczego nie musisz wybierać raz na zawsze)

Praktyczny ruch dla niemal każdego wystawcy: wdróż v2.0 już teraz, a v3.0 traktuj jako dodatek, nie zamiennik — dopiero gdy zażąda tego konkretny odbiorca po stronie docelowej. Kilka powodów, dla których to podejście sprawdza się bez zgrzytów:

1. Twoje identyfikatory BadgeClass i Assertion nie muszą się zmieniać, gdy później dodasz wsparcie dla v3.0 — dodajesz drugą, inaczej ukształtowaną reprezentację tej samej odznaki, a nie migrujesz poświadczenia dotychczasowych odbiorców.
2. Weryfikatory rozumiejące tylko v2.0 działają dokładnie tak jak wcześniej.
3. Unikasz budowania infrastruktury DID i pipeline’ów podpisywania VC, zanim pojawi się konkretny wymóg, który ich potrzebuje.

Tej samej logiki używamy wewnętrznie na badges.ninja: każda przyznana odznaka wychodzi jako Open Badge w wersji v2.0 — JSON-LD, weryfikacja hosted pod stałym adresem /certify-badge/award/{guid}, gotowość do LinkedIn Add to Profile od razu z pudełka — bo to pokrywa zdecydowaną większość tego, o co faktycznie proszeni są wystawcy. Jeśli twój program później potrzebuje wyjścia v3.0/CLR dla konkretnego partnera instytucjonalnego, to jest to punktowy dodatek na działającym pipeline v2.0, a nie przepisanie wszystkiego od nowa.

Taka kolejność chroni cię też przed subtelniejszym ryzykiem: zaangażowaniem się w infrastrukturę DID, zanim wiesz, jakiej metody DID naprawdę oczekują twoi partnerzy. Ekosystem VC nie zbiegł się jeszcze do jednej metody DID — w praktyce spotkasz did:web, did:key i metody zakotwiczone w rejestrach rozproszonych (ledger), a wybranie złej metody dla partnera pilotażowego oznacza, że pracę nad tożsamością wystawcy trzeba będzie później powtórzyć. Czekanie na konkretnie nazwany wymóg oznacza, że dowiesz się, jakiej metody naprawdę potrzebujesz, zanim cokolwiek zbudujesz.

Szybki test dla twojego programu

Zadaj sobie te trzy pytania, zanim poświęcisz czas inżynierski na v3.0:

• Czy jakikolwiek odbiorca moich poświadczeń — ATS pracodawcy, komisja licencyjna, instytucja partnerska — wprost wymaga wyjścia zgodnego z CLR 2.0 lub W3C VC? Jeśli nie, v2.0 w zupełności wystarczy.
• Czy moi odbiorcy muszą trzymać to poświadczenie w aplikacji cyfrowego portfela, a nie tylko na profilu internetowym czy LinkedIn? Jeśli nie, v2.0 w zupełności wystarczy.
• Czy buduję infrastrukturę zaufania między wystawcami, w której weryfikacja hosted oparta na URL naprawdę nie wystarcza? Jeśli nie, v2.0 w zupełności wystarczy.

Jeśli trzy razy odpowiedziałeś „nie”, to wdrażając v2.0 w 2026 roku wcale nie zostajesz w tyle — po prostu dopasowujesz specyfikację do ekosystemu, który faktycznie z niej korzysta. Wróć do tego pytania, gdy konkretny partner albo wymóg zgodności wprost zażąda v3.0 — a nie wtedy, gdy poczujesz ogólne przeświadczenie, że „v3 jest nowsza”.

Więcej o tym, jak dane weryfikacyjne odznak wypadają na tle starszych, niestandardowych formatów poświadczeń, znajdziesz w tekście Blockchain Certificates kontra Open Badges, który analizuje kompromisy między weryfikacją a przenośnością z innej perspektywy.

---

Gotowy, by wystawić swoje pierwsze weryfikowalne poświadczenie? Zacznij za darmo na badges.ninja — wizualny kreator, publiczna strona weryfikacyjna, certyfikat PDF, wyjście Open Badge v2.0. Bez karty kredytowej.