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 runs at most one OID4VCI issuer, one OID4VP verifier, and one OAuth2 authorization server per tenant. Running many instances of a service per tenant, for example several issuer programs under one tenant, is outside the scope of this deployment flow.
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 (credential designs, attribute sources, verifier DCQL, AS clients and federation providers) lives in the tenant's configuration. 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 attribute sources.
- Verifier role: verifier DCQL and trust.
- AS role: AS clients and federation providers.