I have recented commented on the fact that parts of the Multos specification have not evolved since August 1997. Java Card was then at its 1.0 version, and in 10 years, has known 3 major releases: 2.0 introduced the new framework, 2.1 made it mature by defining binary-level interoperability, and 2.2 added a few missing things. Java Card is currently dominating the smart card market, with a very large market share. In such a context, why introduce a new version of the framework, and on top of it, a major upgrade of the framework?
The push factor
The first reason, of course, is due to a mix of engineering push (we can do it, so let’s do it), and of commercial push (we can get more money out of it, so let’s do it).
The most obvious push factor, though, is Moore’s law. Smart card chips continuously become more powerful, and they pack more and more ptechnologies. Java Card 2 has been designed for 8-bit processors, and 32-bit processors are becoming quite common today. The amount of RAM available has also significantly increased, with 8k being common, and 16-32k becoming available on high-end cards. Persistent memory has also increased, with hundreds of kilobytes of ROM, and large amount of mutable persistent memory (EEPROM or flash). Another important change is the availability of high-speed I/O interfaces, such as USB (soon coming in a SIM card near you).
As the capacities of smart cards increase, the limits of Java Card 2 become more and more visible, in two different ways. First, some applicatione are not possible, or at least are difficult to develop using the Java Card 2 model. Then, as applications become more complex, the usability issues of Java Card 2 become obvious
This leads us to another push factor. 10 years ago, Java Card has been a great progress over existing development techniques for smart cards. It is well suited for small applications, but it is also quite limited, in ways that could be easily fixed on today’s chips. Encoding strings as byte arrays and performing systematic casts feels uselss and outdated, and the demand for an updated programming model grows from developers (this is a push factor, because Java Card developers rarely work for the end customers, but rather for the card manufacturers of for specialized consultants.
Another push factor, and also the most powerful, is the struggle for value inside the mobile phone. All actors strongly believe that mobile computing represents a major opportunity in the coming years, so everybody wants the biggest possible share of the cake. The smart card industry wants to use its long relationship with telcos (SIM cards have represented telcos on mobile phones for quite a while), combined with its experience in handling sensitive applications, to put value-added services on the SIM card, rather than putting them on the mobile phone. Of course, in order to compete with mobile phones, smart card manufacturers ned to put forward a modern programming model that integrates well in today’s Web-everywhere architecture. Hence, Java Card 3 and its servlet model.
The pull factor
Despite all the good reasons to push a new technology, Java Card 3 would not exist if there weren’t a few reasons to believe that there is a market for the technology, i.e., a pull factor.
The first one comes from the mobile operators, who want to enable richer applications, and believe that at least some of them can fit on their SIM cards. They keep pushing for smart card Web servers, because it allows them to keep a provisioning model that they know well from SIM Toolkit, and because it offers a much improved user interaction.
Another important pull factor is NFC. SIM cards are one of the strongest options for implementing NFC, and at least some of the deployments will happen with SIM cards. NFC is also very interesting for smart cards, because it is likely to lead to the deployment of really multi-applicative platforms, possibly with multiple application providers. Once again, the interaction model offered by Java Card 3 represents a strong opportunity, as it will be very tempting to add an interface to these contactless applications. Java Card and GlobalPlatform are at the heart of all NFC deployments, and Java Card 3 is likely to emerge as a natural evolution when more sophisticated interactions will be required, or when more complex applications will be required.
Another factor is slowly building today, but we expect it to become a major argument. Internet security issues put a positive light on every device that provides a feeling of security. Secure tokens based on Java Card 3 are likely to be such devices, and it should be possible to build good hype on this basis, if we are able to provide a real improvement in terms of security.
As you can guess from the comments above, the key market for Java Card 3, at least as it is perceived today, is the mobile communication market. SIM cards are a strategic asset for operators, they want to add more value to these assets, and smart card manufacturers want to help them (SIM cards represent at least two thirds of their revenues).
The interesting part is that, even though mobile telecom is the targeted market, all other traditional smart card markets are also involved. Mobile payment and mobile banking are two great opportunities, getting a lot of interest these days. This means that the financial sector is also involved. We can say the same thing for mobile ticketing, for mobile V (i.e., mobile DRM), and some government-related applications could also be deployed. With multi-applicatoin SIM cards, it is even possible to think about new smart card applications, even though this does not happen very often, and it is likely that only few applicaionts will succeed.
Another market with interesting potential is IT security. With Java Card 3, a smart card is more likely to be used as a personal secure token, in particular if it is able to provide some protection of personal data. However, the demand on such devices remains unclear today.
We have only mentioned so far emerging or transforming markets. However, today’s Java Card market represents about 2 billion cards per year, and the first priority of the smart card industry is to secure this market for the coming years. This market has a lot of inertia, and innovations take a long time to pick up. Some markets haven’t yet picked up Java Card as mainstream technology; in most cases, these are not ready to move to Java Card 3’s servlet model.
The consequence is here that Java Card 3 must address all smart card markets, from the commodity markets for mass deployments to the high-end markets for early adopters of the Smart Web. We will see in the next post how this has been addressed.