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:
- Overview
- Request
- Response
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.
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:
- Overview
- Request
- Response
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.
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:
- Overview
- Request
- Response
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.
Connect an environment to rewrite this call to real service bases and run it.
- Overview
- Request
- Response
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.
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:
- Overview
- Request
- Response
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.
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:
- Overview
- Request
- Response
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.
Connect an environment to rewrite this call to real service bases and run it.