Open Badges: otwarty standard weryfikowalnych poświadczeń

Standard rozkłada poświadczenie na trzy części, a ten podział jest sprytniejszy, niż się z początku wydaje. Issuer opisuje, kto wystawia: nazwa, strona, kontakt. BadgeClass opisuje, co jest przyznawane: tytuł poświadczenia, opis, kryteria, obraz. Assertion to wreszcie pojedyncze przyznanie: ta jedna osoba otrzymała tę BadgeClass tego dnia.

Dzięki temu opis typu certyfikatu musi istnieć tylko raz, niezależnie od tego, czy przyznajecie go 20 czy 2000 osobom. Tak wygląda prawdziwa Assertion z naszego systemu, skrócony jest tylko token:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://oneclickbadge.com/ob/assertion/3f9d…",
  "badge": "https://oneclickbadge.com/ob/badge/3f9d…",
  "recipient": {
    "type": "url",
    "hashed": false,
    "identity": "https://oneclickbadge.com/cert/3f9d…"
  },
  "issuedOn": "2026-07-04T18:22:31Z",
  "verification": { "type": "hosted" },
  "evidence": "https://oneclickbadge.com/cert/3f9d…"
}

Dwa szczegóły warte są drugiego spojrzenia. Pole badge to tylko adres: leży tam BadgeClass, która z kolei wskazuje na Issuer, i tak narzędzie sprawdzające przechodzi przez cały łańcuch. A jako recipient stoi tu adres strony certyfikatu; adres e-mail, nawet zahaszowany, nie pojawia się nigdzie. Dokument publiczny obywa się więc bez bezpośrednich danych kontaktowych. Imię i nazwisko osoby stoi na powiązanej stronie certyfikatu, tam, gdzie sama wpisała je przy odbiorze.

Specyfikacja zna dwa sposoby, żeby uczynić Assertion weryfikowalną. Przy podpisanych badge'ach dokument nosi kryptograficzny podpis wystawcy, dowodzi więc sam siebie, ale wymaga zarządzania kluczami po stronie wystawcy. Przy hostowanych badge'ach obowiązuje prostsza zasada: Assertion jest prawdziwa, dopóki daje się pobrać pod własnym adresem id u wystawcy. Sprawdzenie oznacza wtedy po prostu: pobrać URL i porównać.

Metoda hostowana ma niedoceniany atut: czyste unieważnienie. Gdy wystawca wycofuje poświadczenie, ten sam adres od tej chwili odpowiada statusem HTTP 410 i krótkim dokumentem z linią „revoked: true”. Wycofany certyfikat nie milknie po cichu: pod tym samym adresem aktywnie sygnalizuje, że już nie obowiązuje. Tak robimy to również w OneClickBadge, na przykład gdy certyfikat został przez pomyłkę wystawiony dwa razy.

Jeden szczegół standardu jest niemal poetycki: „baking”. Grafika badge'a, zwykle PNG, dostaje swoją Assertion wraz z adresem weryfikacji wbudowaną wprost w plik obrazu, technicznie jako blok tekstowy iTXt ze słowem kluczowym openbadges. Obraz wygląda potem dokładnie tak samo, ale nosi w sobie swoją ścieżkę weryfikacji: kto przeciągnie plik do narzędzia sprawdzającego, trafia na Assertion, przez ile pobrań i czatów obraz by nie wędrował.

Ważna pozostaje kolejność: dowieść może tylko hostowana Assertion. Obraz da się dowolnie kopiować i zmieniać, a odpowiedzią pod adresem poświadczenia steruje wyłącznie wystawca.

Rozprawiamy się tu z najczęstszym nieporozumieniem, które straszy w wielu artykułach: LinkedIn nie czyta metadanych Open Badge. Nie ma tam importu badge'y, automatycznego sprawdzania ani specjalnego symbolu dla zweryfikowanych badge'y. To, co LinkedIn ma, to sekcja profilu „Licencje i certyfikaty” z polami na nazwę, organizację wystawiającą i adres URL. Nic z tego nie oznacza, że LinkedIn coś certyfikuje lub uznaje.

Bezużyteczny dla LinkedIn standard jednak przez to nie jest, wręcz przeciwnie: w polu URL powinien znaleźć się adres poświadczenia. Kto w profilu kliknie „Pokaż poświadczenie”, trafia na stronę certyfikatu, za którą stoi weryfikowalna Assertion. Sam wpis da się przygotować dla odbiorców na jedno kliknięcie, z gotowo wypełnionymi polami formularza. Jak to wygląda z perspektywy uczestników, pokazuje przewodnik po dodawaniu do profilu.

Samodzielne wdrożenie standardu opłaca się nielicznym organizatorom: potrzebowalibyście stale dostępnych punktów końcowych dla Issuer, BadgeClass i każdej pojedynczej Assertion, do tego logiki unieważniania i „upieczonego” obrazu. Dla wydarzeń, webinarów i szkoleń jest gotowa droga: w OneClickBadge projektujecie certyfikat uczestnictwa, a każdy wystawiony egzemplarz dostaje automatycznie swoją hostowaną Assertion, mechanizm unieważniania oraz PDF wraz z obrazem.

Dystrybucja do wielu uczestników odbywa się bez wgrywania listy, przez link do samodzielnego odbioru, który udostępniacie po wydarzeniu. Dlaczego akurat przy temacie poświadczeń jest to też decyzja dotycząca ochrony danych, opisuje strona Certyfikaty dla wielu uczestników.

Wersja 3.0 przenosi standard na W3C Verifiable Credentials, model z podpisami kryptograficznymi i większą kontrolą po stronie odbiorcy. Dla ekosystemów uczelnianych i długowiecznych poświadczeń edukacyjnych to właściwy kierunek. Dla przypadku uczestnictwa w wydarzeniu 2.0 w formie hostowanej jest dziś stanem pragmatycznym: rozumie je każde popularne narzędzie sprawdzające, unieważnianie działa i nikt nie musi zarządzać portfelami ani kluczami. Dlatego stawiamy na 2.0 hosted i spokojnie dalej obserwujemy 3.0.