Set up the credential issuer

In EDK the tenant runs the credential issuers that provisioning created; the issuer service lists them and reads one, but does not create or delete them. Setting one up means finding it, then reading and updating its settings: metadata and display, security, issuance behaviour, credential defaults and the authorization server it uses.

Complete first: Configure the authorization server, Connect Azure KMS with BYOK and BYOC.

Steps and why they come in this order

Step	Why here
1. List your issuers	Open on what already exists. The list gives the issuer id the authorization-server bindings are addressed by, and shows every issuer the tenant runs before one is changed.
2. Read the current issuer settings	Provisioning already wrote settings. Read every settings area first so updates change only what you intend.
3. Update metadata, display and branding	The issuer identifier and display appear in every offer and credential, so settle them before anything is issued.
4. Set security, issuance behaviour and credential defaults	Encryption, batch and missing-claim policy, and issuer-wide defaults apply to every configuration, so they are set once before configurations inherit them.
5. Bind the authorization server	An offer cannot name a token endpoint until the issuer has an enabled default authorization-server binding.
6. Check what the issuer publishes	Stored settings are only half the answer. Compare them with the public metadata a wallet will actually read.

What the API does and does not cover

• Listing, but no instance lifecycle, in EDK. The issuer service lists the tenant's issuers and reads one (/api/oid4vci/v1/instances); the tenant is taken from the access token. Creating, updating and deleting issuer instances is not part of EDK: the tenant gets its issuer when onboarding runs with the issuer capability, and this journey configures it.
• Settings are Platform Config. Everything below is under /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/... and uses the tenant application token.
• Published metadata has no management operation. Wallets read /.well-known/openid-credential-issuer anonymously on the tenant host. No OpenAPI operation returns that document; step 6 shows how to find its URL and compare it with the stored settings.
• Credential configurations are their own journey. Linking credential designs and status lists to the issuer is Configure credential configurations, after the designs and lists exist.

Deeper reference

Issuer configuration maps the Admin Console issuer screens (surface=issuer) and the 10 Issuer Configuration Postman folder. Credential defaults and Issuer authorization servers are the console references for steps 4 and 5.

Next journey

Continue with Design the issuer.