Check out the new USENIX Web site.

6 Example of PNDS Application

To demonstrate the PNDS features and capabilities, we have developed a personal address book as an example of an application (figure 5). This PNDS-based application contains two parts.

  1. The first part, the address book itself, supplies mobile users with a set of person information, classified in a hierarchical structure composed of person entries and directory entries. Entries which are private to the user are stored locally on the PNDS smartcard, while shared or public entries are bound to referrals.
  2. The other part provides user profile information dedicated to personalize the address book user interface on the terminal according to user's preferences. (Note that in our example, we did not use any referral or remote attribute in user profiles, but of course this can be possible.)
Image adrbk.gif

Figure 5 - The Personal Address Book

This application is an appropriate PNDS demonstration. It must be available from anywhere whatever the terminal used. As opposed to the address book application code, address book data are personal. This requires features showing the advantages of PNDS and smartcards.

Via the PNDS, the address book application accesses data located on external naming server without being aware of requests to remote servers. Actually, as the address book data are distributed over the network, the PNDS opens the door to a worldwide personal address book.

6.1 PNDS as a Personalized and Private Secure Data Server

The PNDS provides information which enables users to browse their address book over a hierarchical structure of entries, from a directory entry to another. Users can select a person entry (a leaf of the structure), to retrieve its related information. A person entry consists of a set of attributes such as the common name (cn), given name (gn), phone number (pn), e-mail (mail) and photo (jpegphoto).

The PNDS can be viewed as an opened and powerful secure data server, not only as a simple and closed secure data provider such as in a traditional file system. The PNDS is a full naming and directory server.

In addition to the lookup(), the PNDS provides a search() command to find out person(s) into the directory structure according to conditions on attributes. For example: gn=Pierre or pn=+33 4 42*.

Furthermore, the semantics of some entries may be different. For instance, Gemplus corporate directory has not to be stored inside the smartcard because it is provided and supported as part of the Gemplus' information system on the network. Thus in our case, just a referral entry is stored in the PNDS for Gemplus R&D directory entry. When this entry is selected, PNDS provides all necessary information to the JNDI naming manager to transparently forward requests to Gemplus' server (REFERRAL_THROW). If the mode is set to REFERRAL_IGNORE, PNDS provides the Reception Desk entry (pn).

Finally, some attributes of a person entry may be too large with respect to smartcard features. For example, attributes such as pictures or home-pages cannot be stored on the smartcard. However a picture attribute is bound as a remote attribute to the picture provided by a content server on the Internet.

The PNDS smartcard is one part of a personal address book distributed on the Internet. PNDS acts as a federation component.

6.2 User Profile Management

PNDS provides also an appropriate support to personalize an anonymous terminal with user profiles. We have decided to manage two levels of user profiles:

In our example, the general profile is implemented by a directory entry created as a subdirectory of the PNDS root. This entry named UserProfiles (UP) provides information attributes related to the PNDS holder such as his/her common name (cn), given name (gn), and preferred language (lg) (figure 5). All these data describe the user.

We chose to store user profile information related to the address book directly as attributes to the PersonalAddressBook entry (AB). These attributes consist of the information to personalize the address book user interface according to the user's preferences such as foreground color (fgcolor), and background color (bgcolor) (figure 5).

Also, when services themselves are not part of the PNDS smartcard, user service profiles can be specified by creating new UserProfile subdirectory entries (e.g., S1, S2 on figure 5).

6.3 Perspective of this Application

As an extension to our demonstration, we plan to integrate our personal address book in an e-mail manager such as Netscape Communicator which supports access to LDAP directory servers on the Internet. In the latest 4.5 version, this application supports the notion of Roaming Access for roaming users to retrieve user profile information from any place on the network.

At each new connection from an anonymous terminal (e.g. a public network computer), users must manually enter an LDAP server address along with a distinguished name (dn), in order for the application to retrieve their profile and set their preferences accordingly. However, since relatively few users know their distinguished name, and probably fewer can type it correctly, this manual configuration may be tedious and can easily be replaced by just inserting a smartcard into a smartcard reader.

Also, accessing the Internet from anywhere at anytime should allow users not only to retrieve their personal preferences but also to benefit from features and services which are available locally, provided as part of the local network or service provider.

A plugin can allow Netscape Mail to access the address book service from the PNDS, and update the current configuration. Thus, when users insert their card into a terminal, the Netscape mail address book will be personalized from the PNDS.


[Section 7] [Table of contents]