How Verifiable Credentials Actually Work

Blockchain for Academic Credentials — Part 2 of 3: The Architecture

In Part 1 I argued that diploma verification barely needs a blockchain, and that the hard problem is trust, not tampering. Now let’s look at how the system actually works — because once you see the moving parts, you’ll understand exactly where (and whether) a chain belongs.

The trust triangle

Every verifiable credential system has three roles:

• Issuer — the university that issues the credential.
• Holder — the student who receives and holds it.
• Verifier — the employer who checks it.

Three data objects flow between them:

• DID (Decentralized Identifier) — an identity like did:web:snu.ac.kr. Resolving it returns a DID Document containing that party’s public keys.
• VC (Verifiable Credential) — the signed credential: a set of claims (“this person holds a 2026 bachelor’s degree”) plus the issuer’s signature.
• VP (Verifiable Presentation) — the wrapper the holder builds around one or more VCs to present them, adding their own signature on top.

Step 1 — Identities (DID)

Each party has a keypair and a DID. How the DID is created is exactly where blockchain does or doesn’t enter:

• did:key — generated locally from a keypair. No chain, no server. Usually the student.
• did:web — the university publishes its public key at snu.ac.kr/.well-known/. Relies on domain trust, no chain.
• did:ethr — public keys and key-rotation history recorded in an on-chain registry (ERC-1056). This is the first place a chain appears.

Step 2 — Issuance (OID4VCI)

The student logs into the university’s issuing portal; the university builds a VC and sends it to the student’s wallet. The standardized flow for this is OID4VCI (OpenID for Verifiable Credential Issuance). Conceptually the VC looks like this:

{
  "issuer": "did:web:snu.ac.kr",
  "credentialSubject": { "id": "did:key:studentDID", "degree": "Bachelor", "year": 2026 },
  "credentialStatus": { "type": "BitstringStatusList", "index": 50 },
  "proof": { "...issuer signature..." }
}

The proof is everything. Because the university signed the whole document with its private key, changing a single field breaks the signature. Roughly 80% of “forgery prevention” is already done right here — with a signature, no blockchain required.

Step 3 — Holding

The issued VC lands in the student’s wallet, not on a university server. This is the core of self-sovereign identity: even if the university shuts down, the student still owns and controls the credential. (It’s also, not coincidentally, where the trust-anchor problem from Part 1 lives.)

Step 4 — Presentation and verification (OID4VP)

On an employer’s site, the student clicks “apply with DID,” their wallet opens, and they submit selected VCs wrapped as a VP. This flow is OID4VP. The verifier then checks four things, in order:

1. Issuer signature — is the VC’s proof really signed by the university’s key? (Resolve the issuer’s DID Document, compare keys.)
2. Holder binding — is the person presenting the VP the same subject the VC was issued to? (Prevents using someone else’s credential.)
3. Revocation — has this VC been revoked? (See Step 5.)
4. Trust anchor — does did:web:snu.ac.kr genuinely belong to the university? ← the governance step that cryptography can’t settle.

Step 5 — Revocation, the tricky part

A VC can’t be un-issued, but degrees do occasionally get revoked. The common solution is a status list: a long bit-string the issuer publishes, where each VC carries a pointer (“check position 50”). To revoke, flip bit 50 from 0 to 1. At verification time, the verifier fetches the list and reads that bit. Put the list on a web server and you need no chain; put it in a smart contract and you have an on-chain revocation registry.

The shape of it

So the lifecycle is issue → sign → hold → present → verify → revoke. Notice how much of it runs on signatures and a status list alone. The blockchain, when present, slots into just a few spots — issuer registry, revocation, anchoring — which is exactly what Part 3 is about.

---

Tags: Verifiable Credentials, Decentralized Identity, Self Sovereign Identity, Web3, Blockchain