Open Badge v2 与 v3 详解：今天你应该用哪个规范？

如果你在 2026 年着手搭建一个数字徽章认证项目，研究还不到一个小时就会撞上这个问题：应该颁发 Open Badge v2.0，还是更新的 v3.0？诚实的答案是“这取决于谁要读取你的凭证”——但如果你得在周五之前拍板，这个答案并不解渴。所以我们来老老实实梳理一下：这两个规范到底有什么区别，今天各自被谁支持，以及大多数颁发者现在应该上线哪一个。

Open Badge v2.0 到底是什么

Open Badge v2.0 是 1EdTech（前身为 IMS Global）制定的规范，自 2017 年以来一直是数字徽章体系的基石。它构建在 JSON-LD 之上，围绕三个相互关联的对象组织起来：

• IssuerOrg——谁颁发了这份凭证（名称、URL、邮箱、logo）
• BadgeClass——凭证类型本身（名称、描述、颁发标准、图片）
• Assertion——颁发给特定接收者的具体授予记录（接收者身份、issuedOn 日期、证据、验证方式）

某位接收者的 Assertion 指向一个 BadgeClass，而 BadgeClass 又指回一个 IssuerOrg。验证方式有两种：hosted（验证方从一个稳定的 URL 实时抓取 Assertion JSON，并信任该域名）或 signed（Assertion 携带一个 JWS 签名，验证方会用颁发者公开发布的公钥来核验）。包括 badges.ninja 在内的大多数平台默认使用 hosted 验证、signed 作为可选项，因为 hosted 实现起来更简单，也更方便人工抽查。

下面是一段精简过的 v2.0 Assertion，也就是调用 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" }
}

正是这种结构让 v2.0 成为了事实上的标准：它简单到一个下午就能实现，也是几乎所有徽章数据消费方都默认期望看到的格式。

v2.0 中的 hosted 与 signed 验证

有必要弄清楚 v2.0 内部这两种验证模式的区别，因为人们常常把“v2.0 不如 v3.0 安全”和“hosted 验证不如 signed 验证安全”混为一谈。这其实是两个不同的维度。

• Hosted——verification.type 为 "hosted"，Assertion 的 id 是一个实时可访问的 URL。验证方抓取这个 URL 并核对返回内容是否一致；信任来自对该域名的控制权（例如，只有 badges.ninja 能在 badges.ninja/certify-badge/award/... 下发布内容）。大多数面向消费者的验证页面都采用这种方式，因为普通人只需点击链接即可。
• Signed——verification.type 为 "signed"，Assertion 携带（或引用）一个覆盖整个 payload 的 JWS 签名。验证方解析出颁发者的公钥，并独立于任何 URL 是否可访问来核验签名。这在思路上更接近 v3.0 的模型，只是没有 DID 这一层。

一段最简单的 Node signed 验证代码是这样的：

import { jwtVerify, importJWK } from 'jose';

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

如果你的项目在意即便 API 因维护而下线，凭证依然可以被验证，那么 signed 的 v2.0 已经能给你带来 v3.0 大部分的持久性优势，而不必引入 DID。

Open Badge v3.0 改变了什么

Open Badge v3.0 是基于 W3C Verifiable Credentials（VC）Data Model 的一次重写，而不是对 v2.0 那套 JSON-LD 结构的渐进式升级。实际影响较大的几点区别：

• 默认采用加密签名。 每一份 v3.0 凭证都是一份已签名的 VC——不存在“hosted、信任 URL”这种兜底方案。验证始终基于数学计算，而非基于域名。
• 基于 DID 的颁发者身份。 颁发者不再是带有 URL 和邮箱的 IssuerOrg 对象，而是通过去中心化标识符（DID）来标识，该标识符可解析出一份公钥文档。
• 与 Comprehensive Learner Record（CLR）2.0 对齐。 v3.0 在设计上就考虑了与 CLR 的互操作性，因此单份凭证既能承载成就数据，也能携带 CLR 消费方所期望的结构化成绩单细节（能力项、评估结果、课程/学期上下文）。
• 与数字钱包兼容。 由于 v3.0 凭证是标准的 W3C VC，它们可以像驾照或疫苗接种证明一样，被保存在身份钱包中——而不只是显示在网页上。

简单说：v2.0 回答的是“一个人或一段简单脚本能否验证这份凭证”，而 v3.0 回答的是“这份凭证能否与更广泛的可验证凭证生态——钱包、DID、正式的学习记录——互通”。

并排对比

为什么现有基础设施仍然运行在 v2.0 上

这一点对大多数项目来说是决定性的：你的接收者真正希望展示凭证的那些地方，目前依然只认 v2.0。 LinkedIn 的 Add to Profile 流程、Credly、Badgr，以及绝大多数招聘系统（ATS）集成，解析的都是 v2.0 的 Assertion/BadgeClass 结构。如果你的目标是“让接收者能把徽章发到 LinkedIn 上，让招聘方能点开链接完成验证”，那么 v2.0 并不是一个你被困住的过时格式——它就是这个生态目前通行的语言。

我们在 LinkedIn Skill Assessments vs Open Badges 一文中，从接收者的角度探讨过同样的张力——一枚徽章的价值很大程度上取决于它能多轻松地融入招聘方和同行已经在使用的场景，而今天，这些场景绝大多数都是 v2.0 形态的基础设施。

v3.0 真正派上用场的场景

v3.0 并非炒作——它确实为特定项目解决了真实问题：

• 受 CLR 强制要求约束的大学和颁发者。 如果你在配合正式的成绩单系统颁发凭证，或者州/地区教育主管部门要求输出符合 CLR 2.0 的内容，v3.0 内置的对齐能力可以省去在 v2.0 Assertion 上硬塞 CLR 字段的麻烦。
• 面向数字钱包存储的项目。 如果你的接收者需要把凭证存进钱包应用，而不只是在网页上展示，那么只有 W3C VC（即 v3.0）才能原生做到这一点。
• 基于 DID 信任的跨颁发者凭证交换。 如果你在搭建或加入一个网络，其中颁发者身份需要具备加密层面的可移植性，而不是“信任这个 URL”，那么 DID 就是正确的基础组件。

对于 2026 年的培训项目、训练营或职业发展类颁发者来说，以上都不是常见需求。它们常见于那些明确要求 CLR 或 W3C VC 的、有合规或互操作性要求的机构。

一份精简后的 v3.0 凭证展示了信封结构有多么不同，尽管底层的成就数据在概念上是同一次授予：

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

注意 issuer 字段是一个 DID，而不是 URL，整份文档携带的是一个 proof 区块，而不是 verification 指针。这正是前面提到的 DID 解析和 VC 签名工具链——真正的工程工作量，而如果下游目前还没人消费它，这份投入就是被浪费的。

几个值得澄清的常见误解

• “v3.0 更安全。” 不一定——signed 的 v2.0 和 v3.0 都依赖加密验证。v3.0 的优势在于标准化的 身份（DID）和 钱包 互操作性，而不是相对 signed v2.0 的安全性升级。
• “v2.0 已经过时了。” 并没有。1EdTech 同时维护着两套规范，而 v2.0 依然是颁发者日常使用的那些平台和集成所引用的版本。
• “整个项目必须二选一。” 不需要。没有什么能阻止一个颁发者把 v2.0 用于常规场景，同时为某个明确要求 v3.0 的特定合作方集成额外输出 v3.0——底层的授予数据不会变，变的只是表示形式。

迁移路径（以及为什么你不需要一次性选定）

对几乎所有颁发者来说，务实的做法是：现在就上线 v2.0，把 v3.0 当作一项新增能力，而不是替代品，等到某个具体的下游消费方真正提出要求时再加上。 这样做能顺利落地，原因有以下几点：

1. 之后新增 v3.0 支持时，你的 BadgeClass 和 Assertion ID 不需要改变——你是在为同一份底层授予记录增加第二种、形态不同的表示，而不是在迁移现有接收者的凭证。
2. 只理解 v2.0 的验证方依然能像以前一样正常工作。
3. 你可以避免在真正遇到具体需求之前，就提前搭建 DID 基础设施和 VC 签名流水线。

这也是我们在 badges.ninja 内部使用的同一套逻辑：每一次授予都以 Open Badge v2.0 的形式发出——JSON-LD、在稳定的 /certify-badge/award/{guid} URL 上提供 hosted 验证、开箱即用地支持 LinkedIn 的 Add to Profile——因为这覆盖了颁发者实际被要求产出内容中的绝大多数场景。如果你的项目之后需要为某个具体的机构合作方提供 v3.0/CLR 输出，那也只是在一条已经跑通的 v2.0 流水线之上做一次范围明确的新增，而不是推倒重来。

这种先后顺序还能帮你规避一个更隐蔽的风险：在还不知道合作方到底期望哪种 DID 方法之前，就提前押注某套 DID 基础设施。VC 生态目前尚未收敛到单一的 DID 方法——did:web、did:key 以及各种基于账本锚定的方法在实践中都能见到，而如果为某个试点合作方选错了方法，后续就得重做颁发者身份这部分工作。等到有明确命名的需求出现时再动手，意味着你能在真正开工之前，就搞清楚自己到底需要哪种方法。

给自己项目做的快速自查

在为 v3.0 投入工程时间之前，先问自己这三个问题：

• 是否有任何凭证消费方——雇主的 ATS、执照颁发机构、合作院校——明确要求 CLR 2.0 或 W3C VC 输出？ 如果没有，v2.0 就够用。
• 你的接收者是否需要把这份凭证存进数字钱包应用，而不只是放在网页个人资料或 LinkedIn 上？ 如果没有，v2.0 就够用。
• 你是否正在构建跨颁发者的信任基础设施，而基于 URL 的 hosted 验证确实无法满足需求？ 如果没有，v2.0 就够用。

如果三个问题的答案都是“没有”，那么在 2026 年选择上线 v2.0 并不算落后——你只是让规范匹配了真正在消费它的生态。等到某个具体的合作方或合规要求明确点名要 v3.0 时，再重新考虑这个问题——而不是仅凭“v3 更新”这种笼统的感觉就动手。

关于徽章验证数据相比更老旧、非标准的凭证格式表现如何，可以参考 Blockchain Certificates vs Open Badges 一文，它从另一个角度深入探讨了验证和可移植性方面的取舍。

---

准备好颁发你的第一份可验证凭证了吗？ 在 badges.ninja 免费开始——可视化设计器、公开验证页面、PDF 证书、Open Badge v2.0 输出。无需信用卡。