Instance Deployment
A registered tenant has routing, isolation, and an owner, but its issuer, verifier, and authorization server are not yet reachable at the tenant's own URLs. This is the final onboarding step: bind a public endpoint for each service so the tenant advertises and serves it at the right host and path.
The EDK uses one tenant deployment boundary for the OID4VCI issuer and OID4VP verifier runtimes, while the tenant may own multiple UUID-addressed hosted and external authorization-server resources. Authorization-server cardinality is license-controlled and is independent of the number of deployed containers. VDX can additionally deploy multiple issuer or verifier instances for a tenant.
How a Service Becomes Reachable
The three services are configuration-driven. The bootstrap provisions the tenant's default authorization server, and the per-tenant issuer and verifier configuration includes credential designs, connector invocation bindings, verifier DCQL, hosted AS clients, external authorization-server resources, and explicit federation bindings. What turns a configured service into one reachable at the tenant's URLs is a public-endpoint binding: it tells the service what host and path to advertise and serve for that tenant.
Bind a service with PUT /tenants/{tenantId}/public-endpoints/{serviceType} (upsertTenantPublicEndpoint), where {serviceType} is OID4VCI_ISSUER, OID4VP_VERIFIER, or OAUTH2_AUTHORIZATION_SERVER. In the hosted EDK model, set host to the tenant subdomain, for example acme.example.com; for bring-your-own-domain deployments, set host to the verified custom domain. Use pathPrefix only when the service intentionally lives below a path on that host, and set wellKnownPath for the spec-canonical well-known route. See the Platform Admin API reference for the request and response shapes.
Once the binding exists, the service advertises itself at the bound host and path: the issuer's well-known document, credential_offer_uri, and status_uri all root at the binding rather than at the request host. For the default hosted OID4VCI issuer, credential_issuer is the tenant origin, for example https://acme.example.com; it is not the platform host and it is not https://<base-domain>/platform. The same binding rule applies to the verifier and authorization server. Read the bindings back with GET /tenants/{tenantId}/public-endpoints to confirm the host, path prefix, well-known path, and enabled state took effect.
A binding must reference a verified domain for the same tenant, and at most one binding per (tenant, serviceType) is allowed. The binding rules and hardening are covered in Domains and Public Endpoints.
Per-Service Configuration
Each service's own configuration is covered in the Roles and Topology section:
- Issuer role: credential designs and connector invocation bindings.
- Verifier role: verifier DCQL and trust.
- AS role: UUID authorization-server resources, hosted clients and identities, external discovery, and federation bindings.