Credential State Management 

This page describes the credential state operations supported by the Digital Credential Platform:

1. user-initiated removal
2. attribute updates
3. issuer-initiated state changes
4. Bulk state updates.

User-Initiated Credential Removal 

The Digital Credential Platform currently supports two user-initiated actions related to credential state.

• Unenrollment of a digital credential from the iD Wallet App – this action follows the workflow described in the next section.
• Deletion of the iD Wallet App – the following action affects only the iD Wallet App and is not propagated, as it does not involve any interaction with the DC Backend. Therefore, it does not follow the workflow described in the next section.

User-Initiated Credential Removal Flow 

Attribute Updates 

Attribute Updates Overview 

Attribute updates are initiated by Issuers for the following purposes:

• Processing changes to demographic data
• Updating age-related fields annually on the enrolled user's birth date

Attribute updates are processed for a digital credential (credentialId) and apply to all digital credential instances (deviceCredentials) enrolled in digital wallets.

The attribute update process consists of two steps:

1. Attribute update scheduling — processed for all deviceCredentials, regardless of their state.
2. Attribute update provisioning — processed only for ACTIVE deviceCredentials.

For SUSPENDED credentials, deviceCredentials pending attribute updates are processed once the digital credential is REINSTATED.

During these steps, notifications may be sent to the Issuer through Events.

IMPORTANT
Attribute updates are allowed only for ACTIVE or REINSTATED credentials. Requests for SUSPENDED credentials are rejected.

Attribute Updates Workflow 

Attribute Update Scheduling

Attribute Update Provisioning

Issuer-Initiated Credential State Updates 

Issuer-Initiated Credential State Update Overview 

Issuers can initiate state updates either for an entire credential or for a specific deviceCredential.

In lifecycle management requests, the state field represents the intended target state requested by the Issuer. The scope and behavior of the update depend on the combination of:

• targetRecordTypes,
• the recordIdentifierType provided (documentId, credentialId, or midUid).

Target Record Types Behavior 

targetRecordTypes is an optional parameter that allows the caller to alter the state of credential and deviceCredential records independently.

If targetRecordTypes is not provided or is left empty, the default behavior applies and both credential and deviceCredential are targeted.

The default behavior is equivalent to:

JSON
1"targetRecordTypes": ["CREDENTIAL", "DEVICE_CREDENTIAL"]

It means that the default value is targeting both - credential and deviceCredential.

NOTE
In most cases, this parameter does not need to be provided explicitly. When in doubt, do not provide targetRecordTypes.

targetRecordTypes: ["CREDENTIAL"]

Only the credential state stored in the DC Backend is updated. No state updates are propagated to deviceCredentials in end-user mobile apps.

IMPORTANT
Exception: Credential revocation additionally triggers cleanup of all associated deviceCredentials (see details below).

Record Identification :  

State Effect :  

targetRecordTypes: ["DEVICE_CREDENTIAL"]

Only deviceCredential records are updated. The credential state is not affected.

midUid limits the update to a single deviceCredential.

IMPORTANT
Exception: The last deviceCredential revocation additionally triggers cleanup of associated credential.

Record Identification :  

State Effect :  

targetRecordTypes: ["CREDENTIAL", "DEVICE_CREDENTIAL"]

Both Credential and DeviceCredential records may be updated.

Processing order:

1. Credential state update
2. DeviceCredential state update

Behavior modifiers:

• If recordIdentifierType = midUid:
  • Credential is updated
  • Only the specified deviceCredential is updated

Confirmation events emitted after a successful state change include both previousState and newState. The newState reflects the effective state after the change has been applied in accordance with the Issuer’s request.

Success Events :  

Failure Events :  

Failure events include error details describing the reason for the failure.

Supported state updates include:

• Suspending a credential or deviceCredential so that it cannot be used across the full spectrum of supported use cases. The issuer sends the requested state as SUSPENDED.
• Reinstating a suspended credential or deviceCredential so that it becomes usable again (Issuer sends requested state as REINSTATED)
• Unlinking, revoking, or deleting a digital credential or deviceCredential (Issuer sends requested state as REVOKED)

Credential Deletion

A credential in the REVOKED state is removed from the system. As a result, no credential state is stored in the DC Backend.

Likewise, if a deviceCredential is UNLINKED, it is removed from the DC Backend.

If removed digitalCredential was the last deviceCredential assigned to credential then credential data are removed from backend and new event mIDCredentialRemoved is produced

Bulk State Update 

Bulk State Update allows the Issuer to submit a single request containing state update instructions for multiple Digital Credentials.

Unlike a singleton state update, which processes a single record per request, a bulk request contains an array of individual update entries. Each entry is processed independently using the same rules and validation logic as a standard singleton state update - it means that as a result, a single bulk request may produce a mix of successful and failed update results across its entries.

Bulk processing is asynchronous. Submitted requests are not processed immediately. Instead, they are picked up by a scheduler configured at the tenant level and executed according to the tenant-specific schedule.

As the batch is processed, the platform emits the corresponding events for each individual Credential or deviceCredential, depending on the request scope and processing outcome.

A bulk request is composed of multiple single update instructions contained in the updates array.

For details please check Lifecycle Management OpenAPI and Lifecycle Events.

Issuer-Initiated State Updates Flow