Open Badge v2 vs v3 explicado: que especificação deves usar hoje?

Se estás a montar um programa de credenciação em 2026, vais deparar-te com esta pergunta logo na primeira hora de pesquisa: deves emitir Open Badge v2.0 ou o v3.0, mais recente? A resposta honesta é “depende de quem tiver de ler as tuas credenciais” — mas isso não ajuda muito se és tu quem tem de decidir até sexta-feira. Por isso, vamos ver o que realmente mudou entre as duas especificações, quem dá suporte a quê hoje em dia, e qual é que a maioria dos emissores devia usar já.

O que é, na verdade, o Open Badge v2.0

O Open Badge v2.0 é a especificação da 1EdTech (antiga IMS Global) que tem sido a espinha dorsal da credenciação digital desde 2017. Está construída sobre JSON-LD e organizada em torno de três objetos ligados entre si:

• IssuerOrg — quem emitiu a credencial (nome, URL, e-mail, logótipo)
• BadgeClass — o próprio tipo de credencial (nome, descrição, critérios, imagem)
• Assertion — a atribuição concreta a um destinatário concreto (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 funciona de duas formas: hosted (o verificador vai buscar o Assertion JSON em direto a um URL estável e confia no domínio) ou signed (o Assertion tem uma assinatura JWS que o verificador confere face à chave pública publicada do emissor). A maioria das plataformas, incluindo a badges.ninja, usa por omissão a verificação hosted, com signed como opção, porque hosted é mais simples de implementar e mais fácil de confirmar visualmente por uma pessoa.

Aqui tens um Assertion v2.0 resumido, o género de coisa que receberias 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" }
}

É por causa desta estrutura que o v2.0 se tornou o padrão de facto: é simples o suficiente para se implementar numa tarde, e é o que praticamente qualquer consumidor de dados de emblemas espera encontrar.

Verificação hosted vs signed no v2.0

Vale a pena perceber os dois modos de verificação dentro do próprio v2.0, porque há quem confunda “o v2.0 é menos seguro do que o v3.0” com “a verificação hosted é menos segura do que a signed”. Não são o mesmo eixo.

• Hosted — o verification.type é "hosted", e o id do Assertion é um URL em direto. Um verificador vai buscar esse URL e confirma que a resposta coincide; a confiança vem de controlar o domínio (por exemplo, só a badges.ninja pode publicar em badges.ninja/certify-badge/award/...). É isto que a maioria das páginas de verificação voltadas para o público usa, porque qualquer pessoa pode simplesmente clicar na ligação.
• Signed — o verification.type é "signed", e o Assertion transporta (ou referencia) uma assinatura JWS sobre o payload. Um verificador resolve a chave pública do emissor e confirma a assinatura independentemente de o URL estar acessível. Isto está 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 tem este aspeto:

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 teu programa se preocupa com as credenciais continuarem verificáveis mesmo depois de a tua API ficar offline para manutenção, o v2.0 signed dá-te a maior parte do benefício de durabilidade do v3.0 sem teres de adotar DIDs.

O que o Open Badge v3.0 muda

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

• Assinatura criptográfica por omissão. Todas as credenciais v3.0 são uma VC assinada — não há alternativa “hosted, confia no URL”. A verificação é sempre matemática, não baseada no 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 concebido para interoperar com o CLR, pelo que uma única credencial pode transportar dados da conquista mais o tipo de detalhe de registo estruturado que os consumidores de CLR esperam (competências, resultados de avaliação, contexto de disciplina/período letivo).
• Compatibilidade com carteiras digitais. Como as credenciais v3.0 são VCs padrão do W3C, podem ser guardadas em carteiras de identidade da mesma forma que uma carta de condução ou um certificado de vacinação — não apenas apresentadas numa página web.

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

Comparação lado a lado

Porque é que a base instalada ainda assenta no v2.0

Esta é a parte que pesa na decisão para a maioria dos programas: os sítios onde os teus destinatários realmente querem que as suas credenciais apareçam continuam a esperar v2.0. O fluxo Add to Profile do LinkedIn, a Credly, a Badgr e a grande maioria das integrações de sistemas de acompanhamento de candidaturas processam a forma Assertion/BadgeClass do v2.0. Se o teu objetivo é que os destinatários consigam publicar isto no LinkedIn e os recrutadores consigam clicar para verificar, o v2.0 não é um formato antiquado ao qual estás preso — é o formato que o ecossistema fala atualmente.

Abordámos esta mesma tensão do lado do destinatário em LinkedIn Skill Assessments vs Open Badges — o valor de um emblema é, em grande parte, função de quão facilmente se encaixa nos sítios onde recrutadores e colegas já olham, e hoje isso é, esmagadoramente, infraestrutura com a forma do v2.0.

Quando é que o v3.0 importa mesmo

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

• Universidades e emissores sujeitos a exigências de CLR. Se emites a par de um sistema formal de registo académico, ou um organismo educativo estatal/regional exige uma saída compatível com CLR 2.0, o alinhamento nativo do v3.0 poupa-te a ter de acrescentar campos de CLR à força a um Assertion v2.0.
• Programas orientados para o armazenamento em carteira digital. Se os teus destinatários precisam de guardar a credencial numa aplicação de carteira em vez de apenas a apresentar numa página web, só uma VC do W3C (ou seja, v3.0) vai funcionar aí de forma nativa.
• Troca de credenciais entre emissores com confiança baseada em DID. Se estás a construir ou a juntar-te a uma rede em que a identidade do emissor precisa de ser portátil de forma criptográfica em vez de “confia neste URL”, os DIDs são a peça certa.

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

Uma credencial v3.0 resumida mostra como o invólucro é diferente, mesmo quando os dados da conquista subjacente são conceptualmente a mesma atribuiçã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" }
}

Repara que o campo issuer é um DID, e não um URL, e que todo o documento transporta um bloco proof em vez de um ponteiro verification. Isto é a resolução de DID mais as ferramentas de assinatura de VC mencionadas acima — trabalho de engenharia a sério, e trabalho desperdiçado se ainda não houver ninguém a jusante a consumi-lo.

Ideias erradas que vale a pena esclarecer

• “O v3.0 é mais seguro.” Não necessariamente — tanto o v2.0 signed como o v3.0 dependem de verificação criptográfica. A vantagem do v3.0 é a identidade estandardizada (DIDs) e a interoperabilidade com carteiras, não uma melhoria de segurança face ao v2.0 signed.
• “O v2.0 está obsoleto.” Não está. A 1EdTech mantém as duas especificações, e o v2.0 continua a ser a versão a que as plataformas e integrações que os emissores realmente usam no dia a dia fazem referência.
• “Tens de escolher uma para todo o programa.” Não tens. Nada impede um emissor de publicar v2.0 para uso geral e acrescentar saída v3.0 para uma integração específica com um parceiro que a exija — os dados da atribuição subjacente não mudam, só a representação.

O caminho de migração (e porque não precisas de escolher para sempre)

A jogada prática para quase todos os emissores: lança o v2.0 agora, e trata o v3.0 como um acrescento, não uma substituição, quando um consumidor específico a jusante o exigir. Há várias razões pelas quais isto funciona sem atritos:

1. Os IDs do teu BadgeClass e Assertion não precisam de mudar quando acrescentares suporte para v3.0 mais tarde — estás a acrescentar uma segunda representação, com forma diferente, da mesma atribuição subjacente, e não a migrar as credenciais dos destinatários existentes.
2. Os verificadores que só entendem v2.0 continuam a funcionar exatamente como antes.
3. Evitas construir infraestrutura de DID e fluxos de assinatura de VC antes de teres um requisito concreto que precise deles.

É a mesma lógica que usamos internamente na badges.ninja: todas as atribuições saem como um Open Badge v2.0 — JSON-LD, verificação hosted num URL estável /certify-badge/award/{guid}, pronto para o Add to Profile do LinkedIn logo de raiz — porque isso cobre a esmagadora maioria do que os emissores realmente precisam de produzir. Se o teu programa precisar mais tarde de saída v3.0/CLR para um parceiro institucional específico, isso é um acrescento delimitado sobre um fluxo v2.0 que já funciona, e não uma reescrita.

Essa sequência também te protege de um risco mais subtil: comprometeres-te com infraestrutura de DID antes de saberes que método de DID os teus parceiros realmente esperam. O ecossistema de VC ainda não convergiu num ú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 que descobres que método precisas mesmo antes de construíres seja o que for.

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

Faz estas três perguntas antes de gastares tempo de engenharia no v3.0:

• Algum consumidor das tuas credenciais — um ATS de um empregador, uma ordem profissional, uma instituição parceira — exige explicitamente saída CLR 2.0 ou VC do W3C? Se não, o v2.0 chega.
• Os teus destinatários precisam de guardar esta credencial numa aplicação de carteira digital, e não apenas num perfil web ou no LinkedIn? Se não, o v2.0 chega.
• Estás a construir infraestrutura de confiança entre emissores em que a verificação hosted baseada em URL genuinamente não é suficiente? Se não, o v2.0 chega.

Se respondeste “não” três vezes, não estás atrasado por lançares v2.0 em 2026 — estás a ajustar a especificação ao ecossistema que realmente a consome. Reconsidera a questão quando um parceiro específico ou um requisito de conformidade pedir v3.0 pelo nome, e não por uma sensação geral de que “o v3 é mais recente”.

Para saberes mais sobre como os dados de verificação de emblemas se comportam face a formatos de credenciais mais antigos e não padronizados, vê Blockchain Certificates vs Open Badges, que aprofunda os compromissos de verificação e portabilidade a partir de outro ângulo.

---

Pronto para emitir a tua primeira credencial verificável? Começa 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.