Cllient issues for Smart Card Web Servers

Just like any other Web server, a Smart Card Web Server (SCWS) depends greatly on the capabilities of its clients. A presentation by Peter-Paul Koch to Google gives a very good overview of the capabilities of the various mobile browsers.

What you can read in this presentation is quite sad. There have been many discussions about portability issues for MIDP applications over different handsets, and these slides made me realize that the problems are just about the same for people developing mobile Web sites, even for very stupid issues.

Since SCWS primarily targets SIM cards, it means that these portability issues are going to creep in the SIM card. SIM Toolkit developers usually have many tales about the way in which handsets support SIM Toolkit in a variety of strange and unpredictable ways, but it seems that the situation is not getting any better as we move to another application model.

If we move in this presentation, we get to its core proposal, which is to use W3C widgets for mobile applications. And when we get there, the relationship with SCWS becomes completely different.

First, the issue that W3C widgets address concerns the flaky connections available on mobile networks (and in particular the sharing of bandwidth with people connected on the same cell). Naturally, SCWS also addresses the same issue, since a local Web server does not require any bandwidth.

Let’s look at this closer. If the two technologies address the same issues, they may actually be competing technologies. A W3C Widget is a small bundle including an HTML page with some additional content (JavaScript, images, …), and a descriptor. This is definitely something that Java Card 3.0 could do. Of course, the technologies are not equivalent, because Java Card 3.0 also provides the ability to locally generate content dynamically, and store data persistently.

The main competition between these two models is about the place where widgets should be stored. The “natural” place to store widgets is on the mobile, because that is what the people specifying W3C Widgets had in mind (widgets stored on the client). On the other hand, mobile operators may like the ability to push widgets to their users through their Java Card 3 SIM cards.

Enough for competition. One of the requirements from this presentation is the need for JavaScript Device APIs. Such APIs allow a Web application to access some features of the device, like the camera, the contacts, and many other things. Now, that could be interesting for Java Card 3. I can see a few interesting uses for pictures taken during the execution of a Java Card 3 application, or for accessing the contact list (that would actually be funny for the SIM to recover some access to the user’s contacts through this API).

A side effect of these Device APIs is that, since they provide an access to sensitive features, some security measures are required, such as a signature of the widgets or some interaction with the user when these widgets are installed. Then, as we have such signatures, it is tempting to extend the list of potentially sensitive things that become accessible. One of them would be to make mashups between a SIM-based application and outside application easier, by somehow allowing an exception to the “single origin” browser rule (possibly through a specific API).

There remains a number of issues to be addressed regarding widgets, including the security issue, but this approach sure is interesting, and I have the feeling that it is rather a step forward for client-side Web servers such as SCWS, even though it can also be seen as a potential competitor.

No Comments

Leave a Reply

Your email is never shared.Required fields are marked *