#Overview

The DID Registry subsystem hosts and resolves did:web identifiers in the walt.id Enterprise Stack. Three services cooperate: the DID Store persists documents, the DID Service creates them, and the DID Registry serves them publicly.

A did:web DID must be created through the DID Service and resolved through a DID Registry. The registry stores nothing — it reads from whichever DID Stores are attached as dependencies.

#The three services

#How did:web maps to a URL

The did:web method encodes the HTTPS location of the DID document:

did:web:<host>:<path-segments>
         │       └── colons in the DID become slashes in the URL
         └── domain (port encoding is also supported)

When creating a DID, the domain and path fields must match the URL you intend to serve. Path segments in the request (users/alice) become colon-separated segments in the DID (users:alice).

#Resolution at a glance

The DID Registry exposes three unauthenticated GET patterns for serving DID documents:

See Resolution for full details, parameters, and response codes.

#Tenant vs organization placement

Both did-registry and did service instances live inside the organization tree. The distinction between "tenant level" and "organization level" is where in the path the service is placed — not a separate service type.

See Setup → Tenant vs organization level for configuration.

#Complete flow

For did:web:example.com:users:alice:

1. Create DID Store at waltid.tenant1.did-store.main
2. Create KMS at waltid.tenant1.kms.main and generate a key
3. Create DID Service at waltid.tenant1.did.main — attach KMS and DID Store dependencies
4. Create did:web via POST .../dids/create/web — document written to the DID Store
5. Create DID Registry at waltid.tenant1.did-registry.main — attach DID Store dependency
6. (Optional) Set rootDidRegistry on the organization
7. Resolve publicly: GET /v1/waltid/users:alice/did.json

Or use Composable Init to bootstrap all services in one request.

#Get started

1. Setup — Provision and wire the three services
2. Create did:web — Generate DIDs with single or multiple keys
3. Resolution — Serve and verify did.json publicly
4. DID Store management — List, view, update, and delete stored DIDs

Advanced:

• External DID Web Hosting — Custom domains, DNS, and reverse proxy
• Full API Reference — Swagger documentation

#Operational endpoints

Service lifecycle and dependency management are documented under Administration → Service Operations:

• Create this service
• View or update configuration
• Manage dependency services