Concepts

This section introduces the concepts of ActivID CMS static data collection plug-ins. The design behind the ActivID CMS static data collection plug-in mechanism enables third-party developers to store third-party application-specific data and/or organization-specific data on devices during issuance.

This application-specific or organization-specific data is stored on the devices using the Federal Information Processing Standard (FIPS) 201 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. (GC) applet. The GC applet treats all data as opaque and it never attempts to assign any meaning to the data with which it is dealing.

You can use a static data Cardholder-related information including things such as health benefits, biometrics, unique organizational identifiers, or unique personal identifiers that rarely change. plug-in to personalize a GC instance with information that is accessible using the PIV Personal Identity Verification (technical standard of "HSPD-12")API In the context of ActivID CMS, an Application Programming Interface (API) is an external interface (for example, the CCM API) that makes it possible for applications not supported by HID Global to incorporate ActivID functionality. or the Government Smart Card—Interoperability Standard (GSC-IS) V2.1 Basic Services Interface (BSI This is a smart card Basic Services Interface (BSI) defined by the U.S. Government as part of the standards in the Government Smart Card-Interoperability Specifications (GSC-IS). For more information, visit: http://smartcard.nist.gov/).

For example, using create PIV or BSI tags at issuance or post-issuance, regardless of the access rights (PIN or Secure Channel) protecting the PIV or GC instance. A sample static data plug-in is provided in the ActivID CMS distribution to demonstrate how to personalize BSI tags.

The device profile An XML file that contains information about all the applets and applet instances that are to be loaded onto the device. that is used during device issuance defines which plug-ins are to be applied to the device. Multiple plug-ins may be specified in a single device profile to enable support for multiple third-party applications on the device.

Multiple plug-ins may also serve to separate a single application between containers with different access controls. By utilizing multiple device profiles, it is possible to enable plug-ins for only a subset of all devices issued.

A plug-in is responsible for generating the data that is to be stored in the GC applet. When the plug-in is called, ActivID CMS passes a set of parameters to the plug-in that can include:

  • Static data directly specified in the device profile

  • Information entered by the user using the ActivID CMS GUI

  • Data retrieved from a directory (for example, the user’s LDAP common name)

  • Data from a generic server plug-in

These parameters may be used directly as the data to be stored in the GC applet or they may be used to load information from files (based on a filename) or from other sources, such as external servers.

Static data plug-in parameters settings can be changed; independent if they are considered visible or not, or designated as modifiable or not. See Developing a Static Data Plug-In for definitions of visible and modifiable. All plug-ins are implemented in Java as a class that is instantiated by ActivID CMS at the time of issuance.

Note: The Static Data Collection plug-in is also responsible for the formatting of information on the device.