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 that this service does not generate or persist DIDs directly.
reference. Use DID Service in combination with the DID Store Service for persisting DIDs.

Service Dependencies

The diagram below illustrates how the services interact:

DID Registry Dependencies

  • 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

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

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

  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).

Last updated on October 2, 2025