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, อีเมล, โลโก้)
• BadgeClass — ประเภทของใบรับรองนั้นเอง (ชื่อ, คำอธิบาย, เกณฑ์, รูปภาพ)
• Assertion — การมอบรางวัลที่เจาะจงให้กับผู้รับที่เจาะจง (ตัวตนของผู้รับ, วันที่ issuedOn, หลักฐาน, วิธีการตรวจสอบ)

Assertion ของผู้รับจะชี้ไปยัง BadgeClass ซึ่งชี้กลับไปยัง IssuerOrg อีกที การตรวจสอบทำได้สองแบบ คือ hosted (ผู้ตรวจสอบดึงไฟล์ Assertion JSON ที่ยังใช้งานอยู่จาก URL ที่คงที่ และเชื่อถือโดเมนนั้น) หรือ signed (Assertion มีลายเซ็น JWS ที่ผู้ตรวจสอบเช็คกับกุญแจสาธารณะที่ผู้ออกเผยแพร่ไว้) แพลตฟอร์มส่วนใหญ่ รวมถึง badges.ninja ใช้ hosted verification เป็นค่าเริ่มต้นและมี signed เป็นตัวเลือกเสริม เพราะ hosted นั้นทำได้ง่ายกว่าและมนุษย์ตรวจสอบด้วยตาได้ง่ายกว่า

นี่คือตัวอย่าง Assertion แบบย่อของ v2.0 ซึ่งเป็นสิ่งที่คุณจะได้รับกลับมาจากการเรียก 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 กลายเป็นมาตรฐานโดยพฤตินัย มันเรียบง่ายพอที่จะพัฒนาให้เสร็จได้ภายในบ่ายเดียว และเป็นสิ่งที่แทบทุกฝ่ายที่บริโภคข้อมูลตราสัญลักษณ์ดิจิทัลคาดหวังจะเห็น

Hosted กับ Signed Verification ใน v2.0

การเข้าใจโหมดการตรวจสอบทั้งสองแบบภายใน v2.0 เองเป็นเรื่องคุ้มค่า เพราะคนมักสับสนระหว่างแนวคิดที่ว่า “v2.0 ปลอดภัยน้อยกว่า v3.0” กับ “hosted verification ปลอดภัยน้อยกว่า signed” ทั้งสองเรื่องนี้ไม่ใช่แกนเดียวกัน

• Hosted — verification.type มีค่าเป็น "hosted" และ id ของ Assertion คือ URL ที่ใช้งานได้จริง ผู้ตรวจสอบจะดึง URL นั้นและเช็คว่าคำตอบตรงกัน ความน่าเชื่อถือมาจากการควบคุมโดเมน (เช่น มีแค่ badges.ninja เท่านั้นที่เผยแพร่ไปยัง badges.ninja/certify-badge/award/... ได้) นี่คือสิ่งที่หน้าตรวจสอบสำหรับผู้บริโภคส่วนใหญ่ใช้ เพราะมนุษย์แค่คลิกลิงก์ก็ตรวจสอบได้
• Signed — verification.type มีค่าเป็น "signed" และ Assertion มี (หรืออ้างอิงถึง) ลายเซ็น JWS ครอบคลุมข้อมูลทั้งหมด ผู้ตรวจสอบจะดึงกุญแจสาธารณะของผู้ออกและเช็คลายเซ็นได้โดยไม่ต้องพึ่งว่า URL ใด ๆ เข้าถึงได้หรือไม่ แนวคิดนี้ใกล้เคียงกับโมเดลของ v3.0 มากกว่า เพียงแต่ไม่มีชั้น DID

การตรวจสอบ signed verification แบบง่าย ๆ ใน 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

หากโปรแกรมของคุณให้ความสำคัญกับการที่ใบรับรองยังตรวจสอบได้แม้ API ของคุณจะออฟไลน์เพื่อซ่อมบำรุง signed v2.0 จะให้ประโยชน์ด้านความคงทนใกล้เคียงกับ v3.0 โดยไม่ต้องใช้ DID

สิ่งที่ Open Badge v3.0 เปลี่ยนแปลง

Open Badge v3.0 คือการเขียนใหม่บนพื้นฐานของ W3C Verifiable Credentials (VC) Data Model ไม่ใช่การอัปเดตแบบค่อยเป็นค่อยไปจากโครงสร้าง JSON-LD ของ v2.0 ความแตกต่างที่มีผลจริงในทางปฏิบัติมีดังนี้:

• เซ็นด้วยการเข้ารหัสเป็นค่าเริ่มต้น ใบรับรอง v3.0 ทุกใบเป็น VC ที่ถูกเซ็นแล้ว ไม่มีทางเลือกสำรองแบบ “hosted เชื่อถือ URL” การตรวจสอบเป็นเรื่องทางคณิตศาสตร์เสมอ ไม่ใช่การอิงกับโดเมน
• ตัวตนผู้ออกที่อิงกับ DID แทนที่จะเป็นอ็อบเจ็กต์ IssuerOrg ที่มี URL และอีเมล ผู้ออกจะถูกระบุด้วย Decentralized Identifier (DID) ซึ่งจะแปลงไปเป็นเอกสารกุญแจสาธารณะ
• สอดคล้องกับ Comprehensive Learner Record (CLR) 2.0 v3.0 ถูกออกแบบมาให้ทำงานร่วมกับ CLR ได้ ดังนั้นใบรับรองเดียวสามารถบรรจุทั้งข้อมูลความสำเร็จและรายละเอียดแบบใบแสดงผลการเรียนที่มีโครงสร้างตามที่ผู้บริโภค CLR คาดหวัง (สมรรถนะ, ผลการประเมิน, บริบทของภาคเรียน/วิชา)
• ใช้งานร่วมกับกระเป๋าดิจิทัลได้ เนื่องจากใบรับรอง v3.0 เป็น W3C VC มาตรฐาน จึงสามารถเก็บไว้ใน wallet สำหรับยืนยันตัวตนได้เหมือนใบขับขี่หรือใบรับรองการฉีดวัคซีน ไม่ใช่แค่แสดงบนหน้าเว็บเท่านั้น

พูดสั้น ๆ คือ v2.0 ตอบคำถามว่า “มนุษย์หรือสคริปต์ง่าย ๆ ตรวจสอบใบรับรองนี้ได้ไหม” ส่วน v3.0 ตอบคำถามว่า “ใบรับรองนี้ทำงานร่วมกับระบบนิเวศ verifiable-credentials ที่กว้างขึ้นได้ไหม เช่น wallet, DID, บันทึกผู้เรียนอย่างเป็นทางการ”

เปรียบเทียบแบบเคียงข้างกัน

ทำไมฐานผู้ใช้งานที่มีอยู่จึงยังคงใช้ v2.0

นี่คือส่วนที่เอียงการตัดสินใจของโปรแกรมส่วนใหญ่ สถานที่ที่ผู้รับใบรับรองของคุณอยากให้ใบรับรองไปปรากฏจริง ๆ ยังคงคาดหวัง v2.0 อยู่ ขั้นตอน Add to Profile ของ LinkedIn, Credly, Badgr และการเชื่อมต่อระบบติดตามผู้สมัครงาน (ATS) ส่วนใหญ่ล้วนแปลงโครงสร้าง Assertion/BadgeClass ของ v2.0 หากเป้าหมายของคุณคือ “ผู้รับสามารถโพสต์สิ่งนี้ลง LinkedIn ได้ และผู้สรรหาบุคลากรคลิกเข้าไปตรวจสอบได้” v2.0 ไม่ใช่รูปแบบเก่าที่คุณติดอยู่ แต่มันคือรูปแบบที่ระบบนิเวศใช้พูดคุยกันอยู่ในตอนนี้

เราพูดถึงความตึงเครียดนี้จากมุมของผู้รับไปแล้วใน LinkedIn Skill Assessments vs Open Badges — คุณค่าของตราสัญลักษณ์ดิจิทัลส่วนใหญ่ขึ้นอยู่กับว่ามันเชื่อมต่อกับสถานที่ที่ผู้สรรหาและเพื่อนร่วมงานมองอยู่แล้วได้ง่ายแค่ไหน และวันนี้นั่นคือโครงสร้างพื้นฐานแบบ v2.0 เป็นส่วนใหญ่อย่างท่วมท้น

เมื่อไหร่ที่ v3.0 มีความสำคัญจริง ๆ

v3.0 ไม่ใช่แค่กระแส มันแก้ปัญหาจริงให้กับโปรแกรมบางประเภท:

• มหาวิทยาลัยและผู้ออกภายใต้ข้อบังคับ CLR หากคุณออกใบรับรองควบคู่ไปกับระบบใบแสดงผลการเรียนอย่างเป็นทางการ หรือหน่วยงานการศึกษาระดับรัฐ/ภูมิภาคกำหนดให้ต้องมีผลลัพธ์ที่รองรับ CLR 2.0 ความสอดคล้องที่มีอยู่ในตัวของ v3.0 จะช่วยให้คุณไม่ต้องยัดฟิลด์ CLR เข้าไปใน Assertion ของ v2.0
• โปรแกรมที่ต้องการเก็บในกระเป๋าดิจิทัล หากผู้รับของคุณต้องเก็บใบรับรองไว้ในแอป wallet แทนที่จะแค่แสดงบนหน้าเว็บ มีเพียง 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 resolution และ VC signing ที่กล่าวถึงข้างต้น เป็นงานวิศวกรรมจริง และเป็นงานที่สูญเปล่าหากยังไม่มีอะไรที่ปลายทางนำไปใช้จริง

ความเข้าใจผิดทั่วไปที่ควรทำความเข้าใจให้ถูกต้อง

• “v3.0 ปลอดภัยกว่า” ไม่จำเป็นเสมอไป signed v2.0 และ v3.0 ต่างก็อาศัยการตรวจสอบด้วยการเข้ารหัสทั้งคู่ ข้อได้เปรียบของ v3.0 คือ ตัวตน (DID) ที่เป็นมาตรฐาน และการทำงานร่วมกับ wallet ได้ ไม่ใช่การอัปเกรดด้านความปลอดภัยเหนือกว่า signed v2.0
• “v2.0 ถูกเลิกใช้แล้ว” ไม่จริง 1EdTech ยังคงดูแลรักษาทั้งสองสเปกอยู่ และ v2.0 ยังคงเป็นเวอร์ชันที่แพลตฟอร์มและการเชื่อมต่อต่าง ๆ ที่ผู้ออกใช้งานจริงในชีวิตประจำวันอ้างอิงถึง
• “คุณต้องเลือกใช้แบบเดียวสำหรับทั้งโปรแกรม” ไม่จำเป็นเลย ไม่มีอะไรขวางกั้นผู้ออกจากการเผยแพร่ v2.0 สำหรับการใช้งานทั่วไป และเพิ่มผลลัพธ์ v3.0 สำหรับการเชื่อมต่อกับพาร์ทเนอร์เฉพาะรายที่ต้องการมัน ข้อมูลรางวัลเบื้องหลังไม่เปลี่ยนแปลง เปลี่ยนแค่รูปแบบการนำเสนอเท่านั้น

เส้นทางการย้ายระบบ (และทำไมคุณไม่ต้องเลือกไปตลอดกาล)

แนวทางที่เหมาะสมสำหรับผู้ออกเกือบทุกราย คือ ใช้งาน v2.0 ตอนนี้ และมอง v3.0 เป็นส่วนเพิ่มเติม ไม่ใช่การแทนที่ เมื่อผู้บริโภคปลายทางเฉพาะรายต้องการมัน มีเหตุผลหลายข้อที่ทำให้วิธีนี้ได้ผลอย่างราบรื่น:

1. ID ของ BadgeClass และ Assertion ไม่จำเป็นต้องเปลี่ยนเมื่อคุณเพิ่มการรองรับ v3.0 ในภายหลัง คุณแค่เพิ่มการนำเสนอรูปแบบที่สองที่มีโครงสร้างต่างออกไปสำหรับรางวัลเดิม ไม่ใช่การย้ายใบรับรองของผู้รับที่มีอยู่แล้ว
2. ผู้ตรวจสอบที่เข้าใจแค่ v2.0 ยังคงทำงานได้เหมือนเดิมทุกประการ
3. คุณหลีกเลี่ยงการสร้างโครงสร้างพื้นฐาน DID และไปป์ไลน์ VC signing ก่อนที่จะมีข้อกำหนดที่ชัดเจนว่าต้องใช้มันจริง ๆ

นี่คือตรรกะเดียวกับที่เราใช้ภายใน badges.ninja เอง คือทุกรางวัลจะออกไปในรูปแบบ Open Badge v2.0 — JSON-LD, hosted verification ที่ URL คงที่ /certify-badge/award/{guid}, พร้อมใช้งานกับ LinkedIn Add to Profile ได้ทันที — เพราะนั่นคือสิ่งที่ครอบคลุมสิ่งที่ผู้ออกส่วนใหญ่ถูกขอให้ผลิตจริง ๆ อย่างท่วมท้น หากภายหลังโปรแกรมของคุณต้องการผลลัพธ์แบบ v3.0/CLR สำหรับพาร์ทเนอร์สถาบันเฉพาะราย นั่นคือส่วนเพิ่มเติมที่จำกัดขอบเขตบนไปป์ไลน์ v2.0 ที่ทำงานได้อยู่แล้ว ไม่ใช่การเขียนใหม่ทั้งหมด

ลำดับแบบนี้ยังปกป้องคุณจากความเสี่ยงที่ละเอียดอ่อนกว่านั้นด้วย นั่นคือการผูกมัดกับโครงสร้างพื้นฐาน DID ก่อนที่คุณจะรู้ว่าพาร์ทเนอร์ของคุณคาดหวัง DID method แบบไหนจริง ๆ ระบบนิเวศ VC ยังไม่ได้ลงตัวที่ DID method เดียว — did:web, did:key และ method ที่ยึดกับ ledger ต่างก็ปรากฏให้เห็นในโลกจริง และการเลือกผิดสำหรับพาร์ทเนอร์นำร่องหมายถึงต้องทำงานด้านตัวตนผู้ออกใหม่ในภายหลัง การรอจนกว่าจะมีข้อกำหนดที่ระบุชื่อชัดเจนหมายความว่าคุณจะรู้ว่าต้องใช้ method ไหนจริง ๆ ก่อนที่จะเริ่มสร้างอะไรเลย

เช็คลิสต์อย่างย่อสำหรับโปรแกรมของคุณ

ถามตัวเองสามคำถามนี้ก่อนที่จะเสียเวลาด้านวิศวกรรมไปกับ v3.0:

• มีผู้บริโภคใบรับรองของคุณรายใดบ้าง ไม่ว่าจะเป็น ATS ของนายจ้าง คณะกรรมการออกใบอนุญาต หรือสถาบันพาร์ทเนอร์ ที่กำหนดให้ต้องมีผลลัพธ์แบบ CLR 2.0 หรือ W3C VC อย่างชัดเจนหรือไม่? ถ้าไม่มี v2.0 ก็เพียงพอสำหรับคุณแล้ว
• ผู้รับของคุณจำเป็นต้องเก็บใบรับรองนี้ไว้ในแอป wallet ดิจิทัล ไม่ใช่แค่โปรไฟล์เว็บหรือ LinkedIn หรือไม่? ถ้าไม่ v2.0 ก็เพียงพอสำหรับคุณแล้ว
• คุณกำลังสร้างโครงสร้างพื้นฐานความน่าเชื่อถือข้ามผู้ออกที่การตรวจสอบแบบ hosted โดยอิง URL ไม่เพียงพอจริง ๆ หรือไม่? ถ้าไม่ v2.0 ก็เพียงพอสำหรับคุณแล้ว

หากคุณตอบว่า “ไม่” ทั้งสามข้อ การใช้งาน v2.0 ในปี 2026 ไม่ได้ทำให้คุณล้าหลังแต่อย่างใด คุณแค่กำลังจับคู่สเปกให้เข้ากับระบบนิเวศที่บริโภคมันจริง ๆ ต่างหาก กลับมาทบทวนคำถามนี้อีกครั้งเมื่อมีพาร์ทเนอร์หรือข้อกำหนดด้านการปฏิบัติตามกฎระเบียบเฉพาะรายขอ v3.0 โดยระบุชื่อชัดเจน ไม่ใช่จากความรู้สึกทั่วไปว่า “v3 ใหม่กว่า”

หากต้องการทราบเพิ่มเติมว่าข้อมูลการตรวจสอบตราสัญลักษณ์ดิจิทัลเทียบกับรูปแบบใบรับรองแบบเก่าที่ไม่ได้มาตรฐานได้อย่างไร โปรดดู Blockchain Certificates vs Open Badges ซึ่งเจาะลึกเรื่องข้อแลกเปลี่ยนด้านการตรวจสอบและความพกพาได้จากมุมมองที่ต่างออกไป

---

พร้อมที่จะออกใบรับรองที่ตรวจสอบได้ใบแรกของคุณแล้วหรือยัง? เริ่มต้นใช้งานฟรีที่ badges.ninja — เครื่องมือออกแบบด้วยภาพ, หน้าตรวจสอบสาธารณะ, ใบรับรอง PDF, ผลลัพธ์ Open Badge v2.0 ไม่ต้องใช้บัตรเครดิต