Introduction & Philosophy

1. Introduction & Operational Philosophy

What DID.is Is

DID.is is the universal identity resolution, cryptographic evidence verification, and agent trust infrastructure designed for the decentralized web and autonomous AI agent internet. It bridges the gap between low-level cryptographic assertions (such as elliptic curve signatures, hash chains, and verifiable credentials) and high-level trust decisions made by end-users, compliance officers, risk analysts, and automated software agents.

DID.is operates as a decoupled system: a high-performance, deterministic core resolution daemon written in Rust (resolver-core) paired with a Next.js 16 / React 19 presentation and workbench layer (apps/web).

┌───────────────────────────────────────────────────────────────────────────────────┐
│                               DID.is DUAL-TIER ARCHITECTURE                       │
├─────────────────────────────────────────┬─────────────────────────────────────────┤
│  Next.js 16 Presentation & Workbench    │  Rust Core Resolution Daemon            │
│  (apps/web)                             │  (resolver-core)                        │
├─────────────────────────────────────────┼─────────────────────────────────────────┤
│  • Pure client-side input heuristics    │  • Strict W3C DID Core 1.0/1.1 parsing   │
│  • Instant Interactive Showcase         │  • Elliptic curve point validation      │
│  • Four-level progressive disclosure    │  • rustls WebPKI Mozilla root audit     │
│  • Interactive SVG Evidence Graph       │  • Bidirectional DIF Domain Linkage     │
│  • Real-time SSE telemetry renderer     │  • did:webvh SCID & hash chain verifier │
│  • Zero-PII browser memory storage      │  • Fail-closed Bitstring Status List    │
└─────────────────────────────────────────┴─────────────────────────────────────────┘

What DID.is Independently Verifies

When you submit an identifier, credential, or agent endpoint to DID.is, the engine executes direct, non-repudiable checks:

1. DID Syntax & Method Conformance: Validates identifier ABNF against W3C DID Core 1.0/1.1 and executes method-specific driver logic for did:key, did:jwk, did:web, and did:webvh 1.0.
2. Cryptographic Point & Key Material: Validates that public keys decoded from Multibase or JWK representations reside on valid curve points (Ed25519, NIST P-256, secp256k1, or X25519), rejecting points at infinity, small-subgroup attacks, or private key leakage.
3. Transport Security & X.509 Leaf Certificates: Validates HTTPS handshakes via rustls against WebPKI Mozilla root stores, recording leaf certificate validity, subject alternative names (SANs), serial numbers, and expiry windows.
4. Two-Way Domain Linkage: Audits DIF Domain Linkage (/.well-known/did-configuration.json) to confirm bidirectional cryptographic binding: proving that the web origin authoritatively signed a claim asserting control of the DID, and that the DID document lists the origin.
5. Verifiable History Chains (did:webvh): Validates Self-Certifying Identifiers (SCID), SHA-256 entry hash chains, authorized update-key signatures, witness consensus thresholds, and pre-rotation commitments.
6. Verifiable Credentials & Revocation Status: Validates W3C Data Integrity (eddsa-jcs-2022, ecdsa-jcs-2019) and VC-JOSE/VC-JWT proofs, verifying issuer verification methods against assertionMethod relationships, and executing fail-closed Bitstring Status List v1.0 lookups.
7. Autonomous Agent & Tool Trust: Connects to Streamable HTTP Model Context Protocol (MCP) tool servers and Agent-to-Agent (A2A) cards, generating deterministic RFC 8785 schema fingerprints and tracking tool inventory drift.
8. Delegated Authority Chains: Verifies multi-hop delegation receipts, enforcing capability attenuation, validity window containment, and acyclicity back to trusted root authorities.

What DID.is Explicitly Does NOT Prove

To maintain institutional integrity, DID.is enforces strict non-claims:

• No Verification of Legal Corporate Existence: DID.is does not query national corporate registries (e.g., Delaware Division of Corporations, UK Companies House, commercial KYC databases). Real-world organizational identity is fixed at NOT_ESTABLISHED.
• No Guarantee of Host Benevolence or Reliability: The existence of a cryptographically valid key does not prove that the keyholder is honest, solvent, or immune to operational compromise.
• No Defense Against Web Hosting Takeovers on did:web: did:web is method-governed by DNS and web hosting. Whoever controls the underlying web server or DNS records can replace or delete did.json at will without possessing a cryptographic update key.
• No Proof of Private Key Custody: Proving that a document contains an active public key does not guarantee that the holder’s corresponding private key has not been exfiltrated or mishandled.

Grounded Cryptographic Language

DID.is strictly eliminates marketing hype and cryptographic absolutism from all user-facing diagnostics:

• Never use: “tamper-proof,” “unhackable,” “impossible to fake,” or “permanent address.”
• Always use: “tamper-evident” (changes break the SHA-256 hash chain), “cryptographically verifiable” (signatures evaluate mathematically against published keys), “method-governed” (trust bounds depend on method rules, e.g., web hosting vs. SCID logs), and “fail-closed” (unreachable or ambiguous checks default strictly to non-verification).

Audience & Scope: Public Guide vs. Operator Runbook

This document serves as the Public User & Customer Guide. It covers everything public consumers, web clients, relying party engineers, and API subscribers need to know.

Area	This Document (USER_GUIDE.md)	Companion Guide (OPERATOR_RUNBOOK.md)
Primary Scope	Web UI, Universal Command Bar, Dossier navigation, API queries, VCs, MCP/A2A inspection.	Internal AWS EC2 topology, Cloudflare edge secrets, systemd unit files, disk failover.
Security Classification	Public / Client-Safe (Zero privileged data).	Privileged / Internal SRE and On-Call Engineers only.
Data Boundaries	Zero-PII queries, public evidence retrieval, client-side WebCrypto demo.	SQLite schema migrations (v1-v16), write lock serialization, backup routines.
Target Audience	End users, enterprise clients, auditors, developers.	Systems administrators, site reliability engineers.

---

2. The Nutrition Label Model (Truth Over Scores)

Why DID.is Rejects Synthetic 0–100 Trust Scores

Most conventional security tools attempt to reduce complex trust vectors into a single synthetic scalar—such as Trust Score: 88/100 or a colored “Safe” badge. DID.is fundamentally rejects this paradigm as dangerous security theater:

┌────────────────────────────────────────────────────────────────────────┐
│                   THE FALLACY OF THE 0-100 TRUST SCORE                 │
├────────────────────────────────────────────────────────────────────────┤
│  Scenario A: Autonomous Pairwise Agent                                 │
│  • Uses did:key (Ed25519)                                              │
│  • Intentionally ephemeral, no website, no domain linkage              │
│  • Cryptographic Integrity: 100% | Update Authority: SELF_CERTIFYING   │
│  ❌ A synthetic score penalizes it for lacking a website (e.g. 45/100)  │
│                                                                        │
│  Scenario B: Phishing Domain with Free Let's Encrypt Cert              │
│  • Uses did:web on newly registered scam domain                        │
│  • TLS Valid: Yes | Domain Linkage: Present | Keys: Valid             │
│  • Real-World Legal Standing: Fraudulent                               │
│  ❌ A synthetic score awards it 95/100 because all technical boxes pass│
└────────────────────────────────────────────────────────────────────────┘

Synthetic scores create false liability and gameable metrics. An identity that is 100% appropriate for an ephemeral agent-to-agent session is completely inappropriate for an enterprise supplier onboarding workflow. Collapsing multidimensional cryptographic evidence into a single number conceals critical risk factors.

The Orthogonal Evidence Philosophy

DID.is models verification after the FDA Nutrition Facts Label:

Nutrition Label Metric	DID.is Equivalent	Function
Total Sugars	control: NOT_ESTABLISHED	Discloses raw, unvarnished risk factors without moral judgment.
Serving Size	source: HTTPS (1,234 bytes)	Bounded measurement of the exact data retrieved.
Ingredients List	keys: Ed25519 (Multikey)	Concrete breakdown of constituent cryptographic elements.
% Daily Value	Relying Party Policy Engine	The consumer decides if the evidence satisfies their criteria.

Each dimension evaluated by DID.is answers two explicit questions:

1. What it proves: The precise technical fact established by the test.
2. What it does NOT prove: The operational or legal boundaries beyond which the test provides zero guarantees.

Auditable, Falsifiable, and Reproducible Findings

Every statement made in the DID.is web interface is directly falsifiable. The frontend never synthesizes verdicts client-side; every verdict, dimension state, and graph node originates from deterministic execution in resolver-core.

At the bottom of every dossier, DID.is displays the exact curl command to reproduce the findings:

# Reproduce the exact verdict and dimensions using the public API
curl -s "https://did.is/api/v1/resolve/did:web:identity.foundation" | \
  jq '{verdict, dimensions: [.dimensions[] | {id, state, statement}]}'

# Inspect the underlying graph nodes and edges
curl -s "https://did.is/api/v1/graph/did:web:identity.foundation"

---