Open Badge v2 vs v3, Ipinaliwanag: Aling Spec ang Dapat Mong Gamitin Ngayon?

Kung nagse-set up ka ng credentialing program noong 2026, matatagpuan mo ang tanong na ito sa unang oras pa lang ng research mo: dapat ka bang mag-issue ng Open Badge v2.0 o yung mas bago na v3.0? Ang tapat na sagot ay “depende kung sino ang kailangang magbasa ng mga credential mo” — pero hindi ‘yon satisfying kung ikaw mismo ang kailangang magdesisyon by Friday. Kaya’t tignan natin kung ano talaga ang nagbago sa dalawang spec, sino ang sumusuporta sa alin ngayon, at alin ang dapat i-ship ng karamihan ng mga issuer ngayon.

Ano Talaga ang Open Badge v2.0

Ang Open Badge v2.0 ay ang spec ng 1EdTech (dating IMS Global) na naging backbone ng digital credentialing mula noong 2017. Built ito sa JSON-LD at nakaayos sa paligid ng tatlong magkakaugnay na object:

• IssuerOrg — sino ang nag-issue ng badge (pangalan, URL, email, logo)
• BadgeClass — ang credential type mismo (pangalan, description, criteria, image)
• Assertion — ang specific na award para sa specific na recipient (identity ng recipient, issuedOn date, evidence, verification method)

Ang Assertion ng isang recipient ay tumuturo sa isang BadgeClass, na tumuturo naman pabalik sa isang IssuerOrg. Nangyayari ang verification sa isa sa dalawang paraan: hosted (kinukuha ng verifier ang live Assertion JSON mula sa isang stable URL at nagtitiwala sa domain) o signed (may dalang JWS signature ang Assertion na chine-check ng verifier laban sa naka-publish na public key ng issuer). Karamihan sa mga platform, kasama na ang badges.ninja, default na gumagamit ng hosted verification na may signed bilang option, dahil mas simple i-implement ang hosted at mas madaling i-spot-check ng tao.

Narito ang isang trimmed v2.0 Assertion, yung klase ng ibabalik mula sa isang GET /awards/{id} call:

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

Ito ang structure kung bakit naging de facto standard ang v2.0: sapat na kasimple para ma-implement sa isang hapon lang, at ito ang inaasahang makita ng halos lahat ng consumer ng badge data.

Hosted vs Signed Verification sa v2.0

Worth i-understand ang dalawang verification mode sa loob mismo ng v2.0, dahil madalas pinaghahalo ng mga tao ang “mas less secure ang v2.0 kumpara sa v3.0” sa “mas less secure ang hosted verification kumpara sa signed.” Hindi sila same axis.

• Hosted — ang verification.type ay "hosted", at ang id ng Assertion ay isang live URL. Kinukuha ng verifier ang URL na ‘yon at che-check kung tumutugma ang response; nanggagaling ang trust sa pagkontrol sa domain (halimbawa, badges.ninja lang ang pwedeng mag-publish sa badges.ninja/certify-badge/award/...). Ito ang ginagamit ng karamihan sa consumer-facing verification pages dahil pwede lang i-click ng tao ang link.
• Signed — ang verification.type ay "signed", at may dala (o reference) ang Assertion na JWS signature sa buong payload. Kinukuha ng verifier ang public key ng issuer at chine-check ang signature nang hindi umaasa kung reachable ang kahit anong URL. Mas malapit ito sa spirit sa model ng v3.0, wala lang DID layer.

Ganito ang tingin ng minimal signed-verification check sa Node:

import { jwtVerify, importJWK } from 'jose';

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

Kung importante sa program mo na manatiling verifiable ang mga credential kahit offline na ang API mo for maintenance, ibinibigay sa ‘yo ng signed v2.0 ang karamihan sa durability benefit ng v3.0 nang hindi kailangang mag-adopt ng DIDs.

Ano ang Binabago ng Open Badge v3.0

Ang Open Badge v3.0 ay isang rewrite sa ibabaw ng W3C Verifiable Credentials (VC) Data Model, hindi lang incremental update sa JSON-LD shape ng v2.0. Ito ang mga difference na mahalaga sa practice:

• Cryptographic signing by default. Bawat v3.0 credential ay isang signed VC — walang “hosted, trust the URL” fallback. Laging mathematical ang verification, hindi domain-based.
• DID-based na issuer identity. Sa halip na isang IssuerOrg object na may URL at email, ang issuer ay ikinikilala sa pamamagitan ng Decentralized Identifier (DID), na nire-resolve sa isang public key document.
• Alignment sa Comprehensive Learner Record (CLR) 2.0. Dinesign ang v3.0 para maka-interoperate sa CLR, kaya isang credential lang ay pwede nang magdala ng achievement data plus yung klaseng structured transcript detail na inaasahan ng CLR consumers (competencies, assessment results, term/course context).
• Digital wallet compatibility. Dahil standard W3C VCs ang mga v3.0 credential, pwede silang i-hold sa identity wallets katulad ng pag-hold ng driver’s license o vaccine credential — hindi lang i-display sa isang web page.

Sa madaling salita: sinasagot ng v2.0 ang “kaya ba ng tao o simpleng script na i-verify itong credential na ‘to,” at sinasagot ng v3.0 ang “kaya ba ng credential na ‘to mag-interoperate sa mas malawak na verifiable-credentials ecosystem — wallets, DIDs, formal learner records.”

Side-by-Side Comparison

Bakit Nasa v2.0 Pa Rin ang Installed Base

Ito na yung part na nagde-decide para sa karamihan ng programs: yung mga lugar kung saan gusto talaga lumitaw ng mga credential ng recipients mo, umaasa pa rin sa v2.0. Ang Add to Profile flow ng LinkedIn, Credly, Badgr, at ang malaking majority ng applicant-tracking-system integrations ay nagpaparse sa Assertion/BadgeClass shape ng v2.0. Kung ang goal mo ay “makapag-post ang recipients nito sa LinkedIn at makaka-click through ang recruiters para i-verify ito,” hindi legacy format ang v2.0 na kinakapitan mo — ito ang format na kausap ngayon ng ecosystem.

Na-cover na namin itong exact tension mula sa side ng recipient sa LinkedIn Skill Assessments vs Open Badges — ang value ng isang badge ay malaking function kung gaano ito kadali mag-fit sa mga lugar na tinitingnan na ng mga recruiter at peers, at ngayon, overwhelmingly v2.0-shaped infrastructure ang ‘yon.

Kailan Talaga Mahalaga ang v3.0

Hindi hype ang v3.0 — nagre-resolve ito ng real problems para sa specific na programs:

• Mga university at issuer na under sa CLR mandates. Kung nagi-issue ka kasabay ng isang formal transcript system, o kailangan ng state/regional education body ng CLR 2.0-compatible output, sina-save ka ng built-in alignment ng v3.0 sa pagba-bolt ng CLR fields sa isang v2.0 Assertion.
• Mga program na naka-target sa digital wallet storage. Kung kailangan ng recipients mo i-hold ang credential sa isang wallet app sa halip na i-display lang sa web page, W3C VC lang (i.e., v3.0) ang gagana natively doon.
• Cross-issuer credential exchange na may DID-based na trust. Kung nagbi-build o sumasali ka sa isang network kung saan kailangang cryptographically portable ang issuer identity kaysa “trust this URL,” ang tama diyan ay DIDs.

Wala sa mga ‘to ang common case para sa isang training program, bootcamp, o professional-development issuer noong 2026. Common sila para sa mga institution na may compliance o interoperability requirements na specifically nagbabanggit ng CLR o W3C VCs.

Ipinapakita ng isang trimmed v3.0 credential kung gaano kaiba ang envelope, kahit na conceptually same award ang underlying achievement data:

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

Pansinin na DID ang issuer field, hindi URL, at may dalang proof block ang buong document sa halip na verification pointer. Yun ang DID resolution + VC signing tooling na binanggit sa itaas — real engineering work, at work na nasasayang kung wala pa namang downstream na gumagamit dito.

Mga Common Misconception na Dapat Linawin

• “Mas secure ang v3.0.” Hindi necessarily — parehong umaasa sa cryptographic verification ang signed v2.0 at v3.0. Ang advantage ng v3.0 ay standardized identity (DIDs) at wallet interoperability, hindi security upgrade laban sa signed v2.0.
• “Deprecated na ang v2.0.” Hindi. Minamaintain ng 1EdTech ang parehong spec, at v2.0 pa rin ang version na tinutukoy ng mga platform at integration na ginagamit talaga ng mga issuer day to day.
• “Kailangan mo pumili ng isa para sa buong program.” Hindi. Wala namang pumipigil sa isang issuer na mag-publish ng v2.0 para sa general use at magdagdag ng v3.0 output para sa isang specific na partner integration na nangangailangan nito — hindi nagbabago ang underlying award data, representation lang.

Ang Migration Path (at Bakit Hindi Mo Kailangan Pumili Habang-buhay)

Ang practical move para sa halos lahat ng issuer: i-ship ang v2.0 ngayon, at ituring ang v3.0 bilang addition, hindi replacement, kapag may specific na downstream consumer na nangangailangan nito. Ilang reasons kung bakit gumagana ito nang cleanly:

1. Hindi kailangang magbago ang BadgeClass at Assertion IDs mo kapag nagdagdag ka ng v3.0 support mamaya — nagdadagdag ka lang ng pangalawang, iba-hugis na representation ng parehong underlying award, hindi mo mini-migrate ang existing credentials ng recipients.
2. Patuloy na gagana katulad ng dati ang mga verifier na v2.0 lang ang naiintindihan.
3. Naiiwasan mo ang pagbuild ng DID infrastructure at VC signing pipelines bago ka pa magkaroon ng concrete requirement na nangangailangan nito.

Ito rin yung same logic na ginagamit namin internally sa badges.ninja: lumalabas ang bawat award bilang isang v2.0 Open Badge — JSON-LD, hosted verification sa isang stable /certify-badge/award/{guid} URL, ready na sa LinkedIn Add to Profile out of the box — dahil sina-cover nito ang overwhelming majority ng talagang hinihingi sa mga issuer. Kung kailangan ng program mo mamaya ng v3.0/CLR output para sa isang specific institutional partner, scoped addition lang ‘yon sa ibabaw ng gumaganang v2.0 pipeline, hindi rewrite.

Pinoprotektahan ka rin ng sequencing na ‘to mula sa mas subtle na risk: ang pag-commit sa DID infrastructure bago mo pa alam kung anong DID method talaga ang inaasahan ng mga partner mo. Hindi pa converge ang VC ecosystem sa isang DID method — lumalabas sa wild ang did:web, did:key, at ledger-anchored methods, at kung mali ang napili mo para sa isang pilot partner, magre-redo ka ng issuer-identity work mamaya. Ang paghintay sa isang named requirement ay nangangahulugang malalaman mo kung anong method talaga ang kailangan mo bago ka magbuild ng kahit ano.

Isang Mabilis na Gut-Check Para sa Sarili Mong Program

Itanong ang tatlong tanong na ‘to bago ka gumastos ng engineering time sa v3.0:

• May consumer ba ng credentials ko — isang employer ATS, isang licensing board, isang partner institution — na explicitly nangangailangan ng CLR 2.0 o W3C VC output? Kung wala, kaya na ng v2.0.
• Kailangan ba ng recipients ko na i-hold itong credential sa isang digital wallet app, hindi lang web profile o LinkedIn? Kung wala, kaya na ng v2.0.
• Nagbi-build ka ba ng cross-issuer trust infrastructure kung saan genuinely hindi sapat ang URL-based hosted verification? Kung wala, kaya na ng v2.0.

Kung “wala” ang sagot mo nang three times, hindi ka nahuhuli sa pag-ship ng v2.0 noong 2026 — ini-match mo lang ang spec sa ecosystem na talagang gumagamit nito. Balikan ang tanong kapag may specific na partner o compliance requirement na humihingi ng v3.0 by name, hindi dahil lang sa general feeling na “mas bago ang v3.”

Para sa iba pang detalye kung paano nananatiling matatag ang badge verification data kumpara sa mas lumang, non-standard credential formats, tingnan ang Blockchain Certificates vs Open Badges, na sumisid sa verification at portability trade-offs mula sa ibang angle.

---

Ready ka na bang mag-issue ng first verifiable credential mo? Mag-start nang free sa badges.ninja — visual designer, public verification page, PDF certificate, Open Badge v2.0 output. Walang kailangang credit card.