Skip to main content
Version: v0.25.0 (Latest)

Keys and DID

The Admin Console is the admin backend UI of a product built on EDK, not a separate "platform only" tool. Operators use Key Management and DID Management for cryptographic keys (sign, encrypt, decrypt, MAC, and related ops) and DIDs that publish public key material. Private material stays in tenant KMS.

What already exists when you open these screens depends entirely on how that product onboards tenants and users. One product may pre-provision a software KMS, keys, and a did:web; another may show empty lists until an operator or product-specific automation creates them. This page documents the console surfaces and matching REST, not a single onboarding recipe.

Screenshots are from the Admin Console. Click a shot for full 1920x1080. REST for the same actions is on the REST API tab; each capture uses the same Overview / Request / Response / API reference layout as elsewhere in the docs. Connect an environment (bottom-right) to Run live calls and Open in Admin Console on your deployment.

Audience: tenant admin, or platform operator working in a tenant context.

Prerequisites: console access for the tenant (or API tokens for the tenant public admin APIs and platform-config tenant routes). A tenant that your product has already created.

Console reference (same screens): Providers, Keys, DID Identifiers, DID Methods

Terms​

TermMeaningConsole / API
KMS resourceManagement record for a key store (software, AWS KMS, Azure Key Vault, ...)Providers (joined table); .../kms/resources
Runtime providerWhat KMS uses for key ops (providerId, type, default)Same Providers table; GET /api/kms/v1/providers
KeyAlias + type/algorithm in a providerKeys; GET /api/kms/v1/keys
DIDPublic document binding verification methods to an id (e.g. did:web)Identifiers; DID API and public DID resolution

Providers merges resource and runtime views. Keys lists aliases across providers. Open a DID for verification methods linked to those keys.

When you Add KMS, provider id is permanent (keys reference it; it cannot be renamed). Product-managed software KMS often uses id default and display name Software KMS; that id is not required to equal the tenant slug.

Providers​

Navigation: Resources > Key Management > Providers
Deep link: #resource=kms&rarea=providers

Table of key stores for the tenant:

  • Name (e.g. Software KMS)
  • Technology (Software KMS, AWS KMS, Azure Key Vault, ...)
  • Owner (This tenant / Platform provided)
  • Status (Ready, Needs credential, ...)
  • Default when this provider is the tenant default for new keys

Empty list means onboarding has not attached a KMS yet, or your product expects operators to add one here.

Open a row for configuration, credential status (write-only; never shown back), and provider-scoped keys. Platform offers, if any, appear under Available from the platform; Enable makes a tenant copy without exposing platform credentials.

Add KMS opens a wizard: technology, credential ownership (product managed vs tenant supplied), provider id (immutable), display name, then technology-specific fields (e.g. key store file vs AWS region / Azure vault URL).

Providers reference

Providers table with Software KMS

Keys list​

Navigation: Resources > Key Management > Keys
Deep link: #resource=kms&rarea=keys

Toolbar: search, Import, Generate key. Table columns: Alias, Key type, Signature algorithm. Operators work with aliases; kid is on the detail page.

If onboarding already created keys for AS, issuer, or verifier, they appear here under product-specific aliases. If the table is empty, create keys with Generate key or Import before binding them in protocols or DIDs. Click a row for detail.

Keys reference

Keys table with aliases

Generate a key​

From Keys, click Generate key. Dialog fields:

FieldWhat you choose
ProviderRuntime provider that will hold the key (defaults to the first / default Software KMS when only one exists)
AliasHuman name you will use later (e.g. custom-wallet-binding)
Key type and algorithmFrom that provider’s reported algorithms (e.g. ECDSA_SHA256, Ed25519)

Provider must be ready. Generate keeps private material in KMS and returns metadata (and public JWK over REST when applicable).

Generate key dialog

Import a key​

From Keys, click Import. Use when key material was created outside the product.

FieldWhat you enter
Public or private JWKJSON with a kty field (EC, OKP, ...)
AliasOptional human name

Invalid JSON or missing kty is rejected in the dialog before submit. REST carries provider and alias on keyInfo.

Import key dialog with JWK and alias

Key detail​

Click an alias in the Keys table:

  • Back to keys
  • Info: alias, key type, signature algorithm, kid (copy)
  • JWK: public JWK when the provider exposes it

Private material is never shown.

Keys reference

Key detail for issuer-signing

DIDs​

A DID is a public document of verification methods and services, not a second key store. How a DID is resolved (for example did:web at a well-known HTTPS URL) is defined by the DID method and by the product’s public identity setup - not by Admin Console navigation and not covered as infrastructure detail here.

Whether any DID already exists when you open Identifiers depends on product onboarding - the same as for KMS and keys.

Identifiers list​

Navigation: Resources > DID Management > Identifiers
Deep link: #resource=did&rarea=identifiers

Table: Alias, Method, DID (truncated), Status. Search and method filter on the toolbar.

Identifiers reference

DID identifiers list

Identifier detail tabs​

Click a row. The detail header shows method, alias, and DID. Four tabs:

TabWhat it showsTypical actions
OverviewMethod, alias, DID, controllers; verification relationships (purpose ↔ verification method); lifecycleAdd/remove relationship bindings; Deactivate when the method allows
KeysVerification methods (alias when linked to KMS, key type, purposes)Search; Remove VM when method allows key management
ServicesService id, type, endpointAdd / Remove when method allows service management
JSONResolved DID documentCopy JSON

Method capabilities gate mutations. Relationships on Overview are not the same as the Keys tab: Keys lists the verification methods; Overview assigns them to purposes (authentication, assertion, ...).

Match verification-method aliases with Key Management > Keys when the product uses those keys for protocols.

Identifiers reference

DID identifier detail tabs

Methods (reference area)​

Navigation: Resources > DID Management > Methods
Deep link: #resource=did&rarea=methods

Read-only list of DID methods the deployment supports and capability flags (create/update/deactivate, key management, service management). No mutations. Full write-up: Methods reference.

Dependency chain​

Dependency chain from KMS resource through provider and keys to DID verification methods and product protocol crypto

Retiring a KMS or deleting keys still bound by DIDs or protocol config breaks those flows. Generate replacements and re-bind before delete.

Next​