---
title: "Overview"
description: "A DID Web Registry facilitates the distribution of did:web identifiers and their associated public keys, serving as a trust anchor within decentralized identity ecosystems."
stack: "Enterprise Stack (commercial) — version 0.21.0"
stack_version: "0.21.0"
stack_comparison: https://docs.walt.id/community-vs-enterprise.md
canonical_url: https://docs.walt.id/enterprise-stack/services/did-registry/overview
generated: 2026-07-20
---
# Overview

A **DID Web Registry** facilitates the distribution of `did:web` identifiers and their associated public keys, serving as a **trust anchor** within decentralized identity ecosystems.

The **DID Registry Service** in the walt.id Enterprise Stack provides a flexible, multi-tenant solution for creating and managing DID Web Registries.

## Capabilities

The DID Registry Service enables:

- Flexible hosting configurations for various domain and namespace combinations.
- Listing of all registered `did:web` identifiers.
- Resolution of a specific `did:web` into its `did.json` document.

**Note:**

Note that this service does not generate or persist DIDs directly.  
reference. Use [DID Service](https://docs.walt.id/enterprise-stack/services/did-service/overview.md) in combination with the [DID Store Service](https://docs.walt.id/enterprise-stack/services/did-store-service/overview.md) for persisting DIDs.

## Service Dependencies

The diagram below illustrates how the services interact:

![DID Registry Dependencies](https://docs.walt.id/img/enterprise-stack/services/DID-Registry-Service-Dependencies.png)

- **DID Registry Service**: Hosts the DIDs. Depends on the **DID Store Service**, which persists them.
- **DID Service**: Creates DIDs and stores them in the DID Store Service. Uses the **KMS Service** for key operations.
- **DID Hosting Alias Service** (optional): Allows tenants to use custom domains instead of the default enterprise stack domain.

## DID Registry Configuration

The DID Registry Service supports two use cases:

### 1. Use Case: Organization Level DID:WEB Registries
- Registry bound to the **organization** within the walt.id Enterprise Stack.
- DIDs are scoped across the entire organization (not limited to individual tenants).
- Best suited for entities managing multiple tenants in one stack.

DIDs will have the pattern: `did:web:{sub-domain}.{domain]:{user} (e.g. did:web:org1.enterprise.com:alice)`.

More information regarding [Organization Level DID:WEB Registries](https://docs.walt.id/enterprise-stack/services/did-registry/organization-level-did.md)

### 2. Use Case: Tenant Level DID:WEB Registries
- Registry bound to a **tenant or sub-tenant**.
- DIDs are scoped to that specific tenant.
- Useful when isolation between tenants is required.

DIDs will have the pattern: `did:web:{sub-domain}.{domain]:{tenant}:{user} (e.g. did:web:org1.enterprise.com:tenant1:alice)`.

More information regarding [Tenant Level DID:WEB Registries](https://docs.walt.id/enterprise-stack/services/did-registry/tenant-level-did.md)

## Service & Web Resource Hierarchy

The diagram below shows how Enterprise Stack resources map to web resources and how `did:web` identifiers are constructed:

![DID Web Registry Hierarchy](https://docs.walt.id/img/enterprise-stack/services/DID-Web-Registry-Single-Domain-Hierarchy.png)

1. **Organization** – The root resource in the Enterprise Stack. By default, the organization name is prefixed to the deployment domain (e.g., `org.enterprise.domain.com`).
2. **Tenant** – Addressed by the tenant name as a path parameter in the URL.
3. **DID Registry** – A resource within a tenant, addressed via an additional path parameter.
4. **DIDs** – Created by the DID Service. Each DID receives a unique path for resolution.

## Hosting Alias Service

The **Hosting Alias Service** can optionally map a custom domain to an organization or (sub-)tenant.

For example, the domain `tenant.com` can be bound to a tenant in the Enterprise Stack. DIDs for this tenant then follow the pattern: `did:web:tenant.com:{user} (e.g. did:web:tenant.com:alice)`.