Enrollment 

Enrollment is the process of proofing a user’s identity and provisioning a Digital Credential into a digital wallet.

A user can enroll a Digital Credential by downloading and installing the IDEMIA iD Wallet App.

The user then follows the required steps to enroll the credential in the wallet. Enrollment can start in one of two ways:

• Remote identity proofing:
  • directly in the app through document-based enrollment, where the user follows the guided steps to complete identity proofing.
• Direct Issuance QRCode
  • by scanning a QR code provided by the Issuer, where the transaction has already been created and the required attributes are already defined.

The data collected during enrollment is used to verify the user’s identity. If proofing is successful, the Digital Credential is provisioned into the user’s digital wallet.

The initial steps of the enrollment journey may differ depending on the selected enrollment option, but both paths ultimately lead to a proofing decision.

The Enrollment process can include the following processes:

• Trusted Attributes used to direct issuance
• Velocity check
• Document authentication
• Attribute matching
• Biometric matching
• Provisioning
• Notifications via Events

Remote enrollment options 

Remote enrollment leverage the ID&V Proofing processes to allow a user to remotely prove who they are pretending to be by scanning a document and performing biometric matching with liveness detection.

The Issuer can determine if whether remote enrollment is enabled and what modes are available among the following:

1. ICAO Document NFC scanning
   1. This mode offers the strongest level of assurance with the ability to read and cryptographically verify the ICAO document content, guaranteeing authenticity and content consistency.
   2. The biometric matching will be performed against the portrait extracted from the document
2. Document Authentication based
   1. This mode leverages IDEMIA's ID&V documentation for determining the document genuineness
   2. The biometric matching will be performed against the portrait extracted from the document

Customization is however not available from the experience portal. Contact your partner manager for setting up a specific mapping.

Digital Credential Direct Issuance 

The Direct Issuance enables the issuance of digital credentials based on trusted, pre-verified attribute data provided by Issuer via API. The process yields a unique QRCode that can be conveyed to the end-user by the Issuer.

Once the transaction is claimed, the user can independently complete the enrollment process on their mobile device. Completion of the process may involve biometric re-validation is requested by the Issuer.

After successful completion of the required steps, the digital identity initial validation can be finalized and the credential can be provisioned.

Detailed information about the Direct Issuance process, supported flows, and integration requirements is available in the Direct Issuance Integration Guide

Credential Issuance 

Attribute Mapping 

The Digital Credential Platform provides a default attribute mapping for issuing ISO/IEC 23220-4 Photo ID mDoc credentials.

The mapping defines how source document attributes are transformed into ISO-compliant data elements included in the issued credential. It also specifies the applicable document types, the target ISO document type, namespaces, and the list of attributes to be issued.

By default, the platform issues Photo ID credentials using the following docType:

Yaml
1docType: "org.iso.23220.photoid.1"

The default mapping can be used as-is or overridden by the issuer, depending on the implementation model.

Issuers may customize the mapping by:

• defining a custom mapping file and providing it to the integrator or administrator responsible for configuration on the Digital Credential Platform side.

Mapping Configuration Structure

A mapping configuration consists of the following main sections:

Applicable Document Types

The applicableDocumentTypes section defines which input document types can use the mapping. Mentioned document type must be matched with defined in the DC Platform name of documentType.

Yaml
1applicableDocumentTypes:
2  - PASSPORT
3  - IDENTITY_CARD
4  - DRIVING_LICENSE
5  - RESIDENT_CARD

This means that the same mapping can be applied when issuing credentials based on one of the listed document types.

docType

The docType is the main identifier of the mapping file and defines the ISO credential profile that will be issued.

For the Photo ID profile, the docType is: docType: "org.iso.23220.photoid.1"

This value is defined by ISO/IEC DTS 23220-4:2025 and identifies the credential as an ISO Photo ID mDoc. This profile follows the general mDoc framework and defines a ready-to-use identity credential format for Photo ID use cases.

A mapping file contains one docType only. The Digital Credential Platform uses this value to determine which credential profile the mapping applies to during issuance.

Issuers should treat this as a fixed identifier for the Photo ID profile — Issuers should not modify the docType unless they intend to issue a different ISO-defined credential profile.

Namespaces

Credential data is grouped into namespaces. A namespace defines the logical scope of the data elements included in the credential. The default Photo ID mapping may use the following namespaces:

The default mapping primarily uses the core ISO namespace:

Yaml
1namespace:
2  - name: "org.iso.23220.1"

Data Element Mapping

Each dataElement defines how an internal platform attribute is mapped to an ISO data element.

Example:

Yaml
1namespace:
2  - name: "org.iso.23220.1"
3    dataElement:
4      - name: "lastName"
5        isoIdentifier: "family_name"
6        mandatory: true
7
8      - name: "firstName1"
9        isoIdentifier: "given_name"
10        mandatory: true
11
12      - name: "selfie"
13        isoIdentifier: "enrolment_portrait_image"
14        isoFormat: binary
15
16      - name: "countyCode"
17        isoIdentifier: "issuing_country"
18        mandatory: true
19        defaultValue: "FR"

In this example, the DC Platform attribute lastName is issued as the ISO element family_name, and firstName1 is issued as given_name.

Because both attributes are marked as mandatory: true, the platform validates whether their values are available during issuance.

The outcome of this validation depends on the issuer configuration. Missing mandatory attributes may either be reported as warnings or cause the issuance process (and whole enrollment) to fail with an error.

The selfie attribute is mapped to the ISO element enrolment_portrait_image and uses the binary format. Since the mandatory property is not defined for this element, it is treated as optional and is included only if the value is available during enrollment.

If defaultValue is defined for an attribute, it can be used when no value is provided during enrollment. For mandatory attributes, the platform validates whether a value is available either from enrollment data or from the configured default value.

Default Mapping Example

The following example shows the beginning of the default Photo ID mapping configuration.

Yaml
1applicableDocumentTypes:
2  - IDENTITY_CARD
3  - DRIVING_LICENSE
4  - RESIDENT_CARD
5  - PHOTO_ID_PASSPORT
6  - PASSPORT
7docType: "org.iso.23220.photoid.1"
8namespace:
9  - name: "org.iso.23220.1"
10    dataElement:
11      - name: "lastName"
12        isoIdentifier: "family_name"
13        mandatory: true
14      - name: "firstName1"
15        isoIdentifier: "given_name"
16        mandatory: true
17      - name: "birthDate"
18        isoIdentifier: "birth_date"
19        mandatory: true
20      - name: "frontPortrait"
21        isoIdentifier: "portrait"
22        isoFormat: binary
23        mandatory: true
24      - name: "selfie"
25        isoIdentifier: "enrolment_portrait_image"
26        isoFormat: binary
27      - name: "issueDate"
28        isoIdentifier: "issue_date"
29        isoFormat: date
30        mandatory: true
31      - name: "expireDate"
32        isoIdentifier: "expiry_date"
33        isoFormat: date
34        mandatory: true
35      - name: "jurisdictionId"
36        isoIdentifier: "issuing_authority"
37        mandatory: true
38      - name: "countyCode"
39        isoIdentifier: "issuing_country"
40        mandatory: true
41      - name: "is18"
42        isoIdentifier: "age_over_18"
43        isoFormat: boolean
44        mandatory: true
45      - name: "is21"
46        isoIdentifier: "age_over_21"
47        isoFormat: boolean
48      - name: "is25"
49        isoIdentifier: "age_over_25"
50        isoFormat: boolean
51      - name: "ageInYears"
52        isoIdentifier: "age_in_years"
53      - name: "documentId"
54        isoIdentifier: "document_number"
55      - name: "address1"
56        isoIdentifier: "resident_address"
57      - name: "city"
58        isoIdentifier: "resident_city"
59      - name: "postalCode"
60        isoIdentifier: "resident_postal_code"
61      - name: "country"
62        isoIdentifier: "resident_country"
63      - name: "gender"
64        isoIdentifier: "sex"
65  - name: "org.iso.23220.datagroups.1"
66    dataElement:
67      - name: "photoIdVersion"
68        isoIdentifier: "version"
69        isoFormat: string
70        defaultValue: "1"
71      - name: "DG1.RawData"
72        isoIdentifier: "dg1"
73        isoFormat: binary
74      - name: "DG2.RawData"
75        isoIdentifier: "dg2"
76        isoFormat: binary
77      - name: "DG14.RawData"
78        isoIdentifier: "dg14"
79        isoFormat: binary
80      - name: "DG15.RawData"
81        isoIdentifier: "dg15"
82        isoFormat: binary
83      - name: "DG29.RawData"
84        isoIdentifier: "sod"
85        isoFormat: binary

Customizing the Mapping

Issuers can override the default mapping when a different credential structure is required.

Custom mapping can be used to:

• include or exclude optional attributes,
• add recommended or conditional attributes,
• map issuer-specific source fields to ISO identifiers,
• define additional namespaces,
• add national, regional, sector-specific, or issuer-specific extensions,
• support different source document types.

A custom mapping can be configured in one of the following ways:

• Custom mapping file The issuer can define a mapping file and provide it to the integrator or Digital Credential Platform administrator for configuration.

Custom Namespace Support

In addition to ISO namespaces, issuers may define their own namespaces for data elements that are not covered by the default ISO Photo ID profile.

Custom namespaces should be used when the issuer needs to include:

• national attributes,
• regional or state-level attributes,
• sector-specific attributes,
• custom data defined by the issuer.

Example custom namespace:

Yaml
1namespace:
2  - name: "com.example.photoid.extension.1"
3    dataElement:
4      - name: "internalCustomerId"
5        isoIdentifier: "customer_id"

Issuer-defined namespaces should follow a controlled naming convention and be reviewed with the DC Platform Administrator to avoid collisions with ISO namespaces or namespaces defined by other issuers.

Attributes validation 

During provisioning of the credential with the ISO datagroup, failOnMissingMandatoryAttributes configuration is to provide flexibility in deciding whether the absence of mandatory attributes should only trigger a warning placed in the mIDIssued event (the default behavior) without interrupting the issuance process (soft validation), or whether the absence of any mandatory attribute should instead halt the entire identity issuance process and result in errors within mIDIssuanceFailed (hard validation).

The DC Backend supports two configurable validation modes, controlled by the failOnMissingMandatoryAttributes feature toggle:

1. Hard Validation (default, feature toggle set to true)

   The ISO Digital Credential issuance process is rejected if any mandatory field is missing. Instead of mIDIssued, an mIDIssuanceFailed event is generated. The error object in this event contains detailed information about the missing attributes and their corresponding namespaces. This mode enforces strict compliance with ISO when full attribute completeness is required. It is especially useful for document-based enrollment, where the user completes identity proofing directly in the app without external supervision and the platform must ensure that all mandatory attributes are present before issuing the credential.

2. Soft Validation (feature toggle set to false)

   The ISO Digital Credential issuance continues even if some mandatory fields are missing. Missing fields are logged and included in the warnings array within the mIDIssued event. This mode ensures smooth integration with minimal disruption while still reporting validation gaps

Credential Issuance Options 

All options below are configuration available through your partner manager.

Credential expiration

The digital credential may contain an expiration date that represents the administrative validity of the credential or the underlying source document. It can be aligned with the expiration date of the physical document used during enrollment or provided by the issuer via API.

Expiration of the credential date does not automatically prevent MSO issuance or presentation; post-expiration behavior must be defined and enforced by the issuer according to the applicable lifecycle policy. The issuer is responsible for defining what should happen when the credential or source document expires.

Depending on the use case and applicable rules, an expired document may be rejected, renewed, suspended, revoked, or still used for limited identity verification purposes.

MSO Expiration

ISO MSO expiration is a mechanism that forces each devices to get a re-issued digital credential on a regular basis. This mechanism is privacy preserving to avoid the MSO from being used by colluding relying parties as a tracking mechanism but also to minimize the risk of Offline credential usage despite remote revocation being invoked.

Digital Credential have a default expiration of 30 days which is a good balance between processing overhead vs security.

This value can be typically increased if MSO status list is enabled.

MSO Status list

MSO Status list provided the ability for relying parties to have near-realtime revocation validation of MSO.

This feature is disabled by default.

MSO Auditing

Successful Issuance

If the issuance process completes successfully, the backend emits an mIDIssued event. The enrollment request is then marked as accepted.

Subscription to the mIDIssued event is optional and typically required only when the Issuer doesn't generate the credentialId.

A recommended processing flow for subscribers includes:

• storing the received event,
• responding to event hub with HTTP code 202 Accepted.

Issuance Failure

If an internal error occurs during issuance, the backend emits an mIDIssuanceFailed event.

This event indicates an internal platform error that is not expected to occur under normal conditions. If the issue persists, the Issuer should raise an exception and open a support ticket with IDEMIA.

In this case, enrollment is terminated and the user may attempt enrollment again.

Provisioning 

Credential provisioning starts after the proofing process has been successfully completed and the proofing decision has been accepted by the platform.

At this stage, the backend initiates the issuance and provisioning of the digital credential to the device.

The Digital Credential Backend performs the following actions:

For each requested device:

• A unique midUid is generated for the deviceCredential.
• A Mobile Security Object (MSO) is generated.
  • The issuanceType is set to MSO_PROVISIONING.

After successful backend issuance, the provisioning process continues on the user device.

IDEMIA iD Wallet Processing:

1. The user receives a notification confirming successful issuance.
2. The wallet emits an mIDClaimed event indicating that the credential has been successfully claimed on the device.

The backend forwards the mIDClaimed event to subscribers. Subscription to the mIDClaimed event is recommended, as it provides an acknowledgment from the device that the digital credential enrollment is completed.

A suggested processing flow for subscribers includes:

• storing the event,
• responding with HTTP 202 Accepted,
• persisting midUid and credentialId,
• setting the credential state to ACTIVE.

At this point, the enrollment and provisioning process is considered complete and successful.

Enrollment sequence diagram