Digital Credential Identity Provider
In addition to supporting ISO 18013-5 digital credential in-person presentment and ISO 18013-7 support, the Digital credential platform offers an OpenID Connect (OIDC) Identity Provider (IDP) interface that leverages Digital Credentials as core foundation.
This approach offers the following differentiation compared to traditional OIDC IDP:
- Distributed model: The DC IDP only store technical information referencing user identifiers and associated digital credential. All sensitive information is distributed to the users devices Digital Credential
- Multi-factor biometric authentication: Digital credentials are cryptographically bound to mobile device hosted keys that can be used as authentication factor. The Digital Credential may also contains a holder portrait which can be used reference portrait for biometric matching as additional authentication factor.
Using OIDC over ISO 18013-7 provides the following benefits:
- Maturity: OIDC is an extremely mature standard
- Ubiquity: every major platform, framework, and cloud provider already supports OIDC, which makes integration trivial compared to building mdoc/CBOR tooling from scratch.
- Flexibility: the DC OIDC implementation is not tied to a single credential format.
- Federation: natively supports chaining identity providers, useful in enterprise and cross-border scenarios.
- Developer experience: OIDC has vast tooling, SDKs, and well-understood security model which lowers the integration barrier significantly.
- Added features: OIDC provides added value feature like out of band transaction management
Who is this documentation for?
This section serves two distinct integration roles. Before reading further, identify which applies to you.
You are a Relying Party integrator if you are building a service that will authenticate users via their Digital Credential. You will integrate directly with the Digital Credential OIDC endpoints.
You are an Issuer integrator if you are the organization that issues Digital Credentials through IDEMIA Digital Credential and want visibility into how those credentials are used across partner services. You will consume events emitted by the Digital Credential to monitor authentication activity, measure adoption, and observe how users interact with Online Authentication and CIBA flows.
Both roles share the same API reference and event schemas. The flows described below are presented from both perspectives.
OIDC Authorization Code Flow
IDEMIA Authorization Code Flow is based on OpenID Connect (OIDC), a standards‑based protocol that enables secure user authentication through a trusted Identity Provider — the Digital Credential (DC) Platform.
Using OIDC Code flow, relying parties can authenticate users and obtain verified identity attributes in a standard, secure, consent‑driven manner.
During the authentication flow, the user is redirected to the DC platform and presented with a QR-Code to scan with their DC-enabled application.
Within the application, the user reviews the authentication request and provides explicit consent to share (or decline sharing) the requested identity attribute. The user proceeds with authenticating in the mobile application. On successful authentication, a session specific Code is provided back to the relying party. The code can be exchanged for the idToken containing the scope of attributes requested. The approved attributes are securely transmitted to the Relying Party within the OIDC IdToken, allowing the relying party to grant access to the protected resource.
Client-Initiated Backchannel Authentication
Using OIDC CIBA, relying parties can request authentication, transaction confirmation and a selective set of identity attributes to their users out-of-band, ie without the user being actively engaged. This mode can serve as a strong second factor authentication or as a secure transaction confirmation, as the user validates the request on a trusted personal device.
During this flow, The relying party sends a machine-to-machine request to the DC Platform for a known user with an optional contextual information. The DC platform then identifies the set of device to notify and triggers a push notification to the target user's device.
Within the application, the user reviews the contextual information, provides explicit consent to share (or decline sharing) the requested identity attribute and authenticates. The result of the authentication is then conveyed to the relying party in a machine-to-machine fashion.
