Open Badges: o padrão aberto por detrás de comprovativos verificáveis

O padrão divide um comprovativo em três partes, e a separação é mais inteligente do que parece à primeira vista. O Issuer descreve quem emite: nome, site, contacto. A BadgeClass descreve o que é atribuído: título do comprovativo, descrição, critérios, imagem. A Assertion é a atribuição individual: esta pessoa recebeu esta BadgeClass nesta data.

Assim, a descrição de um tipo de certificado só precisa de existir uma vez, quer o atribuam a 20 ou a 2000 pessoas. É este o aspeto de uma Assertion real do nosso sistema, apenas com o token abreviado:

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

Dois detalhes merecem um segundo olhar. O campo badge é apenas um endereço: é aí que fica a BadgeClass, que por sua vez aponta para o Issuer, e é assim que uma ferramenta de verificação percorre toda a cadeia. E como recipient aparece aqui o endereço da página do certificado; um endereço de e-mail, mesmo com hash, não surge em lado nenhum. O documento público dispensa, assim, quaisquer dados de contacto diretos. O nome da pessoa fica na página do certificado ligada, ali onde ela própria o inscreveu ao resgatar.

A especificação prevê duas formas de tornar uma Assertion verificável. Nos badges assinados, o documento leva uma assinatura criptográfica do emissor, prova-se portanto a si próprio, mas exige gestão de chaves do lado de quem emite. Nos badges alojados vale uma regra mais simples: a Assertion é autêntica enquanto puder ser consultada no seu próprio endereço id junto do emissor. Verificar significa então apenas consultar o URL e comparar.

O método alojado tem uma vantagem subestimada: a revogação limpa. Quando o emissor retira um comprovativo, o mesmo endereço passa a responder de imediato com o estado HTTP 410 e um documento curto com a linha «revoked: true». Um certificado retirado não desaparece sem mais, assinala ativamente que já não é válido. É assim que fazemos também no OneClickBadge, por exemplo quando um certificado foi emitido duas vezes por engano.

Um detalhe do padrão é quase poético: o «baking». A imagem do badge, normalmente um PNG, recebe a sua Assertion e o respetivo endereço de verificação embutidos diretamente no ficheiro de imagem, tecnicamente como um bloco de texto iTXt com a palavra-chave openbadges. Depois disto a imagem fica exatamente igual, mas leva o seu caminho de verificação dentro de si: quem arrastar o ficheiro para uma ferramenta de verificação chega à Assertion, por mais transferências e conversas por onde a imagem tenha passado.

A hierarquia mantém-se importante: só a Assertion alojada consegue provar seja o que for. Uma imagem pode ser copiada e alterada à vontade, ao passo que a resposta no endereço do comprovativo é controlada apenas pelo emissor.

Aqui desfazemos o equívoco mais comum que anda por muitos artigos: o LinkedIn não lê os metadados dos Open Badges. Não existe lá importação de badges, nem verificação automática, nem símbolo especial para badges verificados. O que o LinkedIn tem é a secção de perfil «Licenças e certificados», com campos para o nome, a organização emissora e um URL. Nada disso significa que o LinkedIn tenha certificado ou reconhecido o que quer que seja.

Nem por isso o padrão é inútil para o LinkedIn, pelo contrário: o campo do URL é o lugar do endereço de comprovação. Quem clicar em «Mostrar credencial» no perfil chega à página do certificado, atrás da qual está a Assertion verificável. O próprio registo pode ficar preparado para os destinatários num só clique, com os campos do formulário já preenchidos. Como isto se apresenta do lado dos participantes é o que mostra o guia para adicionar ao perfil.

Implementar o próprio padrão compensa a muito poucos organizadores: precisariam de pontos de acesso permanentemente disponíveis para o Issuer, a BadgeClass e cada Assertion, mais a lógica de revogação e uma imagem com o comprovativo embutido. Para eventos, webinars e formações, isto já vem pronto: no OneClickBadge desenham um certificado de participação, e cada exemplar emitido recebe automaticamente a sua Assertion alojada, o mecanismo de revogação e o PDF com a imagem.

A distribuição por muitos participantes acontece sem carregar listas, através de um link de resgate que partilham depois do evento. Porque é que, no tema dos comprovativos, isto é também uma decisão de proteção de dados está na página Certificados para muitos participantes.

O OneClickBadge conserva os comprovativos emitidos mesmo depois da eliminação habitual do evento. Ao eliminar a conta, porém, o emissor pode escolher expressamente remover também os certificados. A revogação é uma operação separada: indica que um comprovativo é inválido.

A versão 3.0 passa o padrão para as W3C Verifiable Credentials, um modelo com assinaturas criptográficas e mais controlo do lado de quem recebe. Para os ecossistemas do ensino superior e para comprovativos de formação de longa duração, é o rumo certo. Para o caso da participação em eventos, a 2.0 na forma alojada é hoje o estado pragmático das coisas: qualquer ferramenta de verificação comum a entende, a revogação funciona, e ninguém tem de gerir carteiras nem chaves. Por isso apostamos na 2.0 alojada e continuamos a observar a 3.0 com calma.