Skip to main content

DID Model

zkIdentity uses Decentralized Identifiers (DIDs) to establish a persistent, self-sovereign identity for each user. The DID is derived deterministically from the user's wallet public key, requiring no registration, no central authority, and no on-chain transaction. This document explains the derivation process, the properties of the resulting identifiers, and how they integrate with the broader verification system.

What is a DID?​

A Decentralized Identifier (DID) is a globally unique identifier that does not require a centralized registration authority. DIDs are defined by the W3C DID Core specification and follow a standard URI format:

did:<method>:<method-specific-identifier>

zkIdentity uses the did:key method, which derives the identifier entirely from a cryptographic public key. This is the simplest and most self-sovereign DID method because the identifier is a pure function of the key material -- it exists the moment the key exists.

Derivation Process​

The DID is derived deterministically from the user's Ethereum wallet public key. The general process follows the did:key specification:

  1. Extract the public key from the user's connected wallet.
  2. Encode with multicodec to create a self-describing byte sequence identifying the key type.
  3. Encode with Base58btc to produce a human-readable string.
  4. Assemble the DID by prepending the did:key: prefix.
Wallet Public Key
        |
        v
Multicodec Encoding
        |
        v
Base58btc Encoding (with 'z' prefix)
        |
        v
did:key:z6Mkh...

Properties​

The did:key method provides several important properties for zkIdentity:

Deterministic​

The same wallet always produces the same DID. There is no randomness in the derivation. If two systems independently derive a DID from the same public key, they will produce identical results. This means:

  • Users do not need to "register" their DID anywhere.
  • There is no DID issuance transaction.
  • The DID is immediately available the moment a wallet is connected.

Self-Certifying​

The DID contains its own public key (encoded in the identifier itself). This means:

  • Anyone can extract the public key from the DID and verify signatures.
  • No external resolution infrastructure is needed to obtain the public key.
  • The DID document is implicit and does not need to be stored anywhere.

No Registration Required​

Unlike many DID methods (e.g., did:ethr, did:ion) that require an on-chain registration transaction, did:key requires nothing. This eliminates:

  • Gas costs for DID creation.
  • Dependency on blockchain availability for identity creation.
  • The need for a DID registry contract.

Wallet-Bound​

The DID is intrinsically bound to the wallet's key pair. The user proves ownership of the DID by signing with their wallet. This binding is used throughout the verification flow:

  • The attestor verifies that the session request is signed by the DID's corresponding private key.
  • The ZK proofs cryptographically link the verification to the DID.
  • The on-chain attestation references the DID, connecting it to the wallet.

DID Resolution​

Resolving a did:key is a purely local operation:

  1. Parse the DID string to extract the method-specific identifier.
  2. Decode the Base58btc string (strip the z prefix).
  3. Parse the multicodec prefix to identify the key type.
  4. Extract the public key bytes.
  5. Construct the implicit DID document.

No network requests are required. Resolution is instant and works offline.

Relationship to Ethereum Addresses​

The DID and the Ethereum address are both derived from the same private key but through different processes. They are not directly convertible to each other without access to the full public key. However, both are controlled by the same private key holder.

In practice, the frontend links the DID to the Ethereum address by having the wallet sign both the DID and the address in the session creation request.

Multi-Wallet Considerations​

If a user has multiple wallets, each wallet produces a different DID. Each DID is treated as an independent identity in the zkIdentity system. There is currently no built-in mechanism to link multiple DIDs to the same real-world identity.

This is a deliberate design choice: linking DIDs would reduce privacy by allowing observers to correlate wallets. Users who want to prove their identity across multiple wallets must verify each wallet independently.

Security Considerations​

Key Compromise​

If a user's wallet private key is compromised, the attacker gains control of the associated DID and any attestations linked to it. There is no recovery mechanism for did:key identifiers because the DID is the key. Users should follow standard wallet security practices:

  • Use hardware wallets for high-value identities.
  • Maintain secure backups of seed phrases.
  • Consider using a dedicated wallet for identity (separate from trading/DeFi wallets).

Key Rotation​

The did:key method does not support key rotation. If a user needs a new key, they get a new DID and must re-verify. This trade-off is accepted for the simplicity and self-sovereignty benefits of the method.