P3P Preference manager

Project Manager: Daniel Dardailler <danield@w3.org>
Author of this document: Olle Olsson <olleo@sics.set>

Created: 26 March 2003. Last updated: 29 August 2003.

Table of Content:

• Introduction
• Progress to date
• Deviation

Introduction

Policy management has been investigated in the area of access control. A number of concepts and models have been designed, implemented, and evaluated. Due to the similarity between privacy protection and access control, it can be advantageous to explore how models and approaches from the area of access control can be mapped to the area of privacy protection. This work explores the part that concerns administration of privacy preferences.

This subproject concenrns development of a demonstration system, centered around a preference manager, a piece of software that supports other components involved in accessing servers on the web. The preference manager delivers valid preferences, represented in APPEL. These preferences can then be used by a preference evaluator, evaluating a server privacy policy against current (user) preferences. This preference evaluator may be inside a web browser, in a proxy server, or in some other component accessing web resources.

The main purpose of the preference manager is to provide complete preferences, for specific use, or for general use. By "specific use" we mean the preference appropriate for a single specific access to some specific server. By "general use" we mean a preference that encodes the totality of constraints in a situation, independent of what services will be accessed.

The intent of this subproject is to evaluate principles and mechanisms for administration of preferences. APPEL is an "exchange language", and as such does not concern the question of rationale for a preference; what is the reason for the specific APPEL preference? Administration, on the other hand, is critically dependent on rationale; why are these constraints provided.

Part of the rationale question will be supported by adding a management model to the APPEL approach to preference. This management model will be based on a role hierarchy model. An example of a role hierarchy model is the RBAC model, "Role Based Access Control". RBAC is a "holistic" approach, which does not correspond directly to the Web situation, where there are two different "actor domains" involved; the server domain and the user domain.

So this project is concerned with applying an RBAC-like approach to the user side only. I.e. user privacy preferences are used, these preferences are seen as originating in (constructed from) a preference modelling framework. The concrete preference is computed from more generic statements about privacy.

To leverage on existing work, we will reuse functionality and components from on-going work at SICS, in the area of Policy-Based Reasoning, specifically practical results from the Delegent system.

To simplify evaluation, it is highly likely that a proxy-server approach will be adopted, where preference evaluation will be performed, on request from ordinary web browser.

The main results are:

• A conceptual framework for understanding the management of user privacy preferences, able to generate APPEL preference documents
• Principles of managing privacy preferences in a role-based framework
• Evaluation of adequacy of APPEL to represent RBAC-like policies
• Architectural principles for preference managers (preference servers)

Progress to Date

Technical work has been performed in three streams:

• conceptual design - reinterpretation of role-based access concepts into privacy preferences
• technical design - design of the administration tool
• architectural design - design of the role and relationships between different components in a web environment

See the complete report at http://www.sics.se/w3c/resources/projects/2001/qh/papers/

Deviations from plan

None.