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 輸出。不需要信用卡。