Decentralized Identity

Overview

Replace domain-based email addresses with self-sovereign identities (DIDs) that users control independently of service providers.

Problem Statement

Current email addresses are: - Provider-locked: user@gmail.com is owned by Google - Not portable: Changing providers means changing identity - Centralized: Provider controls verification and reputation - Domain-dependent: Small domains lack reputation

Vision

Traditional: user@msgs.global (owned by msgs.global)

Decentralized: did:msgs:user123 (owned by user, resolved via msgs.global or any resolver)
              or user@user.id (self-hosted DID, works with any mail provider)

Architecture

1. DID Methods

did:msgs:abc123           # msgs.global-managed DID
did:web:alice.com         # Self-hosted via HTTPS
did:key:z6Mkf...          # Pure cryptographic identity
did:ion:EiDk...           # Bitcoin-anchored (Sidetree)

2. DID Document

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:msgs:alice123",
  "authentication": [{
    "id": "did:msgs:alice123#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:msgs:alice123",
    "publicKeyMultibase": "zH3C2AVvL..."
  }],
  "service": [{
    "id": "did:msgs:alice123#email",
    "type": "EmailService",
    "serviceEndpoint": "https://msgs.global/api/v1/did/alice123/inbox"
  }],
  "alsoKnownAs": [
    "mailto:alice@msgs.global",
    "mailto:alice@alice.com"
  ]
}

3. Message Addressing

From: did:msgs:alice123
To: did:msgs:bob456

[Message body]

Resolved to actual SMTP delivery via DID document lookup.

Key Benefits

1. Portability

User keeps identity when switching providers
Multiple providers can serve same DID
No lock-in

2. Verifiable Credentials

{
  "@context": "https://www.w3.org/2018/credentials/v1",
  "type": ["VerifiableCredential", "EmailVerificationCredential"],
  "issuer": "did:msgs:msgs.global",
  "credentialSubject": {
    "id": "did:msgs:alice123",
    "verifiedEmail": "alice@msgs.global",
    "reputation": {
      "score": 95,
      "since": "2024-01-01"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-07T20:00:00Z",
    "verificationMethod": "did:msgs:msgs.global#key-1",
    "proofValue": "..."
  }
}

3. Reputation Portability

Reputation attached to DID, not email address
Take your reputation when you migrate
Multi-provider reputation aggregation

4. Privacy

Correlation-resistant DIDs (different DID per context)
Pseudonymous communication
Selective disclosure

Integration Scenarios

Scenario 1: Gradual Migration

Phase 1: DIDs as aliases (alice@msgs.global + did:msgs:alice123)
Phase 2: DID-first (did:msgs:alice123, with mailto fallback)
Phase 3: Pure DID (legacy SMTP deprecated)

Scenario 2: Hybrid Model

User has:
  - Primary DID: did:msgs:alice123
  - Work email: alice@company.com (linked to DID)
  - Personal email: alice@gmail.com (linked to DID)

All messages signed/encrypted with DID keys, but delivered via traditional SMTP

Technical Components

DID Resolver Service

@app.route('/api/v1/did/<did_id>')
def resolve_did(did_id):
    """Resolve DID to DID document"""
    if did_id.startswith('did:msgs:'):
        return resolve_msgs_did(did_id)
    elif did_id.startswith('did:web:'):
        return resolve_web_did(did_id)
    else:
        return resolve_universal_did(did_id)

def resolve_msgs_did(did_id):
    # Lookup in msgs.global registry
    doc = db.query("SELECT did_document FROM dids WHERE id = ?", did_id)
    return doc

def resolve_web_did(did_id):
    # Fetch from HTTPS
    # did:web:alice.com -> https://alice.com/.well-known/did.json
    domain = did_id.replace('did:web:', '')
    response = requests.get(f'https://{domain}/.well-known/did.json')
    return response.json()

SMTP Bridge

def send_to_did(did_id, message):
    """Send message to DID (resolve to SMTP)"""
    # 1. Resolve DID
    did_doc = resolve_did(did_id)

    # 2. Find email service endpoint
    email_service = find_service(did_doc, 'EmailService')

    if email_service['serviceEndpoint'].startswith('https://'):
        # API delivery
        deliver_via_api(email_service['serviceEndpoint'], message)
    else:
        # Find legacy mailto
        mailto = find_also_known_as(did_doc, 'mailto:')
        deliver_via_smtp(mailto, message)

Verifiable Credentials API

@app.route('/api/v1/credentials/issue', methods=['POST'])
def issue_credential():
    """Issue verifiable credential to DID"""
    data = request.json

    credential = {
        '@context': 'https://www.w3.org/2018/credentials/v1',
        'type': ['VerifiableCredential', data['type']],
        'issuer': 'did:msgs:msgs.global',
        'credentialSubject': {
            'id': data['did'],
            **data['claims']
        }
    }

    # Sign with msgs.global's DID key
    signed = sign_credential(credential)
    return signed

@app.route('/api/v1/credentials/verify', methods=['POST'])
def verify_credential():
    """Verify a credential"""
    credential = request.json

    # 1. Resolve issuer's DID
    issuer_did = resolve_did(credential['issuer'])

    # 2. Verify signature
    if verify_signature(credential, issuer_did):
        return {'verified': True}
    else:
        return {'verified': False, 'reason': 'Invalid signature'}

Migration Path for msgs.global

Phase 1: DID Registry (3 months)

[ ] Create DID database schema
[ ] Implement DID resolver API
[ ] Auto-generate DIDs for existing users
[ ] DID document publication

Phase 2: Credential Issuance (3 months)

[ ] Issue email verification credentials
[ ] Port reputation scores to credentials
[ ] Allow users to present credentials

Phase 3: DID Delivery (6 months)

[ ] Support sending to DIDs
[ ] SMTP bridge for DID resolution
[ ] Webmail UI for DID addresses

Phase 4: Full Decentralization (12 months)

[ ] Support did:web (user-hosted DIDs)
[ ] Federation with other DID methods
[ ] Deprecate legacy addressing (optional)

Challenges

Adoption: Chicken-and-egg (senders need receivers)
UX: DIDs are ugly (did:msgs:abc123 vs alice@msgs.global)
Discovery: How do you find someone's DID?
Backward Compatibility: Legacy SMTP for decades
Regulation: Legal name requirements in some jurisdictions

Solutions

Adoption: Start with aliases, gradual migration
UX: Human-readable aliases (alice.msgs -> did:msgs:alice123)
Discovery: DID directories, search services
Compatibility: Transparent SMTP bridge
Regulation: DID can include legal identity claims

Related Standards

W3C DID Core Specification
W3C Verifiable Credentials
did:web Method Specification
did:key Method Specification
Sidetree Protocol (ION, Element)

Status

🔬 Research & Experimentation Phase

Next Steps

Deploy DID resolver (did:msgs method)
Issue credentials to test users
Build DID address book in webmail
Prototype DID-to-SMTP bridge
Measure adoption and UX friction