#Overview

The Issuer2 Service is walt.id's Enterprise solution for creating, signing, and distributing verifiable digital credentials using multiple credential formats and standards. It implements the OID4VCI v1.0 specification and introduces a profile-based architecture for easier credential issuance. Supported credential formats include W3C VC, SD-JWT VC (IETF), and ISO 18013-5 mDL.

#Supported Standards

#How Issuance Works

Issuing a credential with the Issuer2 Service follows four steps. The first two are one-time setup; the last two you repeat for every credential you issue.

1. Create the issuer service — Declare the credential types it should support (credentialConfigurations) and point it at a KMS which manages the keys for signing. See Setup.
2. Create a credential profile — Bind a credential type to an issuer key, DID or X509 certificate and a data template. See Credential Profiles.
3. Create a credential offer — Generate an OID4VCI offer URL from a profile, optionally overriding profile defaults per offer. See Credential Offers.
4. The wallet claims the offer

The credential-issuance guides take you through all four steps end to end for each format (SD-JWT VC, W3C VC, mDL).

#Core Features

#Profile-Based Issuance

The Issuer2 Service introduces a profile-based architecture that simplifies credential issuance:

• Credential Profiles – Define reusable configurations for each credential type, including issuer keys, credential data templates, status configuration, and notification settings.
• Credential Offers – Create offers from profiles with runtime overrides, supporting both pre-authorized and authorization code flows.

#Credential Exchange

The Issuer2 Service supports credential exchange protocols based on:

• OID4VCI v1.0: Flows such as Pre-Authorized Code Flow (with or without PIN/Transaction Code) and Authorization Code Flow (with ID Token, VP Token, username/password login, or integration with external authorization servers like Keycloak). See Protocol Flows.
• mDoc Issuance: Remote issuance of Mobile Driver's Licenses (mDL) and other ISO 18013-5 credentials via OID4VCI (ISO 18013-7).

#Credential Request and Response Encryption

credentialEncryptionKey enables OID4VCI Credential Request encryption and Credential Response encryption.

Issuer2 supports this profile:

• Key type: EC P-256
• JWE alg: ECDH-ES
• JWE enc: A128GCM
• Compression: not supported

When configured, issuer metadata includes credential_request_encryption and credential_response_encryption with encryption_required = false.

Wallets can keep using normal JSON credential requests. Wallets that send an encrypted Credential Request as application/jwt and include credential_response_encryption receive the Credential Response as an encrypted JWE.

#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 creating the profile or 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 via idTokenClaimsMapping.

#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 through the Credential Status Service, supporting StatusList2021, Bitstring Status List, and Token Status List.
• Different credential formats have different status type compatibility:
  • W3C JWT/SD-JWT: Bitstring Status List, StatusList2021
  • SD-JWT VC (IETF): Token Status List
  • mDoc: Token Status List
• Configure credential status at the profile level or override per offer.
• Credentials can include expiration and "valid from" dates.

#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, the DID Registry and the DID Store
• X.509 Certificates – Support for X.509 certificate chains (x5Chain) for mDL and other certificate-based credentials.

#Notifications & Session Events

• Webhook-based notifications for real-time updates on issuance events, with bearer-token authentication for secure delivery.
• A Server-Sent Events (SSE) stream for monitoring issuance session progress live.
• Configure notifications at the profile level or override per offer. See Notifications & Session Events.

#Client Authentication

• Client authentication is configured with clientAuthenticationConfig on the issuer service. You can enable one or both of: anonymous pre-authorized code (preauth-anonymous — OID4VCI token requests using grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code without client_id), and attestation-based client authentication (client-attestation — OAuth 2.0 Attestation-Based Client Auth).
• When client-attestation is configured, only trusted wallets that present valid OAuth-Client-Attestation and OAuth-Client-Attestation-PoP headers can complete the token step; attestation JWT signatures are verified using a static JWK, a KMS key, or X.509 chain trust anchors (including regulated environments such as VICAL and eIDAS).
• The issuer's RFC 8414 authorization server metadata reflects the active methods (for example token_endpoint_auth_methods_supported, pre_authorized_grant_anonymous_access_supported).
• See Client Attestation — Issuer Integration for configuration details.

#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.
• Find out more about the Data Retention configuration options where you can set maxIssuerSessionAge, cron schedule, dry-run behavior, and deletion limits to meet your compliance requirements.

#Getting Started

• Setup – Create an Issuer2 service inside your tenant.
• Issue SD-JWT VC / W3C VC / mDL – End-to-end guides from an empty service to a credential in a wallet.
• Credential Profiles – Create and manage reusable credential configurations.
• Credential Offers – Create credential offers from profiles.
• Protocol Flows – Pre-authorized and authorization code flow sequences.
• Configurations – Manage display metadata and service settings.
• Data Functions – Populate credentials with dynamic data.
• Notifications & Session Events – Track issuance events via webhooks or SSE.
• Full API Reference – Complete Swagger documentation.