#Credential Delivery

Credential Delivery describes how a credential gets from the Community Stack Issuer API 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 Community Stack does not constrain how you integrate issuance into your applications. It exposes simple API endpoints that return an OID4VCI standard compliant credential offer URL. You decide whether that URL becomes a QR code, a deep link behind a button, or both.

#What's included

The Community 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):

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

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. 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 Community 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.

#2. 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 Issuer API.
• 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.

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

Regardless of which issuance flow you use (pre-authorized code or authorization code), 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 Community 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 issuance flow (pre-authorized code or authorization code, with or without PIN).

#FAQs

• Is a PIN required for the pre-authorized code issuance flow? - No. The PIN is optional. In the Community 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 Community Stack require a specific wallet? - No. The issuer API uses standard OID4VCI endpoints and credential offer semantics. Any wallet that implements the relevant OID4VCI versions and issuance flows can claim credentials from the Community Stack Issuer API.
• 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 (pre-authorized code or authorization 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

• Issue your first credential – Step-by-step guide showing how to generate credential offers using the pre-authorized code flow.
• Configure credential data sourcing – Learn how to populate credential claims from your data sources.