The PNDS is an individual naming server with a similar approach to LDAP embedded into a smartcard . This service must be supplied in any circumstances. The smartcard is an appropriate support to provide such a personal naming server for mobile users, as it contains the personalization part of mobile users' services.
A directory structure like LDAP appears to be a solution to propose different naming spaces to different services. A naming space is defined by a directory entry.
The PNDS has been prototyped on a GemXpresso: the Gemplus' 32-bit RISC JavaCard. This card allows one to easily write a card applet in Java language and to invoke it through a generated Java proxy. The client application invokes Java object methods without being aware of the specific smartcard commands.
The PNDS is made of directory entries in a hierarchical structure. Each entry contains a list of attributes. The design was made with the concern to save memory in the card and to have a better execution speed. Thus, a special attribute is referenced as the entry name, and binding an object to an entry is perfomed by adding an attribute. An attribute consists of a name-value pair. For example, an entry corresponding to a person description could be as it follows.
cn = Durand
gn = Pierre
l = Marseille
pn = +33 4 12 34 56 78
m = firstname.lastname@example.org
Searching an entry in a directory is carried out by a search engine implemented in the smartcard. This search engine provides a list of entries matching attribute criteria.
A request to get, add or modify an entry is allowed only after being authenticated by the user's password.
A common interface for Java objects has been defined by several international companies to unify the access to different types of naming and directory services. This interface is named JNDI [ref 18] (Java Naming and Directory Interface). JNDI supports are available for major naming and directory servers (e.g., X500, LDAP, NIS, COS).
We decided to choose JNDI to realize the PNDS integration into distributed systems because this model proposes a way to federate all naming servers. PNDS appears to be just a new naming and directory server to be integrated within this framework (figure 4).
Figure 4 - PNDS Integration into JNDI
In addition to the PNDS embedded-smartcard server, and like the other naming services, we have developed a JNDI SPI (Service Provider Interface) [ref 19], outside the smartcard, to request the PNDS. A client application invokes JNDI methods to the PNDS like other naming servers without being aware of PNDS smartcard requests.
For example, a client application can call the lookup(), the getAttributes(), or the list() methods, to lookup, retrieve attributes, or list sub-entries of a particulary entry. Also, by calling the createSubcontext() or the modifyAttributes() methods, the client application can create new objects/entries in the graph, or create, modify or remove attributes of an entry.
The DirContext Java class, which has been implemented, converts standard JNDI commands to PNDS requests to a GemXpresso smartcard proxy. Implementation of the InitialContextFactory JNDI interface provides PNDS initial contexts, that is to say the way to access and send requests to the PNDS.
As explained previously, implementing a JNDI interface to the PNDS supplies client applications with a unique interface. However the JNDI API allows the management of referrals. A JNDI referral context references another context. This context may be on the same server or on a different one. This other server may host a different type of naming service (e.g. COS, LDAP, ...).
A PNDS entry is a referral entry when it contains a referral attribute with a reserved name and an address to the referred context. When a request needs to explore an entry bound to a referral entry, the behaviour of PNDS depends on the mode of operation that is currently set  :
The PNDS is not only a naming and directory server, but also an access point to other naming servers. The PNDS contains both personal named objects and links to other named objects managed by other servers outside the smartcard.
[Section 6] [Table of contents]