Browse Prior Art Database

Protection-preserving Refinement of Privacy Policies Disclosure Number: IPCOM000016199D
Original Publication Date: 2002-Aug-24
Included in the Prior Art Database: 2003-Jun-21

Publishing Venue



Privacy policies define what an enterprise can do with collected data. In particular, privacy rules define which data user can use what type of data to perform which operation for what purpose. E.g., a doctor can read the type medical record for treatment purposes. In addition, they can add precedence (rules with higher-precedence overrule rules with lower precedence), conditions (if the patient is an adult) and obligations (...but the relatives must be notified). The elements data user, data type, operation, and purpose of a privacy policy are structured in a hierarchy. The idea is to define a notion of policy refinement. This solves the following problems: Laws or sector-specific privacy rules can be expressed in a base policy. This base policy can then be refined to suit the needs of particular enterprises. Two enterprises can agree on a common base policy that governs the exchange of policy-protected data. Each enterprise then refines the common policy to suit its own needs. Given a user-friendly coarse-grained privacy policy (like P3P), an enterprise can refine it into a detailed fine-grained privacy policy for internal use. The goal of a policy refinement is that the refined policy cannot violate the base policy. The basic idea of our notion of refinement is to refine the elements of a privacy policy by attaching leaves to the element hierarchy. This results in the following restrictions on the refining policy: A policy can refine any hierarchical element in a definition by sub-classing. This means that a policy can add sub-trees to any element in the definition of the base policy. The elements include data user, data type, operation and purpose. The meaning of the refined terms in the refined policy model is required to be a special case of the meaning of the terms used in the base policy. A refined policy can add rules to the rule-set given by the base-policy. The added rules have lower precedence than the existing ones. A refined policy cannot add new conditions. A refined policy can add new obligations. Given a refined policy following these restrictions, one can return to a given base policy as follows: Each element is replaced by its nearest ancestor that exists in the common base model. For example, when exchanging policy-protected data that has been collected under a refined policy, one has to again abstract from enterprise details by replacing any refined element by its nearest ancestor that exists in the base policy. If, for example, "medical-lab-results" is a refinement of the data type "medical-results", the term "medical-lab-results" will be replaced by "medical-results" before actually sending policy-protected data. The projected rules and condition macros of the refined policy are retained.