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.
The KMS has no public ingress. Tenant runtime services call tenant-KMS over internal gRPC for key generation, signing, verification, and public-key access. The platform administrative REST is internal and JWT or mesh protected; the public surface is limited to the DID resolver, OAuth and OIDC, the OID4VCI issuer, the OID4VP verifier paths, and the admin console at https://platform.<base-domain>/admin-console.
| 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, and it has no public ingress. |
| 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, and execute the folders in order: later steps consume identifiers captured by earlier ones.
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. 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 wallet-facing protocol endpoints and the public well-known documents accept unauthenticated requests.