Open Badge v2 vs v3 erklärt: Welche Spezifikation solltest du heute nutzen?

Wenn du 2026 ein Zertifizierungsprogramm aufsetzt, stößt du innerhalb der ersten Rechercheminute auf diese Frage: solltest du Open Badge v2.0 oder das neuere v3.0 ausstellen? Die ehrliche Antwort lautet „es kommt darauf an, wer deine Credentials lesen muss” — aber das ist wenig befriedigend, wenn du bis Freitag entscheiden musst. Schauen wir uns also an, was sich zwischen den beiden Spezifikationen tatsächlich geändert hat, wer heute was unterstützt, und welche Variante die meisten Aussteller jetzt ausliefern sollten.

Was Open Badge v2.0 tatsächlich ist

Open Badge v2.0 ist die 1EdTech-Spezifikation (früher IMS Global), die seit 2017 das Rückgrat digitaler Zertifizierung bildet. Sie basiert auf JSON-LD und ist um drei verknüpfte Objekte herum strukturiert:

• IssuerOrg — wer das Credential ausgestellt hat (Name, URL, E-Mail, Logo)
• BadgeClass — der Credential-Typ selbst (Name, Beschreibung, Kriterien, Bild)
• Assertion — die konkrete Vergabe an einen konkreten Empfänger (Empfängeridentität, Ausstellungsdatum, Nachweise, Verifizierungsmethode)

Die Assertion eines Empfängers verweist auf eine BadgeClass, die wiederum auf eine IssuerOrg zurückverweist. Die Verifizierung erfolgt auf zwei Arten: gehostet (der Prüfer ruft die live Assertion-JSON von einer stabilen URL ab und vertraut der Domain) oder signiert (die Assertion trägt eine JWS-Signatur, die der Prüfer gegen den veröffentlichten öffentlichen Schlüssel des Ausstellers prüft). Die meisten Plattformen, einschließlich badges.ninja, setzen standardmäßig auf gehostete Verifizierung mit signiert als Option, weil gehostet einfacher zu implementieren und für einen Menschen leichter stichprobenartig zu prüfen ist.

Hier eine gekürzte v2.0-Assertion, wie du sie von einem GET /awards/{id}-Aufruf zurückbekommen würdest:

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

Diese Struktur ist der Grund, warum v2.0 zum De-facto-Standard geworden ist: Sie lässt sich an einem Nachmittag implementieren, und es ist genau das, was so gut wie jeder Konsument von Badge-Daten erwartet.

Gehostete vs. signierte Verifizierung in v2.0

Es lohnt sich, die zwei Verifizierungsmodi innerhalb von v2.0 selbst zu verstehen, denn oft wird „v2.0 ist weniger sicher als v3.0” mit „gehostete Verifizierung ist weniger sicher als signierte” gleichgesetzt. Das sind aber nicht dieselben Achsen.

• Gehostet — der verification.type ist "hosted", und die id der Assertion ist eine live URL. Ein Prüfer ruft diese URL ab und prüft, ob die Antwort übereinstimmt; Vertrauen entsteht dadurch, dass jemand die Domain kontrolliert (z. B. kann nur badges.ninja unter badges.ninja/certify-badge/award/... veröffentlichen). Das nutzen die meisten verbraucherorientierten Verifizierungsseiten, weil ein Mensch einfach auf den Link klicken kann.
• Signiert — der verification.type ist "signed", und die Assertion trägt (oder referenziert) eine JWS-Signatur über die Nutzdaten. Ein Prüfer löst den öffentlichen Schlüssel des Ausstellers auf und prüft die Signatur unabhängig davon, ob eine URL erreichbar ist. Das kommt dem Modell von v3.0 im Grundgedanken schon recht nahe — nur ohne die DID-Ebene.

Eine minimale Prüfung der signierten Verifizierung in Node sieht so aus:

import { jwtVerify, importJWK } from 'jose';

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

Wenn deinem Programm wichtig ist, dass Credentials auch dann verifizierbar bleiben, wenn deine API wegen Wartungsarbeiten offline ist, bringt dir signiertes v2.0 den größten Teil des Haltbarkeitsvorteils von v3.0 — ganz ohne DIDs einzuführen.

Was Open Badge v3.0 ändert

Open Badge v3.0 ist ein Neuaufbau auf Basis des W3C-Verifiable-Credentials-Datenmodells (VC), kein inkrementelles Update der JSON-LD-Struktur von v2.0. Die Unterschiede, die in der Praxis zählen:

• Kryptografische Signierung standardmäßig. Jedes v3.0-Credential ist eine signierte VC — es gibt kein „gehostet, der URL vertrauen”-Fallback. Verifizierung ist immer mathematisch, nicht domänenbasiert.
• DID-basierte Ausstelleridentität. Statt eines IssuerOrg-Objekts mit URL und E-Mail wird der Aussteller über einen Decentralized Identifier (DID) identifiziert, der zu einem Dokument mit öffentlichem Schlüssel aufgelöst wird.
• Ausrichtung am Comprehensive Learner Record (CLR) 2.0. v3.0 wurde so entwickelt, dass es mit CLR zusammenspielt, sodass ein einzelnes Credential sowohl Achievement-Daten als auch die Art strukturierter Transkriptdetails tragen kann, die CLR-Konsumenten erwarten (Kompetenzen, Bewertungsergebnisse, Semester-/Kurskontext).
• Kompatibilität mit digitalen Wallets. Da v3.0-Credentials standardmäßige W3C-VCs sind, können sie in Identity-Wallets gehalten werden — genau wie ein Führerschein oder ein Impfnachweis — und nicht nur auf einer Webseite angezeigt werden.

Kurz gesagt: v2.0 beantwortet die Frage „kann ein Mensch oder ein einfaches Skript dieses Credential verifizieren”, und v3.0 beantwortet die Frage „kann dieses Credential mit dem breiteren Verifiable-Credentials-Ökosystem zusammenspielen — Wallets, DIDs, formale Learner Records”.

Direkter Vergleich

Warum die installierte Basis noch auf v2.0 läuft

Das ist der Punkt, der die Entscheidung für die meisten Programme kippt: die Orte, an denen deine Empfänger ihre Credentials tatsächlich zeigen wollen, erwarten immer noch v2.0. Der „Zum Profil hinzufügen”-Flow von LinkedIn, Credly, Badgr und die überwiegende Mehrheit der Bewerbermanagement-System-Integrationen (ATS) parsen die Assertion-/BadgeClass-Struktur von v2.0. Wenn dein Ziel ist „Empfänger können das auf LinkedIn posten, und Recruiter können durchklicken, um es zu verifizieren”, ist v2.0 kein Legacy-Format, an dem du festhängst — es ist das Format, das das Ökosystem heute spricht.

Wir haben genau dieses Spannungsfeld aus Empfängersicht in LinkedIn Skill Assessments vs Open Badges behandelt — der Wert eines Badges hängt maßgeblich davon ab, wie leicht es sich in die Orte einfügt, an denen Recruiter und Kollegen ohnehin schon schauen, und das ist heute überwiegend v2.0-geprägte Infrastruktur.

Wann v3.0 tatsächlich wichtig ist

v3.0 ist kein Hype — es löst reale Probleme für bestimmte Programme:

• Universitäten und Aussteller mit CLR-Vorgaben. Wenn du parallel zu einem formalen Transkriptsystem ausstellst, oder eine staatliche/regionale Bildungsbehörde CLR-2.0-kompatible Ausgaben verlangt, erspart dir die eingebaute Ausrichtung von v3.0, CLR-Felder nachträglich an eine v2.0-Assertion anzuflanschen.
• Programme, die digitale Wallet-Speicherung anstreben. Wenn deine Empfänger das Credential in einer Wallet-App halten müssen, statt es nur auf einer Webseite anzuzeigen, funktioniert nur eine W3C-VC (also v3.0) dafür nativ.
• Aussteller­übergreifender Credential-Austausch mit DID-basiertem Vertrauen. Wenn du ein Netzwerk aufbaust oder ihm beitrittst, in dem die Ausstelleridentität kryptografisch portabel sein muss statt „dieser URL vertrauen”, sind DIDs das richtige Grundelement.

Keiner dieser Fälle ist 2026 der Normalfall für ein Trainingsprogramm, ein Bootcamp oder einen Weiterbildungs-Aussteller. Sie sind der Normalfall für Institutionen mit Compliance- oder Interoperabilitätsanforderungen, die CLR oder W3C-VCs ausdrücklich beim Namen nennen.

Ein gekürztes v3.0-Credential zeigt, wie unterschiedlich die Hülle aussieht, selbst wenn die zugrunde liegenden Achievement-Daten konzeptionell dieselbe Vergabe sind:

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

Beachte, dass das issuer-Feld eine DID ist, keine URL, und dass das gesamte Dokument einen proof-Block statt eines verification-Zeigers trägt. Das ist die oben erwähnte DID-Auflösung plus VC-Signierungswerkzeug — echte Entwicklungsarbeit, und Arbeit, die verschwendet ist, wenn nachgelagert noch niemand sie konsumiert.

Verbreitete Missverständnisse, die man klarstellen sollte

• „v3.0 ist sicherer.” Nicht unbedingt — signiertes v2.0 und v3.0 beruhen beide auf kryptografischer Verifizierung. Der Vorteil von v3.0 liegt in standardisierter Identität (DIDs) und Wallet-Interoperabilität, nicht in einem Sicherheits-Upgrade gegenüber signiertem v2.0.
• „v2.0 ist veraltet.” Ist es nicht. 1EdTech pflegt beide Spezifikationen, und v2.0 bleibt die Version, auf die sich die Plattformen und Integrationen beziehen, die Aussteller tagtäglich tatsächlich nutzen.
• „Man muss sich für das gesamte Programm auf eine Variante festlegen.” Musst du nicht. Nichts hindert einen Aussteller daran, v2.0 für den allgemeinen Gebrauch zu veröffentlichen und v3.0-Ausgaben für eine bestimmte Partnerintegration hinzuzufügen, die das verlangt — die zugrunde liegenden Award-Daten ändern sich nicht, nur die Darstellung.

Der Migrationspfad (und warum du dich nicht für immer festlegen musst)

Der praktische Weg für so gut wie jeden Aussteller: liefere jetzt v2.0 aus und behandle v3.0 als Ergänzung, nicht als Ersatz, sobald ein konkreter nachgelagerter Konsument es verlangt. Ein paar Gründe, warum das sauber funktioniert:

1. Deine BadgeClass- und Assertion-IDs müssen sich nicht ändern, wenn du später v3.0-Unterstützung hinzufügst — du fügst eine zweite, anders geformte Darstellung derselben zugrunde liegenden Vergabe hinzu, du migrierst nicht die Credentials bestehender Empfänger.
2. Prüfer, die nur v2.0 verstehen, funktionieren genau wie zuvor weiter.
3. Du vermeidest es, DID-Infrastruktur und VC-Signierungs-Pipelines aufzubauen, bevor du eine konkrete Anforderung hast, die sie tatsächlich braucht.

Das ist dieselbe Logik, die wir intern bei badges.ninja verwenden: Jede Vergabe geht als v2.0-Open-Badge hinaus — JSON-LD, gehostete Verifizierung unter einer stabilen /certify-badge/award/{guid}-URL, sofort einsatzbereit für LinkedIn „Zum Profil hinzufügen” — weil das die überwältigende Mehrheit dessen abdeckt, was Aussteller tatsächlich gefragt werden zu liefern. Wenn dein Programm später v3.0-/CLR-Ausgaben für einen bestimmten institutionellen Partner braucht, ist das eine abgegrenzte Ergänzung auf einer funktionierenden v2.0-Pipeline, kein Neuaufbau.

Diese Reihenfolge schützt dich außerdem vor einem subtileren Risiko: dich auf DID-Infrastruktur festzulegen, bevor du weißt, welche DID-Methode deine Partner tatsächlich erwarten. Das VC-Ökosystem hat sich nicht auf eine DID-Methode geeinigt — did:web, did:key und ledger-verankerte Methoden tauchen alle in freier Wildbahn auf, und die falsche Wahl für einen Pilotpartner zu treffen bedeutet, die Ausstelleridentitätsarbeit später zu wiederholen. Wer wartet, bis eine konkrete Anforderung genannt wird, findet heraus, welche Methode wirklich gebraucht wird, bevor irgendetwas gebaut wird.

Ein schneller Realitätscheck für dein eigenes Programm

Stell dir diese drei Fragen, bevor du Entwicklungszeit in v3.0 investierst:

• Verlangt irgendein Konsument deiner Credentials — ein Arbeitgeber-ATS, eine Zulassungsstelle, eine Partnerinstitution — ausdrücklich CLR-2.0- oder W3C-VC-Ausgaben? Wenn nein, deckt dich v2.0 ab.
• Müssen deine Empfänger dieses Credential in einer digitalen Wallet-App halten, nicht nur in einem Webprofil oder auf LinkedIn? Wenn nein, deckt dich v2.0 ab.
• Baust du aussteller­übergreifende Vertrauensinfrastruktur auf, bei der URL-basierte gehostete Verifizierung wirklich nicht ausreicht? Wenn nein, deckt dich v2.0 ab.

Wenn du dreimal „nein” geantwortet hast, hängst du nicht hinterher, weil du 2026 v2.0 ausgeliefert hast — du passt die Spezifikation an das Ökosystem an, das sie tatsächlich konsumiert. Stell die Frage neu, sobald ein konkreter Partner oder eine Compliance-Anforderung v3.0 namentlich verlangt, nicht aufgrund eines allgemeinen Gefühls, dass „v3 neuer ist”.

Mehr dazu, wie Badge-Verifizierungsdaten im Vergleich zu älteren, nicht standardisierten Credential-Formaten abschneiden, findest du in Blockchain Certificates vs Open Badges, das die Verifizierungs- und Portabilitäts-Kompromisse aus einem anderen Blickwinkel beleuchtet.

---

Bereit, dein erstes verifizierbares Credential auszustellen? Kostenlos starten bei badges.ninja — visueller Designer, öffentliche Verifizierungsseite, PDF-Zertifikat, Open-Badge-v2.0-Ausgabe. Keine Kreditkarte erforderlich.