Decentralized identity & verifiable credentials

A credential is just four fields: who issued it, who it's about, what it claims, and a signature that ties the first three together. Verifying one is two completely local checks — recompute the signature from the credential's own fields, and look the issuer up in a small list published once, in advance. Switch the issuer above and watch the verdict flip without a single message leaving the browser.

A real system uses public-key signatures; this course's toy stand-in reuses the same toyHash / toyHashPair from the blockchain chapters, so "sign" and "verify" mean one concrete, reproducible computation throughout. A credential is the triple (issuer, subject, claim) plus a signature:

Nobody who doesn't reproduce this exact computation over this exact triple can land on the same number — change one character of the claim, or the subject, or the issuer, and the signature comes out unrelated, with no partial credit. Verifying a credential is two independent checks, both done entirely offline:

• issuer, subject, claim — the three fields the signature is computed over; presented alongside the credential.
• signature — the number the issuer computed at issuance time; the verifier recomputes it and compares.
• trusted-issuer registry — a small, fixed list of issuer names the verifier already holds locally, published once, long before verification time.

1. Recompute the signature

   The verifier reruns the same formula over the credential's own (issuer, subject, claim) fields and checks the result against the signature on the credential. Tamper with any one field and this check fails — there is no live channel back to the issuer that could catch this instead.

2. Check the issuer against a local registry

   Separately, the verifier looks the issuer's name up in its own trusted-issuer list. This list was agreed on once, in advance — enrolling or revoking an issuer updates the list, not any individual verification.

3. Both must pass

   A credential is valid only if the signature recomputes correctly and the issuer is on the trusted list. A self-consistent signature from an untrusted issuer is still rejected — self-sovereign identity means the subject holds and presents their own credential, not that any signer is believed.

Edit the presented claim and watch the recomputed signature stop matching the one actually issued. The credential itself never changes — only what's typed into the "presented claim" field — so this is exactly the check a verifier runs on a claim a subject hands them, with no round trip to the issuer at all.

The State DMV issues Alice a credential for the claim "over-21". Working entirely from the course's shared toy hash, this signs to 227.

1. An untampered presentation verifies

   Alice presents (issuer="State DMV", subject="Alice", claim="over-21", signature=227). Recomputing the signature over those exact fields lands back on 227 — signature check passes. "State DMV" is on the registry — issuer check passes. Both hold: accepted.

2. Tampering the claim breaks the signature check

   Suppose the claim is altered to "over-99" after issuance, keeping the same signature=227. Recomputing over ("State DMV", "Alice", "over-99") gives 216, not 227 — signature check fails on its own, before the issuer is even considered. Rejected.

3. A self-consistent signature from an untrusted issuer still fails

   Now suppose "Fake Issuer" signs the same claim for Alice from scratch: recomputing over ("Fake Issuer", "Alice", "over-21") gives 277, and a credential carrying signature=277 recomputes correctly — the signature check passes, because it was actually produced by that computation. But "Fake Issuer" isn't in the two-entry trusted registry, so the issuer check fails. Rejected — a technically-valid signature is not enough on its own.

4. Both checks passing is the only way through

   Out of the three cases, only the first clears both the signature check and the issuer check at once. That conjunction — not either check alone — is what "valid credential" means.