Building Decentralized Identity Systems on Ethereum

The Problem with Centralized Identity

Every time you log in with Google or Facebook, you are delegating control of your identity to a corporation. They can suspend your account, sell your data, or be breached. Decentralized identity flips this model — you hold your own credentials, you decide what to share, and no single party can revoke your existence.

The W3C has standardized two key specifications that form the foundation of decentralized identity: Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs). Ethereum is one of the most widely adopted DID method registries because it provides a global, permissionless, tamper-proof ledger for anchoring identity claims.

Real-world use cases already in production: Gitcoin Passport for Sybil resistance, ENS names as human-readable DIDs, Ethereum Attestation Service for on-chain credentials, and WorldID for proof of personhood.

Decentralized Identifiers (DIDs) on Ethereum

A DID is a URI that resolves to a DID Document — a JSON object describing the subject's public keys, authentication methods, and service endpoints. The did:ethr method anchors DIDs directly to Ethereum addresses.

A did:ethr DID looks like: did:ethr:0x1234...abcd

The DID Document is derived from the Ethereum address and any updates registered in the ERC-1056 EthereumDIDRegistry contract. The registry stores key rotations and service endpoints without requiring the subject to deploy their own contract.

Key operations:
- setAttribute: publish a public key or service endpoint
- revokeAttribute: remove a previously published attribute
- changeOwner: transfer DID control to a new address (key rotation)

The registry is deployed on mainnet, Sepolia, and most major L2s. The uPort/Veramo SDK provides JavaScript bindings for all registry operations.

Verifiable Credentials and On-Chain Attestations

A Verifiable Credential is a tamper-evident claim made by an issuer about a subject. For example: "This address has completed KYC" or "This developer passed the Solidity certification exam."

VCs are typically stored off-chain (IPFS, user's device) and verified on-chain by checking the issuer's signature. The Ethereum Attestation Service (EAS) provides a generalized on-chain registry for attestations with a schema system.

EAS core concepts:
SchemaRegistry: anyone can register a schema (e.g., { address recipient, bool kycPassed, uint256 timestamp }).
AttestationRegistry: issuers create attestations referencing a schema. Each attestation is a struct stored on-chain with a unique UID.
Revocation: issuers can revoke attestations. Consumers check revocation status before accepting a credential.

EAS is deployed on Ethereum mainnet and Optimism, Base, Arbitrum, and Linea. It is the infrastructure behind Coinbase's onchain verification and Gitcoin Passport's onchain stamps.

Building a DID-Based Login System

Implementing Sign-In with Ethereum (SIWE, EIP-4361) is the simplest form of decentralized identity. The user signs a structured message with their wallet — no password, no OAuth, no server-side session unless you want one.

The SIWE message includes: domain, address, statement, URI, version, chain ID, nonce, and issued-at. The server verifies the signature, extracts the address, and establishes a session.

For richer identity, layer EAS attestations on top of SIWE:
1. User signs in with SIWE to prove address ownership.
2. Backend queries EAS for relevant attestations (KYC, role, membership).
3. Access control decisions are made based on attested claims.

This pattern requires no username, no password, and no centralized identity provider. The user's private key is the only authentication factor. Recovery is handled via social recovery or EIP-7702 delegation.

Privacy Considerations and ZK Identity

Naive on-chain identity is fully public — anyone can see your attestations. For sensitive claims like KYC status, age verification, or medical credentials, zero-knowledge proofs are essential.

ZK identity flow:
1. Issuer signs a credential containing the sensitive claim.
2. The credential is stored privately by the holder (not on-chain).
3. When proving a claim, the holder generates a ZK proof that they hold a valid credential satisfying some predicate (e.g., "age >= 18") without revealing the underlying data.
4. The smart contract verifies the ZK proof on-chain. No sensitive data touches the chain.

Protocols implementing this pattern: Semaphore (anonymous group membership), Polygon ID (ZK VC verification), Anon Aadhaar (Indian government ID proofs), and WorldID (proof of personhood with ZK).

Building production ZK identity systems requires expertise in circuit design and trusted setup. For most teams, integrating an existing protocol like Polygon ID or Semaphore is preferable to building from scratch.