Enterprise Deployment Walkthrough
This walkthrough takes a fresh EDK enterprise deployment from container installation to issuing and verifying credentials. First-run onboarding can be completed with the onboarding web interface, the setup REST API, or offline license resources. The API examples shown here are sanitized captures from the published enterprise containers, so the examples reflect actual wire behavior.
The walkthrough has two parts:
- Part 1, Deploying EDK: installing the enterprise containers and the Helm chart, then onboarding the platform itself: license request or offline license activation, platform administrator bootstrap, setup gate closure, and operator sign-in.
- Part 2, Using the REST APIs: signing in as the platform operator, creating the first tenant, obtaining a tenant-AS service token for runtime services, and building out tenant credential capabilities: signing keys and a did:web identifier, credential designs for an EU Personal ID (SD-JWT) and a mobile driving licence (ISO mdoc), a token status list, issuance over OID4VCI, DCQL queries with selective disclosure, verification over OID4VP, and the authorization code flow.
The services
An EDK enterprise deployment runs a central platform service plus the tenant runtime services. The platform role is its own service so first-run setup, license activation, platform administration, platform configuration, and the platform-only authorization server are separate from the customer tenant-bearing AS. The platform service is also the internal peer that other services call over gRPC for platform configuration.
Customer traffic enters only through the gateway: https://platform.<base-domain> for setup, operator sign-in, platform administration, and the admin console, and https://<tenant>.<base-domain> for tenant protocol routes plus protected tenant administration APIs. Tenant runtime services call tenant-KMS over internal gRPC for service-to-service key generation, signing, verification, and public-key access. Do not publish workload container hosts, container ports, health routes, or gRPC receivers as customer endpoints.
| Service | Role |
|---|---|
| Platform | Internal first-run setup, platform administration, platform configuration, and the platform-only authorization server. |
| Tenant KMS | Key generation and signing. Keys never leave this service; protected administration goes through the tenant gateway and service-to-service signing traffic stays internal. |
| DID | DID management and public did:web resolution. |
| Tenant AS | Customer tenant-bearing OAuth2 authorization server. |
| Issuer | OID4VCI credential issuance, credential designs, and status list management. |
| Verifier | OID4VP verification and DCQL query management. |
| Admin console | Browser UI for platform operators, served at /admin-console on the platform host. |
Following along
Each page links to the relevant API reference for full request and response schemas. To run the same calls yourself, use the Postman collection and environment from the deployment repository under postman/, also available on the downloads page. The collection starts from a small set of seed values, then discovers platform and tenant API bases from runtime config instead of asking you to maintain separate URL variables for every service.
The first-run setup API at /api/platform/setup/v1 is available only while the durable setup gate is open. It creates the signed local license request when needed, installs or consumes the issued license, and enables the platform operator login. A mounted license token alone is not enough on a fresh instance: an operator account still has to be created through setup or supplied as part of a complete mounted bootstrap profile. After setup, open https://platform.<base-domain>/admin-console and sign in with that operator account.
The admin console, onboarding UI, and license portal load browser-safe runtime settings from /api/platform/bootstrap/v1/runtime-config/{applicationId} before sign-in. Service base URLs, audiences, and named endpoints live under data.services. Platform-owned APIs are returned on the platform origin, for example /api/platform/admin/v1 and /api/platform/config/v1. Tenant-owned APIs are returned on tenant origins, for example https://<tenant>.<base-domain>/api/kms/v1 and https://<tenant>.<base-domain>/api/did/v1; they are not platform endpoints. The admin console always uses its same-origin /admin-console/api/* BFF for browser API calls. The BFF uses configured internal service URLs for platform and tenant API calls, forwards the public host and scheme when loading runtime config, and keeps OAuth access and refresh tokens server-side in an HttpOnly session-backed flow.
The apps then call the protected APIs with the operator token or a tenant-scoped service token. Platform-admin requests require the platform operator token from operator sign-in. Tenant runtime services such as KMS, DID, issuer, and verifier use tenant-scoped service tokens where required. Only the setup/bootstrap runtime projection, wallet-facing protocol endpoints, and the public well-known documents accept unauthenticated requests.