Overview
The Issuer2 Service is walt.id's enterprise solution for creating, signing and distributing verifiable digital credentials based on various formats and standards.
It is currently an opt-in beta feature. The interfaces are unstable and may change without notice. In order to enable the feature, make sure you include "issuer2" in the enabledFeatures list in the _features.conf file.
Note: The Wallet API currently does not support accepting credentials issued by the Issuer2 service.
Supported Standards
| Credential Formats: | SD-JWT VC (IETF), W3C VC (v1.1+, v2.0), ISO 18013-5 mDL |
| Credential Exchange: | OID4VCI (v1.0), ISO/IEC 18013-7 |
| Credential Status: | StatusList2021, Bitstring Status List, Token Status List |
| Signing Algorithms: | ed25519, secp256k1, secp256r1, RSA |
Core Features
Credential Exchange
The Issuer Service supports credential exchange protocols based on:
- OID4VCI: v1.0 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). This is the same as the issuer service.
- Embedded in Credential – include branding directly in the issued credential for case-specific styling.
Credential Status & Lifecycle
- Not currently supported.
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 retention & auto-purge
- Issuance sessions can contain personally identifiable information (PII) such as offer payloads, subject data, and interaction logs. Enable the optional data-retention job to define a maximum issuer-session age, purge schedule, and safety guardrails so expired sessions are removed automatically.
- Configuration lives in the Enterprise Stack → Setup → Data Retention
file where you can set
maxIssuerSessionAge, cronschedule, dry-run behavior, and deletion limits to meet your compliance requirements.
Reusable Credential Templates
- Credential templates allow you to create reusable credential offers that can be claimed by multiple subjects as part of the authorization flow.
Getting Started
- Setup – Configure an issuer service inside your tenant
- Reusable Credential Templates – Create reusable credential offers
- Issuing Credentials – Walkthrough for issuing credentials
Last updated on January 21, 2026
