Previous | Table of Contents | Next |
Since the PC/SC architecture is a platform-independent design, you might think that it would make sense to implement PC/SC in network computers as well as Windows PCs, rather than to define a wholly different smart card architecture for these computers.
Given that many of the same companies participate in both the PC/SC Workgroup and the Open Card Framework Group, there are hopeful signs that PC/SC and Open Card will be harmonized and that the attractive features of Open Card will be folded into and strengthen PC/SC.
The ICC Specification for Payment Systems, popularly known as EMV96, is produced by three bank card associations: Europay (www.europay.com), MasterCard (www.mastercard.com), and Visa (www.visa.com). (The abbreviation EMV is derived from Europay, MasterCard, and Visa.) It has undergone a number of transformations since it was first published in 1993. The current version, version 3.0, was published June 30, 1996, hence EMV96. The specification is available in its entirety from the Web sites of all three associations.
Initially, the specification was simply intended to describe a closed proprietary system for handling credit and debit smart cards so that vendors could build interoperable and price-competitive hardware that banks and merchants could purchase to implement the system. Electronic commerce burst on the scene and MasterCard and Visa began to develop the SET (Secure Electronic Transactions) specification to handle credit and debit cards on the Internet; the EMV specification is being evolved by its sponsors into a specification for the SET smart card.
The EMV specification comes in three parts, which define
Thus, EMV is more than just an API. It is a specification for smart card transaction processing. It is also unique in that it is the first detailed specification to describe a smart card that contains more than one application; that is, a multiapplication smart card. The applications on which it focuses are payment applications, but it would not be difficult to use the EMV specification as a starting point for the description of how an application should interact with a universal multiapplication smart card. If multiapplication cards are to be widely used, such a protocol will be needed and, to the extent that they want to be the owners of the consumers smart card platform, this may be what the bank card associations have in mind in the long run. Figure 7.3 shows the overall architecture of an EMV smart card.
Figure 7.3. EMV card layout.
A domain is a collection of similar applications. The similarity is based on both the type of data and transaction protocols used by the applications. EMV96, for example, defines the domain of payment system applications. IATA 791, discussed in the section IATA 791/20.204, defines the domain of air travel applications. The directory for each domain has a unique name and a terminal picks a domain by simply resetting the card and selecting the domains directory in the master directory. The EMV payment system directory is 1PAY.SYS.DDF01. The IATA air travel domain directory is FLY.SYS.DDF01.
The general steps in an EMV payment system transaction are as follows:
The application selection and card updating steps are not particular to the payment system domain and could be incorporated in any domain. The risk management and transaction processing steps are definitely specific to EMVs payment system domain. Each application in the EMV payment system domain is a card from an issuer. For example, one application might be a One Bank credit card and another application might be a Second Bank debit card.
Each entry in the payment system directory file, 1PAY.SYS.DDF01, describes one payment system application. In a typical situation in which the cardholder is to be asked to select a method of payment, the host program would read this file and present the cardholder with the list of payment systems that it found on the cardholders EMV smart card. Obviously, if the host application couldnt handle a particular payment system it found on the card, it wouldnt offer it as an alternative.
After an application has been selected, the host application selects the application directory and reads a number of parameters that tailor the risk management and transaction processing steps to the policies and protocols of the particular application. One Bank may require the host to go online to its network computers to authorize all transactions, whereas Second Bank may require the host to go online only for transactions over $10. All the policy and protocol parameters are stored in application files defined by the EMV specification.
The optional card updating step is accomplished by command scripts that are provided to the terminal by the owner of each application. These scripts may be stored in the terminal, or they may be provided to the host during online interaction. For example, suppose a terminal had been instructed by the application parameters on the card to go online to authorize a transaction, and suppose further that the issuers system determined that the card had been reported as stolen. In addition to denying the particular transaction, the issuer would send an update script or procedure to the terminal that would cause its application on the card to be blocked. In this way, the stolen card could not be used for any subsequently attempted offline transactions.
One key shortcoming of the EMV architecture is the lack of a well-defined method for sharing data (except public key certificates) within the payment system domain or across domains. The cardholder may wish to maintain one version of his home address and telephone numbers on the card in order to make updating quick and easy.
Previous | Table of Contents | Next |