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

Onboarding Walkthrough

This is the ordered customer runbook for bringing up an EDK deployment and onboarding the first tenant. All calls go through the gateway:

  • https://platform.<base-domain> for setup, operator sign-in, platform administration, and the admin console.
  • https://<tenant>.<base-domain> for tenant protocol routes and protected tenant administration APIs.

Do not call workload container hostnames, container ports, health routes, or gRPC receivers directly. TLS terminates at the customer gateway with a certificate valid for platform.<base-domain> and *.<base-domain>.

Prerequisites​

The enterprise stack is running from the published Nexus artifacts:

  • Docker images from nexus.sphereon.com/edk-docker.
  • Helm chart from https://nexus.sphereon.com/repository/edk-helm when deploying on Kubernetes.
  • A platform database owned by the platform service.
  • A separate tenant workload database used by tenant-KMS, DID, tenant-AS, issuer, and verifier, with schema-per-tenant isolation by default.

Step 1: Complete Platform Setup​

Open the platform host:

https://platform.<base-domain>

Complete first-run setup there. Setup installs or imports the protected license bundle and creates the first platform operator account. The setup API exists at /api/platform/setup/v1 only while the setup gate is open; after setup it returns 404.

Reference: Platform onboarding.

Step 2: Sign In as Platform Operator​

After setup, open:

https://platform.<base-domain>/admin-console

The operator signs in through the platform authorization server using the authorization-code flow with PKCE. Platform-admin calls carry the resulting operator bearer token.

Reference: Operator sign-in.

Step 3: Create the Tenant​

Create the tenant from the admin console or through:

POST /api/platform/admin/v1/tenants

Tenant setup provisions the default tenant authorization server, the tenant-named KMS provider and default key aliases, the tenant did:web identifier, and the tenant gateway endpoint bindings. If issuer and verifier are selected, setup also creates and binds those instances.

Poll the onboarding correlation id until the workflow reports COMPLETED, then verify the tenant and gateway endpoint bindings through the Platform Admin API.

Reference: First tenant.

Step 4: Use the Tenant Gateway​

After onboarding, tenant calls use:

https://<tenant>.<base-domain>

Wallet-facing protocol paths and well-known documents are unauthenticated where the protocol requires it. Tenant administration paths, including KMS, DID, issuer, verifier, and DCQL administration APIs, require a tenant-scoped bearer token and are still reached through the tenant gateway host.

Reference: Tenant keys and did:web and Enterprise deployment walkthrough.

Scripted Path​

For automation, use the Postman collection and provisioning scripts from the deployment repository. The customer environment uses baseDomain, platformUrl, and tenantGatewayUrl; it does not contain per-container service URLs.

Reference: Downloads and Provisioning and onboarding.