Smart Card web server programming

This post summarizes a presentation of Web Gate project (Dmitry Namiot, Simagine 2009 Innovation Award).

Web gate for SCWS

Introduction

Web gate project presents a bridge for the mobile Internet and Smart Cards Web Server (SCWS). This bridge provides a "standard" (practically defined and implemented) way for the mobile internet developers (web developers) to deploy smart cards based features in the own projects. All in all, Web gate is a development tool targets web developers and provides for them a smooth access to smart cards features.

Project description

The main idea behind this project is how to mix SCWS and mobile Internet. No doubt, that the mobile internet word is much bigger, than the potential SCWS-alone based projects. So the aim of this project is to bring SCWS-based capabilities to the mobile internet developers. Let them deploy smart cards based projects via the familiar (well known) for them web tools.

As per above-declared goals we have to implement at least the following things:

- propose a set of the components (widgets), provided access to the smart cards features
- propose a smooth integration for the selected components into modern web development tools

As a result web developers will get a tool (it is a key point – we are providing project for SCWS, but our target is actually web development crowd), let them access to smart cards features without knowing any technical details about smart card programming. And even more – this access will be tied to the web development exclusively, so there is no need in the new development skills for the web developers at all.

From our understanding the ability to win developers is a key issue for any new computer platform, including smart cards. Such a win can provide a stream of the new applications from the development community and so make the platform successful. And on this way the web development is becoming the mainstream. At the first hand it is so due to its simplicity and the huge army of the developers. So we are expecting here, that adding for web developers some forms of the convenient access to the smart cards data will be more than simply requested feature. This feature will smoothly enhance the existing development tools without adding a new complexity for the developers. It is the main idea behind our Web gate project.

Main features

Web gate offers a set of web controls (widgets) for the mobile web pages. We’ve decided to provide these controls in the form of custom tag. It is a standard approach for the extending markup languages (e.g. HTML), supported nowadays in all the development frameworks (e.g. JSP, ASP, ASP.NET etc.) These tags, being rendered by the application server (servlets container like Tomcat) provides at the end some piece of HTML code. So the initial page could be loaded as usually into browser on the mobile phone.

HTML code, generated by the components contains links to the SCWS. So the user could activate these links and get access to the appropriate servlets on SCWS. And these servlets (also part of Web gate package) provide access to the smart card features (to the features available via smart cards). So for the user this smart card access is just a click away from the original (loaded) page.

There are two types of code chunks created by the Web gate components. The first type is just a "direct" access to card’s features. For example: make a call, send SMS etc. HTML code chunk created by the component is just a "normal" hyperlink pointing to some SCWS servlet, where the relevant attributes (e.g. phone number to call) could be provided as servlet’s parameters

The second type of the components lets developers personalize forms with the data stored on (provided by) the smart card. It is HTML form that should be submitted to some CGI server (as per mobile web page business processes) where some fields could be filled by the data from the smart card. E.g. read some data file from the smart card and use its data within the form or request a cell id and use it as a value for some hidden form’s field etc. So this chunk of HTML code is a form again but instead of the real CGI it could be passed to the SCWS servlet. This servlet will request data from the smart card and return back the initialized form pointed to the real CGI script again. The drawback here is an extra click (submit the form to the localhost). But the positive elements are prevailing in our opinion: high level of customization (substitute data from the smart card), improved usability (no manual typing), safety (do not memorize keys and id’s – they will be extracted from the smart card), high level of the personalization (telecom operators will be able to provide cards with own data for use them in mobile web). And all of this just for the price of one extra click.

High level architecture

Here is what we did (proposed) from the practical point of view. As per life cycle of the typical web application:

1. Web developers prepare a mobile site (page)
2. Web page may include components (controls) pointed to the smart cards. The word "pointed" here describes either the ability request some functionality from the card (via the card) or the ability to get some data, saved on the card and reuse them (data) across the page (within the web application)

3. Page is requested by the web-browser (as usually) from the mobile terminal. As it is stated above the loaded page may include SCWS related stuff. Due to nature of HTML we have the well defined abilities to present the potential actions. It either a hyperlink or a form. So in our case we could present either some hyperlink, pointed to SCWS resource or some form, where the action attribute pointed to SCWS resource (servlet).

4. User may activate SCWS related things (controls) right from the browser. As per the above-mentioned nature of the components it either simply click on the hyperlink or submitting the form.

5. The hyperlinks will be used for the direct actions: place a new call, send a new SMS.

6. The forms will be used for the access to the data, saved on the smart cards. The typical use case is the following. The original mobile web page contains HTML form, where some of the fields should be filled by the data saved on the smart card.

Smart card is a trusted source. So the operator raised the card could save, for example, some own data on the card. It could be for example client’s id (ids), some preferences, marketing related data (sex, age group etc.) And later, when the card owner surfs the Net with the own mobile, the above-mentioned data could be used within the web applications.

What does it mean "used" here? All the existing web applications at the end of the day do absolutely the same things regardless of their business area – perform HTTP requests. E.g. customer fills out some form and submits it to the server. And here the smart cards data goes to the scene. We can add the data from the card to the form. So, technically the target web application will get via HTTP request some parameters, filled (initialized) from the smart card.
How can we do that? We can do it through the followings steps:

- replace action attribute of the original form with our SCWS servlet
- submit the original form to our SWSC application first
- fill the parameters and return back a new page (with the original form again!) where action attribute will be pointed to the its original destination. And some the fields within the returned form could be filled (initialized) by card’s data

So it is an extra click from the user’s point of view (submit form to SCWS servlet first), but for such minimal usability discrimination we can get a huge advantages. This process let us automatically pickup within our form any data right from the smart card. You can see this process as an analogue of form auto-filling, where data comes right from smart card. So it is a practical way for the personalization in the mobile internet.

And by the way, by the same principles we can save some data right on the card for the future usage.

Also we can mark here, that the described approach is similar by the some manner to the well known approach in the web development called ‘url rewriting’. As you can see above, we also "rewrite urls", but do actually a much more than simply session id adding.

Usage scenario

Now let us see how to incorporate our "smart controls" into mobile web pages. In order to make the easy transition to new components for the web developers we are providing the components as custom tags. Tags are familiar for the web development crowd. And all the modern IDE support custom tags.

So in this project we propose components as custom JSP taglibs. They will work "as is" in JSP and/or Coldfusion projects. The similar approach could be moved practically "as is" to ASP.NET world for example.

As we stated above there are two types of components (controls) pointed (referred) to the SCWS:

1. Hyperlinks, actually requested some actions from Smart Cards. The typical use cases are: place a call, send a new SMS.
2. Forms. Actually will be used for the requesting the stored data right from the cards.

For the actions the JSP inclusion looks so (sc here is a prefix, assigned for the taglib):

<!-- make a call -->
<sc:MakeCall phone="1800976"/>

<!-- send a SMS -->

<sc:SendSMS phone="1800976">how are you</sc:SendSMS>

web developers places a links (of course, the attributes could be generated dynamically) and the actual action (place a call, send a SMS) is just an ordinary link activation.

Let us see how the new (smart) forms looks like.

the original form on the web page looks so:

<form action="your_real_action" method="post">
  <input type="hidden" name="id"/>
  Name: <input type="text">
  <input type="submit" value="Submit" />
</form>

our goal is to obtain a value for ID field (hidden field in the form) from user’s smart card. So we offer to the user submit the form to SCWS, our servlet will calculate ID (e.g. read its value from some file, preloaded by the telecom operator) and returns back the same form with the initialized fields. This “smart” form could be presented so:

<!-- submit form to SCWS servlet at the first hand -->

<sc:Form scws="your_scws_servlet" action="your_real_action" method="post">
  <input type="hidden" name="id"/>
  Name: <input type="text">
  <input type="submit" value="Submit"/>
</sc:Form>

this example illustrates the idea with the forms (see above about the components). Code generated by this tag is just a form too, but its action will be described by the attribute scws. So the form could be submitted to our servlet. Servlet will calculate "smart" data and return back the original (here is the trick!) form with the pre-filled data:

<form action="your_real_action" method="post">
  <input type="hidden" name="value_from_smart_card"/>
  Name: <input type="text">
  <input type="submit" value="Submit"/>
</form>

The technical implementation

For the actions (MakeCall, SendSMS) taglib simply generates a link to the appropriate SCWS servlet (the real link to http://127.0.0.1:3516/...)

For the forms taglib creates a form again, changes the action attribute (now it must be our SCWS servlet) and passes the whole original form (tag’s body) as a parameter. Servlet can read this parameter (the original form), replace (substitute) some data within it and return it back.

Conclusion

No doubt, that mobile web area is huge. Smart Card Web Server as per spec is somewhat isolated from the web. The proposed tools fill the gap, combining the best things from the both words: wide adoption of mobile web will meet the high level of personalization. And two tings are especially important here: the personalization comes from the trusted source (smart card) and uses the instruments the web developers are familiar with already.
And what is especially important, that the proposed add-on follows actually to the development model web programmers are already familiar with.

Web gate project suggests the practical approach for the mobile web developers – how to incorporate smart cards features into web projects. The biggest advantage of the suggested method is its smooth (natural) incorporation into the current web development practice. The gate does not introduce a new paradigm for the web developers and leverages their existing skills.
Another big advantage is the openness of the project (the ability to extend it). It is very easy to suggest (add) new components, where new stuff could be added any time without changing the already implemented things.