Open Badge v2 vs v3 explicado: qual especificação você deveria usar hoje?

Se você está montando um programa de credenciamento em 2026, vai esbarrar nessa pergunta já na primeira hora de pesquisa: você deveria emitir Open Badge v2.0 ou o v3.0, mais novo? A resposta honesta é “depende de quem vai ter que ler suas credenciais” — mas isso não ajuda muito se é você quem precisa decidir até sexta-feira. Então vamos passar pelo que realmente mudou entre as duas especificações, quem dá suporte a quê hoje, e qual a maioria dos emissores deveria usar agora mesmo.

O que o Open Badge v2.0 realmente é

Open Badge v2.0 é a especificação da 1EdTech (antiga IMS Global) que tem sido a espinha dorsal do credenciamento digital desde 2017. Ela é construída em cima de JSON-LD e estruturada em torno de três objetos vinculados:

• IssuerOrg — quem emitiu a credencial (nome, URL, e-mail, logo)
• BadgeClass — o tipo de credencial em si (nome, descrição, critérios, imagem)
• Assertion — a concessão específica a um destinatário específico (identidade do destinatário, data issuedOn, evidência, método de verificação)

O Assertion de um destinatário aponta para um BadgeClass, que por sua vez aponta para um IssuerOrg. A verificação acontece de duas formas: hosted (o verificador busca o Assertion JSON ao vivo em uma URL estável e confia no domínio) ou signed (o Assertion carrega uma assinatura JWS que o verificador confere contra a chave pública publicada do emissor). A maioria das plataformas, incluindo a badges.ninja, usa hosted por padrão, com signed como opção, porque hosted é mais simples de implementar e mais fácil de conferir manualmente.

Aqui está um Assertion v2.0 resumido, o tipo de coisa que você receberia de uma chamada 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" }
}

Essa estrutura é o motivo pelo qual v2.0 se tornou o padrão de fato: é simples o suficiente para implementar em uma tarde, e é o que praticamente todo consumidor de dados de badge espera ver.

Verificação hosted vs signed no v2.0

Vale a pena entender os dois modos de verificação dentro do v2.0, porque as pessoas costumam confundir “v2.0 é menos seguro que v3.0” com “verificação hosted é menos segura que signed”. Não são o mesmo eixo.

• Hosted — o verification.type é "hosted", e o id do Assertion é uma URL ao vivo. Um verificador busca essa URL e confere se a resposta bate; a confiança vem de controlar o domínio (por exemplo, só a badges.ninja pode publicar em badges.ninja/certify-badge/award/...). É isso que a maioria das páginas de verificação voltadas ao público usa, porque qualquer pessoa pode simplesmente clicar no link.
• Signed — o verification.type é "signed", e o Assertion carrega (ou referencia) uma assinatura JWS sobre o payload. Um verificador resolve a chave pública do emissor e confere a assinatura independentemente de qualquer URL estar acessível. Isso é mais próximo em espírito do modelo do v3.0, só que sem a camada de DID.

Uma verificação signed mínima em Node se parece com isso:

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 o seu programa se importa com credenciais continuarem verificáveis mesmo depois que sua API sair do ar para manutenção, o v2.0 signed te dá a maior parte do benefício de durabilidade do v3.0 sem precisar adotar DIDs.

O que o Open Badge v3.0 muda

Open Badge v3.0 é uma reescrita em cima do W3C Verifiable Credentials (VC) Data Model, não uma atualização incremental da estrutura JSON-LD do v2.0. As diferenças que importam na prática:

• Assinatura criptográfica por padrão. Toda credencial v3.0 é uma VC assinada — não existe a alternativa “hosted, confie na URL”. A verificação é sempre matemática, não baseada em domínio.
• Identidade do emissor baseada em DID. Em vez de um objeto IssuerOrg com URL e e-mail, o emissor é identificado por um Identificador Descentralizado (DID), que resolve para um documento de chave pública.
• Alinhamento com o Comprehensive Learner Record (CLR) 2.0. O v3.0 foi projetado para interoperar com o CLR, então uma única credencial pode carregar dados de conquista mais o tipo de detalhe de histórico estruturado que os consumidores de CLR esperam (competências, resultados de avaliação, contexto de disciplina/período).
• Compatibilidade com carteiras digitais. Como as credenciais v3.0 são VCs padrão do W3C, elas podem ser guardadas em carteiras de identidade da mesma forma que uma carteira de motorista ou um comprovante de vacinação — não só exibidas em uma página web.

Resumindo: v2.0 responde “uma pessoa ou um script simples consegue verificar essa credencial”, e v3.0 responde “essa credencial consegue interoperar com o ecossistema mais amplo de credenciais verificáveis — carteiras, DIDs, históricos formais de aprendizagem”.

Comparação lado a lado

Por que a base instalada ainda roda em v2.0

Essa é a parte que pesa na decisão para a maioria dos programas: os lugares onde seus destinatários realmente querem que suas credenciais apareçam ainda esperam v2.0. O fluxo Add to Profile do LinkedIn, a Credly, a Badgr e a grande maioria das integrações de sistemas de rastreamento de candidatos (ATS) fazem parse da estrutura Assertion/BadgeClass do v2.0. Se o seu objetivo é “os destinatários poderem publicar isso no LinkedIn e os recrutadores poderem clicar para verificar”, v2.0 não é um formato legado do qual você está preso — é o formato que o ecossistema fala atualmente.

Cobrimos essa mesma tensão pelo lado do destinatário em LinkedIn Skill Assessments vs Open Badges — o valor de um badge é, em boa parte, função de quão fácil ele se encaixa nos lugares onde recrutadores e colegas já olham, e hoje isso é, de forma esmagadora, infraestrutura no formato v2.0.

Quando o v3.0 realmente importa

O v3.0 não é só modismo — ele resolve problemas reais para programas específicos:

• Universidades e emissores sob exigências de CLR. Se você emite junto com um sistema formal de histórico escolar, ou um órgão educacional estadual/regional exige saída compatível com CLR 2.0, o alinhamento nativo do v3.0 evita que você precise encaixar campos de CLR à força em um Assertion v2.0.
• Programas voltados para armazenamento em carteira digital. Se seus destinatários precisam guardar a credencial em um app de carteira em vez de só exibi-la em uma página web, só uma VC do W3C (ou seja, v3.0) vai funcionar de forma nativa ali.
• Troca de credenciais entre emissores com confiança baseada em DID. Se você está construindo ou entrando em uma rede em que a identidade do emissor precisa ser portátil de forma criptográfica em vez de “confie nesta URL”, DIDs são a primitiva certa.

Nenhum desses é um caso comum para um programa de treinamento, um bootcamp ou um emissor de desenvolvimento profissional em 2026. São comuns em instituições com requisitos de conformidade ou interoperabilidade que citam especificamente CLR ou VCs do W3C.

Uma credencial v3.0 resumida mostra o quanto o envelope muda, mesmo quando os dados de conquista subjacentes são conceitualmente a mesma concessão:

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

Repare que o campo issuer é um DID, não uma URL, e que o documento inteiro carrega um bloco proof em vez de um ponteiro verification. Isso é a resolução de DID mais as ferramentas de assinatura de VC mencionadas acima — trabalho de engenharia de verdade, e trabalho desperdiçado se ninguém do outro lado ainda consome isso.

Ideias equivocadas que vale a pena esclarecer

• “v3.0 é mais seguro.” Não necessariamente — v2.0 signed e v3.0 dependem ambos de verificação criptográfica. A vantagem do v3.0 é a identidade padronizada (DIDs) e a interoperabilidade com carteiras, não uma melhoria de segurança sobre v2.0 signed.
• “v2.0 está obsoleto.” Não está. A 1EdTech mantém as duas especificações, e v2.0 continua sendo a versão referenciada pelas plataformas e integrações que os emissores realmente usam no dia a dia.
• “Você tem que escolher uma para o programa inteiro.” Não precisa. Nada impede um emissor de publicar v2.0 para uso geral e adicionar saída v3.0 para uma integração específica com um parceiro que exija isso — os dados da concessão subjacente não mudam, só a representação.

O caminho de migração (e por que você não precisa escolher para sempre)

O movimento prático para praticamente todo emissor: entregue v2.0 agora, e trate v3.0 como uma adição, não uma substituição, quando um consumidor específico do outro lado exigir. Alguns motivos pelos quais isso funciona bem:

1. Os IDs do seu BadgeClass e Assertion não precisam mudar quando você adicionar suporte a v3.0 mais tarde — você está adicionando uma segunda representação, com formato diferente, da mesma concessão subjacente, não migrando as credenciais dos destinatários existentes.
2. Verificadores que só entendem v2.0 continuam funcionando exatamente como antes.
3. Você evita construir infraestrutura de DID e pipelines de assinatura de VC antes de ter um requisito concreto que precise deles.

Essa é a mesma lógica que usamos internamente na badges.ninja: toda concessão sai como um Open Badge v2.0 — JSON-LD, verificação hosted em uma URL estável /certify-badge/award/{guid}, pronto para o Add to Profile do LinkedIn de fábrica — porque isso cobre a grande maioria do que os emissores realmente precisam produzir. Se o seu programa depois precisar de saída v3.0/CLR para um parceiro institucional específico, isso é uma adição pontual em cima de um pipeline v2.0 que já funciona, não uma reescrita.

Esse sequenciamento também te protege de um risco mais sutil: se comprometer com infraestrutura de DID antes de saber qual método de DID seus parceiros realmente esperam. O ecossistema de VC ainda não convergiu para um único método de DID — did:web, did:key e métodos ancorados em ledger aparecem todos na prática, e escolher o errado para um parceiro piloto significa refazer depois o trabalho de identidade do emissor. Esperar por um requisito nomeado significa descobrir qual método você realmente precisa antes de construir qualquer coisa.

Um teste rápido para o seu próprio programa

Faça essas três perguntas antes de gastar tempo de engenharia com v3.0:

• Algum consumidor das suas credenciais — um ATS de um empregador, um conselho de licenciamento, uma instituição parceira — exige explicitamente saída CLR 2.0 ou VC do W3C? Se não, v2.0 te cobre.
• Seus destinatários precisam guardar essa credencial em um app de carteira digital, e não só em um perfil web ou no LinkedIn? Se não, v2.0 te cobre.
• Você está construindo infraestrutura de confiança entre emissores em que a verificação hosted baseada em URL genuinamente não é suficiente? Se não, v2.0 te cobre.

Se você respondeu “não” três vezes, você não está atrasado por entregar v2.0 em 2026 — você está alinhando a especificação ao ecossistema que realmente a consome. Revisite a pergunta quando um parceiro específico ou um requisito de conformidade pedir v3.0 pelo nome, não por uma sensação geral de que “v3 é mais novo”.

Para saber mais sobre como os dados de verificação de badge se comparam a formatos de credencial mais antigos e não padronizados, veja Blockchain Certificates vs Open Badges, que aprofunda as trocas de verificação e portabilidade sob outro ângulo.

---

Pronto para emitir sua primeira credencial verificável? Comece grátis na badges.ninja — designer visual, página pública de verificação, certificado em PDF, saída Open Badge v2.0. Sem necessidade de cartão de crédito.