Setup
We will set up a DID Registry Service inside a tenant. If you don't have a tenant yet, you can learn how to create one here.
Endpoint: /v1/{target}/resource-api/services/create
| API Reference
Example Request
curl -X 'POST' \
'https://{orgID}.enterprise-sandbox.waltid.dev/v1/{target}/resource-api/services/create' \
-H 'accept: */*' \
-H 'Authorization: Bearer {yourToken}' \
-H 'Content-Type: application/json' \
-d '{
"type": "did-registry"
}'
Path Parameters
orgID
: - When performing operations within an organization, it is essential to use the organization's Base URL or another valid host alias. For example, if your organization is namedtest
, your default Base URL will betest.enterprise-sandbox.walt.dev
when using the sandbox environment.target
: resourceIdentifier - The target indicates the organization + tenant in which to create the new Credential Store service and the service's ID ({organizationID}.{tenantID}.[NewDidRegistryServiceID]
), e.g.waltid.tenant1.did-registry1
Body Parameters
type
: serviceType - Specifies the type of service to create. In our casedid-registry
Response Codes
201
- Service created successfully.
Service Dependencies
The DID Registry relies on the DID Store Service to retrieve and manage DID:web
identifiers. Specifically:
- When a DID:web is registered via the DID Store, it becomes accessible via the DID Registry.
- The DID Registry queries the DID Store to list registered
DID:web
identifiers. - The DID Registry provides a resolution endpoint
(did.json)
to return the DID document of aDID:web
.
Configuration
To add the DID Store as a dependency to the DID registry service, use the following API request:
curl -X 'POST' \
'http://waltid.enterprise.localhost:3000/v1/waltid.users.didregistry/did-registry-service-api/dependencies/add' \
-H 'accept: */*' \
-H 'Content-Type: application/json' \
-d 'waltid.users.didstore'
This configuration ensures that the DID Registry can efficiently access and manage registered DID:web identifiers.
Tenant-Level DIDs
The DID Registry Service is designed to work with tenant-level DIDs. This means that the DIDs it manages are scoped to a specific tenant within the organization. When you create a DID using the DID Service, it will be associated with the tenant in which the DID Registry Service is set up.
Example: did:web:{orgID}.enterprise-sandbox.waltid.dev:users:bob
Accessible At: https://{orgID}.enterprise-sandbox.waltid.dev/users/bob/did.json
These DIDs represent individual tenants (e.g., users) under an organization.
Setup:
Create a Tenant:
curl -X POST http://{orgID}.enterprise-sandbox.waltid.dev/v1/waltid.users/resource-api/tenants/create \
-H 'accept: */*' \
-H 'Content-Type: application/json' \
-d '{"configuration": { "didRegistry": "didregistry" }}'
Verify Configuration:
curl -X GET http://{orgID}.enterprise-sandbox.waltid.dev/v1/waltid.users/tenant-api/tenants/config/view \
-H 'accept: application/json'
Create the DID Registry Service:
curl -X POST http://{orgID}.enterprise-sandbox.waltid.dev/v1/waltid.users.didregistry/resource-api/services/create \
-H 'accept: */*' \
-H 'Content-Type: application/json' \
-d '{"type": "did-registry"}'
Organization-level DIDs
The DID Registry Service can also manage organization-level DIDs. These DIDs are scoped to the entire organization and are not limited to a specific tenant. They are useful for representing entities that manage or oversee multiple tenants within the Enterprise stack.
Example: did:web:{orgID}.enterprise-sandbox.waltid.dev:alice
This represents a DID associated with an organization.
Accessible at: https://{orgID}.enterprise-sandbox.waltid.dev/alice/did.json
.
Organization-level DIDs are used for entities that manage or oversee tenants within the Enterprise stack.
Configuration
To configure an organization-level DID, use the following API request:
curl -X 'POST' \
'http://{orgID}.enterprise-sandbox.waltid.dev/v1/organization/update-config' \
-H 'accept: */*' \
-H 'Content-Type: application/json' \
-d '{
"rootDidRegistry": "waltid.didregistry"
}'