Privacy & Zero-PII Guarantees

9. Data Handling, Privacy, & Security Controls

DID.is is engineered from the ground up for zero data retention, strict client confidentiality, and hostile network environments.

[!IMPORTANT] The Zero-PII Guarantee: Confidentiality in the Explorer

• Zero Private Key Transmission: Searching in the Universal Command Bar, resolving DIDs, and inspecting credentials never transmits, logs, or processes private signing keys. DID.is operates exclusively on public cryptographic keys.
• Zero Search History Tracking: Public Explorer queries do not log or track individual IP search histories. Keystrokes typed into the Command Bar are processed strictly in browser memory without sending autocomplete telemetry to the backend.
• Zero Third-Party Cookies or Trackers: DID.is does not use third-party advertising cookies, marketing pixels, or analytics trackers. Your identity resolution queries remain private to your session.

Zero-PII Verification Architecture

• No Personal Identifiers: DID.is does not collect, index, or store names, email addresses, phone numbers, or IP addresses during resolution.
• Anonymous Public Explorer: Public searches executed via the web UI or CLI do not require an account, emit no tracking cookies, and record zero user identifiers.
• Public Claim Isolation: Claiming control of a DID proves control of a cryptographic key or DNS zone. It does not associate personal identity or corporate registration records with the claim.

Client-Side vs. Server-Side Data Boundaries

• Browser Keystroke Privacy: The Command Bar classification engine (apps/web/src/lib/classify.ts) executes entirely client-side using JavaScript regular expressions and structural checks. No partial queries or keystrokes are transmitted over the network while you type.
• Browser Persistence:
  • localStorage: Retains only non-sensitive interface preferences (theme toggle) and recent search strings stored exclusively on your local device.
  • sessionStorage: Scoped strictly to the active browser tab. Used solely for ephemeral handoffs from the Command Bar to workbenches (e.g., handing off a pasted credential to the /verify workbench).
• In-Memory Core Cache: Public resolution observations are cached in-memory using Moka with a hard budget of 64 MiB (max 2 MiB per entry, 300s TTL). Private resolutions executed with project API keys bypass the shared public cache.

Hardened Egress Client (SafeHttpClient)

Because resolving DIDs requires fetching remote documents (did:web, did:webvh, status lists, MCP endpoints), the core daemon operates in a hostile network environment. All outbound HTTP traffic is routed through a single, fortified client:

┌────────────────────────────────────────────────────────────────────────┐
│                      SAFE HTTP CLIENT EGRESS GATES                     │
├────────────────────────────────────────────────────────────────────────┤
│  1. Scheme Enforcement: HTTPS only (Port 443). No plain HTTP.         │
│  2. Userinfo Rejection: Blocks embedded credentials (https://user:pw@) │
│  3. DNS Validation: Resolves all DNS records before connecting.       │
│  4. Public IP Pinning: Connection is pinned directly to validated     │
│     public IP. Re-resolutions and DNS rebinding attacks fail.          │
│  5. Subnet Blacklist: Blocks loopback (127.0.0.1), private RFC 1918,   │
│     carrier NAT (100.64.0.0/10), and cloud metadata (169.254.169.254). │
│  6. Redirect Constraints: Max 2 redirects; targets must pass all IP    │
│     gates; HTTPS-to-HTTP protocol downgrades are refused.              │
│  7. Streaming Body Caps: 1 MiB standard, 4 MiB logs, 2 MiB MCP.        │
│  8. Upstream Timeouts: Strict 4-second timeout per outbound hop.       │
└────────────────────────────────────────────────────────────────────────┘

Deterministic Offline Context Catalog

JSON-LD implementations are notoriously vulnerable to remote schema poisoning and denial-of-service when fetching @context URIs over the network.

DID.is eliminates this attack surface entirely (ADR-002):

• Zero Remote Schema Fetches: The resolver never issues HTTP requests to download remote @context definitions.
• Compiled Catalog: All normative W3C, DIF, and CCG vocabularies are compiled directly into the binary (context_catalog.rs).
• Audit Reporting: Documents referencing unknown context URIs resolve safely; uncataloged contexts are flagged with known: false in the dossier.

---