Skip to main content
Version: v0.25.0 (Latest)

Credential Issuer: Credentials

Catalog id: protocol.issuer.credentials
Status: current

Open it​

NavigationProtocols > Credential Issuer > Credentials
Deep link#tenant={tenant}&surface=issuer&instance={instance}&area=credentials
ScopeAuthenticated tenant, one issuer instance

Postman correlation: The same settings are exercised by 13 Credential Configurations in the canonical EDK Enterprise collection. 01 and 02 read the seeded configurations; 03 and 04 create format-specific configurations; 05 binds the already-created CWT status list. Run 12 Status Lists first and use its returned id rather than a status-list name.

What this screen owns​

Every credential an issuer advertises is a credential configuration, addressed by its credential_configuration_id. That identifier is what appears in issuer metadata, what a credential offer names, and what a wallet asks for.

Two things describe a configuration, and they are edited in different places:

  • The credential design owns identity and presentation: per-locale credential and claim display, claim mandatory and selective-disclosure policy, and rendering. Designs are edited through the credential-design API and its own console area.
  • The credential configuration settings on this screen own everything that is not display: the OAuth2 scope, format-specific identity, cryptographic binding and signing algorithms, proof types, the signing key, the validity period, and the status-list binding.

Writing settings never touches design-authored display or claim metadata, and editing a design never overwrites these settings.

Your own credential configurations​

A configuration does not have to be one of the seeded examples. Writing settings for a credential_configuration_id both stores those settings and registers the identifier in the issuer's credential-configuration index, which is what makes it a configuration the issuer advertises. Creating a configuration and configuring one are the same operation.

In the console, choose Add credential and work through the wizard: Credential (design and configuration id), Cryptography, Keys and signing, Lifecycle and delivery, then Review and create. An existing configuration opens into a detail view with the same material split across the Overview, Cryptography, Keys and signing, Lifecycle and status, and Grants and offers tabs.

Over REST the tenant-scoped contract is:

GET    /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/credential-config-settings
GET    /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/credential-config-settings/{credentialConfigurationId}
PUT    /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/credential-config-settings/{credentialConfigurationId}
PATCH  /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/credential-config-settings/{credentialConfigurationId}
DELETE /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/credential-config-settings/{credentialConfigurationId}

PUT replaces the settings wholesale: scalar and list fields are replaced and omitted or null fields are cleared. PATCH applies RFC 7386 merge-patch semantics, so absent fields stay unchanged and an explicit null clears one. DELETE removes the identifier from the index and clears its settings without deleting the design.

The same paths exist under .../oid4vci/issuer/instances/{instanceId}/... when a tenant runs more than one issuer instance and a configuration should differ per instance.

Validity period​

validityPeriod is an ISO-8601 duration such as P365D or PT12H. It sets the credential expiry relative to issuance time. In the console it is the Default validity field on the Lifecycle and status tab, entered as a number plus a unit.

Status-list binding for supported issuer configurations​

Status publication is a standalone resource. Create and sign the status list through the status-list management guide, retain its response identifiers, and then reference the returned list from an issuer configuration only when that credential format supports this management-plane binding. This is a reference to an existing list, not a pre-created credential entry and not a separate status-list signing-key workflow.

For the supported JWS-based issuer configurations, the binding is the status object on the configuration settings:

FieldMeaning
statusListIdThe correlation id of a status list managed through the status-list API
purposerevocation or suspension, how the bound entry is interpreted
revokeAtExpiryWhether the issuer revokes the entry when the credential reaches its validity end

In the console this is the Status list picker on the Lifecycle and status tab, which lists the tenant's existing lists. The issuer reserves the credential's entry during issuance; list creation does not allocate an index for a credential that does not yet exist.

At issuance the issuer reserves an entry on the bound list, tags it with the authenticated subject as its correlation, and merges the resulting status claim into the credential before signing. After signing, the entry is bound to the issued credential identifier, so revocation can later be addressed by credential rather than by bit index. The issued response remains authoritative for the credential's status URI and index.

The binding is fail-closed in both directions. A configuration bound to a status list never issues without its status claim, because a credential issued without one could never be revoked. If the status-list integration is not present in the deployment, or the reservation fails, issuance fails rather than producing an unrevocable credential.

Format support

Status binding is available for the JWS-based formats, dc+sd-jwt and jwt_vc_json. mso_mdoc uses the standalone CWT Token Status profile documented in mDoc VICAL and CWT status and does not use this issuer status object. Leave the issuer status binding empty for mso_mdoc configurations; do not infer that mdoc status is unsupported merely because it is not configured through this JWS binding.

Issuer defaults and effective values​

Most non-display settings can be set once for the whole issuer instead of per configuration. The Issuance defaults area carries the same Cryptography, Keys and signing, Lifecycle and status, and Grants and offers sections at issuer level.

An effective value resolves in order: the per-configuration setting, then the issuer default, then identity and display carried by the bound design, then the platform default. Identity fields (format, scope, vct, docType) are per-configuration only and have no issuer default. Inheritance is live: values are resolved at read and issuance time and are never snapshotted, so changing an issuer default immediately changes every configuration that does not override it.

To see the resolved value together with the layer it came from:

GET /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/effective-credential-config-settings
GET /api/platform/config/v1/tenants/{tenantId}/oid4vci/issuer/effective-credential-config-settings/{credentialConfigurationId}

Each field comes back as a value plus a source marker naming the layer that supplied it. The console uses the same read to mark which fields on a configuration are inherited and which are overridden.