#Overview

The Issuer Service is walt.id's enterprise solution for creating, signing and distributing verifiable digital credentials based on various formats and standards.

#Feature Flag

This legacy Issuer Service requires the issuer-draft-routes feature in _features.conf. The feature defaults to off. When it is disabled, creating a service with "type": "issuer" is rejected (use "issuer2" instead).

Enable it only if you need draft-protocol (OID4VCI Draft 11/13) issuers or existing integrations that depend on them.

#Supported Standards

#Core Features

#Credential Exchange

The Issuer Service supports credential exchange protocols based on:

• OID4VCI: multiple draft versions (e.g. 11, 13) and flows such as Pre-Authorized Code Flow (with or without PIN) and Authorization Code Flow (with ID Token, VP Token, username/password login or integration with external authorization servers like Keycloak).
• ISO/IEC 18013-7: remote issuance of mobile Driver's Licenses (mDL).

#Credential Data Collection

Flexible data collection options allow populating credentials before or after an offer has been created:

• Before Credential Offer Creation – provide all subject data upfront when initiating the offer.
• After Credential Offer Creation & Before Credential Signing – enrich credentials dynamically using data functions such as webhooks or timestamps.
• During User Authentication – when using the authorization code flow, the subject can authenticate against an external IdP and the retrieved claims are mapped to credential fields.

#Credential Branding

Credential appearance in wallets can be defined via:

• Issuer Metadata – branding per credential type ( background color, text color, logo, description).
• Embedded in Credential – include branding directly in the issued credential for case-specific styling.

#Credential Status & Lifecycle

• Built‑in status management (revocation or suspension) through the Credential Status Service, supporting standards such as Bitstring Status List, Token Status List and StatusList2021.
• Credentials can include expiration and "valid from" dates.
• Lifecycle events and issuance sessions can be viewed in the GUI and via webhooks.

#Keys & DIDs

• Issuer Keys – store and manage keys via the KMS Service. The KMS service can use external KMS providers (e.g. Azure Key Vault, AWS KMS, OCI, Hashicorp Vault, ...) or store the keys in the Enterprise Stack database (only recommended for non-production use-cases).
• DIDs – create and store DIDs via the DID Service and the DID Registry.

#Session data ejection (MongoDB TTL)

• Issuance sessions can contain personally identifiable information (PII) such as offer payloads, subject data, and interaction logs. Finite sessions are ejected automatically by MongoDB TTL (controlled by expiresInSeconds on the offer / session; use -1 for no auto-ejection).
• See Session Data Ejection for covered document types, revocation-safe status indexes, and upgrade notes (the legacy data-retention job has been removed).

#Getting Started

• Setup – Configure an issuer service inside your tenant
• Issue a W3C Credential via OID4VCI – Walkthrough for issuing a W3C VC
• Issue an SD‑JWT VC via OID4VCI – Example for SD‑JWT VC issuance
• Configurations – Manage supported credential types and metadata