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

#Service Dependencies

The diagram below illustrates how the services interact:

• 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:

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