OpenCard  
 
OCF, the OpenCard Framework is a standard Java framework for working with Smart Cards.  
 

OpenCard Framework Frequently Asked Questions

General Questions

Application Development Questions

Positioning of OCF versus PC/SC :

Positioning of the OpenCard Framework versus JavaCard :

Positioning of the OpenCard Framework versus the Visa Open Platform :

General Questions

Question: What are the OpenCard Consortium and the OpenCard Framework ?

Answer:

The terms 'OpenCard Consortium' and 'OpenCard Framework' are used as follows:

  • OpenCard Framework or OCF
    is the name of an object-oriented software framework for smartcard access

  • OpenCard or OpenCard Consortium
    is the name of the group specifying and driving this software framework

(top)

Question: What are OCF's main architectural aspects ?

Answer: One of the main aspects of OCF's architecture is a clearly structured model that divides the functions provided by the smartcard industry into two major categories:

  • Application and Service Developers:
    Application and service developers build smartcard applications and services comprising the card-resident application component and/or the external card-aware application.

  • Card and Terminal Providers:
    Card providers typically offer families of cards and card operating systems together with software development toolkits for a number of operating system platforms. Terminal providers typically offer families of card terminals with software driver support for a number of operating system platforms.

(top)

Question: What issues are addressed by OCF's specifications ?

Answer: Because the smartcard industry is in a strong transition period towards standardization and interoperability, the market players need to reduce their mutual interdependencies. OCF is an appropriate means of satisfying this objective. In order to do so, the OpenCard Framework specifies two interfaces: First, a high-level application programming interface, that hides the characteristics of a particular provider's components (be it a specific type of smartcard and/or smartcard terminal) from the application and service developers. Secondly, a common provider interface that enables the seamless integration of smartcard building blocks from different vendors.

(top)

Question: Who is OCF's target audience and how does this audience benefit from OCF ?

Answer: The architectural model of OCF makes a distinction between Application & Service Developers on one hand and Card & Terminal Providers on the other.

Thus, compliance with the OpenCard Framework becomes mutually beneficial for both developers and providers. Application and service implementors that write to these interfaces can deploy their solutions in many different settings without having to change a single line of code. Providers adhering to these interfaces make their components directly usable for application and service developers, thus gaining easy access to a rapidly growing market.

(top)

Question:What are the advantages of OCF ?

Answer: The OpenCard Framework offers significant advantages to application and service developers as well as card and terminal providers.

Application and service developers benefit from the OpenCard Framework as follows:

  • Vendor independence -- Developers can choose cards and terminals from different suppliers.
  • Asset protection -- Extensibility of the architecture enables developers to participate in future developments of smartcard technology at low cost by migrating at the level of the API.
  • Improved time-to-market -- Developers profit from shorter development cycles by programming against a high-level API.
  • Lower development cost -- Developers save the extra cost for porting their applications to different platforms and benefit from lower skill requirements to accomplish a given task.

Card and terminal providers benefit from OpenCard Framework in these ways:

  • Increased clientel -- Providers gain access to new market segments reaching many more customers.
  • Improved competition -- Providers can compete in terms of functionality and are less vulnerable to the predominance of a single vendor.
  • Less development effort -- Providers inherit functionality provided by the framework which reduces their development efforts.

(top)

Question:Where can I obtain more information about the OpenCard Framework ?

Answer: The group of companies jointly working on OCF have established an OpenCard web site ( http://www.opencard.org) where you can find OpenCard Framework's documentation, (including General Information Web Document, Programmer's Guide, API documentation, and presentations). And of course you can send an e-mail to opencard-info@opencard.org for any suggestion or question.

(top)

Question:Who are OCF's original founders ?

Answer: The OpenCard Consortium was founded by Bull, Dallas Semiconductors, First Access, Gemplus, International Business Machines Corp., Network Computer Inc., Schlumberger, SCM Microsystems, Sun Microsystems, UbiQ, and Visa International.

(top)

Question: What standards does OCF recognize ?

Answer: OCF recognizes PKCS"11 (Cryptoki), EMV, CEN726, ISO 7816 and PC/SC. While EMV and CEN726 are standards specifying card level characteristics, PKCS#11 is a middle ware standard for application information security. OCF recognizes such PKCS#11 usage via so called CardServices , which is available as a PKCS#11 API, so that applications can easily add hardware tokens into a variety of digital security schemes. We expect that other standards for application specific services (for example a purse) will evolve and will be captured in OpenCard as CardServices. CEN726 and EMV cards can be supported as long as appropriate CardServices are available for a specific card respectively a specific card operating system from a specific vendor. PC/SC is not recognized as prerequisite on platforms where it does not exist (network computers, PDA's, POS, etc.). But whenever it is present, it can be used under OpenCard today, at least the reader part; with regard to the smartcard component, we are continuing to work together with PC/SC towards harmonization.

(top)

Question:What platforms does OCF support ?

Answer: Basically any platform that is capable of running JAVA can exploit OCF right away. OCF is currently available on different platforms. The platforms that were used for development, testing and demos so far are WinNT, Win95, Linux, IBM AIX and several Network Computers. There is work underway from other companies.

(top)

Question:What products currently support OCF ?

Answer: At present, the following products support OCF:

You'll find an up-to-date list of supported devices on the following page: http://www.opencard.org/index-devices.html

(top)

Question:What kind of assistance does the OpenCard Consortium provide ?

Answer: The OCF intends to provide technical support for companies using OCF.

(top)

Application Development Questions

Question: Is a demo available to show OCF's capabilities ? Can the OCF Stock Broker demo downloaded from the web be run without an SC reader or card?

Answer: The Stock Broker demo is part of the OCF Build tree which you could download from the OpenCard download page. To run it, you need an appropriate set of smartcard reader and smart card. Up till now, a "emulation type of a demo" hasn't been available. We think that the real benefit of the demo is to point out the ease of application development and its interoperability; that is, having one single application written and runing it on different platforms and/or using different readers/cards.

(top)

Question: Do any "OCF-compliant" products exist (including even beta versions) ?

Answer: We are pleased to say that OCF-compliant products are under development by a number of companies, and that some of these products are already available today.
You'll find an up-to-date list of supported devices on the following page: http://www.opencard.org/index-devices.html

(top)

Question: Why do I need an Application Manager class capable of handling different applications on one card if I, as a developer, am interested in just one application ?

Answer: The smartcard industry is clearly shifting towards the provision of multiple applications on a single card. Solutions that today may be using a single application only may very well offer additional applications to the end user for enhanced value and customer benefit. Appropriate means must therefore be established for management and separation of applications (be it functional code or application data) residing on a card.

Assume a situation with a purse and a loyalty application residing on one card. Now, one application programmer is concerned about his purse program and another application programmer about her loyalty program. And they both would appreciate it if their own application program could access their own on-card component without fuss and if the other's application program would be prevented from accessing the first application's component. And that is the main purpose of the application manager component.

(top)

Question: Does the application need to identify the type of card before it can acquire the right driver to act as the 'middleman' - how is that achieved?

Answer: The application need not be the one to identify the card. Provided that the card has certain bits set, the application manager component can make that decision and handle remote loading. In OpenCard, we have completed the code responsible for remote loading. What bytes on the card are used for that is still under negotiation.

(top)

Question: Does the CardTerminal need to identify the type of reader ?

Answer: No. We do not envision dynamic downloading for the Card Terminal. A Card Terminal is hardware that you need to install anyway.

(top)

Positioning of OCF versus PS/SC :

Question: How is OCF positioned with respect to PC/SC ?

Answer: The general view on the relationship between the OCF and PC/SC standardization efforts is such that these efforts are considered complementary rather than competing - complementary with respect to the scope of their objectives as well as to the environments in which they will be deployed. In view of the fact that, in a broad sense, they both address the communication of computing devices and smartcards, some overlapping between them seems only natural.

(top)

Question: Can or will PC/SC and OCF co-exist?

Answer: OCF and PC/SC can and will coexist on Wintel platforms. The present implementation of OCF can utilize PC/SC on the Wintel platform (which to our knowledge is currently the only PC/SC platform available).

(top)

Question: Will there be a "winning" spec? Will it go to ISO certification?

Answer: No, there will be no "winner". However, depending on the environment, one or the other technology will be more adequate. OCF essentially was created for the Java programming environment and the world of network computing. We strongly believe that the smartcard industry will profit from a standard way of writing smartcard-enabled Java applications, and OCF is well on its way towards becoming this standard.

With regard to Wintel platforms and developing smartcard applications on those platforms using programming languages other than Java: PC/SC certainly will play an important role there. Finally, as OCF and PC/SC are complementary rather than competing, the question is not so much about winning or losing, but about how to make use of both in a given situation.

Whether OCF will go to ISO certification is unclear at this point in time. Parts of it might, in particular those that will be incorporated in the Java Development Kit core and extensions. Decisions of this kind are planned to be handled by the upcoming formal OCF Consortium.

(top)

Question: Do you feel OCF would be superior to PC/SC? Why?

Answer: Again, they are not competing but complementary, so the notion of superiority is meaningless here - all one can compare is levels of function.

OCF aims at achieving transparency for the application programmer with regard to smartcard operating systems, card terminals, and card issuers. PC/SC primarily addresses transparency with regard to card terminals and to a limited extent to card operating systems, but neglects the role of the card issuer. As multi-application cards will be widely deployed soon, provision of functions to support installation, removal, enumeration, selection of applications on the card and of functions to perform name resolution for data files on the card (mapping user-friendly names to ISO 7816-4 file references) is vital.

OCF addresses all of these issues and provides a solution in the form of a card management component. As a consequence, the application programmer can develop his application based on an abstract file system model for just his application, without having to be concerned about where on the card a card issuer will install his application.

Moreover, OCF architects the basic mechanisms by which the framework adapts to a particular card operating system, card terminal, and card issuer. These mechanisms are flexible enough to allow one to download from the network missing components for a particular card at hand and plug them into the framework. The write-once-run-everywhere feature of Java comes in very handy here. Ideally, an OCF-compliant card can be plugged into any kiosk running the OCF framework anywhere in the world; as long as that kiosk has Internet connectivity, it will always be able to service the applications on the card based solely on information contained on the card.

(top)

Question: Does OCF address the PC-device level solutions of PC/SC? How?

Answer: Whereas PC/SC provides very detailed guidance for the Interface Device Subsystem, OCF specifies a software-only API for CardTerminal components. This rationale allows OCF to work with a wide variety of card terminals including terminals that do not talk to a smart card proper but to contactless devices such as smart tokens or smart accessories. In fact, an OCF CardTerminal can use the IFD subsystem of PC/SC on Wintel platforms.

(top)

Question: Is the CardServiceFactory equivalent to the PC/SC resource manager ?

Answer: The CardServiceFactory is equivalent to only a part of the PC/SC Resource Manager; the general structure of the PC/SC Resource Manager, which is a very complex central element of PC/SC, is quite different from the OCF architecture whose object-oriented design is reflected in a clear split of functions into different components of the framework.

(top)

Question: What should I consider if I have to make a decision ?

Answer: The question of whether one should base a development on PC/SC or OCF will largely depend on the foreseen operating environment for the smartcard-aware application. PC/SC primarily addresses transparency with regard to card terminals and to a limited extent to card operating systems. OCF in addition provides transparency for the application programmer also with regard to the card issuer and the particular card application management scheme. As multi-application cards are increasingly deployed, functions to support installation, removal, enumeration, selection of card applications and functions for name resolution of data files on the card become more and more important.

(top)

Question: When should I consider using PC/SC ?

Answer:If you are targeting non-Java applications for Windows and need only to support a particular card issuer, PC/SC may be an obvious choice due to its wide support.

(top)

Question: When should I use OCF ?

Answer: Besides PCs, many systems ( (e.g. a POS terminal, set-top box, or a smart phone) that use smartcards today do not currently run Windows NT/95 and will, for various reasons (e.g. resource requirements) probably not do so in the future. Smartcard solutions developed for those systems currently only have two choices, they can either be tailored in an inflexible way to a given reader and card or they can be based on the Java platform and make use of OCF.

(top)

Question: Why should I consider OCF even on Windows 95/NT ?

Answer: Even on Windows, for applications written in Java, OCF is preferred because of its higher-level APIs and operating system independence allowing for a later move, say to a UNIX system. OCF solves the problem of supporting different multi-application cards through its ApplicationManagement services. The programmer can develop a smartcard-aware application based on an abstract file system model, without worring about where on the card the issuer will install the application. OCF architects the basic mechanisms by which the framework adapts to a particular card operating system, card reader, and card issuer.

These mechanisms are flexible enough to allow the automatic network download and installation of missing components, which is an important feature for upcoming Java-enabled embedded devices such as set-top boxes, PDAs, and smart phones.

(top)

Positioning of OCF versus JavaCard :

Question: What is the difference between OpenCard Framework and JavaCard ?

Answer: OpenCard Framework is Java in the computer or terminal talking to the smartcard, JavaCard is a special, stripped-down version of Java that runs on the smartcard itself. Java applications running on the PC can use OpenCard to access JavaCard smartcards and standard smartcards. If you want to write Java applets (also known as cardlets) to run on the smartcard itself, you have to use a smartcard which is compliant with the JavaCard standard. One exception to this is MULTOS. MULTOS now offers the ability to write your applications in Java and then cross compile them into MEL prior to loading onto the MULTOS smart card. In this case you are not using a true Java Card according to the Java Card Specifications

(top)

Question: Is there any overlapping between JavaCard and OpenCard ?

Answer: No, there is no overlapping. OpenCard Framework and JavaCard fit together perfectly. OpenCard is the ideal host-side application framework for accessing your JavaCard. As is the case with any other smartcard, to access your Java Card, you need a card service which supports the interfaces of your JavaCard applet.

(top)

Positioning of OCF versus Visa Open Platform :

Question: How is Visa's Open Platform Terminal API related to OCF and PC/SC ?

Answer: To hasten worldwide smartcard acceptance, Visa is currently working on an Open Platform Terminal API. This API enhances software development for smartcard acceptance. This API is not in competition but complementary to similar industry initiatives such as PC/SC and OpenCard Framework. Either one of these initiatives- PC/SC and OpenCard- are focusing on specific target platforms. The Visa Open Platform Terminal API is being developed having a wide range of devices in mind such as PC's, NC's, and EFT/POS, etc. The API and services offered by PC/SC and OpenCard can be utilized by Visa Open Platform Terminal API if available in the environment. The Visa Open Platform Terminal API specification is currently under development. The planned availability is 3Q98.

(top)

Question: Is the Opencard Consortium considering to specify more on the terminal framework?

Answer: Whether or not the OpenCard Consortium should put more emphasis on terminal framework is a topic that needs to be discussed and decided at both the Management Board and Technical Workgroup levels. The Consortium is willing to bring this to subsequent Consortium meetings for discussion.

(top)

Question: Is OpenCard in any way involved or keeping track of the Visa Open Platform work ?

Answer: There is no dedicated effort within the OpenCard Consortium to keep track of Visa's Open Platform work. However, there are OpenCard representatives who are aware of those activities.

(top)

Last update: 07/14/1998