Open Badges: der offene Standard hinter prüfbaren Nachweisen

Der Standard zerlegt einen Nachweis in drei Teile, und die Trennung ist klüger, als sie zunächst wirkt. Der Issuer beschreibt, wer ausstellt: Name, Website, Kontakt. Die BadgeClass beschreibt, was verliehen wird: Titel des Nachweises, Beschreibung, Kriterien, Bild. Die Assertion schließlich ist die einzelne Verleihung: Diese eine Person hat diese BadgeClass an diesem Datum erhalten.

Dadurch muss die Beschreibung eines Zertifikatstyps nur einmal existieren, egal ob ihr ihn an 20 oder 2.000 Leute verleiht. So sieht eine echte Assertion aus unserem System aus, nur das Token ist gekürzt:

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

Zwei Details lohnen den zweiten Blick. Das Feld badge ist nur eine Adresse: Dort liegt die BadgeClass, die wiederum auf den Issuer zeigt, so hangelt sich ein Prüfwerkzeug durch die ganze Kette. Und als recipient steht hier die Adresse der Zertifikatsseite; eine E-Mail-Adresse, auch eine gehashte, taucht nirgends auf. Das öffentliche Dokument kommt damit ohne direkte Kontaktdaten aus. Der Name der Person steht auf der verlinkten Zertifikatsseite, dort, wo sie ihn beim Abholen selbst eingetragen hat.

Die Spezifikation kennt zwei Wege, eine Assertion prüfbar zu machen. Bei signierten Badges trägt das Dokument eine kryptografische Signatur des Ausstellers, es beweist sich also selbst, braucht dafür aber Schlüsselverwaltung auf Aussteller-Seite. Bei gehosteten Badges gilt eine einfachere Regel: Die Assertion ist echt, solange sie unter ihrer eigenen id-Adresse beim Aussteller abrufbar ist. Prüfen heißt dann schlicht: URL abrufen und vergleichen.

Das gehostete Verfahren hat einen unterschätzten Vorteil: den sauberen Widerruf. Zieht der Aussteller einen Nachweis zurück, antwortet dieselbe Adresse ab sofort mit dem HTTP-Status 410 und einem knappen Dokument mit der Zeile „revoked: true“. Ein zurückgezogenes Zertifikat verschwindet also nicht einfach, es widerspricht aktiv. So machen wir es auch bei OneClickBadge, etwa wenn ein Zertifikat versehentlich doppelt ausgestellt wurde.

Ein Detail des Standards ist fast schon poetisch: das „Baking“. Die Badge-Grafik, meist ein PNG, bekommt ihre Assertion samt Prüfadresse direkt in die Bilddatei eingebettet, technisch als iTXt-Textblock mit dem Schlüsselwort openbadges. Das Bild sieht danach exakt gleich aus, trägt seinen Prüfpfad aber in sich: Wer die Datei in ein Prüfwerkzeug zieht, landet bei der Assertion, egal über wie viele Downloads und Chats das Bild gewandert ist.

Wichtig bleibt die Rangfolge: Beweisen kann nur die gehostete Assertion. Ein Bild lässt sich beliebig kopieren und verändern, die Antwort unter der Nachweis-Adresse kontrolliert allein der Aussteller.

Hier räumen wir mit dem häufigsten Missverständnis auf, das durch viele Artikel geistert: LinkedIn liest keine Open-Badge-Metadaten. Es gibt dort keinen Badge-Import, keine automatische Prüfung, kein spezielles Symbol für verifizierte Badges. Was LinkedIn hat, ist der Profilbereich „Lizenzen und Zertifikate“ mit Feldern für Name, ausstellende Organisation und eine URL. Von LinkedIn zertifiziert oder anerkannt ist dadurch nichts.

Nutzlos für LinkedIn ist der Standard deshalb aber nicht, im Gegenteil: In das URL-Feld gehört die Nachweis-Adresse. Wer im Profil auf „Nachweis anzeigen“ klickt, landet auf der Zertifikatsseite, hinter der die prüfbare Assertion steht. Der Eintrag selbst lässt sich für Empfänger auf einen Klick vorbereiten, mit fertig ausgefüllten Formularfeldern. Wie das aus Sicht der Teilnehmenden aussieht, zeigt der Guide zum Eintragen ins Profil.

Den Standard selbst zu implementieren lohnt sich für die wenigsten Veranstalter: Ihr bräuchtet dauerhaft erreichbare Endpunkte für Issuer, BadgeClass und jede einzelne Assertion, dazu Widerrufs-Logik und ein gebackenes Bild. Für Events, Webinare und Schulungen geht es fertig: Bei OneClickBadge gestaltet ihr ein Teilnahmezertifikat, und jedes ausgestellte Exemplar bekommt automatisch seine gehostete Assertion, den Widerrufs-Mechanismus und das PDF samt Bild dazu.

Die Verteilung an viele Teilnehmende läuft dabei ohne Listen-Upload, über einen Selbstabhol-Link, den ihr nach dem Event teilt. Warum das gerade beim Nachweis-Thema auch eine Datenschutz-Entscheidung ist, steht auf der Seite Zertifikate für viele Teilnehmende.

Die Version 3.0 stellt den Standard auf W3C Verifiable Credentials um, ein Modell mit kryptografischen Signaturen und mehr Kontrolle beim Empfänger. Für Hochschul-Ökosysteme und langlebige Bildungsnachweise ist das die richtige Richtung. Für den Anwendungsfall Event-Teilnahme ist 2.0 in der gehosteten Form heute der pragmatische Stand: Jedes gängige Prüfwerkzeug versteht es, der Widerruf funktioniert, und niemand muss Wallets oder Schlüssel verwalten. Wir setzen deshalb auf 2.0 hosted und beobachten 3.0 in Ruhe weiter.