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

Tenant Keys and the did:web Identifier

Tenant setup creates the default tenant KMS provider, the signing keys used by AS, issuer, and verifier, and a did:web identifier anchored on the tenant gateway host. Customer calls go through https://<tenant>.<base-domain> with a tenant-scoped bearer token; they do not address workload containers or east-west gRPC ports directly.

Verify the tenant KMS defaults

The provider id is the tenant slug. A new tenant should have exactly the tenant-named provider for tenant runtime operations:

List KMS providers

Endpoint: GET /api/kms/v1/providers

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Tenant setup also creates the default key aliases used by the runtime services. Key material stays in the KMS provider:

List tenant setup KMS keys

Endpoint: GET /api/kms/v1/keys

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Resolve the activation DID

The default did:web identifier uses the tenant gateway host. Resolvers turn did:web:acme.example.com into https://acme.example.com/.well-known/did.json:

List activation-created 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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Resolve activation-created 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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The DID document references the setup-created authentication and assertion keys:

List activation-created DID 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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The public hosting surface serves the DID document at the standard well-known location, unauthenticated and cacheable. This is the URL external resolvers use:

Fetch hosted activation 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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Next, bind the issuing identity to this DID.