# Self-Sovereign Identity: From Phone Numbers to Cryptographic Keys

## The Core Question

Who controls your digital identity? The answer places you on a spectrum from
complete institutional dependence to full self-sovereignty.

## Identity Sovereignty Spectrum

| Model | Who Controls | Key Holder | Recovery | Portability |
|-------|--------------|------------|----------|-------------|
| **Phone-as-Identity** | Telecom carrier | Carrier (SIM) | Social engineering | None |
| **Platform-as-Identity** | Platform (Google, etc.) | Platform | Platform flow | None |
| **Domain-as-Identity** | Registrar + You | You | Registrar + rekey | Partial |
| **Self-Sovereign ID** | You alone | You | You (or your network) | Full |

## What is Self-Sovereign Identity?

Self-sovereign identity (SSI) means **your identity IS your cryptographic keypair**.
No institution grants it. No institution can revoke it. You generate it, you hold it,
you control it.

The tradeoff: pure SSI gives you a identifier like `did:key:z6Mkf5rGMoatrSj1f...`
which no human can remember or type. You gain sovereignty but lose discoverability.

## The Three Concerns of Identity

1. **Cryptographic identity** — your keypair (who you ARE)
2. **Human-readable naming** — what people call you (how you're FOUND)
3. **Service hosting** — where your data lives (how you're REACHED)

| Model | #1 Crypto | #2 Naming | #3 Hosting |
|-------|-----------|-----------|------------|
| Phone | Carrier controls | Carrier assigns | Carrier routes |
| Platform | Platform controls | Platform assigns | Platform hosts |
| Domain | You control | Registrar assigns | You choose |
| Pure SSI | You control | Unsolved | You choose |

**Domain-as-identity is the pragmatic middle**: you hold your own keys (sovereignty)
while DNS provides human-readable names (usability).

## How Domain Identity Works
```
You generate keypair → Publish public key at your domain → Others discover via DNS

example.com/.well-known/keys.json
{
  "pubkey": "ed25519:abc123...",
  "endpoints": ["https://example.com/api/"]
}
```

Your domain attests to your key. Your key signs your actions. The domain is
discoverable; the key is sovereign.

## Federated Authentication

If you already have identity on one domain, you can use it to authenticate elsewhere:
```
┌─────────────────────┐         ┌─────────────────────┐
│  stephen@simtable   │ ──────► │  sguerin@embudo.io  │
│  (existing identity)│  signs  │  (new identity)     │
│  pubkey: st1xyz...  │ petition│  pubkey: st1xyz...  │
└─────────────────────┘         └─────────────────────┘
```

The new domain's governance decides whether to trust the existing attestation.
Your cryptographic identity (the keypair) can accumulate attestations from
multiple domains without starting over each time.

## Identity as Membership, Not Property

You don't "own" `stephen@embudo.io` — you have a **relationship** with embudo.io:

- The domain attests: "We recognize pubkey xyz as stephen"
- You attest: "I claim stephen@embudo.io with pubkey xyz"
- Both parties sign the relationship
- Governance defines rights and obligations

This is identity as **membership in a commons**, with:
- Published rules (governance.json)
- Petition process (apply according to rules)
- Signed records (auditable decisions)
- Mutual attestation (both parties commit)

## Where Phone Fits

In a self-sovereign world, phone is just one **bootstrap mechanism** among many:
```
Ways to establish initial identity:
├── Phone verification ──── prove you're human (one-time)
├── Government ID ───────── prove legal identity
├── Existing domain ID ──── prove reputation
├── Web of trust ────────── existing members vouch
├── Proof of work ───────── compute or payment
└── In-person ───────────── key signing party
```

None of these ARE your identity. They're **evidence presented during onboarding**.
Your identity is the keypair you generate, attested by domains you join.

## The Shift

| Old Model | New Model |
|-----------|-----------|
| Phone number = identity | Phone = one verification method |
| Platform grants identity | You generate identity |
| Identity locked to provider | Identity portable across domains |
| Provider can revoke | Only you control keys |
| Trust the institution | Trust the cryptography |

## Key Takeaways

1. **Self-sovereign identity** = your keypair IS your identity, no institution required
2. **Domain identity** = pragmatic middle ground (sovereign keys + readable names)
3. **Federated auth** = use existing domain identity to bootstrap new ones
4. **Identity as membership** = mutual attestation with rights and obligations
5. **Phone's new role** = verification input during onboarding, not the identity itself