Use cases
What You Can Build With DIDs
Agent identity is only useful if other systems can verify it. These are the highest-leverage places to use Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) right now.
Replace API Keys With DIDs
Replace static API keys with DID-based challenge/verify. Issue scoped credentials per agent.
Agent marketplaces
Verify who built an agent, what they are allowed to do, and who vouches for them.
Cross-platform trust
Agents carry their identity and credentials across systems without re-registration.
Delegation + ownership
Prove which human or org owns an agent, and issue verifiable delegation credentials.
Audit-ready compliance
Credentials provide a portable trail of permissions and attestations.
Tool Verification Without Shared Secrets
Let tools verify the agent directly, instead of trusting forwarded secrets.
Real-world problem
The Moltbook Problem
Moltbook is a social network for AI agents. They use API keys for authentication.here's why that's dangerous.
Current Approach (API Keys)
- •Bearer token = identity: The API key IS the agent. If it leaks, you're compromised.
- •Shared secret auth: Must send the key with every request.
- •Complete impersonation: Anyone with the key can fully impersonate the agent.
- •No safe delegation: To give limited access, you must share your master key.
- •No rotation: Compromised key = lose your entire identity.
- •X (Twitter) verification required: Need an X account to post. Centralized gatekeeping in 2025.
DID-Based Solution
- ✓Challenge-response auth: Prove control without revealing secrets.
- ✓Cryptographic signatures: Can't be replayed or stolen.
- ✓Non-impersonatable: Signatures are unique per request.
- ✓Safe delegation: Issue scoped VCs instead of sharing root keys.
- ✓Revocable credentials: Without losing core identity.
- ✓Self-sovereign identity: No X, email, or third-party required. You control it.
The fix: Replace API keys with DIDs. Agents prove ownership through cryptographic signatures, not shared secrets. No X account required. Identity becomes self-sovereign, portable, revocable, and impossible to steal.
How it should work
If Moltbook Used DID Authentication
Here's how agents would authenticate to Moltbook with DIDs instead of API keys:
Owner creates DID
Human or organization generates their decentralized identifier (e.g., did:key:z6Mk...).
Agent creates DID
AI agent generates its own unique DID, completely separate from the owner.
Owner issues Ownership VC
Owner signs a Verifiable Credential proving "I control this agent" and gives it to the agent.
Agent registers on Moltbook
Agent presents its DID and Ownership VC. No API key, no X account, just cryptographic proof.
Challenge-response authentication
Moltbook sends a challenge. Agent signs it with its private key. Moltbook verifies with public key from DID document.
Agent posts and interacts
Every action is signed by the agent. No bearer tokens sent over the wire. Identity can't be stolen.
Portable across platforms
Same DID works on other services. Agent carries its identity everywhere without re-registration.
Result: No shared secrets. No platform dependency. No impersonation risk. Just cryptographic proof of identity that works everywhere.
Go deeper
Learn the DID mechanics, the VC model, and the trust assumptions behind the system.