7.2 Deriving ICC specifications by issuers

This section begins to discuss some of the card design issues. First, we describe the process of defining the ICC functional requirements and ICC specifications by an issuer. Figure 7.1 illustrates this process.

Figure 7.1: Definition of the issuer ICC specification.

We assume that the issuer is using the services provided by a certain payment system, whose payment network is managed either by a card association or a payment system operator.

In order to facilitate the implementation by issuers of one of his EMV ¢ card application brands, the payment system may first elaborate a set of minimal card requirements derived from the EMV 2000 specifications, taking into account specific business objectives of the payment system. All the issuers that are interested in issuing cards displaying the corresponding brand must observe the minimal card requirements [5]. The payment system may further elaborate a set of proprietary ICC specifications, which customize the general EMV ¢ specifications to the needs of the payment system regarding the card design, within the limits imposed by the minimal card requirements [6]. Note that several ICC profiles can be derived. They answer various levels of security strength and performance for different prices (e.g., a $3 ICC profile). It is important to note that the payment system can directly elaborate the proprietary ICC specifications without establishing a set of minimal card requirements [7].

Taking into account its own business requirements, the issuer defines the ICC functional requirements within the boundaries outlined in the minimal card requirements imposed by the payment system, if any. Considering the ICC functional requirements and the proprietary ICC specification of the payment system, the issuer defines its own issuer ICC specifications, which answer its particular business needs in the framework regulated by the payment system.

Some of the topics the issuer's designer has to address in the definition of the ICC functional requirements are:

Type of ICC architecture;
Type of cryptographic support needed and its impact on the hardware/software platform of the ICC;
Multiapplication support;
ICC file system organization;
ICC functions support;
EMV ¢ application support for cardholder verification, card authentication, issuer authentication, issuer scripts processing, and card risk management.

The issuer ICC specification defines the requirements concerning:

Data elements and files for application selection;
Identification of the card common data objects, which are available for all the applications accommodated in the card;
Identification of the application specific data objects and their organization in AEF(s);
Definition of some application data objects, among which the most important are:
- The content of the PDOL list whenever the ICC implements adaptable transaction profiles, variable AEF organizations, and card risk management depending on the particularities of the business environment at the point of service;
- The AIP and AFL;
- The content of the data object lists used for card risk management, namely CDOL1 and CDOL2;
- The content of the DDOL in case the DDA is chosen as a CAM;
- CVM codes appropriate for an application depending on the services it provides;
- Processing restriction parameters (e.g., application usage control, effective date, expiration date);
- The Issuer Action Code Denial/On-line/Default data objects, which can influence the terminal action analysis based on the status of the TVR.
Definition of the card risk management and the proprietary data objects in connection with it;
Requirements concerning the implementation of the EMV ¢ commands, with an emphasis on the GET PROCESSING OPTIONS, VERIFY, INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE , and GENERATE AC ;
Requirements concerning the commands accepted in post-issuance and their processing by the card: identification of proprietary postissuance commands for data updating, secret keys updating, and the corresponding security mechanisms.