About 10 years ago, the first major issuers started many pilots and experiments based on Java Card 2.1 technology. Visa was pushing the technology actively, and many others were showing strong interest. Of course, Sun was also very active, pushing its Java technology into a new market that had the potential of putting them in everybody’s wallet.
At the same time, the major card manufacturers had a double agenda: they first needed to keep their current flow of revenue, which was mostly based on proprietary application frameworks, especially in the SIM area. At the same time, they were pushing the Java Card technology; at least, their R&D departments were pushing them, as well as the marketing teams who were trailing their competitors, all too happy to announce a forthcoming revolution that would make their competitors’ products obsolete (but not theirs, of course, since theyr were embracing the new technology).
That was 10 years ago, and we know where it led. Java Card has since become the leading application platform for smart cards, with billions of cards deployed over the years. Today, the industry is looking at another round of innovation, and will they be able to pull the same trick twice?
Let’s continue a bit the analysis of the situation 10 years ago. At that time, SIM Toolkit was an emerging technology. Mobile operators were starting to deploy applications on that framework, and they were already feeling the pain of proprietary platforms. At the same time, actors like Visa were starting to consider multi-application cards, which would allow them to leverage their base of users as a deployment platform for third-party applications, with a large potential revenue.
All these factors really profited the smart card industry, and Java Card came at the right time, with the right model. It had significant competitors, in particular the Multos system. However, this system was considered as locked by a single company, itself controlled by MasterCard. Although the Multos system was far better suited to the cards available at that time, this centralized PKI infrastructure was enough for Java Card and its open model to succeed.
All of this sounds awfully positive, and Java Card could not fail. Well, it also had a number of drawbacks: first, the industry was not used to seeing companies like Sun get in their space, so Java was not necessarily welcome. Then, even more importantly, Java Card suffered severe performance issues. The official hardware requirements for the first platform were 32k ROM and 256 bytes of RAM. Although it was actually possible to fit a Java Card runtime environment in such space, this was definitely not enough. Actual cards used more like 64k ROM andd 1k RAM (double that if you want public key cryptography). At the time, such figures were high-end cards, with a high price. In addition, in order to keep the Java Card promise, one also needed a significant amount of EEPROM, which made them even more expensive.
In addition, the performance of the first Java Card cards was not optimal. The virtual machine added some overhead, and the higher abstraction level made it more difficult to tightly optimize memory consumption. There was just one advantage: the application code was smaller than native code, at least without counting the underlying runtime environment.
So, how is the situation today, with the launch of Java Card 3.0? It is similar in many ways. First, in the SIM market, there is an ongoing revolution. ETSI has voted in favor of a high-speed interface between the SIM card and the handset, based on USB. In the same time, OMA has standardized the Smart Card Web Server (SCWS) technology. However, these techcnologies are either not really available (USB), or not yet widely deployed (SCWS). Nevertheless, the situation is quite similar to what it was 10 years ago. Even though Java Card 2.2 and SCWS are interoperable technologies, programming a servlet without Strings or without dynamic object allocation is at least painful and error-prone, which favors the emergence of another application framework.
Another very important aspect is that Java Card is today’s dominant technology, with over half of the market, and no real competitor. This is of course very positive, but it also has a few drawbacks. First, the technology has been really underused over the years. On the billions of cards deployed, how many
have seen applications downloaded after thier issuance? Or applications from different application providers? Not many, for sure. Java Card has been a success as a vector for interoperability, but multi-application cards have not become a reality. This may mean that, before to move to a new framework, we may need to make good use of the existing one.
Another problematic consequence of lready being the dominant technology is that Java Card now represents two platforms: the Classic platform, which is an evolution of the existing platform, and the Connected platform, which proposes an entirely new model. This brings some confusion on the Java Card brand, which now represents two very different models. In addition, positioning the two models in a way that promotes the new model without undermining the previous one is somewhat difficult.
Another element that may have an influence is the deployment of NFC technology. We all know now that this deployment will take some time, but there are positive signs, and this deployment may have two interesting consequences for the smart card market. First, it will push in favor of really multi-applicative cards. Mobile payment is hard to define, mostly because, for the first time, telcos and banks really need to talk to each other as industries. When appropriate models will be around, multi-application smart cards will be around. Then, these NFC applications will neeed a user interface, and there aren’t that many alternatives. They can use SIM Toolkit, but it is a bit outdated. They can deploy mobile applications, but then they will face numerous problems. Or they can embed their user interface with their applications, using a Web server technology. This solution is not guaranteed to win, but it has significant changes of success. If it does, it would make Java Card Connected Edition a very attractive platform.
Overall, the environment is challenging, but not more than it was 10 years ago. There are a few promising emerging technologies, like SCWS and NFC, which can emerge and succeed with the existing technologies, but will require a more powerful platform in order to really achieve its potential.
The major difference today is that the smart card market has matured in the past 10 years, with significant concentration. 10 years ago, most companies were private companies, or they were parts of much larger companies; in their case, the smart card business was small enoug to enjoy a good level of freedom and independence. Today, we are looking at a more consolidated market, with many
public companies, and including a giant company, which controls more than half of the market. The consequence is that conservative forces, who put a higher priority to next quarter’s revenue than to the development of a potential future market, are more powerful today than 10 years ago. As a consequence, the industry is not including much Java Card 3.0 in their plans, even when they promote SCWS technology.
There are other uncertainties, as well. Oracle now controls Sun, and of course Java Card. What will they do with thie technology? In a more open world, can a new competitor emerge, for instance from the open source community? Once again, we already faced new actors and fierce competition 10 years ago, and Java Card made it quite nicely.
Don’t be afraid!