Mobile Security Object (MSO) Renewal 

Digital Credentials issued to a iD Wallet include ISO data groups with a Mobile Security Object (MSO) to ensure freshness. The MSO includes a Time-To-Live (TTL), which defaults to 30 days. After that period, the MSO is no longer valid.

Digital wallets detect MSO expiration automatically.

No action from the Issuer or user is required to initiate MSO renewal.

MSO renewal provisioning is triggered when the iD Wallet detects that the current Mobile Security Object (MSO) is expired or close to expiration. The expiration check is triggered when the app starts and whenever the credential is presented for verification.

If the MSO has expired, the iD Wallet apps call the IDEMIA DC platform and request an asynchronous MSO renewal. This process checks salt configuration, validate sent Merkle Tree, refreshes the MSO and issues the updated MSO.

MSO renewal provisioning may emit the following events:

• mIDIssued
• mIDIssuanceFailed

These events allow the Issuer to track the result of the renewal process and correlate it with the wallet request.

The current Digital Credential app workflow is shown below.

MSO Renewal Provisioning Flow 

MSO Status List 

The MSO Status List is an optional, backward-compatible feature based on an amendment to ISO 18013-5. It adds support for storing MSO status lists, enabling near real-time MSO revocation checks — a capability not included in the original specification.

When enabled, this feature supports both:

• verifier-side MSO validity checks, and
• Issuer-side compliance and audit requirements.

Whenever a credential is registered, reissued (for example, after attribute updates) or its MSO is renewed, new attribute hashes are generated and the Mobile Security Object (MSO) is overwritten.

When the MSO Status List feature is enabled, the platform enhances the standard MSO provisioning flow with additional MSO status metadata. In particular:

• a unique msoUid is generated,
• a bucketId is generated for the corresponding status list,
• a StatusListInfo element is embedded in the MSO.

This additional MSO element contains:

• an MSO identifier,
• a status list URI pointing to the published MSO Status List.

The status list URI has the following logical form:

Text
1https://mso-status.<tenant-domain>/status/<bucketId>

This URI allows verifiers to check whether the MSO presented during verification has been revoked.

Verifier-Side Behavior with Status List 

During offline verification, the verifier can extract the MSO Status List URI from the presented MSO and use it to validate the MSO status. The verification outcome is interpreted as follows:

• If the MSO is not present in the list, it is considered valid.
• If the MSO appears in the list, it is revoked and cannot be positively verified.

The MSO Status List contains only revoked MSOs. This mechanism enables efficient and standards-aligned revocation checking without requiring direct interaction with the Issuer during the verification step.

Status List from Issuer perspective 

When MSO provisioning completes successfully and the MSO Status List feature is enabled, the platform generates and stores a MobileSecurityObjectsInfo object.

This object contains:

• MSO expiration information,
• MSO identifiers,
• MSO public keys,
• the statusListBucketId,
• the statusListUri.

JSON
1{
2  "mobileSecurityObjectsExpiration": "<ISO 8601 UTC timestamp>",
3  "mobileSecurityObjects": {
4    "<msoUid>": {
5      "issuerAuth": "<Base64 encoded cbor>",
6      "publicKey": "<Base64 encoded mso public key>",
7      "statusListBucketId": "<bucketId>",
8      "statusListUri": "https://mso-status.<tenant-domain>/status/<bucketId>"
9    }
10  }
11}

To expose this information to the Issuer, the platform emits a dedicated event MobileSecurityObjectsIssued after successful MSO provisioning when the MSO Status List feature is enabled.

Its purpose is to provide the Issuer with access to MSO metadata, including the URL of the published MSO Status List.

JSON
1"payload": {
2    "credentialId": "a7a82462-3f72-4f42-ba8a-73fb6c7269dd",
3    "midUid": "c6c74456-dbe3-4d9b-b68d-0c13a48f048a",
4    "clientType": "IDEMIA",
5    "mobileSecurityObjectsInfoUrl": "https://test-platform.com/msoinfo/ffe9f213-1999-421f-9d92-b9cacceaec7d/94429287-ee58-472b-bc63-7fff898773d0/a5635406-acae-42bf-9a36-66b1fe098d31?X-Security-Token=IQoJb...",
6    "mobileSecurityObjectsInfoUrlExpiration": "2027-01-14T10:55:31.820Z"
7  }

This event contains a pre-signed URL that allows the Issuer to retrieve the corresponding MobileSecurityObjectsInfo.

NOTE
Pre-signed URLs are time-limited and remain valid for 2 hours. The Issuer should retrieve the referenced object within that period.

Recommended Issuer Processing

If subscribed to this event, the Issuer should:

• Receive and store the MobileSecurityObjectsIssued event.
• Acknowledge receipt with HTTP 202 Accepted.
• Retrieve the pre-signed URL from the event payload.
• Download the MobileSecurityObjectsInfo object.
• Store the downloaded metadata for operational reference or compliance purposes.
• Extract and retain the statusListUri for the relevant MSO.

Subscription to MobileSecurityObjectsIssued event is optional, but recommended when the Issuer needs visibility into MSO-level status list metadata.

This mechanism provides an efficient, standards-aligned revocation check.

Relationship to Standard Issuance Events 

The MSO Status List flow extends the standard MSO provisioning process. In addition to MobileSecurityObjectsIssued after successful MSO re-creation, the platform also emits the standard issuance events:

• mIDIssued — confirms successful MSO provisioning,
• mIDIssuanceFailed — indicates a provisioning failure caused by an internal platform error.

If subscribed, the Issuer should store these events and acknowledge them with HTTP 202 Accepted.

MSO Status List —​ Changes in MSO Issuance Flow 

Audit Data Storage 

Issuer systems may need to keep records required for audit, compliance, dispute resolution, or operational investigation.

To support this requirement, the Digital Credential Platform can expose ISO Audit Data generated during MSO provisioning. This includes the ISO/IEC 18013-5 content produced for a given deviceCredential and allows the Issuer to retrieve, decrypt, and store the data required for compliance and audit purposes.

The available audit data includes:

• full Digital Credential attribute set,
• Mobile Security Object(s) (MSOs),
• salt(s),
• device public key,
• MSO Status List metadata.

IMPORTANT
Generation of audit data requires the MSO Status List feature to be enabled.

NOTE
Long-term storage of ISO Audit Data may also be provided by IDEMIA on behalf of the Issuer, subject to configuration and commercial agreement.

This functionality extends the standard MSO provisioning flow and is available when the required feature toggle is enabled.

Access to audit data is provided through event MobileSecurityObjectsIssued, allowing the Issuer to retrieve MobileSecurityObjectsInfo and hence download and store the data.

JSON
1"payload": {
2    "credentialId": "a7a82462-3f72-4f42-ba8a-73fb6c7269dd",
3    "midUid": "c6c74456-dbe3-4d9b-b68d-0c13a48f048a",
4    "clientType": "IDEMIA",
5    "mobileSecurityObjectsInfoUrl": "https://test-platform.com/msoinfo/ffe9f213-1999-421f-9d92-b9cacceaec7d/94429287-ee58-472b-bc63-7fff898773d0/a5635406-acae-42bf-9a36-66b1fe098d31?X-Security-Token=IQoJb...",
6    "mobileSecurityObjectsInfoUrlExpiration": "2027-01-14T10:55:31.820Z"
7  }

IMPORTANT
This flow uses the same MobileSecurityObjectsIssued event as the MSO Status List flow. The difference is that the corresponding MobileSecurityObjectsInfo object additionally includes the encryptedAuditData section.

If feature toggle enabled, for each successful mIDIssued event with issuanceType = MSO_PROVISIONING, the platform additionally emits a dedicated event: MobileSecurityObjectsIssued

This event provides the Issuer with a pre-signed URL to retrieve a MobileSecurityObjectsInfo object.

The MobileSecurityObjectsInfo contains:

• MSO expiration information,
• MSO metadata,
• status list references,
• access information for encrypted ISO Audit Data.

A logical representation of the structure is shown below:

JSON
1{
2  "mobileSecurityObjectsExpiration": "<ISO 8601 UTC timestamp>",
3  "mobileSecurityObjects": {
4    "<msoUid>": {
5      "issuerAuth": "<Base64 encoded cbor>",
6      "publicKey": "<Base64 encoded mso public key>",
7      "statusListBucketId": "<bucketId>",
8      "statusListUri": "https://mso-status.<tenant-domain>/status/<bucketId>"
9    }
10  },
11  "encryptedAuditData": {
12    "prefix": "<storage prefix>",
13    "preSignedUrl": "<presigned URL>",
14    "preSignedUrlExpiration": "<ISO 8601 UTC timestamp>"
15  }
16}

Audit data is encrypted using JWE (JSON Web Encryption). Only the Issuer can decrypt it using a private key associated with a certificate based on ECC P-256 keys.

This ensures that:

• audit data remains confidential in transit and at rest,
• only the Issuer can access the plaintext content,
• the platform can securely expose compliance data without disclosing it to third parties.

Recommended Issuer Processing 

If the Issuer subscribes to MobileSecurityObjectsIssued for MSO status list and audit data, the recommended processing flow is as follows:

• Receive the MobileSecurityObjectsIssued event from the Event Hub.
• Store the event for traceability and audit purposes.
• Respond with HTTP 202 Accepted.
• Extract the pre-signed URL to MobileSecurityObjectsInfo from the event payload.
• Download the MobileSecurityObjectsInfo object.
• Store MobileSecurityObjectsInfo.
• Extract the pre-signed URL to encryptedAuditData.
• Download the encrypted audit payload.
• Store the encrypted payload.
• Decrypt the ISO Audit Data using the Issuer’s private key.
• Store the decrypted audit data in the Issuer’s repository.

IMPORTANT
All pre-signed URLs are time-limited and remain valid for 2 hours. The Issuer is responsible for retrieving the referenced objects within that validity window.

The audit data storage flow, showing differences from the standard MSO renewal provisioning process, is illustrated below.

Audit Data Storage - Changes in MSO Issuance Flow