As the Web becomes increasingly woven in all our activities, the need arises for solutions that can help simplify and structure interactions with ubiquitous services. This is particularly true for mobile users, who often must interact with surrounding services in unfamiliar ubiquitous computing environments. Having discovered the services, they must also determine how to invoke them. Furthermore, these services might be spread across multiple administrative domains; they might have arbitrary semantics and purposes; and communicating with them might require obtaining credentials for an appropriate ISP.

Carefully designed middleware can bring significant value to such chaotic scenarios, presenting convenient abstractions and interfaces to all participants: users, providers of ubiquitous computing services, ISPs, tool and application developers, and administrators. The middleware should assist in discovering and interacting with local services in unfamiliar ubiquitous computing environments, handling authentication and authorization, mediating among participants, and coping with limited a priori relationships among those participants.

We've designed a proxy-based middleware solution that facilitates user interactions in potentially chaotic ubiquitous computing environments. Part of our approach combines service discovery and role-based authentication, and we describe how to implement and present this combination so that users can exploit ubiquitous computing environments.

We assume Web-based interactions in which human users employ standard Web browsers (on various personal devices) to access Web pages and services. Because the users are in unfamiliar locations or situations, we further assume that they participate actively in discovering and exploiting the electronic context, with an awareness that strangers might need to acquire and exploit various local credentials to use local services successfully. This is similar to asking someone for directions, acquiring a room key in a hotel, using a conference badge to gain access to an event, or arranging payment for a service by presenting a credit card.

Therefore, a good design for ubiquitous computing middleware should have several key properties. First, users shouldn't have to preinstall special-purpose code on their devices, and any code downloads during Web browsing should be minimized. Second, the design should require only local implementations, without any large-scale changes to the Internet, and it should be able to exploit colocation of participants as needed. Third, it should support incremental deployment, facilitate the use of existing legacy services, and allow graceful degradation of functionality when necessary. Fourth, it should facilitate offerings by multiple, competing, and perhaps small service providers. Fifth, it should enable the creation of markets in which all participants can realize value or obtain revenue. Finally, and most important, it should be intuitive and nonintrusive for users.

We decompose the problem into four components:

Regarding the first two components, the technical key to enabling access to contextual services is the Web proxy. Such proxies commonly serve to transcode Web content for specific devices or to control access to a network that requires authenticated or paying users. In our case, the proxy, called Continuum, also decorates Web pages with contextual toolboxes so that users can interact with services in the environment. Continuum adds hotspots to Web pages as they pass through. These serve the dual purpose of associating a toolbox visually with certain data in the Web page, and acting as user-interface artifacts on which the user clicks to access the tools. A page can have many hotspots, associating toolboxes with different components, such as an image, a link, or the entire page. The proxy adds the menu and the associated JavaScript to implement it dynamically as part of a process we call publication. The tools are a user-interface notion. We call the software abstraction behind each tool a frame because, like the frame of an exhibit case, it unites several functional elements. For example, frames might provide access to printing on nearby printers; large-screen displays near the user; or storage, bookmarking, and transcoding services. We also provide a software-development framework that facilitates the design and implementation of tools and frames.

Each frame contains an applet in the client browser, requiring JavaScript support, and a servlet running inside Continuum. The applet is responsible for the user interface and communication with the servlet. The servlet mediates access to an external service or provides the service directly to the user. The Continuum runtime environment provides mechanisms for discovering and using either built-in or external services, and for constructing the frame-user interface. Continuum itself interacts with candidate frames to determine which of them to publish. Continuum adds hotspots to Web pages and publishes frames for each of them. We've strived to ensure that the frame applets are portable across several major browsers for mobile devices.

In this article, however, we focus on the latter two components: combining service discovery and role-based authentication. These are crucial, practical aspects of using an unfamiliar ubiquitous computing environment (see the " Related Work " sidebar). We've incorporated these two aspects into our prototype and designed them into our software-development framework.

We use the following example to illustrate our work. Imagine a small hotel in a large building or convention center that wishes to provide a rich ubiquitous computing environment to its guests. A local ISP provides basic wireless connectivity and a proxy. Local services include a printer for hotel guests in the lobby, and perhaps a vending machine and a cash dispenser. An incoming guest must first use the network to establish a Continuum session. The initial presentation of this session comprises a selection of tools relevant in the local context. (The guest might or might not have a business relationship with the specific ISP.) As the session evolves, the set of tools can change as the user browses and acquires more context.

When the guest checks in, the registration clerk and the guest arrange for the browser on the guest's PDA to acquire an electronic credential, or role assertion. The role assertion contains further information about local service directories, and the proxy can use this information to influence tools and contextual information published to the guest as he or she browses. Figure 1 shows a textual representation of a role assertion. In addition to the basic role information, the assertion also gives two service directories, where users can find services that accept the role: a Service Location Protocol (SLP) directory that the hotel maintains, and a Jini directory that a local third party maintains. One of the tools on one of the hotspots (perhaps a general hotspot associated with the entire page) implements a frame for role assertion acquisition.

Once the frame applet has added the role assertion to the browser attribute store, the proxy can detect role assertions in traffic to and from frames and use the role and directory information to publish frames for services that accept the role. In this way, those services have no need to create or maintain a relationship with the guest. When the guest tries to access one of the services, that service need only accept the role granted by the hotel. A service can also apply checks or validations to verify the user's authenticity.

Solving the challenge of service and role discovery with multiple administrative domains involves three key concepts. First, it's necessary to create a particular role assertion and communicate it to an interested user. Second, Continuum and the frames rely on information in the role assertions to discover relevant services. Subsequently, the user relies on the assertions and other attributes to secure access to a service. Now, using the hotel example, we describe how a user acquires the Guest role assertion and uses it in subsequent service invocations.

During an initial login procedure, Continuum responds to any HTTP request by publishing a tool that requests information from the user. In a trivial implementation, a simple HTTP form would be sufficient. A more sophisticated frame applet can obtain some of the requested attributes through introspective JavaScript code. The user's response establishes a session attribute cache. Tool-publication heuristics use the cache to identify relevant tools and services, and to create the user interface—that is, the hotspots and toolboxes added to each page. Attributes available from the client include its IP address and perhaps the user's public key or identity, trusted home node, device location, and device type. We assume the user wishes to disclose the URL of the home node to the proxy so that the home node service can interact with it. Once the session is established, Continuum transmits the result of the original HTTP request to the user. A frame for issuing or acquiring a role assertion appears in Continuum Tools, the global toolbox not associated with specific data on the Web page.

Figure 2 illustrates what the guest and the clerk might see in the current implementation, as they create and exchange the role assertion. The numbers beside each image indicate the sequence in which the two users' actions occur. The upper part of the figure refers to the issuer; the bottom, to the recipient. They both begin by clicking on a hotspot and choosing Continuum Tools; then, in step 1, they choose the Receive or Issue Role tool, respectively. In steps 2 through 5, each participant generates a simple password and communicates it verbally to the other.

Continuum uses the pair of passwords to match the two users' sessions. Then in steps 6 through 8, the Issue Role frame uses the clerk's home node to generate the role assertion (assuming this is too onerous to accomplish on the clerk's PDA). Step 7 confirms the URL of the home with the clerk, obtaining the URL from the attribute pool. Immediately following this, the home node might challenge the guest for credentials. Then, in steps 9 and 10, the guest's home node receives and perhaps stores the assertion, possibly after a request for credentials from the guest. The procedure ends after the guest and the clerk receive confirmations (steps 11 and 12).

Suppose the user wants to print a Web object on the printer in the hotel lobby, and a local copy center owns and operates the printer. Assume that the hotel and the copy center have arranged that hotel guests may use the printer upon successful presentation of the Guest role. Whether the copy center charges the hotel for guest use and whether the charge appears on the guest's bill are separate issues left to the hotel's discretion.

The user chooses a print service by clicking on a hotspot to reveal a menu that includes the print frame, among others published in the toolbox. When the applet communicates with the servlet, it provides attributes such as the hotel Guest role assertion and, with Continuum's help, a reference to the object to be printed. The servlet then interrogates the directories listed in the role assertion to discover relevant printing services. If the servlet finds more than one, the frame offers a choice to the user. The frame servlet requests access to the printing service, which in turn challenges it for attributes—in particular, for an appropriate role assertion. The service might determine that it needs further attributes or validation, such as some assurance that the user indeed possesses the private key corresponding to the role assertion holder's pseudonym. Once authorization occurs, the servlet invokes the service on the data with which the tool was associated. Then, the servlet converts the object to a format, such as PostScript, that the printer accepts. Figure 3 shows part of the interactions of a print frame as it executes. (These snapshots don't reflect the hotel example.)

In general, services can make their own decisions about the validity of attributes. For example, a vending machine might require some indication that a requesting user is physically near before completing a transaction. The indication might involve some automatic location technology or physical interaction with the user. Other services might accept role assertions or other attributes at face value without any interactive verification. Continuum imposes no particular view on how services evaluate or validate attributes.

What does a service provider (SP) such as the hotel need to do to create and sign its own role assertions? It must negotiate role names and their semantics with local SPs and possibly one or more ISPs whose transmission facilities are available inside the hotel (for example, 802.11b wireless or cellular wireless). If the hotel also wants to make services available to holders of its roles, it needs to advertise those services in its own service directory or in some public service directory that, say, the ISP maintains. If the hotel wishes to make some special services available, it might also want to develop custom frames and disseminate the code to ISPs, who, in turn, can publish them for the appropriate clients.

In our design, middleware at the edge of the network (the frames and the Continuum server) assists with discovery and authorization, among other tasks. It helps SPs broker service-discovery operations; it helps users acquire signed assertions, each of which asserts that the holder is acting in a particular role. There are several prerequisites to enabling role assertions as the basis for service discovery, authentication, and authorization:

An SP must ensure that service directories list its services and that signing authorities issue role assertions that bind users to particular roles. The assertions also list service directories that might accept the role. The roles and their implied semantics are a convention of the services accepting them. The signers of the assertions could be the service provider itself or any business partner or select user whose signature is acceptable. (Recall the example of Figure 1 .)

The SP must ensure that the middleware can publish user tools for its services—either directly by providing and disseminating code or indirectly by adhering to standards. As a trivial example, if a printer follows a standard protocol, and a standard service directory advertises this printer, a general printing tool published by the proxy could provide the user interface and manage the interactions with the printer on behalf of the user.

The user acquires a role assertion for the service. The user can acquire this assertion independently through some interaction with a signing authority or through an interaction mediated by tools that the proxy publishes. (This assumes the user's proxy is the same as the signer's proxy, or that the two proxies cooperate.) The signing authority can be a service or another user.

The user finds out about a service because a tool has been published. The tool execution invokes the service, supplying an acceptable role assertion along with other user attributes and parameters such as the data for which the tool was published. The service might consider the role assertion sufficient, or it might try to validate the assertion and attributes. The user's device can acquire attributes in various ways. Continuum can cache them in a user-associated session. Our framework is flexible enough to support various trust relationships and implementation choices.

There are several ways to implement roles and associated service directories. If a particular role or set of roles can access several different services, it might make sense to group them in one or more directories. An individual SP can host a directory for private roles it creates. Alternatively, the SP could rely on some third party to host the directory. If the third party happens to be the user's ISP, the frames for those services might appear automatically for the user. However, this works only if the ISP and the SP are colocated or have a prior business relationship.

SPs can let others (business partners, ISPs, or other SPs) sign role assertions, yet the former still maintains control over authentication and authorization. For an existing service, the SP might want to rely on some challenge-response mechanism with the user to verify the assertion. Or the tool vendor could implement some custom verification with the SP before invoking the service. A third possibility is that the service interface implemented in the tool involves some standard authentication and authorization negotiation with a special-purpose or standard-based service.

Users can acquire and manage role assertions independently of SPs or ISPs. Examples include users exchanging role assertions through email, beaming them between handheld devices, storing them on some medium for future use with a different user device, or keeping them in persistent storage provided by some trusted service such as their PC.

ISPs can provide added value through service aggregation and tools for exchanging role assertions. Because of the multiplicity of communications media available in a chaotic ubiquitous computing scenario, the user's ISP might not be physically close to or actually aware of the user's location. Even so, by querying the service directories listed in role assertions that the user has acquired independently, the proxy can obtain enough context about the user to publish valuable tools. Of course, closer coupling between the proxy and a physical location could provide better functionality to the user, in the form of a more appropriate set of tools to access local services and acquire local roles. In fact, just having the proxy know where certain roles are relevant could yield an improved set of tools. For instance, a role assertion might also indicate a physical area where the role is valid.

We plan to explore attribute validation further—in particular, location validation. We'd also like to prototype peer-to-peer, wireless exchange of role assertions, and assess how well it works over common wireless technologies such as Bluetooth. We plan to investigate the use of direct attribute challenges from services, bypassing the proxy. Another open problem we hope to study is the relation between ISPs and SPs for disseminating information about role semantics.

Bell University Laboratories at the University of Waterloo and the Natural Sciences and Engineering Research Council of Canada supported this research.

O. Andrei Dragoi is a PhD student in the School of Computer Science at the University of Waterloo, Canada. His research interests include mobile and pervasive computing, middleware for ubiquitous computing, and ad hoc service access and interactions. He received his advanced studies diploma in computer science and engineering from University Politehnica of Bucharest, Romania. Contact him at oadragoi@shoshin.uwaterloo.ca.

James P. Black is an associate professor in the School of Computer Science at the University of Waterloo. His research interests include pervasive, mobile, and wireless computing; distributed systems; wireless networks; the behavior of distributed applications and systems; and computer system performance analysis, modeling, and simulation. He received his PhD in computer science from the University of Waterloo. He is a member of the IEEE Computer Society and the ACM. Contact him at jpblack@uwaterloo.ca.