Issuer configuration

A credential issuer publishes credential metadata and turns a valid issuance session into a credential. It is not an authorization server. The issuer owns issuer identity, credential configurations, signing selections, status references, and protocol profile. OAuth/OIDC resources belong to Authorization-server configuration.

Audience: tenant administrators and developers preparing an issuer for API-driven issuance.

Prerequisites

Complete these guides in this order:

1. Developer journey and authentication boundaries — obtain tenantAccessToken; do not use the platform operator token here.
2. Tenant provisioning and confidential-client access — resolve the tenant and issuer instance ids.
3. Keys and DID — create/select the DID, KMS resource, signing key, and public verification method.
4. Credential designs and claims — create issuer branding and each format- specific credential design.
5. Status-list creation and lifecycle — create each list as a standalone resource and retain its returned id and public URI. The list must exist before binding.
6. Authorization-server configuration — create, validate, activate, and bind the AS. AS configuration is not performed on this page.

After this guide, continue with Credential issuance. Verifier setup is covered by Verifier and DCQL configuration and Trust-domain creation and verifier binding.

What the options control

Area	Controls	Common mistake
Issuer instance	Display name, public route, identity, and enabled state	Using a display name or route as the issuer id; use the returned UUID.
Issuer design	Organisation name, logo, locale, and display card	Putting credential claims in issuer branding.
Signing selection	DID/JWK or X.509 material for metadata and credentials	Choosing a key whose verification method is not publicly resolvable.
Credential configuration	Format, stable id, design, claims, proof, and status profile	Assuming a library design is automatically issuable.
Status binding	Existing list id, purpose, allocation policy, and public URI	Binding a future list name or KMS key before the list exists.
AS binding	Which hosted/external AS supplies grants and token endpoints	Assuming the issuer owns OAuth clients or token endpoints.
Protocol profile	Supported OID4VCI capabilities and upgrades	Applying an upgrade without a dry-run.
Metadata	Public credential_configurations_supported and endpoints	Checking only the admin response instead of public metadata.

Format-specific choices

Format	Required identifier	Important claim/signing choice	Status profile
SD-JWT VC	Stable vct and credential_configuration_id	Selective-disclosure paths must match populated claims.	Token Status List, usually JWT
ISO mdoc	ISO docType and namespace paths	Use correct data-element types and mdoc-compatible signing.	Token Status List, usually CWT
W3C VCDM 1.1	Explicit 1.1 context and types	Keep context, type, issuer, subject, validity, and status consistent.	Bitstring Status List, VC-JWT
W3C VCDM 2.0	Explicit 2.0 context and types	Do not silently reuse 1.1 terms or context.	Bitstring Status List, VC-JWT

Choose the format before creating the configuration. A format change is a new credential contract, not a cosmetic edit.

Configuration order

1. Select the issuer identity and confirm its public verification method.
2. Create issuer branding and credential designs with their claims.
3. Create standalone status lists and record response-derived ids and URIs.
4. Create each credential configuration with its design/version, format, stable configuration id, signing selector, and existing status-list reference.
5. Bind the validated AS UUID from the AS guide. Set an issuer default unless a credential-specific override is necessary.
6. Read public issuer metadata and compare it with the stored configuration.
7. Start credential issuance only after the metadata checks pass.

Creation precedes binding. A developer never needs to create a URL containing a future status-list name or bind a key under that name before the list exists.

Admin Console

Open Protocols > Credential Issuer and select the issuer instance. Use these surfaces in order:

1. Overview / identity — issuer name, public route, DID or X.509 identity, enabled state.
2. Issuer design — organisation name, logo, locale, and render variant.
3. Credentials — design/version, configuration id, format, claims, signing, status profile.
4. Authorization servers — issuer default and credential-specific overrides. This consumes the AS from the separate AS guide; it does not create one.
5. Defaults and protocol profile — effective defaults and dry-run upgrade.
6. Testing / metadata — published endpoints and wallet-visible configuration.

Save one logical change at a time and reread it. A successful save does not prove that public metadata or issuance can use the combination.

REST API

Use issuer and credential-design APIs with tenantAccessToken:

1. Read/create issuer design and render assets.
2. Create/update credential designs and claims.
3. Read issuer signing selections.
4. Create/update credential settings with response-derived design ids, versions, signing selectors, and status-list ids.
5. Create/replace issuer AS bindings using the AS UUID.
6. Read protocol profile, dry-run upgrades, and apply only compatible changes.
7. Fetch public issuer metadata and compare it with the stored configuration.

Administration requires tenantAccessToken. Public metadata and discovery carry no bearer token. OID4VCI token and credential calls use a session-specific walletAccessToken, never the tenant administration token.

Postman correlation

In the canonical EDK Enterprise collection:

• 10 Issuer Configuration covers issuer-level setup.
• 11 Credential Designs creates designs and claims.
• 12 Status Lists creates standalone lists before binding.
• 13 Credential Configurations binds designs, signing selections, and returned list ids.
• 09 Authorization Server Configuration owns AS creation, clients, activation, and issuer binding.
• 15, 17, and 18 issue SD-JWT/mdoc and W3C credentials.

Run 04 Tenant Service Token first. Administration folders use tenantAccessToken; issuance folders use only the wallet token created by their own token-exchange request. Request descriptions link back to the matching sections of this guide.

Troubleshooting by option

Symptom	Inspect
Configuration absent from metadata	Design id/version, enabled state, configuration id, and protocol profile.
Wrong token endpoint	AS binding precedence: credential override, issuer override, then default.
Credential signing fails	Exact selector, KMS resource, alias, and published DID/X.509 material.
Status reference cannot resolve	List was created first and the setting stores its returned id/URI.
Wallet rejects the offer	Format, vct/docType, grant, AS binding, and metadata id.

Next guides

• Credential designs and claims
• Status-list creation and lifecycle
• Credential issuance
• Verifier and DCQL configuration
• Trust-domain creation and verifier binding