Issuer Integration Guide 

Introduction 

This guide describes both OpenID Connect flows supported by the IDEMIA Digital Credential Platform — Online Authentication and CIBA Authentication — from the perspective of an Issuer integrator.

The DC Platform emits events at key stages of both authentication flows. These events give you operational visibility into how authentication requests involving your issued credentials are initiated, progress through the flow, and conclude.

This integration is completely optional and provided as a service to the Issuer Customers of the platform.

This guide explains what each flow looks like from the Issuer's perspective and what you can observe at each stage. For detailed event schemas and delivery configuration, see Authentication Events.

Online Authentication - Code Flow 

Online Authentication is a browser-based authentication flow based on the OpenID Connect Authorization Code Flow.

A user starts from a Relying Party page and authenticates using their Digital Credential through the iD Wallet application. The DC Platform acts as the Identity Provider and orchestrates the flow between the browser session and the mobile application.

As an Issuer, you are not directly involved in this flow. However, the DC Platform provides visibility into how authentication requests involving your issued credentials progress and conclude.

This flow is also an important source of operational and business insight. It allows the Issuer to monitor how Digital Credentials are being used across partner services.

High-level flow 

At a high level, the Online Authentication flow progresses as follows:

1. The user initiates authentication with a Digital Credential on the Relying Party side.
2. The Relying Party sends an authentication request to the DC Platform, which creates an authentication session.
3. The DC Platform returns a QR code or deeplink used to pair the browser session with the iD Wallet application.
4. The user scans the QR code, and the iD Wallet application claims the session.
5. The user reviews the request card in the iD Wallet application and makes a decision.
6. The browser continues polling the DC Platform for session status and authentication result.
7. Once the process is completed, the DC Platform returns the result to the browser, which then redirects to the Relying Party.

This flow separates the browser-based initiation from the mobile-based authentication while maintaining a continuous session from the Relying Party perspective.

Issuer visibility during the Code flow 

From the Issuer perspective, the authentication process can be observed as a progression of stages. The DC Platform emits an event at each meaningful step, allowing you to monitor how requests progress across Relying Party services.

Authentication session initiated — QR code displayed

The DC Platform registers that an authentication request has been initiated by a specific Relying Party. This is the earliest visibility point — before the user has engaged with the mobile application. It allows the Issuer to observe which Relying Parties use Digital Credential authentication and at what volume.

QR code scanned — iD Wallet claims the session

The user has actively engaged with the authentication journey. The session is now associated with the user's iD Wallet application and the consent screen is displayed. This stage shows that the user started the mobile-side of the flow.

Authentication outcome

The session reaches a terminal state. Possible outcomes are:

• the user approves the request — the Relying Party receives an authorization code,
• the user explicitly rejects the request,
• the session expires without a user decision,
• or a technical failure occurs.

For detailed event names, payload schemas, and monitoring guidance for each outcome, see Authentication Events.

The following sequence diagram illustrates the complete Online Authentication flow with the Issuer's visibility perspective.

CIBA Authentication 

CIBA Authentication — short for OpenID Connect Client-Initiated Backchannel Authentication — is a server-to-server authentication flow initiated by the Relying Party's backend. The user reviews and approves the request independently through the iD Wallet application on a trusted device.

Unlike Online Authentication, this flow does not involve browser redirects. The interaction between the Relying Party and the DC Platform happens entirely through backend communication. The user does not need to be in the same browser session or even on the same device where the request originated.

This flow is well suited to scenarios such as:

• transaction confirmation,
• second factor authentication,
• assisted or helpdesk-driven authentication,
• shared-device scenarios.

From the Issuer's perspective, CIBA provides visibility into how backchannel authentication requests involving your issued credentials are initiated, delivered to users, and how they reach their final outcome.

High-level flow 

At a high level, the CIBA Authentication flow progresses as follows:

1. The Relying Party sends a backchannel authentication request to the DC Platform.
2. The DC Platform validates the request and creates an authentication session.
3. The request is paired with the user's iD Wallet application and delivered as a push notification.
4. The user reviews the request and decides whether to approve or reject it.
5. If approved, authentication is performed on the trusted device.
6. The DC Platform synchronizes the authentication result with the backchannel request.
7. Depending on the configured delivery mode (poll, ping, or push), the Relying Party retrieves or receives the authentication result.

The flow connects a backend-initiated request with a user decision made independently in the iD Wallet application.

Issuer visibility during CIBA 

The Issuer is not directly involved in the interaction between the Relying Party and the end-user. However, the DC Platform emits events at each stage of the CIBA flow, allowing you to observe how authentication requests progress.

CIBA request initiated

The journey starts when the Relying Party sends a backchannel authentication request to the DC Platform.

The request includes the information needed to identify the Relying Party, determine the requested authentication context, and associate the request with a known user.

At this stage, the Issuer can observe that a Relying Party has initiated a CIBA authentication request involving one of its users. The request exists only on the backend side and has not yet reached the user.

This stage provides visibility into:

• which Relying Parties initiate CIBA requests,
• request volume over time,
• requested scopes and authentication context,
• distribution of requests across Relying Parties.

Request delivered to the iD Wallet application

Once the request is validated, the DC Platform identifies the target iD Wallet application and delivers the request to the user's device. The user receives a push notification and can open the request card within the application.

This is the first milestone where the Issuer can confirm that the authentication request has reached the user. The authentication process now transitions from backend orchestration to direct user interaction.

This stage helps the Issuer understand:

• whether requests are successfully delivered to the mobile application,
• how often backend-initiated requests progress to user interaction,
• whether users engage with the request after delivery.

User reviews and responds to the request

Inside the iD Wallet application, the user reviews the Relying Party details and the context of the requested action. The user may approve the request, reject it, or ignore it until the session expires.

If the request is approved, authentication is performed on the trusted device. Depending on the configured CIBA delivery mode (poll, ping, or push), the Relying Party either retrieves or receives the result asynchronously.

This stage gives the Issuer visibility into:

• how many requests reach active user interaction,
• how users engage with authentication requests,
• responsiveness of users to CIBA requests,
• progression from request delivery to authentication attempt.

Authentication outcome

The authentication journey concludes once the DC Platform reaches a terminal state and communicates it back to the Relying Party.

The request may end as:

• successful authentication,
• explicit user rejection,
• session timeout,
• or technical failure.

If authentication is successful, the Relying Party receives an access token and can retrieve the associated identity information according to the configured scopes and Issuer settings.

This stage allows the Issuer to monitor:

• authentication success rates,
• how often users explicitly reject requests,
• how often sessions expire without a user decision,
• frequency of technical failures,
• differences in final outcomes across Relying Parties.

It also helps distinguish between user-driven outcomes and backend or platform-level issues.

The following sequence diagram illustrates the complete CIBA Authentication flow, including backend request handling, request delivery to the iD Wallet application, user interaction, asynchronous result handling, and event emission visible to the Issuer.