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. Platform foundations and authentication boundaries: obtain a token for your service client; 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 correlationId, 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

Loading example...

Loading example...

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 correlationId, 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.

What an issuer configuration must contain

An issuer is usable only when these references form one consistent graph:

Reference	Must point to	Why it matters
issuer instance	The tenant issuer resource returned by the platform	Owns the public credential_issuer URL and lifecycle
issuer identity	A DID/JWK or X.509 verification identity	Lets wallets and verifiers validate signatures
design + version	An enabled credential design and its immutable version	Defines claims, display metadata and format
credential configuration id	A stable id such as EmployeeBadge	Is the identifier used in offers, metadata and requests
authorization server	An active hosted/external AS UUID	Supplies token and authorization endpoints
status list	An existing list correlationId with matching proof/profile	Supplies the status URI/index written into credentials
signing selector	A KMS resource/key alias and public verification method	Selects the actual key operation; names alone are insufficient

For a JWT VC configuration, the effective values look like this:

{
  "credentialConfigurationId": "EmployeeBadge",
  "format": "jwt_vc_json",
  "scope": "employee_badge",
  "credentialDefinitionTypes": ["VerifiableCredential", "EmployeeBadgeCredential"],
  "cryptographicBindingMethodsSupported": ["jwk"],
  "credentialSigningAlgValuesSupported": ["ES256"],
  "proofTypesSupported": {"jwt": {"proofSigningAlgValuesSupported": ["ES256"]}},
  "designId": "<response-derived-design-id>",
  "designVersion": 1,
  "authorizationServerId": "<active-as-uuid>",
  "status": {"statusListId": "<list-correlation-id>", "purpose": "revocation"},
  "validityPeriod": "P365D"
}

For SD-JWT replace the format/type contract with dc+sd-jwt and vct. For mdoc use mso_mdoc, docType, namespace-qualified claims, cose_key, and a CWT status list. For W3C VC 1.1/2.0 keep the context and type contract distinct. Do not copy this JSON verbatim with guessed ids: read the design, status-list, AS and signing responses first.

Why each issuer setting exists

• Public issuer URL: identifies the issuer in metadata and credentials. It must be stable and externally resolvable.
• Format and configuration id: tell the wallet which credential request shape to send.
• Scope: is the OAuth scope used by authorization-code issuance; keep it unique per configuration.
• Claims/design version: binds the wire claims to a governed design revision. Updating a design does not silently rewrite an already-issued credential.
• Signing selector: selects the private operation. The DID document or certificate chain is the public evidence and must advertise the corresponding key.
• Status binding: selects the already-created list and purpose. It does not create a list or allocate an entry before issuance.
• AS binding: selects the token endpoint. It is separate from issuer signing and from the client registration held by that AS.
• Validity: controls the credential lifetime; it does not revoke or suspend a credential.

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.

Use the exact issuer screens documented in issuer settings, issuer design, credential configurations, authorization-server selection, and issuer test. Their deep-link contract is:

#tenant={tenantId}&surface=issuer&instance={issuerInstanceId}&area=issuer-design
#tenant={tenantId}&surface=issuer&instance={issuerInstanceId}&area=credentials
#tenant={tenantId}&surface=issuer&instance={issuerInstanceId}&area=authorization-servers
#tenant={tenantId}&surface=issuer&instance={issuerInstanceId}&area=test

REST API

Use issuer and credential-design APIs with the service client's token:

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 correlation 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 the service client's token. 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, under 3. Tenant APIs:

• Credential issuer reads the issuer and its setup: 1. List credential issuers, 2. Get the issuer, 3. List credential configurations, 4. Get the EuPid configuration, 5. List authorization server bindings, and 6. Read public issuer metadata.
• Credential designs reads the designs, issuer designs and render variants.
• Status lists reads the standalone lists and the public status list token.
• Define your own credential adds an EmployeeBadge SD-JWT VC end to end: it resolves the issuer signing selection, creates the status list and the credential design, and then 8. Save the EmployeeBadge configuration binds the returned design and the status list's correlationId. 9. Read the published type metadata confirms the result.
• Authorization server reads the authorization servers and clients. AS creation, federation and issuer binding for a wallet login live in Keycloak wallet login (optional).
• Issue credentials issues the resulting credentials.

Get the 3. Tenant APIs token with your service client first. Administration folders use that token; the Receive it in a test wallet folder uses only the wallet token created by its own token request.

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 correlationId and 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