DID Management: Identifiers
Catalog id: resource.did.identifiers
Tenant DIDs and the detail view used to inspect and, when the method allows, manage verification methods, relationships, and services. A DID is a public document that points at keys; it is not a second key store. Private material stays under Key Management.
Whether any DID is already present depends on how the product onboards tenants and users—not on a fixed Admin Console activation step.
Open it
| Navigation | Resources > DID Management > Identifiers |
| Deep link | #resource=did&rarea=identifiers |
| Scope | Tenant |
Identifiers list
Table columns: Alias, Method, DID (truncated), Status. Toolbar: search and method filter.
Open a row for the identifier detail (tabs below). Empty list means onboarding has not created identifiers yet, or the product expects operators/automation to create them later.
- Admin Console
- REST API
- Overview
- Request
- Response
List DID identifiers
Endpoint: GET /api/did/v1/identifiers
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Identifier detail
Header shows method, alias (or DID), and full DID when an alias is set. Back returns to the list. Four tabs:
| Tab | Purpose |
|---|---|
| Overview | Method, alias, DID, controllers; verification relationships; deactivate when allowed |
| Keys | Verification methods (public key bindings), often linked to KMS key aliases |
| Services | DID document service endpoints |
| JSON | Resolved DID document as JSON (copy) |
What you can change is gated by the DID method’s capability summary (create/update/deactivate, key management, service management). Flags that are off keep the matching actions disabled.
Overview tab
- Details: method, alias, full DID, controllers / also-known-as
- Relationships: which verification methods serve which purposes (authentication, assertion, key agreement, …). Add or remove a purpose↔VM binding when the method allows update.
- Lifecycle: Deactivate when the method supports deactivation
Relationships are not the same as the Keys tab: Keys lists the verification methods themselves; Overview assigns those methods to relationship purposes.
Keys tab (verification methods)
Table of verification methods for this DID:
| Column | Meaning |
|---|---|
| Alias | Linked KMS key alias when present; otherwise the VM id |
| Key type | From linked key metadata, or “public only” when no KMS link is exposed |
| Purposes | Relationship purposes attached to this VM |
Search filters alias and id. Remove is enabled only when method capabilities allow key management and update. Adding VMs is only available when the product/method supports it (capability-gated).
Match aliases here with Key Management > Keys when the product uses those keys for protocols.
- Admin Console
- REST API
Use the Keys tab on the detail screenshot above after opening an identifier.
List verification methods for a DID:
- Overview
- Request
- Response
List verification methods
Endpoint: GET /api/did/v1/identifiers/did%3Aweb%3Aacme.example.com/verification-methods
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Resolve the identifier (document + metadata used by Overview / JSON):
- Overview
- Request
- Response
Resolve DID
Endpoint: GET /api/did/v1/identifiers/did%3Aweb%3Aacme.example.com
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.
Services tab
Service entries on the DID document (id, type, service endpoint). Add / Remove when the method supports service management. Endpoints are public document data—not Admin Console routing configuration.
JSON tab
Pretty-printed resolved DID document. Copy when available. Same logical document products may also publish for method-specific public resolution (for example did:web).
- Admin Console
- REST API
Open JSON on the identifier detail after selecting a DID.
Example public did:web document (no bearer), when the product publishes one:
- Overview
- Request
- Response
Fetch hosted did.json
Endpoint: GET /.well-known/did.json
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Connect an environment to rewrite this call to real service bases and run it.