Typical Issuance and Management Process

The steps in a typical issuance and management process of a badge/smart card used for both physical and logical access from a smart card issuance point of view are:

The device request is also called device provisioning. This mechanism provisions a request for a device into ActivID CMS with a specific device policy, and, optionally, a PIN. The device policy specifies what credentials and data are to be loaded onto the card (such as PKI certificates, OTP, or static data).

ActivID CMS requires a device production request to synchronize a request queued in ActivID CMS with a physical smart card or device. A device production request must always specify an application set (device policy). The list of possible device policies can be programmatically retrieved using the CCM API findApplicationSets method. A device issuance request may be issued by:

There are two possible action types allowed while issuing a device: “issuance” and “produce”. They are equivalent, except that when “produce” is used, the card requires activation after it has been synchronized. To perform a device production request, the following steps are required:

  • Bind a device to the user. The binding may be performed by another system at a later time before the device is synchronized (for details, see Device Binding).

  • Submit an issuance action request with appropriate parameters (PIN, policy, or reason). Set the PIN (optional), Policy (mandatory) and Reason (mandatory) parameters.

To send an issuance request, you do NOT need to provision a PIN. However, at the time of synchronization, the PIN parameter is required. You can either use the ActivID CMS Operator Portal or the synchronize method of the SyncManager to set the PIN parameter. The following is a list of possible values for the reason parameter:

  • FORGOTTEN

  • LOST

  • STOLEN

  • DAMAGED

  • RENEW

  • EXPIRED

  • NONE

NONE is used for an initial issuance or post issuance operation/request. For additional information, see Device Activation. Also, you can refer to the sample code in the testCCM.java file that illustrates how to implement device production/issuance request use cases.

The device must be bound (assigned) to the user. This step is mandatory before the device can be synchronized. A binding is performed between the user's wallet and a security module.

If the device is physically available to the system that is binding the device, both the ATR and CUID can be read from the device using the CCM API. A security module object is always created. Device binding can be performed by:

  • An ActivID CMS Operator Portal

  • An internal or external card or device management kiosk

  • An external badging/printing station

  • An external IDMS

  • An external help desk application

Note: A code sample that illustrates device binding is provided in Binding a Device to a User.

Device synchronization is the process of personalizing the smart card or device. Personalization is the process of loading applets, credentials (such as PKI certificates, keys, and OTP seeds) and data (such as user static information, a user’s photograph, or a user’s biometric information) on to the device.

During device synchronization, the device is physically updated according to the pending actions that have been submitted to ActivID CMS. The resulting device can be:

  • Personalized (ready to be used by a user)

  • Updated if the action was a post-issuance action

  • Unlocked if the pending action was an unlock action, or recycled if the pending action was a recycle action

Device synchronization can be performed at the following locations:

  • Badging station

  • ActivID CMS Operator Portal by the device issuance officer

  • ActivID CMS User Portal by the user

  • External Card or Device Management Kiosk

Device synchronization takes place only after a device production request is submitted to ActivID CMS. For a code sample that illustrates device synchronization, see Synchronizing a Device.

Device activation is the process of changing the device state from produced to the logical state of issued. Device activation can be performed at the following locations:

  • Badging station

  • ActivID CMS Operator Portal

  • ActivID CMS User Portal

Activation is required only if the initial issuance request was “produce”. If the request was “issuance”, then activation is not required. During the activation phase, the contents of the device are not modified. For a code sample that illustrates device activation, see Activating a Device.

The device is protected by a PIN. If the PIN is entered incorrectly too many times, then the device is locked and the user is unable to use the credentials on the device. The CCM API is used to unlock the device and it can be unlocked using any of the following:

  • ActivID CMS Operator Portal,

  • An external badging system,

  • An external badging management kiosk, or

  • ActivID CMS User Portal.

To unlock a device using CCM, perform the following tasks:

  • Create a PIN unlock request using CCM API (a new PIN must be specified in the unlock request).

  • Perform device synchronization.

The smart card must be present during the PIN unlock process. For a code sample that illustrates a device unlock using the CCM API, see Requesting that the PIN be Unlocked.

For information about unlocking the PIN using assisted online unlock on the ActivID CMS User Portal, or unlocking the PIN using self-service unlock on the ActivID CMS User Portal, refer to the ActivID CMS User online documentation.

For information about unlocking the PIN using assisted offline unlock and ActivClient, or unlocking the PIN using face-to-face unlock on the ActivID CMS Operator Portal, refer to Unlocking a Device.

ActivID CMS supports device replacement in the following situations:

  • Temporary replacement (such as when a user forgets the device). In this case, a temporary replacement device is issued when:

  • The help desk operator creates a device replacement request.

  • The issuance operator performs device personalization.

  • The new device is given to the user.

  • Permanent replacement (such as when a card is stolen, lost, expired, or damaged). Technically, damaged is actually the fourth type of replacement (damage replacement). When performing a permanent replacement of the device, you must complete the following tasks:

  • The help desk operator creates a device replacement request.

  • The issuance operator performs device binding.

  • The new device is given to the user.

  • The user enrolls the device using the ActivID CMS User Portal.

The device replacement request can be performed using any of the following:

  • ActivID CMS Operator Portal,

  • ActivID CMS User Portal,

  • A badging station,

  • An external help desk, or

  • IDMS/IDPRS.

Device replacement issuance can be performed via one of the following:

  • ActivID CMS Operator Portal,

  • ActivID CMS User Portal, or

  • A badging station.

Usually, this capability is implemented by an external help desk system. For a code sample that illustrates device replacement using the CCM API, see Requesting a Replacement Device.

The device and all its credentials can be terminated (or revoked). This process is usually triggered when the user is leaving the organization or company. A device might also be terminated when no permanent device replacement mechanism is in place and a device is lost, stolen, or damaged.

Device termination results in the revocation of the security module associated with the user and all the device’s associated credentials. No physical contact with the device is required in order to terminate it. Device recycle can be used to clear a device of its data. However, device recycle is not usually performed in production, especially when user information is printed on the badge. Device termination can be triggered from or performed by any of the following:

  • An IDMS/IDPRS,

  • A badging station,

  • An external help desk, and

  • ActivID CMS Operator Portal (by a Help Desk officer).