Credential Delivery

Credential Delivery describes how a credential gets from the Enterprise Stack issuer into the holder's wallet. It focuses on the protocol flows used to issue credentials (based on OpenID for Verifiable Credential Issuance, OID4VCI) and the device journeys (same-device vs cross-device) used to deliver credential offers.

The Enterprise Stack does not constrain how you integrate issuance into your applications. It exposes simple API endpoints that return a OID4VCI standard compliant credential offer URL. You decide whether that URL becomes a QR code, a deep link behind a button, or both.

"Which OID4VCI flow do we use, and how does the credential offer actually reach the user’s wallet – on the same device or across devices?"

What's included

The Enterprise Stack supports different issuance flows and device journeys for delivering credentials. These two dimensions are independent and can be combined freely.

Issuance flows (how users prove they’re eligible and how the wallet gets permission to fetch the credential):

  • Authorization Code Flow
  • Pre-Authorized Code Flow (with and without PIN)

Device journeys (how the credential offer reaches the user’s wallet – on the same device or across devices):

  • Same-device credential offers (link / button)
  • Cross-device credential offers (QR code scanned from another device)

1. Authorization Code Issuance Flow

In the authorization code issuance flow, the credential offer can be shared broadly (e.g. any user visiting a page), but the user must authenticate with an external Authorization Server / Identity Provider (IdP) before they can receive the credential.

This means:

  • The offer can be long-lived and reused by any eligible user.
  • Users prove they’re eligible by signing in at your IdP (e.g. Keycloak, Azure AD, custom OIDC IdP) during the flow.
  • After successful authentication, the wallet exchanges the authorization code for a token and then uses that permission to request the credential from the Enterprise Stack issuer.
  • You can combine this with Data & Identity Sourcing to fetch user claims from the Authorization Server and inject them into the credential at issuance time.

2. Pre-Authorized Code Issuance Flow (with and without PIN)

In the pre-authorized code issuance flow, the issuer has already verified the user's eligibility (via your backend, existing session, or business logic). The credential offer is generated for a specific user and includes a pre-authorized code that grants the wallet immediate permission to fetch the credential – no interactive authentication required by the receiver of the credential.

The Enterprise Stack supports both variants defined by OID4VCI:

  • Without PIN – the wallet uses the pre-authorized code directly to get permission and request the credential.
  • With PIN – the offer indicates that a user PIN (transaction code) is required. The PIN is delivered via a separate channel (e.g. email, SMS, in-person) and must be entered in the wallet when claiming the credential.

This means:

  • Eligibility is determined upstream (e.g. back-office process, portal, CRM) before the offer is created.
  • You can use existing secure channels (logged-in portals, emails, SMS, letters) to deliver offers and PINs.
  • You can add a “second factor” for sensitive credentials (pre-authorized code + PIN).
  • You avoid re-authenticating the user at issuance time when you already trust your upstream process.

3. Device Journeys: Same-device & Cross-device Offers

Regardless of which issuance flow you use (authorization code or pre-authorized code, with or without PIN), the device journey defines how the user encounters and accepts the credential offer:

Cross-device flow

  • The credential offer URL is encoded as a QR code on one device (e.g. desktop web application, kiosk).
  • The user scans the QR code with their mobile wallet and continues the flow on their phone.
  • This is ideal when the user interacts with an issuer on a desktop/laptop, but the wallet lives on a smartphone.

Same-device flow

  • The credential offer URL is embedded in a link or button on the same device that runs the wallet.
  • The user taps the link (e.g. in an email or web page on their phone), which opens the wallet and displays the credential offer.
  • This is ideal when everything happens on a single device (e.g. mobile-first experiences).

With the Enterprise Stack:

  • The issuer API returns a standards-compliant OID4VCI credential offer URL.
  • You are free to:
    • Turn that URL into a QR code (cross-device).
    • Use it directly as a deep link (same-device).
    • Offer both options in parallel.
  • The choice of same-device vs cross-device is independent of the chosen issuance flow. You can use any device journey with authorization code or pre-authorized code (with or without PIN).

Credential Delivery for Different Issuers and Tenants

Each tenant or issuer service in the Enterprise Stack can define its own combination of issuance flows and device journeys:

  • Which issuance flows are used (authorization code, pre-authorized code, or both).
  • Whether a PIN is required for pre-authorized offers.
  • How credential offers are embedded into frontends (e.g. portals, emails, kiosks) via QR codes or links.
  • How delivery interacts with other capabilities such as Data & Identity Sourcing or Credential Status.

This means you can operate multiple issuers with completely different delivery and UX patterns in the same Enterprise Stack deployment – for example:

  • Issuer Service A: authorization code issuance flow, cross-device QR codes on desktop.
  • Issuer Service B: pre-authorized code issuance flow with PIN, offers delivered via email links (same-device).
  • Issuer Service C: a mix of both issuance flows, with frontends choosing between QR and deep links per journey.

FAQs

  • Is a PIN required for the pre-authorized code issuance flow? - No. The PIN is optional. In the Enterprise Stack, you can configure pre-authorized offers with or without a PIN and decide when a second factor (transaction code) is appropriate for your use case.
  • What’s the difference between same-device and cross-device flows? - In a same-device journey, the user taps a link on the same device that holds the wallet (e.g. from an email on their phone). In a cross-device journey, the user interacts with the issuer on one device (e.g. desktop) and scans a QR code with a wallet on another device (e.g. phone). Both can be used with any issuance flow and require no extra issuer configuration beyond generating the offer URL.
  • Does the Enterprise Stack require a specific wallet? - No. The issuer service uses standard OID4VCI endpoints and credential offer semantics. Any wallet that implements the relevant OID4VCI versions and issuance flows can claim credentials from the Enterprise Stack.
  • How do QR codes relate to OID4VCI issuance flows?
    In OpenID for Verifiable Credential Issuance (OID4VCI), a QR code is simply a user-friendly way to deliver an issuance URL to a wallet app – typically a credential offer URL (and, depending on the flow, parameters such as a pre-authorized code). The QR code itself usually just encodes this URL. When the user scans it with their wallet, the wallet opens the URL and continues the OID4VCI issuance flow (authorization code or pre-authorized code, with or without PIN). In same-device journeys, the same URL is usually opened via a link or button instead of a QR code. So QR codes are not a separate OID4VCI feature, but a UX pattern for starting issuance flows, especially in cross-device scenarios.

Get Started

Ready to deliver credentials to wallets? Here are the next steps:

Last updated on December 15, 2025
Credential Templates, Types, and SchemasIssuer