Previous Table of Contents Next


CHAPTER 7
READER-SIDE APPLICATION PROGRAMMING INTERFACES

We discussed some very low-level reader-side application programming interfaces (APIs) to smart cards in our discussion of reader SDKs in Chapter 6, “Smart Card Software Development Tools.” These APIs are primarily concerned with controlling the reader and usually view the card as simply a place to send byte strings to and receive byte strings from; it is up to the application to construct and deconstruct these byte strings. In a sense, this is the wrong way around. What an application program typically cares most about is the functionality of the card and not the card reader, just as it cares about what’s on a floppy disk and not about the control signals for the floppy disk reader.

Until very recently, there were no reader-independent smart card application programming interfaces. This was true for two reasons. First, because the card reader stood between the application program and the card reader, and because card manufacturers couldn’t know which reader their card would be used with, most SDKs were provided by reader manufacturers and not card manufacturers. A reader manufacturer’s primary concern was, understandably, to tell people how to use its reader, not how to use the various cards that might be used with it. Furthermore, unlike cards, card readers and therefore the programming interfaces to them are not standardized. Since readers varied widely in their capabilities, each of these interfaces was unique and tended to highlight those features of the reader that made it different from its competitors. Second, because most smart card systems were closed, consisting of a particular reader used with a particular card, there was no real reason to try to define and gain consensus for a reader-independent interface to smart cards.


Is There a Windows for Smart Cards? Will There Ever Be?:  
For the application programmer, smart cards are like programming languages. There are those dull old standard commands and then there are those exciting new (vendor-specific) language extensions. It is very hard to resist reaching outside the standards perimeter when that vendor goodie on the other side of the line does exactly what you need done and then some. As a result, it is unlikely that smart card manufacturers will be given any marketplace incentive to compete solely on the speed, size, and cost of a standard command set in the near future.

Furthermore, smart cards are just now coming into their own as a viable general-purpose computing platform, and everybody seems to want to be the Microsoft of smart cards—probably including Microsoft. At least for the next four or five years, as smart cards get more memory and more processing power, their operating systems and command sets will sprout ever more differentiating capabilities.

This is not to say that there won’t be pushback from the application building and card issuing communities for standardization. Big customers from the monolithic industries, such as financial services and telecommunications, will use their buying power to force the production of minimum-cost commodity cards. But there will be explosive growth at the edges as new applications for smart cards are discovered and needs for new capabilities are uncovered. As these new capabilities prove generally useful, they will find their way into newer versions of the standard cards.

Will there be a Windows for smart cards? One operating system for all applications provided by a single vendor? Probably not as long as the amount of memory on a smart card stays below a megabyte and candy machines aren’t network devices. While space on a smart card remains at a premium, there will be economic incentives to get as many applications on the card as possible. This will mean constant pressure on the size of the operating system and probably clustering the applications into compatible families. There may be a standard card API for payment applications, a standard card API for gaming applications, and a standard card API for personal data applications, but not a standard Windows-like API for all applications.


As smart cards have come into more general use and smart card readers have become standard equipment on more and more computing platforms, this situation has started to change rapidly. Programmers want to build smart card applications that can be used with many cards and readers, and system builders don’t want to be held captive by a single reader or card supplier. Perhaps the best known and most widely distributed general-purpose smart card interface is the PC/SC API, but there are others. Table 7.1 lists some popular general-purpose—that is, application-independent—reader-side smart card APIs.

Table 7.1. General-purpose reader-side smart card APIs.
Name Primary Vendor URL Email Contact

PC/SC Microsoft www.smartcardsys.com charliec@microsoft.com
MULTOS MAOSCO www.multos.com nick.habgood@multos.com
Open Card Framework IBM www.nc.com/opencard/ kai@zurich.ibm.com


Previous Table of Contents Next