Open Badge v2 vs v3 spiegato: quale specifica dovresti usare oggi?

Se stai impostando un programma di certificazione digitale nel 2026, ti imbatterai in questa domanda entro la prima ora di ricerca: dovresti emettere Open Badge v2.0 o il più recente v3.0? La risposta onesta è “dipende da chi deve leggere le tue credenziali” — ma non è una risposta soddisfacente se sei tu a dover decidere entro venerdì. Vediamo quindi cosa è cambiato davvero tra le due specifiche, chi supporta cosa oggi, e quale dovrebbero adottare subito la maggior parte degli emittenti.

Cosa è realmente Open Badge v2.0

Open Badge v2.0 è la specifica di 1EdTech (in precedenza IMS Global) che rappresenta la spina dorsale della certificazione digitale dal 2017. È costruita su JSON-LD ed è strutturata attorno a tre oggetti collegati tra loro:

• IssuerOrg — chi ha emesso la credenziale (nome, URL, email, logo)
• BadgeClass — il tipo di credenziale in sé (nome, descrizione, criteri, immagine)
• Assertion — l’assegnazione specifica a uno specifico destinatario (identità del destinatario, data issuedOn, evidenze, metodo di verifica)

L’Assertion di un destinatario punta a una BadgeClass, che a sua volta punta a un IssuerOrg. La verifica avviene in uno di due modi: hosted (il verificatore recupera il JSON dell’Assertion live da un URL stabile e si fida del dominio) oppure signed (l’Assertion porta con sé una firma JWS che il verificatore controlla rispetto alla chiave pubblica pubblicata dall’emittente). La maggior parte delle piattaforme, badges.ninja compresa, usa di default la verifica hosted con l’opzione signed disponibile, perché hosted è più semplice da implementare ed è più facile da controllare a colpo d’occhio per un essere umano.

Ecco un’Assertion v2.0 ridotta all’essenziale, il tipo di risposta che otterresti da una chiamata 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" }
}

Questa struttura è il motivo per cui v2.0 è diventato lo standard de facto: è abbastanza semplice da implementare in un pomeriggio, ed è ciò che quasi ogni consumatore di dati sui badge si aspetta di vedere.

Verifica hosted vs signed in v2.0

Vale la pena capire le due modalità di verifica all’interno dello stesso v2.0, perché spesso si confonde “v2.0 è meno sicuro di v3.0” con “la verifica hosted è meno sicura della signed”. Non sono la stessa cosa.

• Hosted — il campo verification.type è "hosted", e l’id dell’Assertion è un URL live. Un verificatore recupera quell’URL e controlla che la risposta corrisponda; la fiducia deriva dal controllo del dominio (ad esempio, solo badges.ninja può pubblicare su badges.ninja/certify-badge/award/...). È ciò che usano la maggior parte delle pagine di verifica rivolte agli utenti finali, perché un essere umano può semplicemente cliccare sul link.
• Signed — il campo verification.type è "signed", e l’Assertion porta con sé (o referenzia) una firma JWS sul payload. Un verificatore risolve la chiave pubblica dell’emittente e controlla la firma indipendentemente dal fatto che un URL sia raggiungibile. Questo è più vicino nello spirito al modello di v3.0, solo senza il livello dei DID.

Un controllo minimo di verifica signed in Node ha questo aspetto:

import { jwtVerify, importJWK } from 'jose';

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

Se al tuo programma interessa che le credenziali restino verificabili anche dopo che la tua API va offline per manutenzione, signed v2.0 ti offre gran parte del vantaggio di durabilità di v3.0 senza dover adottare i DID.

Cosa cambia con Open Badge v3.0

Open Badge v3.0 è una riscrittura basata sul W3C Verifiable Credentials (VC) Data Model, non un aggiornamento incrementale della struttura JSON-LD di v2.0. Le differenze che contano nella pratica:

• Firma crittografica di default. Ogni credenziale v3.0 è una VC firmata — non esiste un fallback “hosted, fidati dell’URL”. La verifica è sempre matematica, non basata sul dominio.
• Identità dell’emittente basata su DID. Invece di un oggetto IssuerOrg con URL ed email, l’emittente è identificato da un Decentralized Identifier (DID), che si risolve in un documento con chiave pubblica.
• Allineamento con il Comprehensive Learner Record (CLR) 2.0. v3.0 è stato progettato per interoperare con CLR, quindi una singola credenziale può contenere sia i dati sul risultato ottenuto sia il tipo di dettaglio del transcript strutturato che i consumatori CLR si aspettano (competenze, risultati delle valutazioni, contesto di termine/corso).
• Compatibilità con i wallet digitali. Poiché le credenziali v3.0 sono VC standard del W3C, possono essere conservate in wallet di identità allo stesso modo di una patente di guida o di un certificato vaccinale — non solo mostrate su una pagina web.

In breve: v2.0 risponde alla domanda “un essere umano o uno script semplice possono verificare questa credenziale?”, mentre v3.0 risponde a “questa credenziale può interoperare con il più ampio ecosistema delle verifiable credentials — wallet, DID, learner record formali?”.

Confronto diretto

Perché la base installata gira ancora su v2.0

Questo è l’elemento che fa pendere la decisione per la maggior parte dei programmi: i posti dove i tuoi destinatari vogliono davvero che compaiano le loro credenziali si aspettano ancora v2.0. Il flusso Add to Profile di LinkedIn, Credly, Badgr e la stragrande maggioranza delle integrazioni con i sistemi di applicant tracking analizzano la struttura Assertion/BadgeClass di v2.0. Se il tuo obiettivo è “i destinatari possono pubblicarlo su LinkedIn e i recruiter possono cliccare per verificarlo”, v2.0 non è un formato legacy a cui sei costretto — è il formato che l’ecosistema parla attualmente.

Abbiamo trattato esattamente questa tensione dal punto di vista del destinatario in LinkedIn Skill Assessments vs Open Badges — il valore di un badge è in gran parte funzione di quanto facilmente si integri nei posti dove recruiter e colleghi già guardano, e oggi quell’infrastruttura è schiacciantemente modellata su v2.0.

Quando v3.0 conta davvero

v3.0 non è solo hype — risolve problemi reali per programmi specifici:

• Università ed emittenti soggetti a obblighi CLR. Se emetti credenziali insieme a un sistema formale di transcript, o se un ente educativo statale/regionale richiede un output compatibile con CLR 2.0, l’allineamento integrato di v3.0 ti evita di dover innestare campi CLR su un’Assertion v2.0.
• Programmi orientati alla conservazione in wallet digitali. Se i tuoi destinatari devono conservare la credenziale in un’app wallet e non semplicemente mostrarla su una pagina web, solo una VC W3C (cioè v3.0) funzionerà lì in modo nativo.
• Scambio di credenziali tra emittenti diversi con fiducia basata su DID. Se stai costruendo o entrando in una rete in cui l’identità dell’emittente deve essere portabile in modo crittografico invece che basata su “fidati di questo URL”, i DID sono lo strumento primitivo giusto.

Nessuno di questi è un caso comune per un programma di formazione, un bootcamp o un emittente di sviluppo professionale nel 2026. Sono comuni per istituzioni con requisiti di conformità o interoperabilità che nominano esplicitamente CLR o le VC W3C.

Una credenziale v3.0 ridotta all’essenziale mostra quanto sia diverso l’involucro, anche quando i dati di achievement sottostanti rappresentano concettualmente lo stesso riconoscimento:

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

Nota che il campo issuer è un DID, non un URL, e l’intero documento porta un blocco proof invece di un puntatore verification. Questo è il lavoro di risoluzione DID + strumenti di firma VC menzionato sopra — vero lavoro ingegneristico, che però è sprecato se ancora nessun consumatore a valle lo utilizza davvero.

Idee sbagliate comuni che vale la pena chiarire

• “v3.0 è più sicuro.” Non necessariamente — sia v2.0 signed sia v3.0 si basano sulla verifica crittografica. Il vantaggio di v3.0 è l’identità standardizzata (DID) e l’interoperabilità con i wallet, non un miglioramento della sicurezza rispetto a v2.0 signed.
• “v2.0 è deprecato.” Non lo è. 1EdTech mantiene entrambe le specifiche, e v2.0 resta la versione a cui fanno riferimento le piattaforme e le integrazioni che gli emittenti usano davvero ogni giorno.
• “Devi sceglierne una sola per l’intero programma.” Non è vero. Nulla impedisce a un emittente di pubblicare in v2.0 per l’uso generale e aggiungere un output v3.0 per una specifica integrazione con un partner che lo richiede — i dati del riconoscimento sottostante non cambiano, cambia solo la rappresentazione.

Il percorso di migrazione (e perché non devi scegliere per sempre)

La mossa pratica per quasi ogni emittente: rilascia v2.0 adesso, e tratta v3.0 come un’aggiunta, non una sostituzione, quando un consumatore a valle specifico lo richiede. Alcuni motivi per cui questo approccio funziona bene:

1. I tuoi ID di BadgeClass e Assertion non devono cambiare quando in seguito aggiungi il supporto v3.0 — stai aggiungendo una seconda rappresentazione, con una forma diversa, dello stesso riconoscimento sottostante, non stai migrando le credenziali dei destinatari esistenti.
2. I verificatori che comprendono solo v2.0 continuano a funzionare esattamente come prima.
3. Eviti di costruire infrastrutture DID e pipeline di firma VC prima di avere un requisito concreto che le richieda.

È la stessa logica che usiamo internamente in badges.ninja: ogni riconoscimento esce come Open Badge v2.0 — JSON-LD, verifica hosted su un URL stabile /certify-badge/award/{guid}, pronto per LinkedIn Add to Profile fin da subito — perché è ciò che copre la stragrande maggioranza di quello che agli emittenti viene effettivamente chiesto di produrre. Se il tuo programma in seguito ha bisogno di un output v3.0/CLR per un partner istituzionale specifico, si tratta di un’aggiunta circoscritta sopra a una pipeline v2.0 funzionante, non di una riscrittura.

Questa sequenza ti protegge anche da un rischio più sottile: impegnarti in un’infrastruttura DID prima di sapere quale metodo DID si aspettano davvero i tuoi partner. L’ecosistema VC non è ancora convergito su un unico metodo DID — did:web, did:key e metodi ancorati a ledger compaiono tutti nella pratica, e scegliere quello sbagliato per un partner pilota significa dover rifare in seguito il lavoro sull’identità dell’emittente. Aspettare un requisito nominato esplicitamente significa scoprire di quale metodo hai davvero bisogno prima di costruire qualsiasi cosa.

Un rapido controllo di realtà per il tuo programma

Fatti queste tre domande prima di investire tempo di sviluppo su v3.0:

• Qualche consumatore delle mie credenziali — un ATS aziendale, un ente di certificazione, un’istituzione partner — richiede esplicitamente un output CLR 2.0 o VC W3C? Se no, v2.0 ti copre.
• I miei destinatari hanno bisogno di conservare questa credenziale in un’app wallet digitale, e non solo in un profilo web o su LinkedIn? Se no, v2.0 ti copre.
• Sto costruendo un’infrastruttura di fiducia tra emittenti diversi in cui la verifica hosted basata su URL genuinamente non è sufficiente? Se no, v2.0 ti copre.

Se hai risposto “no” tre volte, non sei affatto in ritardo rilasciando v2.0 nel 2026 — stai semplicemente allineando la specifica all’ecosistema che la consuma davvero. Riconsidera la questione quando un partner specifico o un requisito di conformità chiederà v3.0 esplicitamente per nome, non sulla base di una sensazione generica del tipo “v3 è più nuovo”.

Per saperne di più su come i dati di verifica dei badge reggono il confronto con formati di credenziali più vecchi e non standard, vedi Blockchain Certificates vs Open Badges, che approfondisce i compromessi tra verifica e portabilità da un’angolazione diversa.

---

Pronto a emettere la tua prima credenziale verificabile? Inizia gratis su badges.ninja — designer visuale, pagina di verifica pubblica, certificato PDF, output Open Badge v2.0. Nessuna carta di credito richiesta.