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, email, λογότυπο)
• BadgeClass — ο ίδιος ο τύπος του διαπιστευτηρίου (όνομα, περιγραφή, κριτήρια, εικόνα)
• Assertion — η συγκεκριμένη απονομή σε συγκεκριμένο παραλήπτη (ταυτότητα παραλήπτη, ημερομηνία issuedOn, αποδεικτικά στοιχεία, μέθοδος επαλήθευσης)

Το Assertion ενός παραλήπτη παραπέμπει σε ένα BadgeClass, το οποίο παραπέμπει πίσω σε έναν IssuerOrg. Η επαλήθευση γίνεται με έναν από δύο τρόπους· hosted (ο επαληθευτής ανακτά το ζωντανό JSON του Assertion από ένα σταθερό URL και εμπιστεύεται τον τομέα) ή 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 έχει γίνει το de facto πρότυπο· είναι αρκετά απλό ώστε να υλοποιηθεί σε ένα απόγευμα, και είναι αυτό που σχεδόν κάθε καταναλωτής δεδομένων διαπιστευτηρίων περιμένει να δει.

Hosted έναντι signed επαλήθευσης στο v2.0

Αξίζει να κατανοήσετε τους δύο τρόπους επαλήθευσης μέσα στο ίδιο το v2.0, επειδή ο κόσμος συχνά συγχέει το «το v2.0 είναι λιγότερο ασφαλές από το v3.0» με το «η hosted επαλήθευση είναι λιγότερο ασφαλής από τη 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 επαλήθευσης σε 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 είναι ένα signed VC — δεν υπάρχει εναλλακτική λύση «hosted, εμπιστέψου το URL». Η επαλήθευση είναι πάντα μαθηματική, όχι βασισμένη σε τομέα.
• Ταυτότητα εκδότη βασισμένη σε DID. Αντί για ένα αντικείμενο IssuerOrg με URL και email, ο εκδότης αναγνωρίζεται από ένα Αποκεντρωμένο Αναγνωριστικό (DID), το οποίο επιλύεται σε ένα έγγραφο δημόσιου κλειδιού.
• Ευθυγράμμιση με το Comprehensive Learner Record (CLR) 2.0. Το v3.0 σχεδιάστηκε για να συνεργάζεται με το CLR, ώστε ένα μόνο διαπιστευτήριο να μπορεί να φέρει δεδομένα επιτεύγματος συν το είδος των δομημένων λεπτομερειών αναλυτικής βαθμολογίας που περιμένουν οι καταναλωτές CLR (δεξιότητες, αποτελέσματα αξιολόγησης, πλαίσιο εξαμήνου/μαθήματος).
• Συμβατότητα με ψηφιακά πορτοφόλια. Επειδή τα διαπιστευτήρια v3.0 είναι τυπικά W3C VC, μπορούν να διατηρηθούν σε πορτοφόλια ταυτότητας με τον ίδιο τρόπο που μπορεί μια άδεια οδήγησης ή ένα πιστοποιητικό εμβολιασμού — όχι απλώς να εμφανίζονται σε μια ιστοσελίδα.

Με λίγα λόγια· το v2.0 απαντά στο «μπορεί ένας άνθρωπος ή ένα απλό σενάριο να επαληθεύσει αυτό το διαπιστευτήριο», και το v3.0 απαντά στο «μπορεί αυτό το διαπιστευτήριο να συνεργαστεί με το ευρύτερο οικοσύστημα επαληθεύσιμων διαπιστευτηρίων — πορτοφόλια, DID, επίσημα learner records».

Σύγκριση δίπλα-δίπλα

Γιατί η εγκατεστημένη βάση εξακολουθεί να τρέχει σε v2.0

Αυτό είναι το κομμάτι που γέρνει την απόφαση για τα περισσότερα προγράμματα· τα σημεία όπου οι παραλήπτες σας θέλουν πραγματικά να εμφανίζονται τα διαπιστευτήριά τους εξακολουθούν να περιμένουν v2.0. Η ροή Add to Profile του LinkedIn, το Credly, το Badgr και η συντριπτική πλειοψηφία των ενσωματώσεων συστημάτων παρακολούθησης υποψηφίων αναλύουν τη μορφή Assertion/BadgeClass του v2.0. Αν ο στόχος σας είναι «οι παραλήπτες να μπορούν να το δημοσιεύσουν στο LinkedIn και οι recruiters να κάνουν κλικ για να το επαληθεύσουν», το v2.0 δεν είναι μια παρωχημένη μορφή στην οποία έχετε κολλήσει — είναι η μορφή που μιλάει σήμερα το οικοσύστημα.

Καλύψαμε ακριβώς αυτήν την ένταση από την πλευρά του παραλήπτη στο LinkedIn Skill Assessments vs Open Badges — η αξία ενός διαπιστευτηρίου είναι σε μεγάλο βαθμό συνάρτηση του πόσο εύκολα εντάσσεται στα σημεία που ήδη κοιτάζουν οι recruiters και οι συνάδελφοι, και σήμερα αυτό σημαίνει σχεδόν αποκλειστικά υποδομή σε μορφή v2.0.

Πότε το v3.0 έχει πραγματικά σημασία

Το v3.0 δεν είναι υπερβολή· λύνει πραγματικά προβλήματα για συγκεκριμένα προγράμματα·

• Πανεπιστήμια και εκδότες υπό απαιτήσεις CLR. Αν εκδίδετε παράλληλα με ένα επίσημο σύστημα αναλυτικής βαθμολογίας, ή μια πολιτειακή/περιφερειακή εκπαιδευτική αρχή απαιτεί συμβατή έξοδο CLR 2.0, η ενσωματωμένη ευθυγράμμιση του v3.0 σας γλιτώνει από το να προσθέτετε πεδία CLR πάνω σε ένα v2.0 Assertion.
• Προγράμματα που στοχεύουν σε αποθήκευση σε ψηφιακό πορτοφόλι. Αν οι παραλήπτες σας χρειάζεται να κρατούν το διαπιστευτήριο σε μια εφαρμογή πορτοφολιού αντί απλώς να το εμφανίζουν σε μια ιστοσελίδα, μόνο ένα W3C VC (δηλαδή v3.0) θα λειτουργήσει εκεί εγγενώς.
• Ανταλλαγή διαπιστευτηρίων μεταξύ εκδοτών με εμπιστοσύνη βασισμένη σε DID. Αν χτίζετε ή εντάσσεστε σε ένα δίκτυο όπου η ταυτότητα του εκδότη πρέπει να είναι κρυπτογραφικά μεταφέρσιμη αντί για «εμπιστέψου αυτό το URL», τα DID είναι το σωστό εργαλείο.

Καμία από αυτές δεν είναι συνηθισμένη περίπτωση για ένα πρόγραμμα εκπαίδευσης, ένα bootcamp ή έναν εκδότη επαγγελματικής ανάπτυξης το 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 που αναφέρθηκαν παραπάνω — πραγματική μηχανική εργασία, και εργασία που πάει χαμένη αν τίποτα downstream δεν την καταναλώνει ακόμη στην πράξη.

Κοινές παρανοήσεις που αξίζει να ξεκαθαριστούν

• «Το v3.0 είναι πιο ασφαλές.» Όχι απαραίτητα — τόσο το signed v2.0 όσο και το v3.0 βασίζονται σε κρυπτογραφική επαλήθευση. Το πλεονέκτημα του v3.0 είναι η τυποποιημένη ταυτότητα (DID) και η διαλειτουργικότητα πορτοφολιού, όχι μια αναβάθμιση ασφάλειας σε σχέση με το signed v2.0.
• «Το v2.0 έχει καταργηθεί.» Δεν έχει καταργηθεί. Το 1EdTech συντηρεί και τα δύο πρότυπα, και το v2.0 παραμένει η έκδοση στην οποία αναφέρονται οι πλατφόρμες και οι ενσωματώσεις που χρησιμοποιούν πραγματικά οι εκδότες καθημερινά.
• «Πρέπει να διαλέξετε ένα για όλο το πρόγραμμα.» Δεν χρειάζεται. Τίποτα δεν εμποδίζει έναν εκδότη να δημοσιεύει v2.0 για γενική χρήση και να προσθέτει έξοδο v3.0 για μια συγκεκριμένη ενσωμάτωση συνεργάτη που την απαιτεί — τα υποκείμενα δεδομένα απονομής δεν αλλάζουν, μόνο η αναπαράσταση.

Η διαδρομή μετάβασης (και γιατί δεν χρειάζεται να διαλέξετε για πάντα)

Η πρακτική κίνηση για σχεδόν κάθε εκδότη· εκδώστε v2.0 τώρα, και αντιμετωπίστε το v3.0 ως προσθήκη, όχι ως αντικατάσταση, όταν ένας συγκεκριμένος downstream καταναλωτής το απαιτήσει. Μερικοί λόγοι για τους οποίους αυτό λειτουργεί καθαρά·

1. Τα IDs του BadgeClass και του Assertion δεν χρειάζεται να αλλάξουν όταν προσθέσετε αργότερα υποστήριξη v3.0 — προσθέτετε μια δεύτερη, διαφορετικά διαμορφωμένη αναπαράσταση της ίδιας υποκείμενης απονομής, δεν μεταφέρετε τα υπάρχοντα διαπιστευτήρια των παραληπτών.
2. Οι επαληθευτές που καταλαβαίνουν μόνο το v2.0 συνεχίζουν να λειτουργούν ακριβώς όπως πριν.
3. Αποφεύγετε να χτίζετε υποδομή DID και pipelines υπογραφής VC προτού έχετε μια συγκεκριμένη απαίτηση που τα χρειάζεται.

Αυτή είναι η ίδια λογική που χρησιμοποιούμε εσωτερικά στο badges.ninja· κάθε απονομή βγαίνει ως Open Badge v2.0 — JSON-LD, hosted επαλήθευση σε ένα σταθερό URL /certify-badge/award/{guid}, έτοιμο για LinkedIn Add to Profile εξ ορισμού — επειδή αυτό καλύπτει τη συντριπτική πλειοψηφία όσων πραγματικά ζητούνται από τους εκδότες. Αν το πρόγραμμά σας χρειαστεί αργότερα έξοδο v3.0/CLR για έναν συγκεκριμένο θεσμικό συνεργάτη, αυτό είναι μια οριοθετημένη προσθήκη πάνω σε ένα λειτουργικό pipeline v2.0, όχι μια επανεγγραφή.

Αυτή η σειρά σάς προστατεύει επίσης από έναν πιο υποβόσκοντα κίνδυνο· να δεσμευτείτε σε υποδομή DID προτού ξέρετε ποια μέθοδο DID περιμένουν πραγματικά οι συνεργάτες σας. Το οικοσύστημα VC δεν έχει συγκλίνει σε μία μέθοδο DID — το did:web, το did:key, και μέθοδοι αγκυρωμένες σε ledger εμφανίζονται όλες στην πράξη, και η επιλογή της λάθος για έναν πιλοτικό συνεργάτη σημαίνει ότι θα ξαναχτίσετε την εργασία ταυτότητας εκδότη αργότερα. Το να περιμένετε μια κατονομασμένη απαίτηση σημαίνει ότι θα ανακαλύψετε ποια μέθοδο χρειάζεστε πραγματικά προτού χτίσετε οτιδήποτε.

Ένας γρήγορος έλεγχος για το δικό σας πρόγραμμα

Κάντε αυτές τις τρεις ερωτήσεις προτού ξοδέψετε χρόνο μηχανικής στο v3.0·

• Απαιτεί κάποιος καταναλωτής των διαπιστευτηρίων μου — ένα ATS εργοδότη, ένα συμβούλιο αδειοδότησης, ένα ίδρυμα-συνεργάτη — ρητά έξοδο CLR 2.0 ή W3C VC; Αν όχι, το v2.0 σας καλύπτει.
• Χρειάζεται οι παραλήπτες μου να κρατούν αυτό το διαπιστευτήριο σε μια εφαρμογή ψηφιακού πορτοφολιού, όχι απλώς σε ένα προφίλ ιστού ή στο LinkedIn; Αν όχι, το v2.0 σας καλύπτει.
• Χτίζετε υποδομή εμπιστοσύνης μεταξύ εκδοτών όπου η βασισμένη σε URL hosted επαλήθευση πραγματικά δεν επαρκεί; Αν όχι, το v2.0 σας καλύπτει.

Αν απαντήσατε «όχι» και τις τρεις φορές, δεν είστε πίσω επειδή εκδίδετε v2.0 το 2026 — ταιριάζετε το πρότυπο στο οικοσύστημα που πραγματικά το καταναλώνει. Επανεξετάστε το ζήτημα όταν ένας συγκεκριμένος συνεργάτης ή μια απαίτηση συμμόρφωσης ζητήσει το v3.0 ονομαστικά, όχι με βάση μια γενική αίσθηση ότι «το v3 είναι νεότερο».

Για περισσότερα σχετικά με το πώς τα δεδομένα επαλήθευσης διαπιστευτηρίων συγκρίνονται με παλαιότερες, μη τυποποιημένες μορφές πιστοποιητικών, δείτε το Blockchain Certificates vs Open Badges, που εμβαθύνει στις ανταλλαγές μεταξύ επαλήθευσης και φορητότητας από διαφορετική οπτική γωνία.

---

Έτοιμοι να εκδώσετε το πρώτο σας επαληθεύσιμο διαπιστευτήριο; Ξεκινήστε δωρεάν στο badges.ninja — οπτικός σχεδιαστής, δημόσια σελίδα επαλήθευσης, πιστοποιητικό PDF, έξοδος Open Badge v2.0. Δεν απαιτείται πιστωτική κάρτα.