did:ethr

A did:ethr DID is anchored to an Ethereum address (or a secp256k1 public key). The core document (DID Document) is not stored on-chain; instead, a smart contract registry (like the ERC-1056 EthrDIDRegistry) records public key updates and service endpoints. This creates a permanent, cryptographically verifiable link between an identity and its controlling keys.

• DID Format: did:ethr:<network>:<address>
• Registry: Stores key management events (add/revoke) and service endpoints.
• Resolution: Clients query the registry to reconstruct the current, valid DID Document.

did:ethr is used to create self-sovereign identities for users, organizations, and devices within the Ethereum ecosystem.

• User Logins: Passwordless authentication for dApps and services using Sign-In with Ethereum (SIWE).
• Verifiable Credentials: Issuing and presenting tamper-proof digital attestations (e.g., proof of KYC, membership).
• Decentralized Attestations: Projects like EAS (Ethereum Attestation Service) use it to sign and verify off-chain data.
• DAO & Governance: Linking a persistent identity to a wallet for reputation and voting systems.

The method is supported by major libraries and integrated into prominent identity stacks.

• Libraries: The official ethr-did and did-jwt libraries by uPort (now Consensys Mesh).
• Identity Wallets: Integrated into wallets like MetaMask via Snaps and Valora.
• Verification Services: Used by Veramo, a modular framework for SSI, and Spruce ID's Sign-In with Ethereum.
• Enterprise: Adopted by Microsoft's ION (which uses a Sidetree protocol atop Bitcoin, but did:ethr is a key parallel for the Ethereum ecosystem).

Developers choose did:ethr for its low friction and crypto-native design.

• Familiar Tooling: Works directly with existing Ethereum wallets and keys; no new key management needed.
• Low Cost: Most identity operations (key rotation, service updates) are simple, low-gas transactions.
• Interoperability: Compliant with W3C DID Core specifications, enabling compatibility with the broader SSI landscape.
• Proven Security: Inherits the security of the Ethereum blockchain and its elliptic curve cryptography.

did:ethr is often compared to other blockchain-based DID methods.

• vs did:key: did:ethr provides an on-chain registry for key rotation and service endpoints, while did:key is a simple, off-chain method without update capabilities.
• vs did:web: did:ethr is decentralized and cryptographically verifiable via blockchain consensus, whereas did:web relies on the security and availability of a traditional web domain.
• vs did:ion: Both support high-frequency operations, but did:ion uses a layer-2 protocol on Bitcoin, while did:ethr is native to the Ethereum execution layer.

The ecosystem is evolving with new standards to deepen integration. EIP-5805: Delegatable Ethereum-backed DIDs is a key proposal.

• Delegation: Allows a primary DID (e.g., a company) to delegate signing authority to subordinate DIDs (e.g., employee wallets), enabling complex organizational structures.
• Enhanced Use Cases: Facilitates enterprise adoption, DAO sub-committees, and automated agent-based interactions.
• Forward Compatibility: Designed to work with existing did:ethr infrastructure, ensuring a smooth upgrade path for current adopters.

Replaces traditional username/password or centralized OAuth with a cryptographic login flow. Users sign a challenge with their Ethereum private key (e.g., via MetaMask) to prove control of their DID. This creates a seamless, passwordless, and phishing-resistant authentication method for Web3 applications.

• Key Benefit: No custodial accounts or data silos.
• Example: A DeFi platform uses did:ethr to authenticate users and securely associate their on-chain reputation with their identity.

Serves as the foundational identifier for issuing and holding Verifiable Credentials (VCs). An issuer (like a university or DAO) can sign a credential (e.g., a diploma or membership proof) linked to a user's did:ethr. The user can then present this credential to any verifier, who can cryptographically check the issuer's signature against the DID's on-chain DID Document.

• Key Benefit: Enables portable, user-controlled credentials that are tamper-proof and instantly verifiable.

DAOs and other decentralized entities use did:ethr as their official, on-chain legal identity. The DID can be controlled by a multisig wallet or a smart contract, with authorization rules encoded on-chain. This allows the organization to:

• Sign agreements verifiably.
• Manage resource permissions (e.g., treasury access).
• Issue credentials to members or partners.

This creates a trust layer for organization-to-organization (B2B) interactions in Web3.

Provides the public key infrastructure for end-to-end encrypted communication. Applications can resolve a user's did:ethr to obtain their current public key from the Ethereum Name Service (ENS) or on-chain registry, enabling secure messaging without relying on a central directory.

• Protocols: Used in frameworks like Waku and XMTP for wallet-to-wallet chat.
• Key Benefit: Communication channels are tied to a user's sovereign identity, not a platform-owned account.

Mitigates duplicate or fake identities in decentralized governance systems. By requiring a DID linked to a unique Ethereum address (with a non-zero cost of creation), projects can implement one-person-one-vote models instead of one-token-one-vote. Users prove control of their DID to claim voting power, making Sybil attacks economically impractical.

• Example: A DAO uses did:ethr to distribute non-transferable governance rights to verified contributors.

While anchored to Ethereum, the did:ethr method is designed for interoperability. Through DID resolvers and universal resolvers, this identity can be recognized and used across different blockchain ecosystems and standards-compliant platforms. The DID Document can also contain service endpoints for other chains.

• Key Benefit: A single, user-controlled identity can interact with multiple chains and verifiers, avoiding fragmentation.

The Ethereum DID Registry is a smart contract (e.g., the ERC-1056 standard). Its security depends on the correctness of its code and the integrity of the underlying blockchain. Risks include:

• Reentrancy or logic bugs in the registry contract.
• Upgrade mechanisms for the registry, which could be malicious or compromised.
• Gas price manipulation (e.g., via time-dependent attacks) to front-run legitimate DID updates. Users must trust the specific deployed instance of the registry contract.

DID operations are subject to Ethereum's consensus and network conditions.

• Chain Reorganizations: A block containing a DID update could be orphaned, temporarily reverting the DID's state.
• Finality Delay: On proof-of-work chains, waiting for sufficient confirmations is critical before considering an update final.
• Network Congestion: High gas fees can make updating or revoking a DID prohibitively expensive during attacks, delaying critical security responses.

did:ethr allows a DID controller to appoint delegate keys (via the registry) to perform specific actions (e.g., signing verifiable credentials) without exposing the primary key. Security considerations:

• Scope Limitation: Delegates should be granted minimal, time-bound permissions.
• Delegate Key Security: A compromised delegate key grants the attacker its assigned capabilities.
• Revocation Lag: Revoking a malicious delegate requires an on-chain transaction, which is not instantaneous.

The core did:ethr identifier is derived from an Ethereum public key. This creates inherent correlation risks:

• The same Ethereum address used for a DID and for financial transactions links identity to all on-chain activity.
• Key rotation (changing the controlling key) is recorded on-chain, creating a public history of ownership changes.
• Privacy-focused solutions like semantic hiding or using a fresh, dedicated address for the DID are necessary to mitigate this.

DID Resolution is the process of retrieving a DID Document from a DID. For did:ethr, this involves querying the Ethereum blockchain. The process uses a DID Resolver, a software component that:

1. Parses the DID string to extract the method (ethr) and identifier (an Ethereum address or public key).
2. Reads the relevant Ethereum Registry for DIDs (ERC-1056) smart contract to fetch the current public key and metadata.
3. Constructs and returns a standardized DID Document in JSON-LD format.

ERC-1056 is the foundational Ethereum Improvement Proposal that defines the smart contract interface for the did:ethr method. This on-chain registry, deployed at a specific address, allows an Ethereum account (the identity owner) to:

• Register and manage the public keys associated with their DID.
• Delegate signing authority to other keys or smart contracts.
• Set attributes (like service endpoints) for their DID Document.
• Revoke previous keys or delegates, enabling key rotation and recovery.

Self-Sovereign Identity is a model where individuals and organizations have exclusive ownership and control over their digital identities without relying on centralized authorities. did:ethr is a technological implementation of SSI principles on Ethereum. It enables:

• Portability: Identities are not locked into a single provider.
• Interoperability: Works across different systems and platforms using W3C standards.
• User Consent: The identity owner controls what information is shared and with whom.
• Minimal Disclosure: Using Verifiable Credentials, users can prove specific claims without revealing their entire identity.