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 tenant application 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 deployment sequence, download the canonical EDK-Enterprise-Deployment.postman_collection.json. Start with 00 Start here to discover platform OAuth endpoints. Use Postman's Get New Access Token and Use Token on 01 Platform - create tenant with the platform operator account. Create the tenant and wait for onboarding to complete. Activate the tenant owner in a browser, then use 02 Tenant owner - register application to register a confidential client on the tenant's default AS.

On 03 Tenant application, obtain a Client Credentials token using that client. The imported OAuth configuration includes repeated audience parameters in the token request body for the tenant workloads registered on that client. 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 04 Platform - shared Azure vault, with platform operator authorization. The tenant accepts the offer using 03 / 08 Enable shared Azure provider. See the Postman setup steps.

For Keycloak, 03 / 09 Keycloak wallet proxy creates a separate hosted wallet AS and federates its user authentication upstream. 03 / 20 Authorization code through Keycloak 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; no platformAccessToken or tenantAccessToken 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.