Using the Static Data Collection Plug- In SPI

This section introduces the sixth of the use cases—support for using the Static Data Collection Plug-In SPI A Service Provider Interface (SPI) consists of a set of constant definitions and method declarations without implementations and intended to be called or used in a pre-determined generic manner with a set of outputs that meet pre-determined abstract rules and expectations. for storing additional static data Cardholder-related information including things such as health benefits, biometrics, unique organizational identifiers, or unique personal identifiers that rarely change. on smart cards. Use cases are comprised of subsections that briefly describe and define how some type of ActivID CMS functionality can be integrated into a custom application.

Use Case: Storing Additional Static Data on Devices

Use Case Goal

To extend ActivID CMS functionality by making it possible to collect and format static data at the time of device issuance and store it on a device using the Static Data Collection Plug-In SPI.

Context

Static data can include such cardholder personal information as biometrics, demographic data, health care, or static credentials that may need to be stored on a device at the time of issuance. A static data collection plug-in can be written to fetch and format this information from both external or internal ActivID CMS sources so that it can stored on the smart card by ActivID CMS.

Solution

To create a static data collection plug-in that collects and formats static data at device issuance time and stores it on a device using the ActivID Static Data Collection Plug-In SPI.

ActivID CMS Static Data Collection Plug-In Architecture

The Static Data Collection plug-in can receive user attributes (LDAP) from ActivID CMS or custom user attributes that are managed by a generic/enrollment plug-in An enrollment plug-in is involved every time a user attribute is set or retrieved by ActivID CMS. This makes it possible to map user attributes to repositories other than ActivID CMS’ standard LDAP (for example, such as IDMS, databases, or XML files).. A Static Data Collection plug-in is enabled as an application in a device policy and must be associated with Personal Identity Verification (PIV) or a Generic Container A Generic Container (GC) applet is used to store static data on devices. The applet treats all data as opaque or generic and never attempts to assign any meaning to the data with which it is dealing. (or a PIV applet) in order to store static data on devices.

Examples

A static data collection plug-in could be created that would, at device issuance time, be invoked to fetch credentials (such as CA The Certificate Authority (CA) issues and manages security credentials and public keys for message encryption in a networks environment. certificates) or demographic data (such as a photograph or biometric), and format it so that ActivID CMS can store it in specific containers of the device.

For example, in the case of a PIV (HSPD 12) integration, ActivID CMS is configured using the PIV Toolkit which contains a PIV static data plug- in. The PIV static data plug-in is invoked to retrieve the users' personal identification data.

For More Information

For more information, refer to About the Static Data Collection Plug-In SPI.