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 

Credential issuance and provisioning begin after the identity proofing process has been completed successfully and the proofing decision has been accepted by the platform.   The process consists of two stages:  

1. Backend issuance, during which the platform creates the Digital Credential and prepares it for provisioning.
2. Device provisioning, during which the credential is delivered to and claimed by the iD Wallet on the user's device.

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:

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

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

Integrators can define custom ISO mappings used to create ISO/IEC 18013-5 datagroups. Each mapping must be provided as a JSON object compliant with the supported JSON Schema.

By default, the configuration includes the ISO/IEC 23220-4 PhotoID mapping.

IMPORTANT
Providing a custom array replaces the entire default configuration. The custom mappings are not merged with the existing mappings. Therefore, if PhotoID support is still required, the default PhotoID mapping must be included in the custom array.

Before applying the configuration, validate the JSON document against the provided JSON Schema.

The following excerpt from the JSON Schema defines the mapping configuration:

JSON
1{
2  "$schema": "https://json-schema.org/draft/2020-12/schema",
3  "mappings": {
4    "title": "ISO mapping available to the tenant",
5    "description": "This list defines the ISO mapping configurations used to create ISO 18013-5 datagroups. By default, the configuration includes the ISO 23220-4 Photo ID mapping. Providing a custom configuration fully replaces the default mappings. Consequently, the Photo ID mapping remains available only if it is explicitly included in the custom configuration.",
6    "type": "object",
7    "additionalProperties": {
8      "type": "object",
9      "description": "Defines how source attributes are mapped to the document type, namespaces, and data elements of an ISO mDoc.",
10      "additionalProperties": false,
11      "properties": {
12        "name": {
13          "type": "string",
14          "description": "User-friendly name identifying the ISO mapping configuration."
15        },
16        "applicableDocumentTypes": {
17          "type": "array",
18          "description": "Lists the source document types for which this ISO mapping is used during Digital Credential issuance. The namespace attribute list must include documentType, and its value should match one of the listed values, for example, IDENTITY_CARD. Its value is determined by ID&V Proofing based on the presented evidence or provided directly by the issuer through the Direct Issuance API. For document types that are not listed, the default Photo ID mapping is used.",
19          "items": {
20            "type": "string"
21          }
22        },
23        "docType": {
24          "type": "string",
25          "description": "ISO 18013-5 mDoc document type to use. The value must follow the reverse-DNS naming convention.",
26          "examples": ["org.iso.23220.photoid.1"]
27        },
28        "namespace": {
29          "type": "array",
30          "description": "List of attribute namespaces to include in the ISO datagroup",
31          "items": {
32            "type": "object",
33            "additionalProperties": false,
34            "properties": {
35              "name": {
36                "type": "string",
37                "description": "Specifies the namespace identifier included in the generated ISO mDoc. The value must follow the reverse-DNS naming convention.",
38                "examples": ["org.iso.23220.1"]
39              },
40              "dataElement": {
41                "type": "array",
42                "description": "Defines how source attributes are mapped to ISO data elements within this namespace.",
43                "items": {
44                  "type": "object",
45                  "description": "Defines the mapping and encoding rules for an individual ISO data element.",
46                  "additionalProperties": false,
47                  "properties": {
48                    "name": {
49                      "type": "string",
50                      "description": "Specifies the name of the source attribute in IDEMIA internal format that provides the value for the ISO data element."
51                    },
52                    "isoIdentifier": {
53                      "type": "string",
54                      "description": "Specifies the identifier of the data element in the generated ISO mDoc."
55                    },
56                    "isoFormat": {
57                      "type": "string",
58                      "description": "Specifies how the source attribute value is encoded in the ISO mDoc. Supported values are: string, date, binary, boolean. When binary is used, the source attribute value must be Base64-encoded."
59                    },
60                    "mandatory": {
61                      "type": "boolean",
62                      "description": "Specifies whether the data element is required to issue the ISO mDoc. If the source attribute is missing and no default value is configured, issuance may fail depending on the failOnMissingMandatoryAttributes setting."
63                    },
64                    "defaultValue": {
65                      "type": "string",
66                      "description": "Specifies the value to use when the source attribute is not provided."
67                    }
68                  }
69                }
70              }
71            }
72          }
73        }
74      },
75      "required": [
76        "name", 
77        "applicableDocumentTypes", 
78        "docType", 
79        "namespace"
80    ]
81    }
82  }
83}

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 the input document types for which the mapping can be used. Each document type specified in this section must match the documentType name configured in the DC Platform and must be provided in the issuance request within the vnd.idemia.identity.dc namespace.

JSON
1"applicableDocumentTypes": [
2  "IDENTITY_CARD",
3  "DRIVING_LICENSE",
4  "RESIDENT_CARD",
5  "PASSPORT"
6  ]

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:

JSON
1...
2"namespace": [
3  {
4    "name": "org.iso.23220.1",
5      ...
6  }
7]

Data Element Mapping

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

Example:

JSON
1"namespace": [
2    {
3        "name": "org.iso.23220.1",
4        "dataElement": [
5            {
6                "name": "lastName",
7                "isoIdentifier": "family_name",
8                "mandatory": true
9            },
10            {
11                "name": "firstName1",
12                "isoIdentifier": "given_name",
13                "mandatory": true
14            },
15            {
16                "name": "birthDate",
17                "isoIdentifier": "birth_date",
18                "isoFormat": "date",
19                "mandatory": true
20            },
21            {
22                "name": "frontPortrait",
23                "isoIdentifier": "portrait",
24                "isoFormat": "binary",
25                "mandatory": true
26            },
27            {
28                "name": "issueDate",
29                "isoIdentifier": "issue_date",
30                "isoFormat": "date",
31                "mandatory": true
32            },
33            {
34                "name": "expireDate",
35                "isoIdentifier": "expiry_date",
36                "isoFormat": "date",
37                "mandatory": true
38            },
39            {
40                "name": "is18",
41                "isoIdentifier": "age_over_18",
42                "isoFormat": "boolean",
43                "mandatory": true
44            },
45            {
46                "name": "selfie",
47                "isoIdentifier": "enrolment_portrait_image",
48                "isoFormat": "binary"
49            },
50            {
51                "name": "ageInYears",
52                "isoIdentifier": "age_in_years",
53                "isoFormat": "integer"
54            },
55            {
56                "name": "country",
57                "isoIdentifier": "resident_country",
58                "default": "FR"
59            }
60        ]
61    }
62]

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.

IDEMIA Digital Credential Namespace

The vnd.idemia.identity.dc namespace is an IDEMIA-specific namespace containing technical and document-related data elements required by the DC Platform.

It supplements the standard ISO namespaces with identifiers used to distinguish a credential from its device-specific instances and to support Digital Credential lifecycle management.

The credentialId identifies the credential, while midUid identifies a specific deviceCredential installed in a wallet. Exposing these identifiers during presentment allows subsequent lifecycle operations to target the appropriate platform record without requiring the Issuer to obtain the identifiers through lifecycle event integration.

The namespace is by default included in Digital Credential datagroups and its data elements can be requested through the supported OIDC, ISO 18013-7 remote presentment, and ISO 18013-5 in-person presentment interfaces.

The namespace also contains the document type and the expiry date of the physical document associated with the Digital Credential.

The vnd.idemia.identity.dc namespace contains the following data elements:

Default Mapping Example

The following example shows the default Photo ID mapping configuration.

JSON
1"mappings": {
2    "default": {
3        "name": "Photo ID",
4        "applicableDocumentTypes": [
5            "IDENTITY_CARD",
6            "DRIVING_LICENSE",
7            "RESIDENT_CARD",
8            "PASSPORT"
9        ],
10        "docType": "org.iso.23220.photoid.1",
11        "namespace": [
12            {
13                "name": "org.iso.23220.1",
14                "dataElement": [
15                    {
16                        "name": "lastName",
17                        "isoIdentifier": "family_name",
18                        "mandatory": true
19                    },
20                    {
21                        "name": "firstName1",
22                        "isoIdentifier": "given_name",
23                        "mandatory": true
24                    },
25                    {
26                        "name": "birthDate",
27                        "isoIdentifier": "birth_date",
28                        "isoFormat": "date",
29                        "mandatory": true
30                    },
31                    {
32                        "name": "frontPortrait",
33                        "isoIdentifier": "portrait",
34                        "isoFormat": "binary",
35                        "mandatory": true
36                    },
37                    {
38                        "name": "issueDate",
39                        "isoIdentifier": "issue_date",
40                        "isoFormat": "date",
41                        "mandatory": true
42                    },
43                    {
44                        "name": "expireDate",
45                        "isoIdentifier": "expiry_date",
46                        "isoFormat": "date",
47                        "mandatory": true
48                    },
49                    {
50                        "name": "jurisdictionId",
51                        "isoIdentifier": "issuing_authority",
52                        "mandatory": true
53                    },
54                    {
55                        "name": "countyCode",
56                        "isoIdentifier": "issuing_country",
57                        "mandatory": true
58                    },
59                    {
60                        "name": "placeOfBirth",
61                        "isoIdentifier": "birthplace",
62                        "isoFormat": "string"
63                    },
64                    {
65                        "name": "nationality",
66                        "isoIdentifier": "nationality",
67                        "isoFormat": "string"
68                    },
69                    {
70                        "name": "gender",
71                        "isoIdentifier": "sex",
72                        "isoFormat": "integer"
73                    },
74                    {
75                        "name": "is18",
76                        "isoIdentifier": "age_over_18",
77                        "isoFormat": "boolean",
78                        "mandatory": true
79                    },
80                    {
81                        "name": "is21",
82                        "isoIdentifier": "age_over_21",
83                        "isoFormat": "boolean"
84                    },
85                    {
86                        "name": "is25",
87                        "isoIdentifier": "age_over_25",
88                        "isoFormat": "boolean"
89                    },
90                    {
91                        "name": "selfie",
92                        "isoIdentifier": "enrolment_portrait_image",
93                        "isoFormat": "binary"
94                    },
95                    {
96                        "name": "ageInYears",
97                        "isoIdentifier": "age_in_years",
98                        "isoFormat": "integer"
99                    },
100                    {
101                        "name": "documentId",
102                        "isoIdentifier": "document_number"
103                    },
104                    {
105                        "name": "address1",
106                        "isoIdentifier": "resident_address"
107                    },
108                    {
109                        "name": "city",
110                        "isoIdentifier": "resident_city"
111                    },
112                    {
113                        "name": "postalCode",
114                        "isoIdentifier": "resident_postal_code"
115                    },
116                    {
117                        "name": "country",
118                        "isoIdentifier": "resident_country"
119                    }
120                ]
121            },
122            {
123                "name": "org.iso.23220.datagroups.1",
124                "dataElement": [
125                    {
126                        "name": "photoIdVersion",
127                        "isoIdentifier": "version",
128                        "isoFormat": "string",
129                        "defaultValue": "1"
130                    },
131                    {
132                        "name": "DG1.RawData",
133                        "isoIdentifier": "dg1",
134                        "isoFormat": "binary"
135                    },
136                    {
137                        "name": "DG2.RawData",
138                        "isoIdentifier": "dg2",
139                        "isoFormat": "binary"
140                    },
141                    {
142                        "name": "DG14.RawData",
143                        "isoIdentifier": "dg14",
144                        "isoFormat": "binary"
145                    },
146                    {
147                        "name": "DG15.RawData",
148                        "isoIdentifier": "dg15",
149                        "isoFormat": "binary"
150                    },
151                    {
152                        "name": "DG29.RawData",
153                        "isoIdentifier": "sod",
154                        "isoFormat": "binary"
155                    }
156                ]
157            },
158            {
159                "name": "vnd.idemia.identity.dc",
160                "dataElement": [
161                    {
162                        "name": "documentType",
163                        "isoIdentifier": "documentType",
164                        "mandatory": true
165
166                    },
167                    {
168                        "name": "credentialId",
169                        "isoIdentifier": "credentialId"
170                    },
171                    {
172                        "name": "midUid",
173                        "isoIdentifier": "midUid"
174                    },
175                    {
176                        "name": "physicalDocumentExpireDate",
177                        "isoIdentifier": "physical_document_expiry_date"
178                    },
179                    {
180                        "name": "deviceCredentialExpireDate",
181                        "isoIdentifier": "device_credential_expiry_date"
182                    },
183                ]
184            }
185        ]
186    }
187}

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:

JSON
1"namespace": [
2    {
3        "name": "com.example.photoid.extension.1",
4        "dataElement": [
5            {
6                "name": "internalCustomerId",
7                "isoIdentifier": "customer_id",
8                "mandatory": true
9            }
10        ]
11    }
12]

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 

The options described in this section determine tenant-specific credential issuance and lifecycle behavior. To review the current settings or request changes, contact your Partner Manager.

Digital Credential Expiration

The Digital Credential expiration date defines the administrative validity period of a credential held on a device. It is independent of the validity period of an ISO mDoc Mobile Security Object (MSO).

By default, a Digital Credential remains valid for 30 days from its issuance date.

The tenant may use the default 30-day validity period or request a tenant-specific period, for example 7 days or 21 days. The selected period applies to every Digital Credential issued for the tenant, causing each credential to expire when that period has elapsed.

Depending on the tenant configuration, the expiration date may be determined using either:

1. A tenant-specific validity period calculated from the credential issuance date.
2. The expiration date of the proofing evidence used to issue the credential.

The proofing evidence expiration date can be used only if the evidence is still valid when the Digital Credential is issued. If the evidence does not contain a valid or usable expiration date, the tenant-specific validity period is applied.

The platform can also be configured to always use the tenant-specific validity period, regardless of the expiration date of the source document or other proofing evidence.

Example

Default 30-day validity period If a Digital Credential is issued on 1 June, it expires on 1 July.

If the tenant-specific validity period is set to 7 days, a Digital Credential issued on 1 June expires on 8 June.

If it is set to 21 days, a Digital Credential issued on 1 June expires on 22 June.

IMPORTANT

Digital Credential expiration and ISO MSO expiration represent separate lifecycle controls. The expiration of an MSO does not necessarily mean that the Digital Credential has expired or must be removed from the Wallet.

To review or change the Digital Credential validity period for your tenant, contact your Partner Manager.

Expiration Grace Period

When a Digital Credential expires, it is not immediately removed from the user's Wallet. It remains visible for a tenant-specific grace period.   By default, the grace period is 30 days. The tenant may request a different duration.

The end of the grace period is calculated as follows:

Text
1Grace period end date =
2Digital Credential expiration date + configured grace period

During the grace period, the credential remains associated with the Wallet, allowing the applicable post-expiration lifecycle policy to be completed. Eligible MSOs will also be renewed during this period.

When the grace period ends, the platform automatically removes the expired Digital Credential from the device. Standard credential deletion and Wallet lifecycle processing then apply.

Because the removal is initiated automatically by the platform, the corresponding lifecycle event identifies PLATFORM as its origin.

Example: If a Digital Credential expires on 1 July and the tenant has a 30-day grace period, the credential remains visible in the Wallet during that period. The platform automatically removes it on 31 July.

To review or change the grace period for your tenant, contact your Partner Manager.

Age Attestations

The platform can automatically derive and maintain age attestations based on the credential subject's date of birth. This capability is enabled by default.

When enabled, the platform:

• calculates applicable age attestations based on the subject's date of birth;
• automatically renews the affected Digital Credential data when the subject crosses a relevant age threshold.

For example, an attestation indicating that a subject is under a specific age may need to be updated when the subject reaches that age.

If automatic age-attestation calculation is disabled for the tenant, age attestations are not automatically populated or maintained by the platform.

Automatic calculation is possible only when the required birth-date information is available in the credential data supplied during issuance.

To enable, disable, or review automatic age-attestation calculation for your tenant, contact your Partner Manager.

ISO mDoc MSO Expiration

An ISO mDoc Mobile Security Object (MSO) has its own validity period, independent of the Digital Credential expiration date.

Short-lived MSOs require each device to regularly obtain refreshed credential material. This limits how long an older MSO can be used, reduces the risk of continued offline use after remote revocation, and supports privacy by preventing the same signed credential material from being reused over an extended period.

The platform can apply different MSO validity periods to different ISO mDoc document types. An ISO mDoc document type is identified by its docType, such as org.iso.23220.photoid.1 or a tenant-specific value such as vnd.mycompany.mydoctype.

The MSO expiration date is calculated from the MSO issuance time:

Text
1MSO expiration date =
2MSO issuance date and time + applicable MSO validity period

If a dedicated validity period is defined for the ISO mDoc docType, the platform applies that period. Otherwise, the tenant's default MSO validity period is used.

Example

A tenant may use different MSO validity periods for org.iso.23220.photoid.1 and vnd.mycompany.mydoctype. Any ISO mDoc docType without a dedicated validity period uses the tenant's default MSO validity period.

To review or change the MSO validity periods for your tenant, contact your Partner Manager.

MSO Validity Period Selection

The platform selects the applicable MSO validity period in the following order:

1. The validity period defined for the relevant ISO mDoc docType, for example org.iso.23220.photoid.1 or vnd.mycompany.mydoctype.
2. The tenant's default MSO validity period.

This allows selected ISO mDoc types to use dedicated MSO validity periods while retaining a common fallback for any docType without a dedicated configuration.

MSO Renewal Window

An MSO may be renewed for as long as the Digital Credential remains available in the Wallet, including during the expiration grace period.

The maximum MSO renewal window is determined as follows:

Text
1MSO renewal window end date =
2Digital Credential expiration date + grace period

When the grace period ends, the Digital Credential is automatically removed from the Wallet and its MSO can no longer be renewed.

IMPORTANT
Digital Credential expiration and MSO expiration are managed independently. An MSO may therefore be renewed after the Digital Credential expiration date, provided that the Digital Credential remains visible in the iD Wallet during the grace period.

Relationship Between Lifecycle Dates

The platform manages three separate lifecycle periods:

1. Digital Credential validity
   Determines the administrative validity period of the credential.

2. Digital Credential grace period
   Determines how long an expired credential remains visible and associated with the iD Wallet before automatic removal.

3. MSO validity
   Determines how long a particular ISO mDoc MSO remains cryptographically valid before it must be renewed.

These periods are managed independently. As a result, a Digital Credential may contain multiple consecutively issued MSOs during its lifecycle.

A typical lifecycle is:

1. The Digital Credential is issued.
2. An MSO is issued with the validity period applicable to its ISO mDoc type.
3. The MSO is renewed as required while the Digital Credential remains available.
4. The Digital Credential reaches its expiration date.
5. The Digital Credential remains visible during the tenant-specific grace period.
6. When the grace period ends, the platform removes the Digital Credential and emits the applicable lifecycle event with PLATFORM as its origin.

MSO Status List

The MSO Status List allows relying parties to perform near-real-time revocation checks for issued MSOs. This capability is disabled by default.

When the MSO Status List is enabled, longer MSO validity periods may be appropriate because relying parties can verify the current revocation status without relying exclusively on short MSO validity periods.

The selected validity period should balance:

• security and revocation requirements;
• expected offline presentation scenarios;
• how frequently devices must obtain renewed MSOs;
• the network and processing resources required for MSO renewal.

This feature is disabled by default. To enable the MSO Status List or review the appropriate MSO validity period for your tenant, contact your Partner Manager.

MSO Auditing

MSO auditing enables the secure retention of information associated with issued MSOs for audit and compliance purposes.

Audit information containing personally identifiable information is encrypted using a certificate provided for the tenant. The corresponding private key remains under the tenant's control.

This capability is disabled by default. To enable MSO auditing or review the applicable retention period, contact your Partner Manager. As part of the onboarding process, you will be asked to provide the encryption certificate required to protect the audit data.

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.

Issuance Result 

Successful Issuance 

  When backend issuance completes successfully, the platform:  

• creates the Digital Credential;
• generates the required device-specific credential data;
• emits an mIDIssued event;
• marks the enrollment request as ACCEPTED.   The mIDIssued event confirms that the credential has been issued successfully by the platform. It does not confirm that the credential has already been claimed by the user's device.   Subscription to the mIDIssued event is optional. It is typically required when the Issuer does not provide the credentialId and needs to retrieve it from the event.   A recommended processing flow for subscribers is:  

1. Receive and securely store the event.
2. Return HTTP 202 Accepted after the event has been stored or otherwise secured for further processing.  

Important

The mIDIssued event confirms successful backend issuance. Completion of provisioning on the user's device is confirmed separately by the mIDClaimed event.  

Issuance Failure 

  If an internal platform error prevents the Digital Credential from being issued, the platform emits an mIDIssuanceFailed event.   This event indicates an unexpected platform error that should not occur during normal operation. The affected enrollment is terminated, and the user may attempt the enrollment again.   If the issue persists, the Issuer should open a support ticket with IDEMIA and provide the relevant request and event identifiers to support troubleshooting.

Provisioning 

After successful backend issuance, credential provisioning continues on each requested user device.   For each device, the platform:  

• creates a device-specific credential instance - Digital Credential;
• assigns a unique midUid to that instance;
• generates a Mobile Security Object (MSO);
• marks the issuance operation as MSO_PROVISIONING.

The issued credential data is then made available to the iD Wallet for provisioning.   Device Provisioning   When the iD Wallet successfully claims the credential on the device:  

1. The user receives confirmation that the credential has been added successfully.
2. The iD Wallet emits an mIDClaimed event.
3. The platform forwards the event to registered subscribers.

The mIDClaimed event confirms that the credential has been successfully claimed on the device and that provisioning for that device is complete.   Subscription to the mIDClaimed event is recommended because it provides device-level confirmation that the enrollment and provisioning process has completed successfully.   A recommended processing flow for subscribers is:  

1. Receive and securely store the event.
2. Return HTTP 202 Accepted after the event has been stored or otherwise secured for further processing.
3. Associate the received midUid with the corresponding credentialId.
4. Mark the device-specific credential instance as ACTIVE.

At this point, the Digital Credential enrollment and provisioning process for the device is considered complete.

Enrollment sequence diagram