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 a VDX capability and is not covered here.
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. The body decides where the service is advertised: set host to a verified custom domain to advertise on that host, or set pathPrefix to root the service under the tenant's platform subdomain, 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. The same 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 on its container-deployment page:
- Container Deployment: Issuer: credential designs and attribute sources.
- Container Deployment: Verifier: verifier DCQL and trust.
- Container Deployment: AS: AS clients and federation providers.