Position Paper: Rule Language Requirements for Privacy-Enabled Identity Management

By Thomas Roessler (W3C), Giles Hogben (JRC), Marco Casassa Mont (HP Labs), Siani Pearson (HP Labs).

The work of the authors is supported by the PRIME project. The project receives research funding from the European Community's Sixth Framework Programme and the Swiss Federal Office for Education and Science.

Introduction

The overall use case that motivates this position paper is a privacy-enabled identity management system using semantic web technologies. By this, we mean a system that uses a set of RDF-based languages to

• exchange instance data - often personal information - between clients and services
• express client-side preferences
• express contextual and assurance requirements
• express service-side policies
• express the agreements reached between clients and services
• express the obligations that arise from these agreements.

In discussing rule use cases and requirements, this position paper focuses on those requirements that are characteristic to the privacy-enabled identity management problem.

Both preferences and policies can be cast in rule-like semantics, as both deal with conditions about what is acceptable, and what is not. In general two categories of rules are of relevance: inference rules and reactive rules.

Specifically, we want to make a case for reactive rules in the context of privacy management. ECA reactive rules (Event-Condition-Action rules) are required to express access control policies, assurance policies and obligation policies. As a significant example we consider privacy obligations. Privacy obligations fit the reactive rule pattern: they define data lifecycle management practices including supported handling policies and under what conditions certain actions have to be taken.

A walk-through

To further illustrate what we mean by a privacy-enabled identity management system, and where rules are useful in such a system, we sketch a walk-through of a negotiation process.

The following diagram represents a typical interaction within a privacy-enabled identity management system. It should be noted that the architecture is in fact symmetric between user and service side, as both have an access control system and both have to establish trust by proving assertions about themselves. However rule requirements are more simply illustrated by taking an asymmetric user-to-service instance of this architecture.

A basic interaction proceeds as follows (following the numbered steps on the diagram); for each step, we have given an implementation example:

1. User requests service (e.g. download Movie X)
2. Service states which assertions must be proved to access the service, and how this data would be treated if submitted. This includes both what obligations would be acceptable (e.g. to delete data after a certain amount of time) and data handling promises such as purposes. (e.g. prove you are over 18, I promise to delete this information after 10 days, but want to keep it for at least 5 days)
3. The User repeats his request with the required proofs (potentially plaintext assertions, cryptographic or zero knowledge proofs) -- if his access control system is satisfied with the server. This decision would typically require the evaluation of the server's promises. It could also involve some realtime evaluation of the server's trustworthiness. (E.g., is the server in a TCPA trusted state?)
4. The server fulfils the request. (Allow access to the movie.)
5. Obligations and promises are enforced in further interactions. Obligations are represented as ECA rules. Sticky policies represent the enforcement of practices promised in the preceding process; they control further access to the data exchanged as part of the negotiation process.

The diagram shows the points in this process where rules are required. Note that several points in the process are symmetric between User and Service, hence the same kinds of rules would be used. This is explained below.

Rules 1

Deciding which credentials need to be requested for which type of service/access request.
(If a user wants to watch an X rated movie, he has to be over 18.)

Rules 2

1. The evaluation of a request for credentials against promised data handling practices and obligations. Note that this is actually the user side version of rules 1 - deciding whether the server's credentials satisfy the user and if not, which further credentials should be requested.
   (Am I happy to prove I'm over 18 if the service is going to publish my birth date on the internet in perpetuity?)
2. A decision on which possible credentials are preferred for satisfying the request, according to the user's preferences
   I can do this with an electronic drivers' licence or by stating my age -- which do I prefer?)

Rules 3

Deciding if credentials or proofs are satisfactory and if system trust properties are fulfilled. This is actually another case of Rules1 except that Rules1 is the intialization special case where no credentials are provided.
(Does the user's electronic driver's licence prove he's over 18?)

Rules 4

Execution of obligations where required.
(E.g., delete the user's data 10 days after he submitted it.)

Use case: Preferences

Motivations:

• Expressing necessary conditions.
• Prioritizing rules.

Constraints

User-side preferences often express constraints: A transaction will not be continued, unlessthe constraints are fulfilled. Fulfilling the constraints, however, is not sufficient for the transaction to proceed. In logical terms, the semantics here are those of necessary conditions, not the ones of sufficient conditions. Such a check can be made on the client side prior to disclosing any personal information or during the negotiation process, and also on the service side after information has been disclosed (through expression of such constraints within access control policies and through the use of sticky preferences, analogous to the enforceable obligations example considered further below).

Examples of user-side preferences that are expressed as constraints include:

• Assurance constraints. Assurance constraints are formulated to obtain degrees of assurance from enterprises that their data will be processed according to their expectations, such as compliance to privacy, security and IT standards.
• Contextual constraints. Contextual constraints are formulated to restrict the cases in which their data will be processed, according to some parameter or parameters that may vary dynamically (such as time, location or platform state).
• Data handling constraints. They are formulated to express their preferences for data handling and retention (such data deletion constraints), notifications, data transformation, etc.

Prioritizing rules

Another typical element of user preferences is to say which out of several possible choices is preferred: A user may, for instance, wish to express that among credentials that prove their age, the least privacy-invasive one is to be picked.

One way of framing this kind of preference is to write a set of rules with well-defined priorities.

Use case: Enforceable obligations

Motivations

• Uniform storage model for instance data and rules
• Using RDF to attach rules to instance data
• Referring to individual triples, or subgraphs
• ECA rules
• Deletion of data from the knowledge base
• Transformation of data in the knowledge base

When a policy negotiation has lead to agreement between different parties on how personal information is to be handled, obligations arise. These obligations specify two kinds of behaviours:

• What actions are to be taken when certain events in relation to the data (or the processing context) occur. These semantics correspond to event-condition-action rules, with almost arbitrary actions. In a privacy context, obligations can most notably include the obligation to delete part of the data. It would be desirable to anticipate this in a rule language's semantics.
• The contextual and data handling constraints mentioned above are turned into obligations when the negotiation process has completed.

In general, obligations can dictate a wide range of actions that need to be fulfilled by organisations on personal data, based on the occurrence of events. Relevant events might be based on: time, accesses to data, changes of contextual information, trust information, etc. Related actions might include:

• Data deletion (e.g. delete data at a due time);
• Data transformation (e.g. obfuscation of data);
• Notification of certain events;

Note that any actions that operate on instance data (such as deletion or transformation), or refer to it (such as notification actions) need a way to address individual triples in the data store.

In order to enable consistent enforcement of obligations, within and across organisational boundaries, instance data and related obligations must be associated together. These associations need to be preserved when data is transmitted i.e. they must be transmitted together.

Important requirements that need to be addressed are:

• Preserving privacy when expressing obligations on personal data: obligations should not disclose personal data or allow for inferences by explicitly referring to these data;
• Dealing with robust associations of obligations to data to avoid that these associations are broken, for example during data transmission or when data is copied or storage locations change;

Simply using today's RDF reification and dropping obligations and instance data into the same graph would, however, break the requirement that obligations and instance data be handled differently according to their respective confidentiality needs.

Hence, besides the pure rule requirements, an additional requirement for future versions of RDF arises: References to individual triples and subgraphs, beyond the abilities of today's reification mechanisms.