Architectures for Privacy Protection

Once user preferences are understood and codified, the network architectures for enforcing these preferences need to be understood. How privacy is stored and enforced both affect the overall privacy architecture. This section will discuss several architectural permutations and their respective advantages and disadvantages.

Each one of these architectures has the same four logical entities:

• The Rule Maker is the entity responsible for making the rules. Typically, the subject of the location information-the Target-also makes the decisions necessary to create the rules. The Rule Maker codifies the rules, possibly as a common-policy document, and makes them available to the Rule Holder.

• The Rule Holder stores rules. Usually, the Rule Holder provides an interface that allows the Rule Maker to modify the rules over time. The Rule Holder also makes rules available to the Rule Evaluator. In addition, Rule Holder is responsible for ensuring that rules are protected. Rules include information that could reveal private information about an individual; therefore, they are also subject to restrictions that ensure that only authorized entities can retrieve the information.

• The Rule Evaluator checks whether a specific request for location information is permitted. The Rule Evaluator acquires rules from a Rule Holder and evaluates those rules against a set of information about the request. The Rule Evaluator produces an authorization decision.

• The Rule Enforcer takes an authorization decision and either permits or blocks a request for location information. This role is usually assumed by an entity on the request path that can block requests that are not permitted.

A number of options exist to determine where each of these functions is implemented and how each is connected.

Architectural Choices

The architectures discussed so far in this book concentrate on the delivery part of location. Architectural choices relating to the way that privacy rules are communicated, stored, and enforced are critical to providing a general and viable location service.

This section outlines a number of options based on the four roles already identified. It can be seen that these options can coexist, which provides users with a choice about how their location information is used.

Minimal Architecture

The simplest architectural configuration that protects user privacy is shown in Figure 10.3. The LIS in this architecture assumes the responsibility of the Rule Evaluator and Enforcer. The device user, or some legal authority, is assumed to be the Rule Maker. The device is the Rule Holder.

Figure 10.3: The LIS assumes many of the privacy roles in this architecture.

The advantage of this architecture lies in its simplicity. The only protocol interface that needs to carry privacy-related information exists in the access network between the LIS and the device. This simplicity ensures a greater chance of success, both in terms of achieving deployment and in protecting privacy.

Centralized Rule Management

One drawback of the minimal approach is that an individual must maintain a privacy profile for every device that they use in this fashion. Centralized management of a privacy profile gives a user the ability to employ the same profile with each device they use to access the Internet.

The first variation on the minimal architecture moves the role of Rule Holder to a centralized service, as shown in Figure 10.4.

Figure 10.4: To simplify rule management, an external service can host privacy preferences.

Privacy rules can be made accessible to the LIS over secure HTTP. The Device provides a URL to the LIS when it requests a Location URI and establishes a context. The LIS retains the role of Rule Evaluator and Rule Enforcer and, indeed, from the LIS's perspective the device appears to continue in the role of rule holder while, in fact, it is actually just a proxy for the centralized privacy profile manager.

The interface provided to the user to apply updates to the profile can be as simple as an FTP or a web form. In some cases, proprietary tools are provided to assist in the management of rules. There are also protocols designed for the management of rules documents, such as XCAP (see Reference 5), which can be used to more efficiently update rules.

This architecture can be supported concurrently with the minimal architecture in Figure 10.3. The LIS only needs to be able to de-reference a URI to retrieve rules in addition to being able to accept rules directly from the device.

Delegating Rule Evaluation

3GPP defines a node, the Privacy Profile Register (PPR) that not only stores privacy rules, but also evaluates them. This delegation model can also be used by the LIS, as shown in Figure 10.5.

Figure 10.5: The LIS can use a PPR to delegate the evaluation of privacy rules.

The PPR in this scenario requires sufficient information about the context of a request to be able to make a decision. When the LIS sends a request to the PPR, it includes enough context information in that request to allow the PPR to evaluate the rules. This context information includes the identity of the requester and the determined location. This implies that the PPR is authorized to receive location information.

This architecture provides some additional protection to a user's privacy preferences. Because the Rule Evaluator role is delegated, the LIS does not gain access to the user's privacy rules. This additional protection may be desirable if the user does not trust the access network enough to provide this information.

A benefit of this option is that the PPR already exists in the 3GPP architecture, which means that the same node can be used to make decisions for the cellular network and the Internet.

This option can be provided to a user through the use of a PPR URI within the framework already described for HELD. This URI type is not yet defined, but it could be used in place of a ruleset URI to request that the LIS use the PPR. Note that this logical architecture also supports an implementation where the device itself adopts the role of rule evaluator. It can do this by hosting the delegate URI itself. This allows a kind of hybrid implementation where the privacy holder role may be as per either of the first two models.

Privacy with a Presence Service

A presence server can provide the advantages of the centralized service by assuming the roles of Rule Holder and Rule Evaluator. In addition, because it is also in the request path, a presence service can act as a Rule Enforcer. Figure 10.6 shows the simplest arrangement of this architecture.

Figure 10.6: A presence service assumes much of the responsibility for controlling privacy.

This architecture permits the same variations as have already been seen with either an external Rule Holder or PPR. User expectations will likely mean that this separation will only exist for operational reasons, load balancing, and better functional separation rather than the case where a user employs a completely separate privacy service. Without a certain depth of understanding of the issues involved, a user is likely to view privacy as either part of a presence service (as it is today in the cellular domain) or merely as prerequisite for the service. Separate privacy services may not develop but will depend on factors such as legislative regimes which could require the storage of user information with state-approved operatives.

The additional presence information available to a presence service can provide more flexibility in evaluating rules. Some of the rules that were discussed in previous sections rely on information that is not normally available to the LIS.

This architecture moves much of the responsibility for privacy that was present in the LIS to the presence service. On the other hand, this does not preclude the LIS from providing a service directly. The LIS still requires a reduced capacity to process privacy rules-it must be able to authenticate and authorize the presence service.

The presence service option is a special case of those architectures that rely on the LIS directly. In order to use the presence service in this manner, the user must provide rules to the LIS that authorize the presence service. This is an effective means of delegating the privacy roles to the presence service; the presence service now protects privacy before the request reaches the LIS.

Architecture Combinations

A combination of the different configurations is also possible if the privacy rules provided to the LIS include clients other than the presence service. A combination of the two is likely for special cases like i2 emergency, where the Rule Maker role is filled by legislation. Legislation is not always going to affect the presence service, only the LIS is guaranteed to fall within its jurisdiction. Figure 10.7 shows how these different choices can be integrated.

Figure 10.7: The i2 emergency impact on the presence privacy architecture.

Both the LIS and presence service provide some level of rule evaluation and enforcement, depending on the rules that they receive. For emergency services, the LIS receives rules from a Rule Maker other than the user: the emergency services legislation.

Choice of Architecture

The choice of architecture is left to a user of the service, the provider of their device, the operator of the service, or all of these in concert. How the choice is made depends on the requirements of user, and how they use location services. If a user employs a presence service for other purposes, protecting privacy at that point may not require too large an increment to their use of that service. If the user does not already use a presence service, having the LIS protect their privacy could be a better option. Service providers can choose whether or not to provide these options to users.

The Internet service model, unlike the full services model applicable to the cellular domain, means that much more variability will exist in terms of prevailing architectures. Whether this settles down over time still remains to be seen. Currently, users habitually access services in the Internet independently of each other. A streaming video service, an e-mail service, a VoIP service, and a number of instant messaging services may all be subscribed to without any connection existing between them. A number of these services include presence functionality in some form or other. Generally, instant messaging and VoIP services aren't able to direct a message or phone call to a user unless their presence, including network location, is registered with the service.

The advantages of centralized privacy management are clear, but the relatively random service adoption patterns at present militate against the effectiveness of these approaches. To a certain extent, the way that an LIS makes privacy decisions is dependent on how a user chooses to structure their services. A user who opts to use a range of services will consequently need to make a decision about how their policy is communicated to the LIS, potentially making that decision for each service involved.

Related to this is the fact that some users maintain multiple identities-sometimes simply as a consequence of subscribing to multiple presence-type services. This is sometimes a deliberate choice; a user can use this as a way of partitioning aspects of their life. For example, they may have an instant messaging identity for work and another for personal communications. There are also services that users will access directly and independently of any presence function. For example, accessing a free web-based navigation service, which may make periodic location requests, does not imply any prior need for a presence function to exist, nor for the service to know the identity of the user.

The form in which location is provided (by-value versus by-reference), the rules applied (or otherwise) to the acquisition of that location information by applications, and the need to associate any user identity with the location information are very dependent on circumstances. For this reason, and because the population and needs of users come and go arbitrarily within a given public Internet access network, the LIS function associated with those networks will need to be able to support all of the models described. Disparate services are able to concurrently interact with the LIS in different ways, each of which is best suited to that particular application. To support maximum flexibility, the mixture of models used at any given time must be made at the discretion of the user, with regard to any prevailing legal obligations for that operator.