Decentralized Identity
Your identity shouldn't depend on any company. Decentralized identity lets you prove who you are without a middleman.
The Problem with Centralized Identity
Today, your online identity is fragmented and dependent:
Problems:
- Different identity on each service
- Platforms can terminate accounts
- No way to prove these are the same person
- Reputation and history locked in silos
| Problem | Impact |
|---|---|
| Platform accounts | You're @alice on Twitter, alice@gmail.com on Google |
| OAuth dependency | "Sign in with Google" means Google controls your access |
| Account termination | Platforms can delete your account |
| No portability | Can't take followers, reputation, or history |
| Surveillance | Platforms track everything |
Decentralized Identifiers (DIDs)
A DID is an identifier that:
| Property | Description |
|---|---|
| You control | No registration authority needed |
| Globally unique | Works across all systems |
| Cryptographically verifiable | Prove you own it with a signature |
| Portable | Take it anywhere |
| Persistent | Doesn't expire or get revoked |
DID Syntax
Examples:
did:nostr:npub1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkxl8ltdid:web:alice.example.comdid:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
How DIDs Work
DID Document contains:
{
"@context": "https://www.w3.org/ns/did/v1",
"id": "did:nostr:npub1abc123...",
"verificationMethod": [{
"type": "SchnorrSecp256k1",
"publicKeyHex": "abc123..."
}],
"authentication": ["#key-0"],
"service": [{
"type": "SolidStorage",
"serviceEndpoint": "https://pod.example/"
}]
}
The DID Document contains:
| Field | Purpose |
|---|---|
verificationMethod | Public keys for authentication |
authentication | Which keys can authenticate |
service | Endpoints (pod, social profiles, etc.) |
assertionMethod | Keys for signing credentials |
keyAgreement | Keys for encryption |
DID Methods in SAND
Comparison
| Method | Resolution | Infrastructure | Use Case |
|---|---|---|---|
| did:nostr | Derive from key | None | Personal identity |
| did:web | HTTPS fetch | Domain | Organizations |
| did:key | Derive from key | None | Ephemeral |
did:nostr
Uses Nostr keypairs as identifiers. Simple, no infrastructure needed:
did:nostr:npub1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqkxl8lt
| Aspect | Detail |
|---|---|
| Resolution | Decode npub to get public key |
| Signing | secp256k1 Schnorr signatures |
| Infrastructure | None required |
| Portability | Perfect—key is the identity |
Your Nostr keypair is your identity. See did:nostr for details.
did:web
Uses your domain as your identifier:
did:web:alice.example.com
Resolution:
GET https://alice.example.com/.well-known/did.json
| Aspect | Detail |
|---|---|
| Resolution | HTTPS fetch |
| Trust | Domain ownership |
| Infrastructure | Web server |
| Use case | Organizations, established entities |
did:key
A DID that's just a public key — no resolution needed:
did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK
| Aspect | Detail |
|---|---|
| Resolution | Decode multibase string |
| Trust | Key possession |
| Infrastructure | None |
| Use case | Ephemeral, quick verification |
Authentication Flow
How you prove identity with DIDs:
No password. No OAuth. Just cryptography.
Verifiable Credentials
DIDs enable Verifiable Credentials — digital credentials that are:
| Property | Description |
|---|---|
| Issued by any party | University, employer, government |
| Held by you | In your wallet, under your control |
| Verified by anyone | Without contacting the issuer |
| Privacy-preserving | Share only what's needed |
Credential Flow
Credential Types
| Type | Example |
|---|---|
| Educational | Degrees, certificates |
| Professional | Licenses, memberships |
| Government | ID, passport, drivers license |
| Financial | Credit scores, bank verification |
| Social | Membership, reputation |
Benefits
| Centralized Identity | Decentralized Identity |
|---|---|
| Provider can revoke access | You control your keys |
| Different identity per service | One identity everywhere |
| Provider stores your data | You control your data |
| Locked into ecosystems | Portable across systems |
| Single point of failure | No central authority |
| Surveillance by default | Privacy by design |
Key Management
Your keys are critical:
| Practice | Why |
|---|---|
| Backup | Lose keys = lose identity |
| Secure storage | Hardware wallet or encrypted storage |
| Key rotation | Update keys periodically |
| Recovery plan | Social recovery or backup keys |
Key Storage Options
| Option | Security | Convenience |
|---|---|---|
| Hardware wallet | Highest | Lower |
| Mobile app (Amber) | High | High |
| Browser extension | Medium | High |
| Paper backup | Medium | Low |
Integration with SAND
One identity → All protocols → All services
Getting Started
- Generate a Nostr keypair — Use Noskey, Amber, or any Nostr client
- Your npub is your DID —
did:nostr:npub1... - Use it for authentication — Sign in to services with your Nostr key
- Store credentials — Keep verifiable credentials in your wallet
- Control access — Decide what to share and when
Learn More
- DID Protocol — Technical specification
- did:nostr — Nostr-based DIDs
- did:key — Key-based DIDs
- did:web — Domain-based DIDs
- Nostr Protocol — The underlying infrastructure
- Universal Resolver — Resolve any DID