Verifiable Degree Credentials with Instant Employer Checks

The problem with paper degrees and email verification

When a graduate applies for a job, a master's programme or a visa, someone has to confirm the degree is real. Today that usually means attested photocopies, a request emailed to the university registrar, or a paid verification service that takes days or weeks. Fake degrees are a known problem in many countries, and the slow process punishes honest graduates most. Employers abroad often cannot easily contact a local registrar at all.

Meanwhile graduates hand over their full transcript, CGPA and personal details just to prove they finished a degree, because there is no way to show only what is needed.

What already exists and the gap

• MIT's Digital Credentials Consortium built the open source Learner Credential Wallet for W3C Verifiable Credentials; its stewardship has since moved to the OpenWallet Foundation. It is a wallet, not an issuer system a registrar can run.
• Blockcerts is an open standard for blockchain-anchored certificates; it works, but anchoring adds cost and complexity that a signature plus a status list does not need.
• Europass Digital Credentials give European institutions a signed credential format, tied to the EU ecosystem.
• Commercial verification services check degrees by contacting institutions, which is slow and paid per check.

The gap is a small, standards-based issuer and verifier that a single university, college or training provider can run without a blockchain, a vendor contract or national infrastructure.

What you build

Three roles and three apps.

• Issuer (registrar): uploads graduate records, reviews them, and issues signed credentials. Keys live in a separate signing service, never in the web app database.
• Holder (graduate): receives credentials in a wallet, sees exactly what each contains, and shares a presentation by link or QR code.
• Verifier (employer or admissions office): opens the link or scans the code, and the page checks signature, issuer, expiry and revocation, then shows the verified fields.

The issuer publishes its public key and a status list at a well-known URL on its own domain. That is the trust anchor: if the key is served from the university's domain, the credential came from the university.

The technically interesting part

Two things make this worth a final year. First, getting the cryptography and canonicalisation right: a signature over JSON only works if issuer and verifier serialise the data identically, which is exactly the kind of bug that ships to production. Test it by mutating a single character and showing verification fail.

Second, revocation and privacy. A status list is a compressed bitstring where each credential owns one index; the verifier downloads the list and checks one bit. That is private (the issuer does not learn who is being checked) and cheap. Selective disclosure lets a graduate prove "graduated, BS Computer Science, 2026" without revealing grades; explain the approach you chose and its limits honestly. Your supervisor should see a threat model that says what happens if the issuer key leaks, and how key rotation limits the damage.

How to evaluate it

• Security tests: tampered payload, wrong issuer key, expired credential, revoked credential and replayed presentation all fail with the right message.
• Interoperability: your credentials verify in at least one independent verifier, and you document any mismatch.
• Performance: verification time on a mid-range phone and on desktop, including status list download.
• Usability: ten people (graduates and two or three HR staff) complete issue, share and verify tasks; record time and errors.
• Comparison: time to verify one degree with your system versus the current email or attestation process at your own university.

Suggested plan

1. Weeks 1 to 3: read the W3C Verifiable Credentials data model and status list specifications; write the threat model draft.
2. Weeks 4 to 8: signing service, issuer portal and credential schema.
3. Weeks 9 to 12: wallet, sharing by link and QR, verifier page.
4. Semester 2, weeks 1 to 4: revocation, key rotation and selective disclosure.
5. Weeks 5 to 9: interoperability testing and security test suite.
6. Weeks 10 to 14: user study, pilot with one department or society, final report.

Path to a product

Start with a training provider, bootcamp or professional course that issues certificates today as PDFs and gets verification emails; they decide faster than universities. Charge per credential issued or a yearly licence per institution, with free verification for employers. Universities are the larger, slower second market; a pilot with one department's short courses is a realistic entry point. Scale by adding templates for internships, workshops and course completions.

Scope warning

Do not build on a blockchain or issue tokens; the project must show why signatures and a status list are enough. Do not store national ID numbers or connect to government databases. Do not issue real university degrees without the registrar's written approval; use a society, a course or clearly marked test data.

Learn what you need on Sefism

• Backend roadmap : the issuer, signing service and APIs are backend work first.
• Backend cheat sheet : authentication, key handling and API design quick reference.
• JSON Schema: Getting Started : define and validate the credential payload.
• MDN HTTP : caching and serving well-known key and status list URLs correctly.
• EU GDPR Rules for Business : data minimisation principles that justify selective disclosure.

Get help with this idea

Verifiable credentials are a good fit when you can explain exactly what a signature proves and what it does not. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, bring your draft proposal and we will pressure-test it together. You build it; the guidance is on the decisions.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session

New here? Create a free account first.