I Read the DID and VC Specs So You Don't Have To

You don't own your Twitter username. The company does. If the platform shuts down tomorrow, that identity is gone — you can recreate it somewhere else, but it's not the same. Your followers, your history, your reputation — tied to a string that a corporation controls.

This is a common but mostly ignored problem. And it applies to more than social media. Your GitHub account, your email, your developer identity — all of it lives on servers you don't control, owned by companies that can revoke access, change the rules, or simply disappear.

DIDs — Decentralized Identifiers — fix this by giving you a cryptographic identifier that you control. No company in the middle. No account to get banned. Just a keypair that's yours.

What is a DID?

A DID is just a string. Three parts: the scheme (did), the method (example, hedera, key), and a unique identifier. Like this:

The method tells you where this DID lives and how to look it up. did:hedera:mainnet:abc123 lives on Hedera. did:key:abc123 is self-contained in the string itself. Different methods, same concept.

The string alone is useless. What matters is what it resolves to — the DID Document. Think of resolution like DNS: you put in a domain name, you get back an IP address. You put in a DID, you get back a document describing who controls it.

That document looks like this:

{
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "type": "Multikey",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "z6MkmM42vxfqZQsv4..."
  }]
}

The authentication field is the important part. It says: "whoever holds the private key matching this public key controls this DID." That's your proof of ownership — not a password, not a company's database. A cryptographic keypair you hold.

Verifiable Credentials — a digital passport

A VC is simply a verified claim about you — issued, signed, and portable.

Think of a passport. The government (issuer) says "this person is a citizen of this country" and stamps it with their authority. You (holder) carry it. The border officer (verifier) checks it.

VCs work the same way, just digital:

Issuer — any entity that makes a claim about you. In Hiero's case, Heka issues a VC saying "this GitHub account owns this GPG key."
Holder — you. The VC lives in your wallet.
Verifier — whoever needs to check the claim. In Hiero, the GitHub App verifies your VC when you open a PR.

The key difference from a real passport — nobody needs to call the government to verify it. The issuer's signature is enough. Fully offline, fully cryptographic.

Verifiable Presentations are what you send to a verifier. You take your VC, wrap it, and sign it yourself. This proves two things at once — the issuer made this claim, and you are the one presenting it right now.

A Real Example — Hiero Contributor Verification

This isn't theoretical. The Hiero open source ecosystem is building exactly this for GitHub contributor identity, using the Heka Identity Platform.

Onboarding flow:

You log in with GitHub
Heka creates a wallet and a DID for you
You link your GPG key to that DID
Heka issues a VC: "this GitHub account owns this GPG key"
Done — your identity is now verifiable without Heka being involved in every check

Verification flow:

You open a pull request
A GitHub App webhook fires
The App resolves your DID and retrieves your DID document
It checks your Verifiable Presentation
Reports pass or fail as a GitHub status check

I've been exploring this codebase as part of applying for the LFDT mentorship program and built a stub GitHub App that demonstrates the verification flow: hiero-contributor-verify. Currently uses stub data but testnet integration is coming.

What is a DID?

Verifiable Credentials — a digital passport

A Real Example — Hiero Contributor Verification

Further Reading

Reading List