Understanding the OpenID4VC credential issuance lifecycle: From offer to acceptance
This article explains the credential issuance lifecycle defined by the OpenID for Verifiable Credential Issuance (OpenID4VC) specification [1], as implemented in the Organisation Wallet Suite by iGrant.io. Through six progressive stages and two terminal states, we trace the journey of a credential from the moment an issuer creates an offer to the point where a holder accepts it into their wallet, and explore what happens when the process encounters errors or is interrupted.
Target audience: Developers, solution architects, and product managers building credential issuance solutions using OpenID4VC with EUDI Wallets, European Business Wallets, or other digital wallets.
1.0 Introduction
The OpenID for Verifiable Credential Issuance (OpenID4VC) specification [1] defines a protocol for issuing verifiable credentials from an issuer to a holder's digital wallet. Built on the widely adopted OAuth 2.0 [2] and OpenID Connect (OIDC) [3] standards, it enables interoperable credential issuance across digital identity ecosystems, whether the credential is a national ID, a university degree, a bank account attestation, or an electronic receipt. Importantly, the OpenID4VC lifecycle applies equally to personal EUDI Wallets and to European Business Wallets, making it a universal framework for credential issuance across both individual and enterprise identity use cases.
Credential issuance is not a single event but a multi-step process. Between the moment an issuer decides to offer a credential and the moment a holder accepts it, several things happen: the offer must be delivered and opened, the holder must be authorized, the credential must be cryptographically constructed and transferred, and the holder's wallet must confirm receipt. At any point along the way, the process can fail, the issuer might deny the request, or the holder might decide to delete the credential later.
Understanding this lifecycle is essential for building reliable integrations. It determines when to update a user interface, when to trigger a business workflow, when to retry an operation, and when to treat an exchange as failed. This article walks through each stage, explains what is happening at the protocol level, and shows how the lifecycle plays out in real-world scenarios.
2.0 The OpenID4VC credential issuance lifecycle
When an issuer initiates credential issuance using OpenID4VC, the process follows a well-defined lifecycle with six progressive stages and two terminal states.
Figure 01: The credential issuance lifecycle: Six progressive stages (blue), issuer validation checks with decision diamonds (orange), successful completion (green), issuer denial (red), and holder deletion (yellow)
The happy path flows top to bottom: the issuer creates an offer, the holder opens it, authorization succeeds, and a token is issued. The issuer then performs validation checks - verifying that a valid Wallet Unit Attestation (WUA) is present and that the European Business Wallet Owner Identification (EBWOID) is in order. These two checks are defined within the European Digital Identity Wallet Architecture and Reference Framework (ARF) [5]. If either check fails, the issuance is denied. If both checks pass, the credential is delivered, the wallet confirms receipt, and the holder accepts it. After the credential is accepted, the holder can choose to delete it.
Each stage is tracked as a status value in the credential exchange record and fires a corresponding webhook event, making the entire lifecycle observable and actionable for developers.
3.0 How the Lifecycle Works
3.1 Offer Sent
The lifecycle begins when the issuer creates and sends a credential offer to the holder. In the OpenID4VC specification, this corresponds to the Credential Offer described in Section 4 [1]. The issuer generates a credential offer containing the necessary metadata, including the credential configuration, issuer endpoint, and grant information, and makes it available to the holder, typically through a QR code or a credential offer URI.
At this point, the offer is waiting for the holder to open it. No authentication or authorization has occurred yet. The issuer triggers this stage by calling the Issue credential API, which returns a credentialOffer that can be encoded as a QR code.
Example: A bank wants to issue a KYC verification credential to a customer who has just opened a new account. The bank's system calls the Issue credential API and displays the resulting QR code on the customer's screen. The credential's lifecycle has begun; the status is now offer_sent.
Credentials may be issued immediately (in-time) or on a deferred basis depending on business requirements. In-time issuance is used when credential data is already available - for example, issuing a Photo ID credential immediately after the holder's passport has been validated. Deferred issuance is used when back-office processing is required first, as explored in Section 4.0.
3.2 Offer Received
Once the holder opens the credential offer - for example, by scanning the QR code with the Data Wallet or any other EU Digital Identity (EUDI) Wallet - the status transitions to Offer Received. The holder's wallet has retrieved the credential offer and resolved the issuer's metadata, but the holder has not yet proceeded to the authorization step.
This stage corresponds to the wallet resolving the Credential Issuer Metadata and Authorization Server Metadata as described in Sections 11.2 and 11.1 of the OpenID4VC specification [1].
For the bank issuing the KYC credential, this is the moment when the customer has scanned the QR code with their wallet. The bank's system, if it has registered a webhook, receives an openid.credential.offer_received event, confirming that the customer has engaged with the offer.
3.3 Token Issued
This stage marks the point at which the holder has been successfully authorized. The authentication and authorization exchange between the holder's wallet and the issuer's authorization server has been completed, and the wallet has obtained an access token.
In OpenID4VC, this maps to the Token Endpoint interaction described in Section 6 [1]. The specification supports two authorization flows:
- Authorization Code Flow: The holder authenticates with the issuer's authorization server and exchanges the authorization code for an access token.
- Pre-Authorized Code Flow: The issuer provides a pre-authorized code (optionally with a transaction code) that the holder's wallet exchanges directly for an access token.
Once the token is issued, the holder's wallet is ready to request the credential from the Credential Endpoint.
In some scenarios, additional proof of identity may be required before issuance proceeds. When issuing a Photo ID credential, for instance, the issuer - a Qualified Trust Service Provider (QTSP) - may require the holder to first present their passport credential for verification. This is handled through a dynamic credential request flow, in which issuance and presentation occur within a single transaction.
3.4 Credential Issued
With a valid access token, the holder's wallet requests the credential from the issuer's Credential Endpoint, as described in Section 7 of the OpenID4VC specification [1]. The issuer validates the request, including proof of key possession, and delivers the credential to the holder's wallet. Credentials can be issued in any of the standard formats: W3C Verifiable Credentials (JWT), IETF SD-JWT VC, or ISO/IEC 18013-5 mdoc/mDL.
At this stage, the credential has been delivered to the wallet but the holder has not yet confirmed or accepted it. The credential exchange record status transitions to credential_issued, and the issuer receives the openid.credential.credential_issued webhook event. Integrations can poll the Read issuance history API or use the webhook to update dashboards in real time.
3.5 Credential Acknowledged
The holder's wallet confirms receipt of the credential using the Notification Endpoint described in Section 10 of the OpenID4VC specification [1]. This acknowledgement informs the issuer that the credential has been successfully received and stored in the wallet. The status transitions to credential_acked.
The distinction between acknowledgement and acceptance is intentional: it allows wallets to implement a review step in which the holder inspects the credential before choosing to keep it. Credentials in the credential_acked state are not yet available for presentation to verifiers - they must reach credential_accepted first.
3.6 Credential Accepted
The holder accepts and saves the credential, marking the issuance as complete. The credential is now fully available in the holder's wallet for future use - for example, presenting it to a verifier during an insurance onboarding process, a bank account login, or a DCQL-based identity verification.
This is the successful terminal state. The issuer receives the openid.credential.credential_accepted webhook, and the credential exchange record shows credential_accepted as its final status.
4.0 Deferred issuance in OpenID4VC
The OpenID4VC specification supports deferred credential issuance for scenarios in which the credential cannot be issued immediately. This is a common requirement in regulated industries where back-office processing - such as underwriting, risk assessment, or regulatory checks - must be completed before a credential can be generated.
In a deferred issuance flow, the issuer creates the credential offer with issuanceMode: "Deferred". The holder scans the QR code and the lifecycle progresses to the Token Issued stage, where it pauses. When processing is complete, the issuer calls the Issue deferred credential API with the credentialExchangeId from the original offer. The holder's wallet automatically retrieves the credential, and the lifecycle resumes through to Credential Accepted. Follow the deferred issuance workflow for step-by-step guidance.
Example: An insurance company cannot issue a policy credential immediately - it requires time for underwriting and regulatory review. The company creates a deferred offer, and the customer scans the QR code. Days later, once underwriting is complete, the issuer calls the deferred issuance API. The customer's wallet retrieves the policy credential automatically, completing the lifecycle.
Back-office systems can monitor pending deferred credentials by calling the List issuance history API and filtering for records in the token_issued state.
5.0 Exception handling and terminal failure states
Not every OpenID4VC credential issuance follows the happy path. The lifecycle includes two terminal states that handle failure and holder-initiated removal.
5.1 Issuance denied
Once the holder has been authorized and the token is issued, the issuer performs validation checks before delivering the credential. As shown in the diagram, the issuer verifies that a valid Wallet Unit Attestation (WUA) is present and that the European Business Wallet Owner Identification (EBWOID) is in order. If either check fails, the lifecycle moves to the Issuance Denied terminal state. Common reasons for denial include:
- Missing or invalid Wallet Unit Attestation (WUA): The holder's wallet does not present a valid attestation, meaning it does not meet the issuer's trust requirements.
- Missing or invalid European Business Wallet Owner Identification (EBWOID): The wallet owner identification associated with the credential request cannot be verified.
- Invalid proof of key possession: The cryptographic proof provided by the wallet is invalid or missing.
- Credential uniqueness enforced: A valid credential of the same type already exists for this holder.
The denial reason is included in the openid.credential.issuance_denied webhook payload, enabling developers to surface specific error messages rather than generic failures. The credential exchange record status is set to issuance_denied.
5.2 Credential deleted
After a credential has been successfully issued and accepted, the holder may choose to permanently remove it from their wallet. This is a holder-initiated action - the holder may no longer require the credential, or may wish to obtain a fresh one.
The issuer receives the openid.credential.credential_deleted webhook event, which allows it to update its records accordingly. This can be significant for compliance purposes: an insurance company, for example, may need to record that a policyholder no longer holds the digital policy attestation in their wallet.
6.0 OpenID4VC lifecycle in practice: al-world scenarios
The OpenID4VC lifecycle model has direct implications for how real-world applications behave. The following scenarios illustrate how different stages and issuance modes apply across digital identity use cases.
6.1 Digital bank account opening with EUDI Wallet
When a customer opens a new bank account using their EUDI Wallet, the bank needs to issue a KYC verification credential after confirming the customer's identity. This is a straightforward in-time issuance scenario: the bank has all the information it needs and can issue the credential immediately by calling the Issue credential API with issuanceMode: "InTime".
The lifecycle progresses through all six stages in a single flow. The bank's integration can use webhooks to track when the customer scans the QR code (offer_received), when the credential reaches their wallet (credential_issued), and when they accept it (credential_accepted), updating the onboarding interface at each step. Try the in-time issuance workflow to see this in action.
6.2 Insurance policy issuance with deferred OpenID4VC credential
When a customer applies for an insurance policy, the insurer typically cannot issue the policy credential immediately - it requires time for underwriting, risk assessment, and regulatory checks. This is where deferred issuance comes in. This scenario applies equally when the policyholder is an individual using a EUDI Wallet or an organisation using a European Business Wallet - for example, a company receiving a liability insurance credential into its organisational wallet.
The insurance company creates the credential offer with issuanceMode: "Deferred". The customer scans the QR code and the lifecycle reaches the Token Issued stage, but pauses there. Once underwriting is complete, the insurance company calls the Issue deferred credential API with the credentialExchangeId from the original offer. The customer's wallet automatically retrieves the policy credential, and the lifecycle resumes through to Credential Accepted. Follow the deferred issuance workflow for step-by-step guidance.
Meanwhile, the back-office system can track the status of every pending policy credential by calling the List issuance history API, filtering for records in the token_issued state.
6.3 Merchant payments with eReceipt and boarding pass credentials
In a merchant-led payment scenario, a customer purchasing a ferry ticket receives multiple credentials in a single transaction: a payment confirmation, an eReceipt, and a boarding pass. Each credential follows its own lifecycle independently. This scenario is well-suited to European Business Wallets, where an organisation may need to receive and store transactional credentials such as eReceipts or travel documents on behalf of its employees or operations.
Webhook events are particularly valuable here. The merchant's system registers webhooks and uses the credential_accepted events to confirm that each credential has been successfully delivered to the customer's wallet. Only when all three credentials show credential_accepted does the merchant's system mark the transaction as fully complete. If any credential shows issuance_denied, the system can trigger a retry or alert the support team.
6.4 Photo ID issuance with dynamic credential request
When issuing a Photo ID credential - a digital identity based on an electronic Machine-Readable Travel Document (eMRTD) - the issuer, a Qualified Trust Service Provider (QTSP), needs to verify the holder's passport before issuing the Photo ID. This is a dynamic credential request: the issuance flow requires the holder to first present an existing credential as proof.
The issuer creates both a Presentation Definition (specifying the passport credential required) and a Credential Definition (specifying the Photo ID to be issued), then links them in a single credential offer. When the holder scans the QR code, their wallet presents the passport credential and receives the Photo ID in one seamless flow. The dynamic credential request workflow provides a detailed walkthrough of this process.
6.5 University degree verification for employment onboarding
An employment agency uses DCQL (Digital Credentials Query Language) to request proof of university degrees from job applicants. For successful presentation, the applicant's wallet must contain degree credentials that have completed the full issuance lifecycle, reaching the credential_accepted state. Credentials still in an intermediate state (e.g. credential_acked but not yet accepted) are not available for presentation.
This illustrates an important principle: the issuance lifecycle directly governs the presentation lifecycle. Understanding when a credential becomes available for use - at the credential_accepted stage - is critical for designing end-to-end workflows that span both issuance and verification under OpenID4VC and OpenID for Verifiable Presentations (OpenID4VP) [4].
7.0 Conclusion
The OpenID4VC credential issuance lifecycle provides a well-defined, standards-based framework for tracking how credentials move from issuer to holder. The six progressive stages - Offer Sent, Offer Received, Token Issued, Credential Issued, Credential Acknowledged, and Credential Accepted - together with the two terminal states of Issuance Denied and Credential Deleted, give developers a clear model for building reliable, event-driven credential issuance systems.
Whether building a banking onboarding system, an insurance credentialing platform, a payment and receipts solution, or a government identity programme, the lifecycle model ensures a consistent and interoperable approach aligned with the European Digital Identity Wallet Architecture and Reference Framework (ARF) [5]. The lifecycle is equally applicable to personal EUDI Wallets and to European Business Wallets, making it the common foundation for credential issuance across the full spectrum of digital identity use cases.
The Organisation Wallet Suite by iGrant.io implements this lifecycle with full support for in-time, deferred, and dynamic credential request issuance modes, backed by comprehensive APIs and real-time webhook notifications at every stage of the OpenID4VC credential issuance process.
References
- OpenID Foundation (2024), 'OpenID for Verifiable Credential Issuance (OpenID4VC)', Available at: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
- IETF (2012), 'RFC 6749 - The OAuth 2.0 Authorization Framework', Available at: https://datatracker.ietf.org/doc/html/rfc6749
- OpenID Foundation (2014), 'OpenID Connect Core 1.0', Available at: https://openid.net/specs/openid-connect-core-1_0.html
- OpenID Foundation (2024), 'OpenID for Verifiable Presentations (OpenID4VP)', Available at: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
- European Commission (2024), 'The European Digital Identity Wallet Architecture and Reference Framework (ARF)', Available at: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases
- iGrant.io (2025), 'Organisation Wallet Suite - OpenID4VC Implementation', Available at: https://www.igrant.io/demo.html