ArchitectureEducation
Architecting verifiable digital credentials for diplomas and micro-credentials
A verifiable credential is a diploma, certificate or badge that an employer or admissions office can check without calling the issuer. This page explains the education standards stack (W3C Verifiable Credentials, Open Badges, the Comprehensive Learner Record and European Digital Credentials), how issuers manage signing keys and revocation, how learner wallets and verifiers interact, and where a distributed ledger adds value.
On this page
- From PDF certificates to signed, portable credentials
- The education credential standards and how they relate
- Issuing and verifying a credential, message by message
- Issuer keys, rotation and institutional governance
- Hosting issuer keys and status on the web, on a ledger, or both
- Where a distributed ledger helps and where it does not
- Choosing credential formats by who will verify them
- Risks in running an education credential service
- A business school issues stackable micro-credentials
- Questions and answers
- Sources
From PDF certificates to signed, portable credentials
Paper and PDF certificates are easy to forge and slow to verify: an employer either contacts the registrar or trusts the document. Hosted digital badges made achievements easier to share, but in their earlier form verification usually depended on the issuer's server still hosting the assertion. When a platform closed or a URL moved, the badge stopped verifying.
The current generation moves trust into the credential itself. 1EdTech's Open Badges 3.0 (OB 3.0) restructures each badge as a W3C Verifiable Credential signed by the issuing organization and aligned with the Verifiable Credentials Data Model 2.0, rather than relying on a hosted copy12.
The practical effect is that a learner can keep a credential in a wallet of their choice and present it years later, and a verifier can check who issued it, that nobody altered it and whether it was revoked, all without contacting the registrar.
The education credential standards and how they relate
Four specifications do most of the work in education, each answering a different question.
- W3C Verifiable Credentials Data Model
- The base format for tamper-evident claims, with issuer, holder and verifier roles. Version 2.0 became a W3C Recommendation in May 2025, together with specifications for securing credentials and publishing their status3.
- Open Badges (OB 3.0)
- 1EdTech's standard for a single achievement as a verifiable credential: what was achieved, the criteria, the evidence and the recipient. It defines a JWT-based proof format and an embedded Linked Data proof format1.
- Comprehensive Learner Record (CLR 2.0)
- A verifiable credential that bundles many achievement assertions, possibly from several providers, into one transcript-like record whose achievement definitions are shared with OB 3.04.
- European Digital Credentials for Learning (EDC)
- The European Commission's format for electronically sealed credentials, built on the European Learning Model, aligned with W3C Verifiable Credentials and issuable to a learner's Europass wallet5.
- Decentralized identifier (DID)
- An identifier, for example one using the did:web method, that resolves to the public keys a verifier needs to check an issuer's signature.
- Bitstring Status List
- A W3C Recommendation for publishing revocation or suspension status as a compressed list of bits, in which each credential points to one position6.
Issuing and verifying a credential, message by message
- Student system (SIS)
The record of achievement stays authoritative; credentials are generated from it, never edited by hand.
- Issuer service
Builds the credential, signs it with the institution's key and assigns a status-list position.
- Key and status host
Serves the issuer's public keys and status lists so verification works without the registrar.
- Learner wallet
Holds credentials the learner controls and creates a presentation for each verifier.
- Employer or admissions
Checks signature, issuer identity, status and expiry, then decides what the credential means to them.
Issuer keys, rotation and institutional governance
The issuer's signing key is, in effect, the institution's signature. Keep it in a hardware security module or managed key service, separate signing from the systems that decide awards, and name an owner: the registrar, central IT or a credentialing office.
Plan rotation from the first day. Credentials signed with a retired key must still verify, so the DID document or key host keeps publishing old public keys with their validity periods; a compromised key is flagged so verifiers reject anything signed with it afterwards.
Revocation needs equal care. A status list lets the issuer withdraw a credential issued in error without revealing who was affected, provided each list is large enough that one position says little. Expiry suits credentials that genuinely lapse, such as a safety certification, but not degrees.
Hosting issuer keys and status on the web, on a ledger, or both
| Concern | Institution's web domain | Public ledger anchor | Hybrid |
|---|---|---|---|
| Verification if the domain lapses | Fails unless the domain is kept for as long as credentials matter | Keys and status history stay resolvable | The ledger copy covers domain loss |
| Key history and audit | Depends on the institution's own records | Ordered, timestamped history of key and status changes | Ledger records changes; the web serves current state |
| Operating effort | Lowest: standard web hosting | Ledger account, fees and monitoring | Both, plus keeping them consistent |
| Personal data exposure | Nothing personal needs publishing | Nothing personal on-chain; keys and status only | Same as the ledger option |
| Fits when | The issuer is long-lived and controls its domain | Consortia, programs with shared governance or issuers that may not last | High-value credentials checked by many kinds of verifier |
A ledger does not make a weak credential trustworthy. It changes where keys and status are published and who can alter them.
Where a distributed ledger helps and where it does not
A ledger is useful in credentialing for three things: a durable, timestamped record of issuer keys; a shared registry when several institutions issue under one framework; and an anchor for revocation records that must outlive any single website. The Hedera Consensus Service, for example, provides ordered, timestamped messages suited to such a registry.
It is not a place for the credentials. Diplomas contain personal data, and rights such as erasure cannot be honored on an immutable public record. Keep credentials in wallets and issuer systems and publish only keys and status; even hashes can be personal data if they link back to a person.
ColdAI's decentralised identity practice implements W3C DID standards with selective disclosure and zero-knowledge proofs7, and our case study on Claude Shannon International University describes academic credentials issued as verifiable on-chain certificates8.
Choosing credential formats by who will verify them
- If
Most verifiers are US employers, licensing bodies or institutions using learning and employment record tools.
ThenIssue OB 3.0 credentials for individual achievements and a CLR 2.0 for transcript-style bundles.
These are the 1EdTech standards that wallets and verifier tools in that ecosystem implement.
- If
Learners will apply for jobs or study across the EU and use Europass.
ThenIssue European Digital Credentials, sealed through a trust service provider under eIDAS.
Europass is built to store, display and verify EDCs.
- If
You serve both audiences.
ThenKeep one award record in the SIS and generate each format from it.
Each format is signed on its own terms; converting one into another breaks signatures and duplicates revocation.
- If
Learners need to prove one fact, such as degree completion, without revealing grades.
ThenIssue separate, narrower credentials, or use a format that supports selective disclosure; our comparison of credential formats sets out the trade-offs.
A single signed transcript discloses everything in it every time it is shared.
Risks in running an education credential service
Signing key compromise
Early signalUnexplained issuance, or a private key stored on an application server.
MitigationHardware or managed key storage, approval steps for issuance, and a rehearsed rotation and revocation procedure.
Loss of the domain or platform
Early signalVerification depends on a vendor-hosted URL or a domain nobody is responsible for renewing.
MitigationOwn the issuer identifier, use a DID method you control and consider a durable anchor for keys and status.
Correlation through identifiers
Early signalThe same learner identifier appears in every presentation to every verifier.
MitigationUse wallet-held or per-verifier identifiers where supported, and avoid plain email addresses as recipient identifiers.
A business school issues stackable micro-credentials
Questions and answers
Are blockchain diplomas more secure than signed digital credentials?
Not inherently. The security of a digital diploma comes from the issuer's signature and how well the signing keys are protected. Putting a diploma on a blockchain adds no protection if keys are poorly managed, and storing personal data on an immutable ledger creates data protection problems. A ledger is useful for publishing issuer keys and revocation status durably, which is a narrower and more defensible role.
What is the difference between Open Badges and a Comprehensive Learner Record?
An Open Badge is one achievement packaged as a verifiable credential: a course, a skill or a certificate, with its criteria and evidence. A Comprehensive Learner Record bundles many achievement assertions, possibly from several providers, into a single transcript-like credential. They share achievement definitions, so institutions commonly issue badges as each achievement is earned and a CLR when a learner needs the whole record.
How does an employer verify a digital diploma?
The learner shares the credential from a wallet, usually by link or QR code. The employer's verifier software checks the signature against the issuer's published key, confirms the issuer is who it claims to be, checks the status list for revocation and checks any expiry date. None of this requires contacting the registrar. The employer still decides what the achievement means for the role.
What happens to issued credentials if the issuing college closes?
Signed credentials keep their content, but verification depends on someone still publishing the issuer's keys and status. If the college's domain lapses, credentials tied to it can stop verifying. Plans for this include agreements for another body to host keys and status, issuer identifiers that do not depend on one domain, or anchoring keys on a ledger. It is worth deciding before the first credential is issued.
Sources
- Open Badges Specification, Version 3.0 — 1EdTech Consortium · checked 10 October 2026
- 1EdTech releases updated standard for digital credentials (Open Badges 3.0) — 1EdTech Consortium · checked 10 October 2026
- The Verifiable Credentials 2.0 family of specifications is now a W3C Recommendation — World Wide Web Consortium · checked 10 October 2026
- Comprehensive Learner Record Standard, Version 2.0 — 1EdTech Consortium · checked 10 October 2026
- European Digital Credentials for Learning — European Commission (Europass) · checked 10 October 2026
- Bitstring Status List v1.0 — World Wide Web Consortium · checked 10 October 2026
- Decentralised Identity (DID): W3C DID standards, selective disclosure and zero-knowledge proofs — ColdAI
- Claude Shannon International University: on-chain academic credentials — ColdAI