The GEOPRIV Model


The Internet Engineering Task Force (IETF) identified a need for standards guidance in the location services. The IETF formed a working group that was tasked with protecting the privacy of the end user of location services. The Geographic/Location Privacy (or GEOPRIV for short) working group has defined an abstract model for location services that includes a strong emphasis on privacy. This abstract model is defined in Reference 3.

The GEOPRIV model begins where location information has already been determined by the Location Generator. Location determination is out of scope for this model simply because there are far too many different ways to determine location. (see Figure 2.2.)

image from book
Figure 2.2: The GEOPRIV abstract model.

The model then describes how this information is published to a Location Server and retrieved by a Location Recipient, who is the consumer of the location information.

GEOPRIV Roles

The Target is the subject of location information, just as the presentity is the target of presence information. Sometimes the Target is referred to as a Presentity Target. The Target is described in GEOPRIV documents as an abstract construct, which can be either man or machine. In practice the Target is often a person-Alice's location is more interesting than where her computer is-but the Target could equally be used to identify items for applications like fleet management, asset tracking, or networks of sensors.

Although the Target is usually a person, it is often the Device that is used when a location is determined. Most methods for location determination work for devices, not people, but usually the assumption is made that the person and their device are in close proximity. The location of the Target can be determined directly, but this is more of an atypical situation.

The Location Generator determines the location of the Device or Target. The GEOPRIV model doesn't describe how this is done, but thousands of options exist, some of which are described in this book.

The Location Generator sends location information to the Location Server, which is responsible for storing location and giving it to Location Recipients. The Location Recipient is the ultimate user of location information; this covers the whole range of location users, from an application that locates the nearest cinema, to the VPC in an emergency call scenario.

Privacy Roles

The Location Server is responsible for managing how, when, and to whom location information is given. This is the way in which the privacy of the Target is protected in the GEOPRIV model.

The Location Server follows a set of rules called an authorization policy when making decisions about whether or not it should give location information to a particular Location Recipient. The authorization policy applied by the Location Server is created by a Rule Maker. In most situations, the Rule Maker is also the Target-the person who is being located is considered the "owner" of the information, so it is reasonable to expect that they can control how that information is disseminated.

The simplest authorization policy is a list of people who are allowed to view location information, otherwise known as a "buddy list." More complex policies can specify other conditions, special actions that are triggered, and modify the location that a Location Recipient sees. Authorization policies are described in more detail later in this chapter.

Applying the GEOPRIV Model

The GEOPRIV abstract model describes a number of roles, which are only concepts used to facilitate discussion and allow analysis of a range of different configurations. To better understand how this model works, real examples should be studied to see how these roles interact.

A Human Example

The simplest realization of the GEOPRIV model doesn't require network protocols or sophisticated technology. Take the following telephone conversation as an example:

Bob: Hello, Bob speaking.

Alice: Hi, it's Alice.

Bob: Hi Alice, how are you?

Alice: I'm well thanks. Bob, where are you?

Bob: I'm at work.

This example demonstrates how a single entity can assume more than one of the roles in the abstract model. In this conversation, Bob is the subject of the location information ("I'm at work"), therefore he is the Target. Presumably, Bob has also determined the location information and he is providing it, so he is both Location Generator and Server. While Bob may not have made a conscious decision, he has somehow decided that Alice is allowed to receive this information, so he has also assumed the role of Rule Maker. Alice is the Location Recipient; she is the user of the location information. There is no Device in this example because the Location Generator has directly determined the location of the Target.

image from book

A GPS Application

Assume now that Bob has a mobile phone which contains a GPS unit. He uses an application on this phone that first determines his current location then sends this to a web site that displays a map showing the nearest cinema.

image from book

In this example, Bob is still the Target and Rule Maker, but his GPS-enabled mobile phone assumes a number of roles. The phone is the Device and, by virtue of its GPS unit, it is also the Location Generator. The phone sends the location to the cinema web site; therefore, it acts as the Location Server as well.

Fitting the GEOPRIV Model to i2

The i2 architecture described in Chapter 1 is a good example of a real application of location services. Applying the GEOPRIV model to the i2 architecture shows two possible arrangements of the GEOPRIV roles. These two variations are named based on how the Location Recipient first receives location information.

These configurations also apply to non-emergency scenarios and actually form the basis of two basic configurations that can be applied to a large proportion of location services.

Location By-Reference in i2

Location by-reference is named so because the location is not directly provided in the session establishment. Instead of location, a location key or location reference is included. The location key is allocated by the LIS and includes enough information for the VPC to contact the LIS and retrieve location information. In Figure 2.3, the path that the Location URI takes is shown dotted, since this is outside of the GEOPRIV model.

image from book
Figure 2.3: GEOPRIV roles in i2-location by-reference.

The location key is usually represented as a URI, which includes all the information that the Location Recipient needs to retrieve a PIDF-LO. For this reason, a location key is referred to as a Location URI.

Figure 2.3 shows a legislative authority as the Rule Maker-that is, the LIS is required to provide location information to the VPC.

Generalized Location By-Reference

For general location applications, the location by-reference system does not change substantially from the emergency i2 architecture. A range of location applications can use location information, which requires changes to the way that rules are created and managed. For general location usage, the user becomes the Rule Maker. Figure 2.4 also shows a separate Rule Holder; a separate service for rules enables easier management of the rules.

image from book
Figure 2.4: A generalized location by-reference configuration.

This generalized location by-reference configuration fits the presence model very closely. The Location URI is a presentity identifier, and by assigning it the LIS acts as a registrar; the presentity is the user or their phone; the presence information is a PIDF-LO; and the location application is a watcher.

Using the by-reference system has a number of advantages, particularly in mobile situations where location can change continuously. A Location URI gives the Location Recipient control over when location is determined; the location is determined when the Location Recipient requests it, which ensures that it is more current and, therefore, more likely to be accurate. A more detailed discussion of the advantages of this model can be found in Reference 4 at the end of the chapter.

Location By-Value in i2

In the location by-value configuration, location information is provided by-value as part of the session establishment (see Figure 2.5). A PIDF-LO is passed as part of call establishment to the VPC, which is the Location Recipient in this scenario.

image from book
Figure 2.5: GEOPRIV roles in i2-location by-value.

Location by-value is very well suited to fixed Internet access. If location is not expected to change, it can be acquired prior to when it is used. This can provide a significant advantage in applications like emergency services, where time is critical.

A Unified Presence Model for Location

The model described in Figure 2.4 shows how a LIS can provide location information by-reference. Figure 2.6 displays a model that uses location by-reference to combine location information with other elements of presence.

image from book
Figure 2.6: GEOPRIV roles in i2-location by-value.

The labeled interfaces in Figure 2.6 show the different stages involved in providing this presence service:

  1. The configuration interface provides the Target (or Device) with the Location URI. The Target is given this information because the LIS does not have a preexisting relationship with the presence service. As part of the request for a Location URI, the Target includes a simple authorization policy that grants its presence service access to location information. The HELD protocol, described in Chapter 3, provides all the necessary elements for this interface. HELD also provides request primitives that are useful for each of the interfaces in this model.

  2. The Target provides the Location URI to the presence service. This occurs when the Target registers with the presence service and whenever the Location URI changes. The protocol used for this interface depends on the type of presence service. For the purposes of this book, this interface is assumed to be SIP, and the REGISTER and NOTIFY methods provide the Location URI to the presence service.

  3. The presence service subscribes to location information from the LIS. The presence server then acts as a compositor, which combines the location information with other elements of presence to form a unified presence document for the user. Location then becomes part of the presence of the Target.

  4. Watchers for this information subscribe to the presence service for the Target, which now includes location information. They can do this without prior knowledge of the Location URI or the LIS.

Combining location information with other presence information has the advantage of enabling existing presence tools for use with location. When this is enabled, Watchers don't need to be individually given location information or a Location URI, they can use a known presentity to request location information as they see fit. Changes in location information, and even the Location URI, are hidden from the Watcher; the presence service generates notifications as these values change.

Another advantage of this approach is that the LIS now needs to serve requests to a single entity: the presence server. This reduces the complexity of the LIS substantially-it no longer needs to serve large numbers of clients with the associated authentication for each.

This configuration does not preclude a direct request to the LIS. For emergency services, a direct request is still likely, since this reduces complexity and ensures that the emergency network can authenticate the source of the information directly, without the need for digital signatures on the location information.

Providing Subscriptions

The presence service can provide a subscription service to each of the Watchers. However, as described earlier, the continuous nature of location information provides challenges for subscription-based systems. The extra step through the presence service to the LIS complicates this situation.

In order to address this, each Watcher provides a filter document to the presence service. The presence service then acts as a compositor for the filter documents, combining them into a single filter document. At this stage, the presence service can simplify the filter document by removing redundant filter rules. This filter document is then provided to the LIS.

In effect, each Watcher is then subscribing directly to the LIS for location information. The presence service optimizes this interaction by consolidating all the requests into a single subscription and combining the filter rules.



IP Location
IP Location
ISBN: 0072263776
EAN: 2147483647
Year: 2004
Pages: 129

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net