#Issuer

The walt.id Issuer enables developers and organizations to issue verifiable digital credentials. It is available as SDKs and stateless REST APIs that are use-case agnostic and simple to integrate.

#Supported Standards

#Core Features

#Credential Exchange

The Issuer supports credential exchange protocols based on:

• OID4VCI:
  Supports multiple versions (Draft 11, 13) and user flows like Pre-Authorized Code Flow (with or without PIN) and Authorization Code Flow (with ID Token, VP Token, username/password, external Authorization Servers like Keycloak).
• ISO/IEC 18013-7:
  Supports issuance using pre-auth code flow for mobile Driver’s Licenses (mDL).

#Credential Data Collection

walt.id's Issuer supports flexible methods to gather and define credential data before signing. Depending on the use case, data can be provided upfront, enriched dynamically, or pulled during user authentication:

• Before Credential Offer Creation
  Credential subject data is collected by the issuer’s system (e.g., from a CRM, user DB, or registry) and passed to the API or SDK when initiating a credential offer. This approach is ideal when all necessary data is available in advance and no end-user interaction is required.
• After Credential Offer Creation & Before Credential Signing
  Enables dynamic enrichment of the credential offer using data functions (e.g., webhooks, timestamps, subject DIDs, or external API calls). This ensures the credential data is accurate and up to date at the time of signing.
• During User Authentication (via OID4VCI)
  When using the authorization code flow, the subject authenticates through an external identity provider (e.g., Azure AD, Google). Verified claims are then retrieved and mapped to credential fields. This method supports real-time data population based on the authenticated user. (Enterprise Stack only)

#Credential Branding

Credential appearance in wallets can be defined in two complementary ways:

• Issuer Metadata Branding is configured per credential type via issuer metadata, including background color, text color, logo, and description. This metadata is hosted and fetched by the wallet during credential exchange, allowing consistent and reusable styling across all credentials of the same type.
• Embedded in Credential
  Branding attributes can be included directly in individual credential instances. This enables visual customization on a per-credential basis — useful when the same credential type represents multiple subcategories, such as hotel bookings for different room types or events.

#Credential Status

• Status Fields In Credentials
  • Credentials may include a status field (e.g. revoked, suspended)
  • Manage and host status credentials externally or via our Enterprise Stack

#Credential Expiration

• Credentials can have expiration and “valid from” dates, set explicitly or generated dynamically.

#Keys & DIDs

• Issuer Keys
  • Store and manage keys via external KMS providers (Azure Key Vault, AWS KMS, Oracle Cloud KMS, Hashicorp Vault, etc.)
  • Alternatively provide raw key material
• DIDs
  • Create DIDs (did:key, did:jwk, did:web, ...) via the DID Lib or Issuer API
  • Store DIDs in an external system
  • Use the DID Service in the Enterprise Stack for storage capabilities

#Getting Started

• API - Issue credentials via OID4VC using the issuer API
• SDKs - Manage keys, DIDs, issue and present credential in Kotlin/Java
• Apps - White-label issuer portal to create and configure different types of credential offers.