Platform foundations

Platform foundations prepares an existing tenant before any credential exists. Issuance and verification both depend on the same three things: a tenant that resolves to the intended host and capabilities, key material the platform can sign with, and an authorization server that grants tokens. These journeys set that up once. The Credential issuance and Credential verification groups both assume it is done, and they can be followed in either order afterwards.

Every journey opens with a read, so you see the data you are about to add to or change before you change it.

Journeys in this group

Journey	What it covers	Complete first
1. Connect Azure KMS with BYOK and BYOC	Read the KMS resources and offerings, configure an Azure Key Vault provider, register an existing key and its certificate chain, and remove references safely.	An operator-provisioned tenant
2. Configure the authorization server	Read the tenant authorization servers, create and activate a hosted server, register clients, and tune its token and grant settings.	An operator-provisioned tenant
3. Federate wallet sign-in to Keycloak	Create a hosted wallet proxy authorization server, register the Keycloak realm as an external resource, federate to it, and bind the proxy to the issuer.	Configure the authorization server
4. Use the Developer Console	Read the tenant Developer Console policy, discover the mounted API operations and their OpenAPI documents, and export a Postman collection.	An operator-provisioned tenant

Platform operators can onboard a tenant before a service client exists. Those platform-origin requests require operator authorization, so they are documented separately from the tenant Developer Console journeys.

Authentication boundaries

Four authorities appear across all journeys, and a token from one never substitutes for another.

• Platform operator. Platform OAuth administration, such as registering a tenant or offering a shared Azure vault, uses platform operator authorization. It never calls tenant-scoped configuration.
• Tenant application. A tenant confidential client obtains a Client Credentials token on the tenant's default authorization server. That token authorizes tenant-scoped management operations: KMS, authorization servers, issuer and verifier settings, designs, status lists and trust domains.
• Wallet. The wallet OAuth configuration issues wallet issuance tokens with different authority. They are restricted to that wallet issuance session and never authorize administration.
• Anonymous. Public metadata and hosted status-list reads use no authentication. A public status URI is fetched anonymously; do not copy a management bearer token into that request.

Choose the right surface

Each step links its Admin Console path, its REST operations and any static capture. Use the Admin Console for guided configuration, the REST reference for an integration contract, and the Developer Console or Postman for repeatable discovery and execution. The surfaces share identifiers, but a successful request on one surface does not prove that a later wallet or verifier step completed.

Postman setup

For the complete developer sequence, download the canonical EDK-Enterprise-Deployment.postman_collection.json and set baseDomain and tenantSlug. Each top-level folder has its own OAuth2 configuration. Use Postman's Get New Access Token and Use Token on 1. Platform operator with the platform operator account, then run Tenants to find or register the tenant. Activate the tenant owner in a browser, then use 2. Tenant owner: create a service client to register a service client, a confidential client on the tenant's default AS that uses the client credentials grant.

On 3. Tenant APIs, obtain a Client Credentials token using that service client. The imported OAuth configuration includes one audience parameter per tenant service in the token request body. Keep these advanced token parameters: the platform, KMS, DID, AS, issuer, verifier and blob APIs validate their own audiences. Tenant REST requests inherit this folder's OAuth configuration. Platform-owned resource sharing uses 1. Platform operator > Share an Azure Key Vault with tenants (optional), with platform operator authorization. The tenant accepts the offer using 3. Tenant APIs > Azure Key Vault (optional) > Use a vault shared by the platform. See the Postman setup steps.

For Keycloak, 3. Tenant APIs > Keycloak wallet login (optional) > Set up the wallet proxy creates a separate hosted wallet AS and federates its user authentication upstream. Issue EuPid with a Keycloak login uses its own wallet OAuth configuration. Administrative client credentials and wallet issuance tokens have different authority. The default tenant AS stays local only.

Postman manages administrative access tokens per folder; no token variable is needed. Public metadata and hosted status-list reads use no authentication. The optional pre-authorized OID4VCI grant uses an explicit token request because Postman has no OAuth helper for that grant. Its token is restricted to that wallet issuance session.