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.