IBM Logo

Enterprise Privacy Authorization Language (EPAL 1.2)

IBM Research Report

Latest public version:
http://www.zurich.ibm.com/security/enterprise-privacy/epal
$Id: index.html,v 1.126.2.2 2003/11/14 02:36:20 mts Exp $
Previous versions:
1.126: EPAL Version 1.2
1.83: EPAL Version 1.1
EPAL 1.0 published as IBM Research Report RZ 3485 (#93951), 03/03/2003.
Business Contact:
Steve Adler, IBM Tivoli Software, adler1 at us.ibm.com
Editors:
Calvin Powers, IBM Tivoli Software, cspowers at us.ibm.com
Matthias Schunter, IBM Research, mts at zurich.ibm.com
Authors:
Paul Ashley, IBM Tivoli Software
Satoshi Hada, IBM Research
Günter Karjoth, IBM Research
Calvin Powers, IBM Tivoli Software
Matthias Schunter, IBM Research

Abstract

This is the Enterprise Privacy Authorization Language (EPAL) technical specification. EPAL is a formal language for writing enterprise privacy policies to govern data handling practices in IT systems according to fine-grained positive and negative authorization rights. It concentrates on the core privacy authorization while abstracting data models and user-authentication from all deployment details such as data model or user-authentication.

An EPAL policy defines lists of hierarchies of data-categories, user-categories, and purposes, and sets of (privacy) actions, obligations, and conditions. user-categories are the entities (users/groups) that use collected data (e.g., travel expense department or tax auditor). Data-categories define different categories of collected data that are handled differently from a privacy perspective (e.g., medical-record vs. contact-data). Purposes model the intended service for which data is used (e.g., processing a travel expense reimbursement or auditing purposes).

Actions model how the data is used (e.g., disclose vs. read). Obligations define actions that must be taken by the environment of EPAL (e.g., delete after 30 days or get consent). Conditions are Boolean expressions that evaluate the context (e.g., "the user-category must be an adult" or "the user-category must be the primary care physician of the data-subject").

These elements are then used to formulate privacy authorization rules that allow or deny actions on data-categories by user-categories for certain purposes under certain conditions while mandating certain obligations. In order to allow for general rules and exceptions, EPAL rules are sorted by descending precedence. E.g., a rule about a particular employee can be inserted before the rule about the department in order to implement an exception.

Table of Contents


1. Introduction

The Enterprise Privacy Authorization Language (EPAL) is an interoperability language for exchanging privacy policy in a structured format between applications or enterprises. This document formally describes EPAL, including concepts, syntax, and semantics. To help readers understand the structure and capabilities of the language, it is presented in several forms. First, a brief overview of the language is given in Section 2 in textual form, explaining the major structures of the language and how they fit together. Secondly, the detailed syntax of the language will be specified in Sections 3 and 4 by parts of the EPAL schema along with some examples of EPAL. Thirdly, the semantics of an EPAL policy is described in Section 5. Data-types that are re-used in multiple places are defined in Section 6. The formal definition of the EPAL syntax is given by the XML Schema for EPAL as an appendix.

1.1 Mission Statement

The EPAL Working Group exists to develop a interoperability language for the representation of data handling policies and practices within and between privacy-enabled enterprise tools, which serve to

1.2 Objectives

The goals for the EPAL language are the following.

There are certain situations for which EPAL is not intended as an appropriate language. EPAL was not designed for the following applications:

1.3 Applications

The following applications expose the design considerations raised during the development of EPAL. For EPAL to satisfy the demands of each use case, particular requirements must be inferred. These case-specific requirements and the accompanying assumptions are listed below.

1.3.1 Rule Creation by a Privacy Administrator

A privacy administrator, who has a legal background and no programming experience, creates EPAL rules to model her firm's privacy policy. This EPAL policy serves as input to a variety of privacy management, audit, and enforcement software tools.

Implications on EPAL requirements:

1.3.2 Interoperability of Privacy Software Products

To allow privacy software from different companies to work together, EPAL should be used as a common format to exchange a privacy policy. For example, a privacy creation tool from one company may create an EPAL policy, and a privacy enforcement tool from another company may read-in the EPAL policy and then enforce it.

Implication on EPAL requirements:

1.3.3 Privacy Enforcement

A company has implemented an privacy enforcement system in their software package. The privacy enforcement system must enforce the given set of EPAL rules and the obligations that are defined by the policy.

Implications on EPAL requirements:

1.3.4 A Privacy Audit

An independent auditor uses EPAL to model a client's privacy policy and to perform a privacy audit. The client's goal is to have demonstrated compliance with privacy legislation and recommended industry-specific practices. Two options exist for performing a privacy audit. One method is to generate rulings against the EPAL-modeled privacy policy from run-time requests. These rulings are logged and subsequently analyzed for requests which violated the privacy policy. There is no interference with requests during an audit. An alternative method is completely separate from the client's run-time system. The auditor also models the requests. Compliance with the EPAL-modeled privacy policy is measured against simulated requests.

Implications on EPAL requirements:

1.4 Requirements

Requirements describe the necessary expressiveness of EPAL, enable and/or facilitate deployment, and guide the design of the structure of the language.

1.4.1 Expressiveness Requirements

EPAL must be expressive and flexible to capture evolving privacy legislation and customized privacy policy in a useful, computer-readable format. The following requirements aim to fulfill these goals.

1.4.2 Deployment-Independence Requirements

EPAL is not designed for any specific target environments or existing software privacy tools. Nevertheless, certain requirements must be satisfied to deploy EPAL.

1.4.3 Language Requirements

Since EPAL is intended to be an interoperability language, the syntax must satisfy the following requirements.

1.5 Requirements on the Environment using EPAL

An EPAL privacy policy and an engine that evaluates it is not sufficient for privacy enforcement. To be deployment independent, EPAL defines an abstract authorization interface that outputs a decision and obligations on input of purpose-identifiers, action-identifiers, user-category-identifiers, data-category-identifiers, and context data. Implicitly, these authorization inputs pose a list of requirements on the environment of the EPAL engine

1.6 Relation of EPAL to the W3C Platform for Privacy Preferences (P3P)

EPAL aims at formalizing enterprise-internal privacy policies. This requires a fine-grained vocabulary that formalizes the privacy relevant aspects of an enterprise. It also includes a fine-grained hierarchy of purposes for which the enterprise collects data. The W3C Platform for Privacy Preferences aims at formalizing privacy statements that are published by an enterprise. The goal is to define a machine-readable equivalent for the human readable privacy promises that are published as a "privacy statement" on a web-pages. Unlike EPAL, P3P defines a global terminology that can be used to describe the privacy promises for any enterprise.

1.7 Documentation Conventions and Notation

The normative syntax is given by the XML schema in the appendix. Fragments of this XML Schema are used to define the XML data structures of EPAL inside the specification.

<!-- All schema fragments are shown in a box like this. -->

Examples illustrate the XML data structures of EPAL as XML code.

<!-- All examples are shown in a box like this. -->

In general, a fixed space font is used to represent excerpts of an EPAL file within the text of this document. Angled brackets <> enclose XML elements. Double quotes "" enclose XML types. Single quotes delimit strings.

1.8 Acknowledgements

We would like to thank Malcolm Crompton for valuable input. In addition, we thank the many reviewers within IBM that gave valuable input. In particular we would like to thank Michael Backes, Kathy Bohrer, Marlena Erdos, Michiharu Kudoh, Birgit Pfitzmann, Martin Presler-Marshall, and Michael Waidner.

2 EPAL Overview and Example

This section briefly describes EPAL and its capabilities. An EPAL policy categorizes the data an enterprise holds and the rules which govern the usage of data of each category. Since EPAL is designed to capture privacy policies in many areas of responsibility, the language cannot predefine the elements of a privacy policy. Therefore, EPAL provides a mechanism for defining the elements which are used to build the policy.

An EPAL policy is essentially a list of privacy rules that are ordered with descending precedence (i.e., if a rule applies, subsequent rules are ignored). A rule is a statement that includes a ruling, a user category, an action, a data category, and a purpose. A rule may also contain conditions and obligations. For example, an enterprise may have the following rule in its privacy policy.

Privacy Policy (informal): Allow a sales agent or a sales supervisor to collect a customer's data for order entry if the customer is older than 13 years of age and the customer has been notified of the privacy policy. Delete the data 3 years from now.
EPAL Privacy Rule:
ruling allow
user category sales department
action store
data category customer-record
purpose order-processing
condition the customer is older than 13 years of age
obligation delete the data 3 years from now

Rules are used to determine if a request is allowed or denied. A request contains a user category, an action, a data category, and a purpose. Continuing with the same enterprise as above, consider the following request.

request (informal) A person acting as a sales agent and an employee requests to collect a customer's email for order entry.
user category sales department
action store
data category customer-record
purpose order-processing

The above rule allows the request, so the sales agent would be permitted to store the customer's contact information. Additional rules can then govern how this stored data may be used.

2.1 Example of EPAL in Use

As in introduction to EPAL, let us consider one common scenario that makes use of EPAL.

A company BestShoesRUs sells shoes to consumers:

  1. The shoes are sold through stores throughout North America and Asia (thirty of them),
  2. Through a mail catalog that is mailed out to subscribers,
  3. Via a 1-800 type phone service (24 hours a day), and
  4. Via the Internet (http://www.bestshoesrus.example.com).

BestShoesRUs has always been concerned with its customers privacy. However, as the business has expanded it has found it more difficult to present and enforce a consistent policy across the business. Customers have started to complain that they are getting unwanted marketing material, and some customers have challenged that BestShoesRUs has revealed their private data to third parties.

To facilitate better privacy practices BestShoesRUs has decided to create an enterprise wide policy using EPAL. The goal of the policy is to define a set of common rules for the handling of PII (Personal Identifiable Information) data that is collected from consumers. This way no matter how the data is collected (store, mail, phone, Internet, North America and Asia) that data is treated in a consistent manner.

To begin the process the CPO and her staff need to define an EPAL policy. The CPO obtains legal advice to obtain requirements for the policy based on legislation and industry regulation. The CPO also contracts some consultants specializing in privacy to get some guidelines around industry accepted practices for handing PII data. Using these two inputs, and also tailoring it for the business requirements of BestShoesRUs the CPO and her staff defines the policy. This policy will be the basis for all of the handling of the PII data across the whole business.

Once this policy is defined the IT staff need to ensure it is enforced. There are a number of aspects to this:

The EPAL policy will be expected to change over time because of new regulations, industry practices and business requirements. New versions of the policy will need to be created.

BestShoesRUs will need to acquire software tools for creation of policy, notice, consents and enforcement. These tools may be acquired from different software vendors. The EPAL policy will be used as the medium for exchanging policy across the tools.

2.2 UML Overview on the EPAL Syntax

The following picture shows a non-normative UML (the Unified Modeling Language) overview over the elements of an EPAL policy. Sub-elements are depicted as aggregation by value while references using id/refid pairs are depicted as ordinary relations. The element <epal-vocabulary> and <epal-policy> are the two top-level elements of EPAL.

Figure: Non-normative High-level UML Overview of an EPAL policy
Non-normative UML Overview of an EPAL Policy

2.3 XML Schema of EPAL

EPAL is well-formed XML, conforming to XML 1.0. In addition to well-formedness, EPAL must be validated by the XML Schema for EPAL. The Schema formally defines the EPAL elements. The cardinality, the type, and the (required or optional) use of each element is stated. Any sequencing restrictions of sub-elements are stated. The type, the (required or optional) use, the permitted values, and any default values for each attribute are stated. Some attributes have values which must be unique IDs. An ID must be unique throughout the EPAL policy.

Section 3 and 4 describe the contents of the XML Schema for EPAL. The EPAL namespace URI is "http://www.research.ibm.com/privacy/epal".

Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:

Prefix Namespace URI Notes
epal http://www.research.ibm.com/privacy/epal The EPAL namespace defined in this specification
xs http://www.w3.org/2001/XMLSchema The W3C XML Schema namespace
xsi http://www.w3.org/2001/XMLSchema-instance The W3C XML Schema namespace for instances

3. EPAL Vocabularies

This section describes the syntax of EPAL vocabularies that define the language to express sector-specific privacy policies. Enterprises usually use a single vocabulary. For exchanging policy data with other enterprises, both enterprises can agree on and share a subset of this vocabulary.

3.1 <epal-vocabulary> Top-level Element for an EPAL Vocabulary

Syntax: The <epal-vocabulary> element defines all elements that will later be referenced in rules. The <epal-vocabulary> element contains the following sub-elements in this fixed order:

  1. One <vocabulary-information> element of type "infoType" that describes the vocabulary.
  2. Zero or more <user-category> elements that define the user categories of the vocabulary.
  3. Zero or more <data-category> elements that define the data categories of the vocabulary.
  4. Zero or more <purpose> elements that define the purposes of the vocabulary.
  5. Zero or more <action> elements that define the privacy-relevant actions of the vocabulary.
  6. Zero or more <container> elements that define external context data that can be evaluated by conditions.
  7. Zero or more <obligation> elements that define the obligations that can be returned by the vocabulary.

The required attribute "version" defines the version of EPAL that has been used.

Semantics: The <epal-vocabulary> element lists all terms that must be known by the system interpreting this vocabulary. In addition, it defines what data may be needed for evaluating the conditions contained in this vocabulary.

Design Note: Separating vocabularies from the actual rules serves the following purposes:

  1. It enables to fix a vocabulary (and the corresponding deployment) while allowing flexibility in the rules.
  2. It enables compact rules that only reference the elements in the vocabulary.
  3. It enables verbose definitions that contain additional information such as human-readable explanations.
  4. It enables an authorization engine to verify that it is able to interpret a policy by only looking at the vocabularies.
  5. It enables a separation of the stable parts (vocabularies) from the more volatile and customizable parts (rules).
  6. It enables more flexible policies since an enterprise, a group of cooperating enterprise, or an industry sector can define and use ts terminology. I.e., unlike P3P, the terminology is defined by the actual policy instead of defining it in the spec.
  7. The drawback is that an enterprise can interpret a policy only if it knows its vocabulary.

The disadvantage is that for interoperability, one needs to agree on a common vocabulary in order to be able to exchange policies.

Schema Fragment

<xs:element name="epal-vocabulary">
<xs:complexType>
    <xs:sequence>
        <xs:element name="vocabulary-information" 
           minOccurs="1" maxOccurs="1" type="epal:infoType"></xs:element>
        <xs:element name="user-category" minOccurs="0"  
           maxOccurs="unbounded">... </xs:element>
        <xs:element name="data-category" minOccurs="0" 
           maxOccurs="unbounded" type="epal:hierarchicalType"></xs:element>
        <xs:element name="purpose" type="epal:hierarchicalType" minOccurs="0" 
           maxOccurs="unbounded"></xs:element>
        <xs:element name="action" type="epal:describedObjectType" 
           maxOccurs="unbounded"></xs:element>
        <xs:element name="container" minOccurs="0"  
           maxOccurs="unbounded">...</xs:element>
        <xs:element name="obligation" minOccurs="0"  
           maxOccurs="unbounded">...</xs:element>
    </xs:sequence>
    <xs:attribute name="version" type="xs:string" default="1.2"/>
</xs:complexType>
</xs:element>

Example: Structure of a <epal-vocabulary> element and its sub-elements

<epal-vocabulary version="1.2" xmlns="http://www.research.ibm.com/privacy/epal"
 xmlns:xs="http://www.w3.org/2001/XMLSchema" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.research.ibm.com/privacy/epal epal.xsd
                     http://www.w3.org/2001/XMLSchema xs-dummy.xsd ">
  <vocabulary-information id="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
    <issuer>
      <name>name</name>
      <organization>organization</organization>
      <e-mail>e-mail</e-mail>
      <address>address</address>
      <country>country</country>
    </issuer>
    <location>http://www.ibm.com</location>
    <version-info end-date="2001-12-31T12:00:00"
      last-modified="2001-12-31T12:00:00" 
      revision-number="" start-date="2001-12-31T12:00:00" test="false"/>
  </vocabulary-information>
  <user-category id="NCName" parent="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
    <property id="NCName">
      <value>value</value>
    </property>
  </user-category>
  <data-category id="NCName" parent="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
  </data-category>
  <purpose id="NCName" parent="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
  </purpose>
  <action id="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
  </action>
  <container id="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
    <attribute auditable="true" id="NCName" maxOccurs="1" minOccurs="1" 
      simpleType="http://www.w3.org/2001/XMLSchema#string">
    </attribute>
  </container>
  <obligation id="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
    <parameter id="NCName" maxOccurs="1" minOccurs="1" 
      simpleType="http://www.w3.org/2001/XMLSchema#string">
    </parameter>
  </obligation>
</epal-vocabulary>

3.2 <vocabulary-information>: Information about the Vocabulary

The <vocabulary-information> of type "infoType" contains information about the vocabulary in the form of three sub-elements. The "id" attribute defines the Name that identifies the vocabulary. The <issuer> describes the issuer, the <version-info> the version and other management information. The "id" attribute of vocabulary-information together with the "revision-number" attribute must uniquely identify a vocabulary for each issuer.

Example: Vocabulary Information inside an EPAL vocabulary

<vocabulary-information 
  id="sample-policy">
  <short-description language="en">Example policy information</short-description>
  <long-description language="en">long-description</long-description>
  <!-- Entity issuing the policy -->
  <issuer>
    <name>EPAL Working Group</name>
    <organization>IBM Research</organization>
    <e-mail>testmail@zurich.ibm.com</e-mail>
    <address>Saumerstr. 4, 8838 Ruschlikon</address>
    <country>Switzerland</country>
  </issuer>
  <!-- Policy version. This is so the enterprise
       can track versions of its policy. -->
  <version-info 
    start-date="2002-03-19T00:00:00" 
    test="true" 
    last-modified="2002-03-19T00:00:00" 
    revision-number="1.02A"
    end-date="2004-03-19T00:00:00"/>
</vocabulary-information>

3.3 <user-category>: Definition of the user category Hierarchies

User categories represent a category of individuals that can access data. Examples include single employees, particular roles, employee groups, other enterprises that may receive data, or the data subject itself (i.e., the owner who's data is collected).

Syntax: Each <user-category> element defines a user-category that can be referenced in a rule. The user-category element is of type "hierarchicalType", i.e., it inherits the mandatory attribute "id", the optional attribute "parent", and elements <short-description>, <long-description>, and <property>

Semantics: The list of <user-category> elements defines the entities accessing the data. A <user-category> describes an entity accessing some data and can reference its parent. This includes individuals, groups of individuals, enterprises, organizations, or software agents. user categories are structured in a list of hierarchies. The elements are ordered in hierarchies by a "parent" attribute that contains the value of the "id" of its parent <user-category>.
For all hierarchical elements (user-category, purpose, data-category), the graph that is built by using elements as nodes and drawing edges from child to parent must be one or more trees, i.e., there must not be any cycles. The meaning of the hierarchy is a grouping, i.e., the parent groups all its children. An access to a parent is allowed only if access to all child categories is allowed.

Design Notes:

Schema Fragment

<xs:element 
  name="user-category" 
  minOccurs="0" 
  maxOccurs="unbounded"
  type="epal:hierarchicalType">
</xs:element>

3.4 <data-category>: Definition of the Data Category Hierarchies

The data categories used in privacy policies are often high-level classifications of data, such as customer contact information, medical record, or statistics. These categories are used to distinguish classifications of collected data that need to be treated differently from a privacy point of view. Organizing the data categories into a hierarchy improves the expressiveness of rules. For example, a rule that mentions a high-level data category applies to all parts. This reduces the number of rules in an EPAL policy.

Syntax: Each <data-category> element defines a data-category that can be referenced in a rule. The data-category element is of type "hierarchicalType", i.e., it inherits the mandatory attribute "id", the optional attribute "parent", and elements <short-description>, <long-description>, and <property>.

Semantics: A <data-category> represents some data of a given data classification. The elements are ordered in one or more hierarchies by a "parent" attribute that contains the value of the "id" attribute of its parent <data-category>.
For all hierarchical elements (user-category, purpose, data-category), the graph that is built by using elements as nodes and drawing edges from child to parent must be one or more trees, i.e., there must not be any cycles. The meaning of the hierarchy is a grouping, i.e., the parent groups all its children. An access to a parent is allowed only if access to all child categories is allowed.

Design Notes:

Schema Fragment:

<xs:element 
  name="data-category" 
  minOccurs="0" 
  maxOccurs="unbounded"
  type="epal:hierarchicalType">
</xs:element>

3.5 <purpose>: Definition of the Purpose Hierarchies

Purpose is an important concept in privacy. Information is often disclosed only for particular purposes. Privacy policies must state the purposes for which data is used or is going to be used. The purposes mentioned in privacy policies are often high-level, such as marketing. More specific rules may deal with more specific purposes that fall under the domain of a high-level purpose, such as direct marketing by a third party via e-mail. Organizing the purposes into a hierarchy improves the expressiveness of rules and allows for compact policies.

Syntax: Each <purpose> element defines one purpose that can be referenced in rule definitions. Each <purpose> element is of type "hierarchicalType", i.e., it inherits the mandatory attribute "id", the optional attribute "parent", and elements <short-description>, <long-description>, and <property> .

Semantics: A <purpose> represents the purpose for which a rule authorizes or denies access. The elements are ordered in one or more hierarchy by a "parent" attribute that contains the value of the "id" attribute of its prospective parent.
For all hierarchical elements (user-category, purpose, data-category), the graph that is built by using elements as nodes and drawing edges from child to parent must be one or more trees, i.e., there must not be any cycles. The meaning of the hierarchy is a grouping, i.e., the parent groups all its children. An access to a parent is allowed only if access to all child categories is allowed.

Design Notes:

Schema Fragment

<xs:element 
  name="purpose" 
  type="epal:hierarchicalType" 
  minOccurs="0" 
  maxOccurs="unbounded">
</xs:element>

3.6 <action>: Definition of a Privacy-relevant Action to be Executed on Data

An enterprise performs certain actions on its data resources. A privacy policy specifies which actions are allowed and which are denied under particular circumstances.

Syntax: Each <action> element defines one privacy-relevant action that can be referenced in rule definitions. Each <action> element is of type "describedObjectType", i.e., it inherits the mandatory attribute "id", and elements <short-description>, <long-description>, and<property> .

Semantics: An <action> represents the action that is authorized. <action> elements are not structured in a hierarchy.

Design Notes:

Schema Fragment

<xs:element 
  name="action" 
  type="epal:describedObjectType" 
  minOccurs="0" 
  maxOccurs="unbounded">
</xs:element>

3.7 <container>: Abstract Definition of the Data to be Evaluated by Conditions

Privacy authorization can depend on conditions based upon the context of the request. For example, some data may be used for marketing only if the person is not a minor or a parent has given consent. Each element <container> defines a data structure that contains context data that can be evaluated by conditions. Each container defines a list of context attributes (variables such as 'age', 'name', 'consentToMarketing', 'timeOfDay', ...) that can later be evaluated by conditions. Each <condition> element in EPAL policies then implements a condition that evaluates such context attributes. For efficiency reasons, each condition can specify a subset of the containers that are actually needed to evaluate this condition. Based on the actual instances of the attributes in these containers, the condition then returns 'true' or 'false'.

Syntax: Each <container> element extends the type "describedObjectType", i.e., it inherits the mandatory attribute "id", and elements <short-description>, <long-description>, and <property>. This type is extended by adding a list of one or more <attribute> elements of type "containerAttributeDefinitionType". Each of these elements specifies the syntax of an attribute that is contained in the container by means of attributes "simpleType", "minOccurs", "maxOccurs", and "auditable". The Boolean "auditable" indicates whether this attribute was collected in an auditable way.

Semantics: A <container> element defines the data structure of a container. A container is a set of attributes. An attribute is multi-valued, i.e., an attribute is a bag of values (as specified by the minOccurs and maxOccurs attributes). The values in a bag are not ordered, and some of the values may be duplicates.

Note that container instances are used to evaluate conditions. We require that all the container instances that are needed for condition evaluation are available at the time of authorization, i.e., if a rule is applicable but the container instance needed to evaluate the condition is missing, this is defined to be an error. The EPAL authorization engine requires that each attribute value validates against the attribute specification of the corresponding container.

Design Notes:

Schema Fragment

<xs:element 
  name="container" 
  minOccurs="0" 
  maxOccurs="unbounded">
  <xs:complexType>
    <xs:complexContent>
      <xs:extension 
        base="epal:describedObjectType">
        <xs:sequence 
          minOccurs="1" 
          maxOccurs="1">
          <xs:element 
            name="attribute" 
            type="epal:containerAttributeDefinitionType" 
            minOccurs="1" 
            maxOccurs="unbounded">
          </xs:element><
        /xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <!-- Declared attribute id's must be unique within each container -->
  <xs:unique 
    name="uniqueAttribute">
    <xs:selector 
      xpath="attribute"/>
    <xs:field 
      xpath="@id"/>
  </xs:unique>
</xs:element>

Example: Two Containers

<container 
  id="DataUserInfo">
  <short-description>Information about the user category</short-description>
  <long-description>More Infos.</long-description>
  <attribute 
    id="DataUserID" 
    maxOccurs="1" 
    minOccurs="1" 
    simpleType="http://www.w3.org/2001/XMLSchema#string">
    <short-description>
     The ID of the user category accessing the data.</short-description>
  </attribute>
  <attribute 
    id="WorkingOnStations" 
    maxOccurs="unbounded" 
    minOccurs="1" 
    simpleType="http://www.w3.org/2001/XMLSchema#string">
    <short-description>A multi-valued attribute describing the 
      stations on which the nurse is allowed to work.</short-description>
  </attribute>
</container>

<container 
  id="PatientRecord">
  <short-description>The record of the patient who's data is accessed.</short-description>
  <attribute 
    id="Station" 
    maxOccurs="unbounded" 
    minOccurs="1" 
    simpleType="http://www.w3.org/2001/XMLSchema#string">
    <short-description>A multi-valued attribute describing the 
      stations on which the patient resides.</short-description>
  </attribute>
  <attribute 
    id="PrimaryCarePhysicianID" 
    maxOccurs="unbounded" 
    minOccurs="1" 
    simpleType="http://www.w3.org/2001/XMLSchema#string">
    <short-description>A multi-value input defining the IDs of 
      all primary care physicians of this patient.</short-description>
  </attribute>
</container>

3.8 <obligation>: Definition of an Obligation

Legislation and privacy policies may state that when a certain action is performed, the enterprise is obligated to take some additional steps. An example is that all accesses against a certain type of data for a given purpose must be logged. Or children's data shall be deleted within 30 days unless parent consent is obtained. In EPAL such consequential actions are called obligations. EPAL is not designed to encode the logic of an obligation. The system which evaluates a request against an EPAL policy must be capable of executing all obligations given the unique name of the obligation.

Syntax: Each <obligation> element defines one obligation that can be referenced in rule definitions. <obligation> elements are not structured in a hierarchy. The <obligation> elements extend the type "describedObjectType", i.e., it inherits the mandatory attribute "id", and elements <short-description>, <long-description>, <property> . This type is extended by a list of <parameter> elements of type "attributeDefinitionType" that specify parameter values to be specified inside the rules.

Semantics: An obligation is opaque and is returned after the rule is processed. An obligation inside a rule can contain values for its parameters to be returned together with the obligation identifier. An obligation parameter is multi-valued, i.e., an obligation parameter is a bag of values. The values in a bag are not ordered, and some of the values may be duplicates. These parameter values are of types as specified by the parameter definition. An obligation shall be returned if the rule was applied (i.e., either no condition was attached or the attached condition was satisfied). This holds for "allow" as well as "deny"-rules.

Design Notes:

Schema Fragment

<xs:element 
  name="obligation" 
  minOccurs="0" 
  maxOccurs="unbounded">
  <xs:complexType>
    <xs:complexContent>
      <xs:extension 
        base="epal:describedObjectType">
        <xs:sequence 
          minOccurs="1" 
          maxOccurs="unbounded">
          <xs:element 
            name="parameter" 
            type="epal:attributeDefinitionType" 
            minOccurs="0" 
            maxOccurs="unbounded">
          </xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
  <!-- Declared parameter id's must be unique within each obligation -->
  <xs:unique 
    name="uniqueParam">
    <xs:selector 
      xpath="parameter"/>
    <xs:field 
      xpath="@id"/>
  </xs:unique>
</xs:element>

Example: An Obligation

<obligation 
  id="retention">
  <short-description>A test obligation</short-description>
  <long-description>long-description</long-description>
  <property 
    id="Name">
    <value>property</value>
  </property>
  <parameter 
    id="days" 
    simpleType="http://www.w3.org/2001/XMLSchema#integer" 
    minOccurs="1" 
    maxOccurs="1"/>
</obligation>

4. EPAL Policies

This section describes the syntax of an EPAL policy that defines privacy rules based on a given <epal-vocabulary> . While the <epal-vocabulary> defines the language to express sector-specific privacy policies, the policy defines rules that formalize what is allowed and what is denied.

4.1 <epal-policy>: Top-level Element for an EPAL Privacy Policy

Syntax: The <epal-policy> element defines the actual privacy rules based on a given vocabulary. The <epal-policy> element contains the following sub-elements in this fixed order:

  1. One <policy-information> element of type "infoType" that describes the policy.
  2. One <epal-vocabulary-ref> element of type "importStatementType" that refers to the <epal-vocabulary> to be used.
  3. Zero or more <condition> elements that formalize conditions that evaluate containers of the vocabulary and that can then be attached as pre-conditions to implement instance-based decisions in rules.
  4. Zero or more <rule> elements that define the actual privacy rules of the policy that define the actual authorizations of the policy.

The <epal-policy> element has an optional attribute "global-condition" that defines a global pre-condition for this policy, a required attribute "version" that defines the EPAL version, and a required attribute "default-ruling" that defines the default ruling of this policy. Default-rulings are 'allow', 'deny', or 'not-applicable'.

Semantics: The default ruling specifies the ruling that is literally returned if no rule is applicable. The ruling 'allow' indicates that the action is allowed if none of the rules was applicable, 'deny' indicates that the action is denied, and 'not-applicable' indicates that this policy does not care even though the request used elements that were defined in the vocabulary used. The global condition refers to a condition-ID. If this condition is false, the default ruling is returned.

Design Notes:

Schema Fragment

<xs:element name="epal-policy">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="policy-information" minOccurs="1" 
         maxOccurs="1" type="epal:infoType"></xs:element>
      <xs:element name="epal-vocabulary-ref" minOccurs="1" 
         maxOccurs="1" type="epal:importStatementType"/>
      <xs:element name="condition" minOccurs="0" 
         maxOccurs="unbounded">...</xs:element>
      <xs:element name="rule" minOccurs="0" 
         maxOccurs="unbounded">...</xs:element>
    </xs:sequence>
    <xs:attribute name="version" type="xs:string" default="1.2"/>
    <xs:attribute name="global-condition" type="xs:NCName"
      use="optional"/>
    <xs:attribute name="default-ruling" use="required">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value="allow"/>
          <xs:enumeration value="deny"/>
          <xs:enumeration value="not-applicable"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
  </xs:complexType>
</xs:element>

Example: An <epal-policy>

<epal-policy default-ruling="allow" global-condition="NCName" 
 version="1.2" xmlns="http://www.research.ibm.com/privacy/epal" 
 xmlns:xs="http://www.w3.org/2001/XMLSchema" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://www.research.ibm.com/privacy/epal epal.xsd 
 http://www.w3.org/2001/XMLSchema xs-dummy.xsd ">
  <policy-information id="NCName">
    <short-description language="en">short-description</short-description>
    <long-description language="en">long-description</long-description>
    <property id="NCName">
      <value>value</value>
    </property>
    <issuer>
      <name>name</name>
      <organization>organization</organization>
      <e-mail>e-mail</e-mail>
      <address>address</address>
      <country>country</country>
    </issuer>
    <location>http://www.ibm.com</location>
    <version-info end-date="2001-12-31T12:00:00"
       last-modified="2001-12-31T12:00:00" 
       revision-number="" start-date="2001-12-31T12:00:00" test="false"/>
  </policy-information>
  <epal-vocabulary-ref id="NCName" location="http://www.ibm.com"
     revision-number="NCName"/>
  <condition id="NCName">...</condition>
  <rule id="NCName" ruling="allow">
      <short-description language="en">short-description</short-description>
      <long-description language="en">long-description</long-description>
      <property id="NCName">
        <value>value</value>
      </property>
      <user-category refid="NCName"/>
      <data-category refid="NCName"/>
      <purpose refid="NCName"/>
      <action refid="NCName"/>
      <condition refid="NCName"/>
      <obligation refid="NCName">
        <parameter refid="NCName">
          <value>value</value>
        </parameter>
      </obligation>
  </rule>
</epal-policy>

4.2 <policy-information>: Information about the Policy

The <policy-information> of type "infoType" contains information about the policy in the form of three sub-elements. The "id" attribute defines the id of the policy. The <issuer> describes the issuer, the <version-info> the version and other management information. The "id" attribute of policy-information together with the "revision-number" attribute must uniquely identify a policy for each issuer.

Example: Policy Information inside an EPAL policy

<policy-information 
  id="sample-policy">
  <short-description
    language="en">Example policy information</short-description>
  <long-description language="en">long-description</long-description>
  <!-- Entity issuing the policy -->
  <issuer>
    <name>EPAL Working Group</name>
    <organization>IBM Research</organization>
    <e-mail>testid@zurich.ibm.com</e-mail>
    <address>Saumerstr. 4, 8838 Ruschlikon</address>
    <country>Switzerland</country>
  </issuer>
  <!-- Policy version. This is so the enterprise
       can track versions of its policy. -->
  <version-info 
    start-date="2002-03-19T00:00:00" 
    test="true" 
    last-modified="2002-03-19T00:00:00" 
    revision-number="1.02A"
    end-date="2004-03-19T00:00:00"/>
</policy-information>

4.3 <epal-vocabulary-ref>: Reference to the EPAL Vocabulary to be Used

Syntax: The <epal-vocabulary-ref> element identifies the vocabulary to be used for the rules and conditions of this policy. It inherits the following attributes from "importStatementType".

  1. "location" a mandatory attribute of type "anyURI" that points to the vocabulary file to be used.
  2. "id" an optional attribute of type "NCName" that signals the expected "id" of the imported vocabulary (the name is stored at vocabulary-information/@id).
  3. "revision-number" an optional attribute of type "string" that signals the expected revision number of the imported vocabulary (the revision number is stored at vocabulary-information/version-info/@revision-number).
  4. It can be augmented by elements <long-description>, <short-description>, and <property> as described for the describedObjectType.

Semantics: The <epal-vocabulary-ref> element points to the vocabulary that will be read by an EPAL engine. If the "id" or "revision-number" of the vocabulary at the given "location" are not identical to the ones in the <epal-vocabulary-ref> element, the policy is defined to be invalid and an evaluation always returns 'error'.

4.4 <condition>: Definition of Conditions evaluating Container Attributes

Legislation and privacy policies make statements based on conditions. Rules must enforce these statements while accounting for the associated conditions. It is assumed that a condition can be evaluated to a boolean value.

Syntax: The <condition> element inherits the mandatory attribute "id", and the elements <short-description>, <long-description>, and <property> from the "describedObjectType". It extends this type by adding exactly one additional element <predicate> of type "functionType", which specifies a particular boolean condition. A <predicate> element consists of a sequence of <attribute-value>, <attribute-bag>, <attribute-reference>, <function>, and <predicate> elements.

A <predicate> represents a boolean function, i.e., a function that returns a boolean value. A <function> represents a non-boolean function. Both are elements of type "functionType". The mandatory "refid" attribute specifies the URI of a particular predicate or function. The syntax and semantics of each predicate or function are listed in Appendix 5. The child elements are viewed as a sequence of arguments, i.e., a combination of <predicate>, <function>, <attribute-value>, <attribute-bag>, <attribute-reference>, and <condition-reference> elements represents a sequence of arguments.

An <attribute-value> element represents an attribute value, i.e., an instance of a particular data type. The data type is specified by the mandatory "simpleType" attribute, and the value is specified as the content of the element.

An <attribute-bag> element represents a bag of attribute values. The values in a bag are not ordered, and some of the values may be duplicates. The data type is specified by the mandatory attribute "simpleType", and the values are specified as zero or more <value> elements.

An <attribute-reference> element represents a reference to a particular container attribute. The container attribute is identified by the pair of the mandatory attributes "container-refid" and "attribute-refid".

A <condition-reference> element represents a reference to another condition specified by the mandatory attribute "refid". For each <condition> element, the reference paths that are built recursively by the <condition-reference> elements under it must not have any cycles.

Semantics: Each <condition> represents one condition. Only if all the conditions in a rule are satisfied, the rule can be applied. Otherwise, it is ignored. To evaluate a <condition> given container instances, we need to evaluate the specified <predicate> element.

Both predicates and functions are evaluated in the same way. The only difference is that predicates return a boolean value but functions return a non-boolean value. It is evaluated according to the semantics of the predicate or function specified by the "refid" attribute. The semantics of all the predicates or functions defined in this specification are listed in Appendix 5. They are described assuming the arguments are given as a sequence of <attribute-value> and <attribute-bag> elements. An <attribute-value> represents an attribute value that is an instance of a particular data type, and an <attribute-bag> element represents a bag of attribute values. Both can be viewed as constant values. Therefore, when the arguments of a predicate or a function include <attribute-value> and <attribute-bag> elements only, the evaluation is straightforward.

When the arguments of a predicate or a function include <attribute-reference>, <condition-reference>, <function>, and <predicate> elements, they need to be evaluated to <attribute-bag> or <attribute-value> elements as follows:

Note that the evaluation of a predicate and a function is recursive because they can take predicates and functions as the arguments.

Design Notes:

Schema Fragment

<xs:element 
  name="condition" 
  minOccurs="0" 
  maxOccurs="unbounded">
  <xs:complexType>
    <xs:complexContent>
      <xs:extension 
        base="epal:describedObjectType">
        <xs:sequence>
          <xs:element 
            name="predicate"
            type="epal:functionType"
            minOccurs="1" 
            maxOccurs="1"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:element>

Example: Conditions Evaluating the Example Containers in Section 3.7

For example, assume that we have a container named "DataUserInfo" and a string-type attribute named "DataUserID" (See Section 3.7 for the definition). Then the condition that the "DataUserID" attribute value must be equal to "John Doe" is implemented as follows:

  <condition id="condition1">
        <predicate
      refid="http://www.research.ibm.com/privacy/epal#string-equal">
      <function
        refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
        <attribute-reference
          container-refid="DataUserInfo"
          attribute-refid="DataUserID"/>
      </function>
      <attribute-value
       simpleType="http://www.w3.org/2001/XMLSchema#string">John Doe</attribute-value>
    </predicate>
  </condition>

In this example, the <attribute-reference> element is used to reference the bag of the "DataUserID" attribute value in the "DataUserInfo" container, and then the "string-bag-to-value" function is used to convert the bag into an attribute value so that we can use the "string-equal" function to compare the two string values.

Here is another example, where the condition requires that the "DataUserID" attribute value is equal to one of "John Doe", "John Doe2", and "John Doe3".

  <condition id="condition2">
    <predicate
      refid="http://www.research.ibm.com/privacy/epal#string-is-in">
      <function
        refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
        <attribute-reference
          container-refid="DataUserInfo"
          attribute-refid="DataUserID"/>
      </function>
      <attribute-bag simpleType="http://www.w3.org/2001/XMLSchema#string">
        <value>John Doe</value>
        <value>John Doe2</value>
        <value>John Doe3</value>
      </attribute-bag>
    </predicate>
  </condition>

The following example compares two bags, which are specified by the two <attribute-reference> elements. In this example, the condition requires that at least one attribute value in the "WorkingOnStations" bag is equal to one of the attribute values in the "Station" bag.

<condition id="condition3">
  <short-description>This condition checks whether a nurse (data user)
       is allowed to access patient data.</short-description>
  <long-description>This access is only allowed 
    if the nurse (data user) is working on a station where the 
    patient resides.</long-description>
   <predicate
    refid="http://www.research.ibm.com/privacy/epal#string-at-least-one-value-equal">
    <attribute-reference
       container-refid="DataUserInfo"
       attribute-refid="WorkingOnStations"/>
    <attribute-reference
       container-refid="PatientRecord"
       attribute-refid="Station"/>
  </predicate>
</condition>

The following example uses two <condition-reference> elements to reference the above "condition1" and "condition3" conditions and create a new condition ("condition4"), which requires that both "condition1" and "condition3" are satisfied.

<condition id="condition4">
  <predicate
    refid="http://www.research.ibm.com/privacy/epal#and">
    <condition-reference
      refid="condition1"/>
    <condition-reference
      refid="condition3"/>
  </predicate>
</condition>

The following example uses a <condition-reference> element to reference the above "condition1" condition and create a new condition ("condition5").

<condition id="condition5">
  <predicate
    refid="http://www.research.ibm.com/privacy/epal#and">
    <condition-reference
      refid="condition1"/>
    <predicate
      refid="http://www.research.ibm.com/privacy/epal#string-equal">
      <function
        refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
        <attribute-reference
          container-refid="PatientRecord"
          attribute-refid="Station"/>
      </function>
      <attribute-value
        simpleType="http://www.w3.org/2001/XMLSchema#string">SW4</attribute-value>
    </predicate>
  </predicate>
</condition>

4.5 <rule>: Definition of an Authorization Rule

A rule states that certain user-categories are allowed or denied to perform an action on data of given categories for given purposes if and only if the given conditions are satisfied, and that, consequently, particular obligations must be executed. Rules are ordered by descending precedence, i.e., if a rule applies (allows or denies a request) all subsequent rules are ignored. Each privacy rule is encoded as a <rule> element in EPAL. Rules have two types: An 'allow'-rule allows an action while 'deny-rules define that the action must not be allowed.

Syntax: The <rule> element extends the type "describedObjectType", i.e., it inherits the mandatory attribute "id", and elements <short-description>, <long-description>, <property> . The "describedObjectType" is extended by the required attribute "ruling" with values 'allow', or 'deny' as well as the following sub-elements in this fixed order:

  1. One or more <user-category> elements that define the user categories of the policy. Each <user-category> is of "referringObjectType". Its "refid" attribute must refer to the "id" attribute of a <user-category> in the referenced vocabulary.
  2. One or more <data-category> elements that define the data categories of the policy. Each <data-category> is of "referringObjectType". Its "refid" attribute must refer to the "id" attribute of a <data-category> in the referenced vocabulary.
  3. One or more <purpose> elements that define the purposes of the policy. Each <purpose> is of "referringObjectType". Its "refid" attribute must refer to the "id" attribute of a <purpose> in the referenced vocabulary.
  4. One or more <action> elements that define the privacy-relevant actions of the policy. Each <action> is of "referringObjectType". Its "refid" attribute must refer to the "id" attribute of an <action> in the referenced vocabulary.
  5. Zero or more <condition> elements that identify the pre-conditions for applying this rule. Each <condition> is of "referringObjectType". Its "refid" attribute must refer to the "id" attribute of a <condition> in the referenced vocabulary.
  6. Zero or more <obligation> elements that specify the obligations that are mandated by this rule. Its "refid" attribute must refer to the "id" attribute of an <obligation> defined in the referenced vocabulary. Each obligation can provide parameters by adding a sequence of <parameter> elements if the obligation definition has parameters. These parameters shall be returned as the parameters of the obligation. Each <parameter> element has a required attribute "refid" to refer to the "id" attribute of a <parameter> of the obligation definition, and contains <value> elements with contents of type "epalSimpleType". The number of <value> elements and the contents are required to validate under the corresponding parameter definition.

Design Notes:

Schema Fragment

<xs:element name="rule" minOccurs="0"
  maxOccurs="unbounded">
  <xs:complexType>
    <xs:complexContent>
      <xs:extension base="epal:describedObjectType">
        <xs:sequence>
          <xs:element name="user-category"
            type="epal:referringObjectType"
            minOccurs="1"
            maxOccurs="unbounded"></xs:element>
          <xs:element name="data-category"
            type="epal:referringObjectType"
            minOccurs="1"
            maxOccurs="unbounded"></xs:element>
          <xs:element name="purpose"
            type="epal:referringObjectType"
            minOccurs="0"
            maxOccurs="unbounded"></xs:element>
          <xs:element name="action"
            type="epal:referringObjectType"
            minOccurs="1"
            maxOccurs="unbounded"></xs:element>
          <xs:element name="condition"
            type="epal:referringObjectType"
            minOccurs="0"
            maxOccurs="unbounded"></xs:element>
          <xs:element name="obligation" minOccurs="0"
            maxOccurs="unbounded">
            <xs:complexType>
              <xs:complexContent>
                <xs:extension
                  base="epal:referringObjectType">
                  <xs:sequence minOccurs="0"
                    maxOccurs="1">
                    <xs:element name="parameter"
                      minOccurs="0"
                      maxOccurs="unbounded">
                      <xs:complexType>
                        <xs:sequence>
                          <xs:element name="value"
                            type="epal:epalSimpleType"
                            minOccurs="0"
                            maxOccurs="unbounded"/>
                        </xs:sequence>
                        <xs:attribute name="refid"
                          use="required"
                          type="xs:NCName"></xs:attribute>
                      </xs:complexType>
                    </xs:element>
                  </xs:sequence>
                </xs:extension>
              </xs:complexContent>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
        <xs:attribute name="ruling">
          <xs:simpleType>
            <xs:restriction base="xs:string">
              <xs:enumeration value="allow"/>
              <xs:enumeration value="deny"/>
            </xs:restriction>
          </xs:simpleType>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>
</xs:element>

5. Privacy Authorization - Semantics of an EPAL Policy

We now describe the precise meaning of an EPAL policy. This is done by a semantics. The goal is to define for any EPAL policy and any elements (data-category, user-category, action, purpose) whether the given user-category is allowed to perform the given action for the given purpose on the given data category. In order to evaluate the conditions, this requires the container attribute data to be input. In addition to a plain answer 'allow' or 'deny', the algorithm may output obligations.

If all elements in the request are leafs of the hierarchy (e.g., a single purpose), the intuition is straightforward: If the algorithm outputs 'allow', the given user-category is allowed to perform the given action for the given purpose on the given data category. If non-leaf elements are used in the query, the semantics is based on a grouping (logical and). A access request on non-leaf elements is allowed only if access for these elements as well as their children are allowed. E.g., a user-category 'department' can only use data if all its sub-user-category (e.g., sales department and human resources department) can use the data. Similarity, a purpose 'marketing' is only allowed if all its sub-purposes are allowed. The rationale is to, e.g., allow access to a complete record if and only if all parts of this record can be accessed.

Note that we do not mandate any particular implementation or interface to the algorithm. We give an example interface that uses XML inputs and outputs as an appendix.

5.1 Simple Requests

5.1.1 Required Inputs

A simple authorization request contains

The tuple (U, T, P, A) is called the authorization-quadruple. The intuition behind a request is "Is the given user-category (and all its children) allowed to perform the given action on the given data-category (and all its children) for the given purpose (and all its children). If yes, what obligations apply?". A consequence of this intuition is that a request to access, e.g., an action on a data-category 'customer record' is only allowed if it is allowed on all its parts.

5.1.2 Desired Outputs

The algorithm outputs

5.1.3 Operational Semantics

The algorithm determines the ruling by processing each rule with descending precedence. Before starting, it checks that the global-condition is satisfied. If not, the default-ruling is returned.

For each rule, the algorithm checks:

  1. Are the elements of the authorization request in the scope of this rule?
  2. Is the condition satisfied?

If these conditions are satisfied, the algorithm acts on the rule. If all rules have been processed (but no 'allow' or 'deny' satisfied these two conditions), the algorithm returns the default-ruling. We now describe the two conditions in more detail:

Scope Check: The scope checks are based on the hierarchies defined in the used <epal-vocabulary>.
A request is in the scope of a rule where the "ruling" attribute is "allow" iff

A request is in the scope of a rule where the "ruling" attribute is "deny" iff

If the request is not in the scope of the rule, the next rule is processed. Else, the algorithm continues processing this rule:

Checking the Conditions: If the rule has no conditions, the algorithm continues by acting on this rule. If the rule has one or more conditions, the conditions are evaluated as described in Section 4.4. If any of the conditions is not satisfied, the algorithm continues by processing the next rule. Else, it acts on this rule.

Acting on a rule: If the ruling is "allow" or "deny", the ruling, the rule-id of the rule, and the obligations of this rule are returned.

Design Notes:

5.2 Compound Requests

The intuitive question that corresponds to this request is "I belong to multiple user categories. Is there any of my user categories that allows me to perform all actions for all purposes on all data categories?". For a given user-category that is allowed or denied to perform the action, the resulting obligations are collected from all applicable rules and then returned.

We will solve this problem in two parts: First, we show how to resolve it for one user-category. Then, we repeat this procedure for all user-categories.

5.2.1 Required Inputs

A compound authorization request contains

5.2.2 Desired Outputs

The algorithm outputs

5.2.3 Operational Semantics

Processing a Single user category: We now define how to process a compound request for one user category and multiple other elements. The compound query for a particular user-category is decomposed into simple requests as follows:

  1. The algorithm creates two empty sets of obligation/rule-id-set pairs that will be used to collect all distinct obligations and the set of rule-id's that mandated it. We call these sets denyObligations and allowObligations. In addition, it creates two sets denyRules and allowRules of rule-id's that will be used to collect the rule-ids that lead to a 'deny' or 'allow' decision, respectively.
  2. The algorithm performs one simple request for the given user-category and any combination of the other elements in the compound request. It uses the same attribute/container instance for all these simple requests.
    If the ruling is "allow", the returned rule-id is added to the set allowRules. If obligations are returned, the (rule-id, obligation)-pairs are added to the set allowObligations. If the ruling is "deny", the rule-id is added to the set denyRules while (rule-id, obligation)-pairs are added to the denyObligations set.

After processing the simple requests for all combinations of elements in the compound request, we can determine the ruling for this user category as follows:

Processing Multiple user categories: Multiple user categories are processed in the order that they are defined inside the vocabulary of the policy:

  1. If the compound processing for any user category is 'allow', select the first one of such user categories and return the 'allow' ruling with the rule-id's (allowRules) and obligation/rule-id-set pairs (allowObligations) that are returned for this user category.
  2. If the compound processing for any user category is 'deny', select the first one of such user categories and return the 'deny' ruling with the rule-id's (denyRules) and obligation/rule-id-set pairs (denyObligations) that are returned for this user category.
  3. Else, return the 'not-applicable' ruling with an empty rule-id-set.

Design Notes:

6 EPAL Data Types

We now list some complex data types that have been used for multiple elements. These data-types define sub-elements that are common to all actual elements that implement or refine these types.

6.1 "identifiedObjectType": Elements with unique identifiers

Any element of this type has a required attribute "id" of type "NCName". This attribute contains an identifier that can be used to reference the element. This type is further refined by the "describedObjectType" and used in the rules to reference the objects that are covered by a rule.

Schema Fragment

<!-- Elements which have an identifier should be of this type -->
<xs:complexType 
  name="identifiedObjectType">
  <xs:attribute 
    name="id" 
    type="xs:NCName" 
    use="required">
  </xs:attribute>
</xs:complexType>

6.2 "referringObjectType": Elements with reference identifiers

Any element of this type has a required attribute "refid" of type "NCName". This attribute contains an identifier that references another element that contains the same value in its "id" attribute. E.g., a user-category inside a rule contains a refid field that references the id attribute of a user-category inside the referenced vocabulary.

Schema Fragment

<!-- Elements which refer to an identifier should be of this type -->
<xs:complexType 
  name="referringObjectType">
  <xs:attribute 
    name="refid" 
    type="xs:NCName" 
    use="required">
  </xs:attribute>
</xs:complexType>

6.3 "describedObjectType": Extensible Elements with Descriptions

The "describedObjectType" extends the "identifiedObjectType". Elements of this type contain a sequence of zero or more elements <short-description> of type "string" that is extended by an attribute 'language' of simple type "language", zero or more elements <long-description> of type "string" that is extended by an attribute 'language' of simple type "language", and zero or more elements <property>. Each <property> element contains <value> elements with contents of type "epalSimpleType".
We require that for any 'language', there must be at most one <long-description> and one <short-description> element.
Property elements can be used to extend the EPAL policy language or to store any external information that is needed by particular implementations. Examples of properties include implementation hints, or expressions describing the element in more detail. The "id" can be used by implementers to retrieve properties that relate to their particular implementation. In general, the content of the properties is not standardized. However, standardizing properties can enable a later extension of EPAL without changing the core standard. This type is further refined by the "hierarchicalObjectType" and is used in the EPAL vocabularies to define and describe non-hierarchical elements of an EPAL policy.

Schema Fragment

<!-- Identified Elements which have descriptions should be of this type -->
<xs:complexType name="describedObjectType">
    <xs:complexContent>
        <xs:extension base="epal:identifiedObjectType">
            <xs:sequence>
                <xs:element name="short-description" minOccurs="0" 
                   maxOccurs="unbounded">
                    <xs:complexType>
                        <xs:simpleContent>
                            <xs:extension base="xs:string">
                                <xs:attribute name="language" use="optional" 
                                   default="en" type="xs:language"></xs:attribute>
                            </xs:extension>
                        </xs:simpleContent>
                    </xs:complexType>
                </xs:element>
                <xs:element name="long-description"
                   minOccurs="0" maxOccurs="unbounded">
                    <xs:complexType>
                        <xs:simpleContent>
                            <xs:extension base="xs:string">
                                <xs:attribute name="language" use="optional" 
                                  default="en" type="xs:language"></xs:attribute>
                            </xs:extension>
                        </xs:simpleContent>
                    </xs:complexType>
                </xs:element>
                <xs:element name="property" minOccurs="0" maxOccurs="unbounded">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="value" type="epal:epalSimpleType" 
                              minOccurs="0" maxOccurs="unbounded"/>
                        </xs:sequence>
                        <xs:attribute name="id" use="required" 
                          type="xs:NCName"></xs:attribute>
                    </xs:complexType>
                </xs:element>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

6.4 "hierarchicalType": Identified elements structured in a hierarchy

The "hierarchicalType" extends the "describedObjectType" by adding an optional "parent" attribute with type "NCName". The parent attribute points to a unique "id" attribute of another element.
This type is used in EPAL vocabularies to define hierarchical elements (such as purpose, or user-category) to define and describe the elements of an EPAL policy while structuring them into a hierarchy.

Schema Fragment

<!-- Elements which can participate in a hierarchy should have this type -->
<xs:complexType 
  name="hierarchicalType">
  <xs:complexContent>
    <xs:extension 
      base="epal:describedObjectType">
      <xs:attribute 
        name="parent" 
        type="xs:string" 
        use="optional">
      </xs:attribute>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

6.5 "contactInfoType": A sequence of elements for contact information

An element of type "contactInfoType" contains a sequence of exactly one of each of the following required elements of type "string": <name>, <organization>, <e-mail>, <address>, and <country> .
This type is used for stating the mandatory address of the issuer of a policy and for adding an optional address to a user-category of a policy.

Schema Fragment

<!-- Contact information   -->
<xs:complexType 
  name="contactInfoType">
  <xs:sequence>
    <xs:element 
      name="name" 
      type="xs:string" 
      minOccurs="1" 
      maxOccurs="1"></xs:element>
    <xs:element 
      name="organization" 
      type="xs:string" 
      minOccurs="1" 
      maxOccurs="1"></xs:element>
    <xs:element 
      name="e-mail" 
      type="xs:string" 
      minOccurs="1" 
      maxOccurs="1"></xs:element>
    <xs:element 
      name="address" 
      type="xs:string" 
      minOccurs="1" 
      maxOccurs="1"></xs:element>
    <xs:element 
      name="country" 
      type="xs:string" 
      minOccurs="1" 
      maxOccurs="1"></xs:element>
  </xs:sequence>
</xs:complexType>

6.6 "attributeDefinitionType": Schema-like Definition of Multi-valued Attributes

An element of type "attributeDefinitionType" extends the "describedObjectType" by adding a set of attributes. The inherited attribute "id" defines the name of the defined attribute. The attribute "simpleType" defines the data type of the attribute by a URI. The allowed data type URIs are taken from the XML Schema Part 2 specification. The following is the list of the allowed data type URIs.

The attribute "minOccurs" defines the minimal number of values that need to occur in a list. The attribute "maxOccurs" defines the maximal number of values that need to occur in a list. "maxOccurs" is either of type "nonNegativeInteger" or else equal the string 'unbounded'.

Schema Fragment

<!-- A Descriptor of an attribute -->
<xs:complexType 
  name="attributeDefinitionType">
  <xs:complexContent>
    <xs:extension 
      base="epal:describedObjectType">
      <xs:attribute 
        name="simpleType" use="required" type="epal:epalSimpleTypeURI"/>
      <xs:attribute 
        name="minOccurs" 
        type="xs:nonNegativeInteger"
        use="optional" 
        default="1"/>
      <xs:attribute 
        name="maxOccurs" 
        use="optional" 
        default="1">
        <xs:simpleType>
          <xs:union 
            memberTypes="xs:nonNegativeInteger">
            <xs:simpleType>
              <xs:restriction 
                base="xs:string">
                <xs:enumeration 
                  value="unbounded"/>
              </xs:restriction>
            </xs:simpleType>
          </xs:union>
        </xs:simpleType>
      </xs:attribute>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

<xs:simpleType name="epalSimpleTypeURI">
  <xs:restriction 
    base="xs:anyURI">
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#string"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#boolean"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#double"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#time"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#date"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#dateTime"/>
    <xs:enumeration value="http://www.w3.org/2001/XMLSchema#integer"/>
  </xs:restriction>
</xs:simpleType>

6.7 "containerAttributeDefinitionType": Schema-like Definition of Multi-valued Container Attributes

An element of type "containerAttributeDefinitionType" extends the "attributeDefinitionType" by adding an optional attribute "auditable".
The "auditable" attribute is Boolean and defines whether this particular attribute must be collected in an auditable way. In practice, this attribute will be used to distinguish consent like "yes to direct mailings" (auditable) and enterprise-internal context "time of day" (not required to be auditable).

Schema Fragment

   <xs:complexType name="containerAttributeDefinitionType">
        <xs:complexContent>
            <xs:extension base="epal:attributeDefinitionType">
                <xs:attribute name="auditable" use="optional"
                      type="xs:boolean" default="false"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

6.8 "epalSimpleType": Data Types Allowed in Attributes, Parameters, and Properties.

An element of type "epalSimpleType" contains values of simple types that can be tunneled through the EPAL engine. These primitive types are taken from the XML Schema Part 2 specification as described in Section 6.6.

Schema Fragment

<xs:simpleType 
  name="epalSimpleType">
  <xs:union 
    memberTypes="xs:string xs:boolean xs:integer xs:double xs:time xs:date
                  xs:dateTime xs:anyURI xs:hexBinary xs:base64Binary"/>
</xs:simpleType>

6.9 "infoType": Information about the Policy or Vocabulary

This type defines the information that is used to describe and identify an <epal-policy> or an <epal-vocabulary> . It contains information about the policy or vocabulary in the form of three sub-elements. This type extends the "describedObjectType" by appending the following sub-elements in the following sequence:

  1. The optional <issuer> of type "contactInfoType" contains the contact information of the issuer.
  2. The optional <location> element of type "anyURI" points to the location in which the policy or vocabulary is stored.
  3. The required <version-info> element contains a required attribute "revision-number" of type "string" that identifies the version of the policy, a required attribute "last-modified" of type "dateTime" that defines when the policy has been modified, an optional attribute "test" of type "boolean" that indicates that this is a test policy, a required attribute "start-date" of type "dateTime" that indicates the start of the lifetime of this policy, an optional attribute "end-date" that defines when the policy expires, and two optional attributes "superseded-by-id" and "superseded-by-revision-number" that identifies another policy that supersedes this policy. If only an "id" is given, all revisions with this id supersede the given policy, if only a revision is given, the policy with the same but the given revision supersedes this policy.
    Note that the "id" attribute together with the "revision-number" attribute must uniquely identify a policy or a vocabulary for each issuer.

Schema Fragment

    <xs:complexType name="infoType">
        <xs:complexContent>
            <xs:extension base="epal:describedObjectType">
                <xs:sequence>
                    <xs:element name="issuer" minOccurs="0"
                        maxOccurs="1"
                        type="epal:contactInfoType"></xs:element>
                    <xs:element name="location" minOccurs="0"
                        maxOccurs="1"
                        type="xs:anyURI"></xs:element>
                    <xs:element name="version-info" minOccurs="1"
                        maxOccurs="1">
                        <xs:complexType>
                            <xs:attribute name="test" type="xs:boolean"
                                default="false"
                                use="optional"></xs:attribute>
                            <xs:attribute name="start-date"
                                type="xs:dateTime"
                                use="required"></xs:attribute>
                            <xs:attribute name="revision-number"
                                type="xs:string"
                                use="required"></xs:attribute>
                            <xs:attribute name="last-modified"
                                type="xs:dateTime"
                                use="required"></xs:attribute>
                            <xs:attribute name="end-date"
                                type="xs:dateTime"
                                use="optional"></xs:attribute>
                            <xs:attribute name="superseded-by-id"
                                type="xs:NCName"
                                use="optional"></xs:attribute>
                            <xs:attribute name="superseded-by-revision-number"
                                type="xs:string"
                                use="optional"></xs:attribute>
                        </xs:complexType>
                    </xs:element>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

6.10 "importStatementType": Import of a File

This type defines the syntax for importing a file (e.g., an EPAL vocabulary file). It contains the following attributes.

  1. "location" a mandatory attribute of type "anyURI" that points to the file to be imported
  2. "id" an optional attribute of type "NCName" that signals the expected "id" of the imported file (When the file is a vocabulary file, the name is stored at /epal-vocabulary/vocabulary-information/@id).
  3. "revision-number" an optional attribute of type "string" that signals the expected revision number of the imported file (When the file is a vocabulary file, the revision number is stored at vocabulary-information/version-info/@revision-number).

In addition, it can be augmented by elements <long-description>, <short-description>, and <property> as described for the describedObjectType.

Schema Fragment

   <xs:complexType name="importStatementType">
        <xs:complexContent>
            <xs:extension base="epal:describedObjectType">
                <xs:attribute name="location" use="required"
                    type="xs:anyURI"></xs:attribute>
                <xs:attribute name="revision-number" use="optional"
                    type="xs:NCName"></xs:attribute>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

Example: Structure of a <import> element and its sub-elements

<import id="epal-example" location="http://www.ibm.com/epal-example-1.0.xml"
        revision-number="1.0">

6.11 "functionType":EPAL Functions and Predicates

This type defines the syntax for specifying an EPAL function or an EPAL predicate with a sequence of arguments. The mandatory "refid" attribute specifies the URI of a particular predicate or function. The syntax and semantics of each predicate or function are listed in Appendix 5.

The child elements are viewed as a sequence of arguments, i.e., a combination of <predicate>, <function>, <attribute-value>, <attribute-bag>, <attribute-reference>, and <condition-reference> elements represents a sequence of arguments.

  1. A <predicate> of type "functionType" represents a boolean function, i.e., a function that returns a boolean value.
  2. A <function> of type "functionType" represents a non-boolean function.
  3. An <attribute-value> element represents an attribute value, i.e., an instance of a particular data type. The data type is specified by the mandatory "simpleType" attribute, and the value is specified as the content of the element.
  4. An <attribute-bag> element represents a bag of attribute values. The values in a bag are not ordered, and some of the values may be duplicates. The data type is specified by the mandatory attribute "simpleType", and the values are specified as zero or more <value> elements.
  5. An <attribute-reference> element represents a reference to a particular container attribute. The container attribute is identified by the pair of the mandatory attributes "container-refid" and "attribute-refid".
  6. A <condition-reference> element represents a reference to a particular condition specified by the mandatory attribute "refid".

Schema Fragment

  <xs:complexType
    name="functionType">
    <xs:sequence>
      <xs:choice
        minOccurs="1"
        maxOccurs="unbounded">
        <xs:element
          name="attribute-value"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension
                base="epal:epalSimpleType">
                <xs:attribute
                  name="simpleType"
                  use="required"
                  type="epal:epalSimpleTypeURI"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="attribute-bag"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:sequence>
              <xs:element
                name="value"
                type="epal:epalSimpleType"
                minOccurs="0"
                maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute
              name="simpleType"
              use="required"
              type="epal:epalSimpleTypeURI"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="attribute-reference"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:attribute
              name="container-refid"
              use="required"
              type="xs:NCName"/>
            <xs:attribute
              name="attribute-refid"
              use="required"
              type="xs:NCName"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="condition-reference"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:attribute
              name="refid"
              use="required"
              type="xs:NCName"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="predicate"
          type="epal:functionType"
          minOccurs="1"
          maxOccurs="1"/>
        <xs:element
          name="function"
          type="epal:functionType"
          minOccurs="1"
          maxOccurs="1"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute
      name="refid"
      type="xs:anyURI"
      use="required"/>
  </xs:complexType>

Example: An EPAL predicate

<predicate
  refid="http://www.research.ibm.com/privacy/epal#string-equal">
  <function
    refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
    <attribute-reference
      container-refid="DataUserInfo"
      attribute-refid="DataUserID"/>
  </function>
  <attribute-value
   simpleType="http://www.w3.org/2001/XMLSchema#string">John Doe</attribute-value>
</predicate>

Appendices

Appendix 1. References (Normative)

CPExchange 1.0
Kathy Bohrer and Bobby Holland, editors. Customer Profile Exchange (CPExchange) Specification, 20 October 2000. Available at: http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
P3P 1.0
World Wide Web Consortium. The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, 28 September 2001. Available at: http://www.w3.org/TR/P3P/
XML 1.0 (Second Edition)
World Wide Web Consortium. Extensible Markup Language (XML) 1.0, Second Edition. Available at: http://www.w3.org/TR/2000/WD-xml-2e-20000814
XML Schema Part 1: Structures
World Wide Web Consortium. XML Schema Part 1: Structures. Available at: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes
World Wide Web Consortium. XML Schema Part 2: Datatypes. Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
XML Schema Requirements
World Wide Web Consortium. XML Schema Requirements. Available at: http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215
XQuery 1.0 and XPath 2.0 Functions and Operators
World Wide Web Consortium. XQuery 1.0 and XPath 2.0 Functions and Operators. Available at: http://www.w3.org/TR/2003/WD-xpath-functions-20030502/

Appendix 2. References (Non-Normative)

XML Schema Language: Part 0 Primer
World Wide Web Consortium. XML Schema Language: Part 0 Primer. Available at: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/
UML Guide
Martin Fowler. UML Distilled. The Addison-Wesley Object Technology Series, August 1999.
Robert C. Martin. UML Tutorial: Part I - Class Diagrams. Available at: http://www.objectmentor.com/publications/umlClassDiagrams.pdf
XML Guide
Didier Martin, et al. Professional XML. Wrox Press Ltd., January 2000.

Appendix 3. Example Authorization Interface

This section specifies an example interface to authorization engines. This interface enables an authorization engine to consume XML inputs while producing XML outputs. This is particularly useful for testing purposes where authorization engines can consume batches of XML inputs while producing batches of outputs that can then be verified for conformance to the semantics.

The following sections define the syntax of an authorization request and result. The namespace URI for the syntax is "http://www.research.ibm.com/privacy/epal/interface".

Appendix 3.1 <epal-query> : EPAL Authorization Request

The top-level element <epal-query> defines a data structure that is input to an EPAL authorization engine for performing an actual authorization.

Syntax: Each <epal-query> element contains a sequence of one or more <user-category> elements, one or more <data-category> elements, one or more <purpose> elements, and one or more <action> elements. All these elements are of type "referringObjectType". In addition, it contains a list of <container> elements. Each <container> element contains an attribute "refid" that identifies the container of the policy that is instantiated. In addition, it contains one or more "attribute" elements that contain the actual attribute values to be used to evaluate the conditions.

Semantics: Each <epal-query> element corresponds to one authorization query. Each "container" element is an instance of the corresponding "container" of the policy. The contained data will be used to evaluate conditions.

Design Notes:

Schema Fragment

  <xs:element 
    name="epal-query">
    <xs:complexType>
      <xs:sequence>
        <!-- The user category accessing the data-->
        <xs:element 
          name="user-category" 
          type="epal:referringObjectType" 
          minOccurs="1" 
          maxOccurs="unbounded"></xs:element>
        <!-- The category of the accessed data -->
        <xs:element 
          name="data-category" 
          type="epal:referringObjectType" 
          minOccurs="1" 
          maxOccurs="unbounded"></xs:element>
        <!-- The stated purpose of the access -->
        <xs:element 
          name="purpose" 
          type="epal:referringObjectType" 
          minOccurs="1" 
          maxOccurs="unbounded"></xs:element>
        <!-- The stated operation of the access -->
        <xs:element 
          name="action" 
          type="epal:referringObjectType" 
          minOccurs="1" 
          maxOccurs="unbounded"></xs:element>
        <!-- The list of XML container instances each corresponding to
              a container definition. -->
        <xs:element 
          name="container" 
          minOccurs="0" 
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element 
                name="attribute"
                minOccurs="0" 
                maxOccurs="unbounded">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="value" type="epal:epalSimpleType" 
                       minOccurs="0" maxOccurs="unbounded"/>
                  </xs:sequence>
                  <xs:attribute name="refid" use="required" 
                     type="xs:NCName"></xs:attribute>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute 
              name="refid" 
              type="xs:NCName"/>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

Example: An EPAL Authorization Query

<?xml version="1.0"?>
<epal-query 
  xmlns="http://www.research.ibm.com/privacy/epal/interface" 
  xmlns:epal="http://www.research.ibm.com/privacy/epal" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.research.ibm.com/privacy/epal/interface 
    epal-interface.xsd http://www.research.ibm.com/privacy/epal epal.xsd ">
  <user-category refid="SalesDepartment"/>
  <data-category refid="CustomerRecord"/>
  <purpose refid="OrderProcessing"/>
  <action refid="Store"/>
  <container refid="CustomerRecord">
    <attribute refid="CustomerID">
      <value>0123456789</value>
      <value>Alice</value>
    </attribute>
  </container>
</epal-query>

Appendix 3.2 <epal-ruling> : Authorization Result

The top-level element <epal-ruling> defines the data structure that is output by the EPAL authorization engine as an answer to an authorization query.

Syntax: Each <epal-ruling> element contains an attribute "ruling" with the ruling, a sequence of zero or more <originating-rule> elements of type "referringObjectType" that identify the rules that mandate this ruling, and zero or more <obligation> elements. Each obligations element inherits an attribute "refid" from the "referringObjectType". It extends this type by one or more child elements <originating-rule> of type "referringObjectType" that identify the rules that mandate this obligation, and a list of <parameter> elements of type "epalSimpleType" that define the parameters for this obligation. The required attribute "simpleType" specifies the epalSimpleType of the parameter as specified in the definition of the policy.

Semantics: The <epal-ruling> element describes one authorization answer. The ruling attribute contains the ruling returned by the engine, the originating-rules identify the rules that were used to allow/deny the request. The contained list of obligations identifies the resulting obligations. Each obligation has a "refid" that points to an "id" of an obligation of the policy. In addition, the obligation has a list of <originating-rule/> sub-elements that identify all rules that mandated this obligation.

Design Notes:

Schema Fragment

    <xs:element 
    name="epal-ruling">
    <xs:complexType>
      <xs:sequence>
        <!-- The rules that mandated authorized access. -->
        <xs:element 
          name="originating-rule" 
          minOccurs="0" 
          maxOccurs="unbounded" 
          type="epal:referringObjectType"/>
        <!-- The returned obligations -->
        <xs:element 
          name="obligation" 
          minOccurs="0" 
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:complexContent>
              <xs:extension 
                base="epal:referringObjectType">
                <xs:sequence>
                  <!-- The rules that mandated this obligation -->
                  <xs:element 
                    name="originating-rule" 
                    minOccurs="1" 
                    maxOccurs="unbounded" 
                    type="epal:referringObjectType"/>
                  <!-- The XML input for each returned obligation -->
                  <xs:element 
                    name="parameter" 
                    minOccurs="0" 
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:sequence>
                        <xs:element name="value" type="epal:epalSimpleType" 
                          minOccurs="0" maxOccurs="unbounded"/>
                      </xs:sequence>
                      <xs:attribute name="simpleType" use="required" 
                         type="epal:epalSimpleTypeURI"/>
                      <xs:attribute name="refid" use="required" type="xs:NCName"/>
                    </xs:complexType>
                  </xs:element>
                </xs:sequence>
              </xs:extension>
            </xs:complexContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute 
        name="ruling">
         <xs:simpleType>
          <xs:restriction base="xs:string">
            <xs:enumeration value="allow"/>
            <xs:enumeration value="deny"/>
            <xs:enumeration value="not-applicable"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
</xs:schema>

Example: An Authorization Answer

<?xml version="1.0"?>
<epal-ruling ruling="allow" 
  xmlns="http://www.research.ibm.com/privacy/epal/interface" 
  xmlns:epal="http://www.research.ibm.com/privacy/epal" 
  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.research.ibm.com/privacy/epal/interface epal-interface.xsd
                      http://www.research.ibm.com/privacy/epal epal.xsd">
  <originating-rule refid="rule1"/>
  <obligation refid="Retention">
    <originating-rule refid="rule1"/>
    <parameter refid="Days"
     simpleType="http://www.w3.org/2001/XMLSchema#integer"><value>2</value></parameter>
    <parameter refid="Hours"
     simpleType="http://www.w3.org/2001/XMLSchema#integer"><value>48</value></parameter>
  </obligation>
</epal-ruling>

Appendix 4. Glossary

action
The action being performed in a rule or a request.
component
A user category, action, data category, or purpose element.
component set
A component set is a named set of user categories, actions, data categories, or purposes. A component set may not mix different types of components, such as an action and a purpose. A component set may contain another component set of the same type of elements. The wildcard is a component set which contains all declared elements of a single type.
compound request
A request with more than one user category, action, data category, and/or purpose element. The representation of a component as an element or a component set is irrelevant.
compound rule
A rule with more than one user category, action, data category, and/or purpose. The representation of a component as an element or a component set is irrelevant.
condition
The condition that indicates when a rule applies. A condition is evaluated on multiple containers.
container
The container that contains context data represented by a set of attributes.
data category
The data on which the action is being performed in a rule.
data subject
The owner whose data is collected and accessed.
user category
An individual, group, organization, or agent performing the action in a rule.
namespace
A namespace is a collection of names, identified by a URI reference, which are used in XML documents as element types and attribute names.
namespace prefix
A namespace prefix is an alias defined in the namespace declaration.
obligation
One or more actions in a rule that must be performed if the action is performed.
precedence
Conflict between two or more conflicting rules may be resolved by indicating an ordering. If each rule conflicts with the others, then a total ordering is required to resolve all conflicts. If some rules do not conflict, then a partial ordering is sufficient to resolve all conflicts. This (partial) ordering is called precedence.
privacy administrator
A role within an enterprise which is involved with the design, assessment, or enforcement of a privacy policy. This role may be occupied by a Chief Privacy Officer, another executive, an external auditor, or a member of the information services/technology department.
purpose
The reason that the action is being performed in a rule.
qualified name
A qualified name has a namespace prefix attached to the name, separated by a colon.
request
Any action or set of actions on data can be formulated as a request. The action or actions are mapped to one or more actions. The data is mapped to one or more data categories. The action is performed by one or more user categories, which may be individuals, departments, organizations, enterprises, or software agents. One or more purposes must be attached to the request. Therefore, a request contains one or more user categories, action, data categories, and purposes. Each component may be represented by the element or by a component set. A request may be of type simple or compound.
rule
A rule defines if a request is permitted or not. A rule contains a ruling of either "allow" or "deny", one or more user categories, actions, data categories, and purposes, one conditions container, and one obligations container. A rule may be of type simple or compound.
ruling
A ruling is the state of permission for a request derived from a rule or a set of rules. Examples of rulings include "allow", "deny", and "not-applicable". The "not-applicable" ruling can be used as a default ruling, but cannot be the ruling of a rule. The "not-applicable" ruling states that the policy does not make a statement about a particular request.
schema
A XML schema that defines the syntax of an XML document.
scope
The scope of a request or a rule is defined by four dimensions: the set of applicable user categories, the set of applicable actions, the set of applicable data categories, and the set of applicable purposes.
simple request
A request with a exactly one user category, action, data category, and purpose element. The representation of a component as an element or a component set is irrelevant.
simple rule
A rule with exactly one ruling, user category, action, data category, and purpose. The representation of a component as an element or a component set is irrelevant.
valid XML
A valid XML document is well-formed XML and it conforms to the structure and vocabulary defined in a DTD or an XML Schema.
well-formed XML
Well-formed XML conforms to the basic syntax rules of XML, but there are no other syntactic guarantees.
XML vocabulary
An XML vocabulary is a description of XML data that is used as the medium for information exchange, often within a specific domain of human activity, for example, privacy.

Appendix 5: EPAL Functions and Predicates

This appendix specifies the functions and predicates used by EPAL. Every function and predicate is uniquely addressed via a URI Reference constructed as follows:

  1. The base URI is the URI of the EPAL namespace, i.e., http://www.research.ibm.com/privacy/epal.
  2. The fragment identifier is the name of the function/predicate.
For example, to reference the "string-equal" predicate, the URI is:

All functions and predicates take a sequence of attribute values and bags of attribute values as arguments. It is important to note that a bag containing only one attribute value is not the same as an attribute value. For example, the "string-equal" function takes two attribute values as the arguments, but not two such bags. Similarly, the "string-bag-to-value" function is supposed to take such a bag as the argument, but not an attribute value. Indeed, it converts such a bag into an attribute value.

Appendix 5.1 EPAL Functions

Arithmetic Functions
Names Arguments Return Value
integer-add Two or more attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the result of addition.
double-add Two or more attribute values of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the result of addition.
integer-subtract Two attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the result of subtraction, where the second argument is subtracted from the first argument.
double-subtract Two attribute values of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the result of subtraction, where the second argument is subtracted from the first argument.
integer-multiply Two attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the result of multiplication.
double-multiply Two attribute values of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the result of multiplication.
integer-divide Two attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the result of division, where the second argument is the divisor.
double-divide Two attribute values of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the result of division, where the second argument is the divisor.
integer-mod Two attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the modulo, where the second argument is the divisor.
integer-abs A single attribute value of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the absolute value.
double-abs A single attribute value of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the absolute value.
round A single attribute value of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the closest integer value to the argument.
floor A single attribute value of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#double representing the largest integer value that is not greater than the argument.
String Conversion Functions
Name Arguments Return Value
lower-case A single attribute value of http://www.w3.org/2001/XMLSchema#string This function converts all of the characters in the string argument to lower case according to the "fn:lower-case" function [XQuery 1.0 and XPath 2.0 Functions and Operators], and returns an attribute value of http://www.w3.org/2001/XMLSchema#string representing the result.
upper-case A single attribute value of http://www.w3.org/2001/XMLSchema#string This function converts all of the characters in the string argument to lower case according to the "fn:upper-case" function [XQuery 1.0 and XPath 2.0 Functions and Operators], and returns an attribute value of http://www.w3.org/2001/XMLSchema#string representing the result.
normalize-space A single attribute value of http://www.w3.org/2001/XMLSchema#string This function normalizes the spaces in the string argument according to the "fn:normalize-space" function [XQuery 1.0 and XPath 2.0 Functions and Operators], and returns an attribute value of http://www.w3.org/2001/XMLSchema#string representing the result.
Numeric Conversion Functions
Name Arguments Return Value
double-to-integer A single attribute value of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the truncated integer value.
integer-to-double A single attribute value of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#double representing the integer value.
Bag Functions
Name Arguments Return Value
string-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#string An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
boolean-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#boolean An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
integer-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#integer An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
double-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#double An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
time-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#time An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
date-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#date An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
dateTime-bag-size A single bag of attribute values of http://www.w3.org/2001/XMLSchema#dateTime An attribute value of http://www.w3.org/2001/XMLSchema#integer representing the size of the bag.
string-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#string This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#string representing the only one value is returned, otherwise an error is returned.
boolean-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#boolean This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#boolean representing the only one value is returned, otherwise an error is returned.
integer-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#integer This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#integer representing the only one value is returned, otherwise an error is returned.
double-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#double This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#double representing the only one value is returned, otherwise an error is returned.
time-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#time This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#time representing the only one value is returned, otherwise an error is returned.
date-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#date This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#date representing the only one value is returned, otherwise an error is returned.
dateTime-bag-to-value A single bag of attribute values of http://www.w3.org/2001/XMLSchema#dateTime This function checks whether the bag contains one and only one attribute value. If it is true, then an attribute value of http://www.w3.org/2001/XMLSchema#dateTime representing the only one value is returned, otherwise an error is returned.
string-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#string A bag of http://www.w3.org/2001/XMLSchema#string containing all the argument values.
boolean-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#boolean A bag of http://www.w3.org/2001/XMLSchema#boolean containing all the argument values.
integer-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#integer A bag of http://www.w3.org/2001/XMLSchema#integer containing all the argument values.
double-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#double A bag of http://www.w3.org/2001/XMLSchema#double containing all the argument values.
time-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#time A bag of http://www.w3.org/2001/XMLSchema#time containing all the argument values.
date-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#date A bag of http://www.w3.org/2001/XMLSchema#date containing all the argument values.
dateTime-bag Zero or more attribute values of http://www.w3.org/2001/XMLSchema#dateTime A bag of http://www.w3.org/2001/XMLSchema#dateTime containing all the argument values.

Appendix 5.2 EPAL Predicates

Equality Predicates
Name Arguments Result
string-equal Two attribute values of http://www.w3.org/2001/XMLSchema#string True iff the two values are equal according to the "fn:compare" function [XQuery 1.0 and XPath 2.0 Functions and Operators].
boolean-equal Two attribute values of http://www.w3.org/2001/XMLSchema#boolean True iff the two values are equal.
integer-equal Two attribute values of http://www.w3.org/2001/XMLSchema#integer True iff the two values are equal.
double-equal Two attribute values of http://www.w3.org/2001/XMLSchema#double True iff the two values are equal.
time-equal Two attribute values of http://www.w3.org/2001/XMLSchema#time True iff the two values are equal according to the "op:time-equal" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
date-equal Two attribute values of http://www.w3.org/2001/XMLSchema#date True iff the two values are equal according to the "op:date-equal" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
dateTime-equal Two attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff the two values are equal according to the "op:dateTime-equal" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
String Comparison Predicates
Name Arguments Result
string-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#string True iff the first argument is greater than the second argument according to the "fn:compare" function [XQuery 1.0 and XPath 2.0 Functions and Operators].
string-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#string True iff the first argument is greater than or equal to the second argument according to the "fn:compare" function [XQuery 1.0 and XPath 2.0 Functions and Operators].
string-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#string True iff the first argument is less than the second argument according to the "fn:compare" function [XQuery 1.0 and XPath 2.0 Functions and Operators].
string-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#string True iff the first argument is less than or equal to the second argument according to the "fn:compare" function [XQuery 1.0 and XPath 2.0 Functions and Operators].
Numeric Comparison Predicates
Name Arguments Result
integer-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#integer True iff the first argument is greater than the second argument.
integer-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#integer True iff the first argument is greater than or equal to the second argument.
integer-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#integer True iff the first argument is less than the second argument.
integer-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#integer True iff the first argument is less than or equal to the second argument.
double-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#double True iff the first argument is greater than the second argument.
double-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#double True iff the first argument is greater than or equal to the second argument.
double-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#double True iff the first argument is less than the second argument.
double-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#double True iff the first argument is less than or equal to the second argument.
Date and Time Comparison Predicates
Name Arguments Result
time-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#time True iff the first argument is greater than the second argument according to the "op:time-greater-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
time-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#time True iff the first argument is greater than or equal to the second argument according to the "op:time-greater-than" and "op:time-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
time-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#time True iff the first argument is less than the second argument according to the "op:time-less-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
time-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#time True iff the first argument is less than or equal to the second argument according to the "op:time-lessr-than" and "op:time-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
date-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#date True iff the first argument is greater than the second argument according to the "op:date-greater-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
date-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#date True iff the first argument is greater than or equal to the second argument according to the "op:date-greater-than" and "op:date-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
date-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#date True iff the first argument is less than the second argument according to the "op:date-less-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
date-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#date True iff the first argument is less than or equal to the second argument according to the "op:date-lessr-than" and "op:date-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
dateTime-greater-than Two attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff the first argument is greater than the second argument according to the "op:dateTime-greater-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
dateTime-greater-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff the first argument is greater than or equal to the second argument according to the "op:dateTime-greater-than" and "op:dateTime-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
dateTime-less-than Two attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff the first argument is less than the second argument according to the "op:dateTime-less-than" operator [XQuery 1.0 and XPath 2.0 Functions and Operators].
dateTime-less-than-or-equal Two attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff the first argument is less than or equal to the second argument according to the "op:dateTime-lessr-than" and "op:dateTime-equal" operators [XQuery 1.0 and XPath 2.0 Functions and Operators].
Logical Predicates
Name Arguments Result
or One or more attribute values of http://www.w3.org/2001/XMLSchema#boolean True iff one of the arguments is true.
and One or more attribute values of http://www.w3.org/2001/XMLSchema#boolean True iff all the arguments are true.
not A single attribute value of http://www.w3.org/2001/XMLSchema#boolean True iff the argument is false.
Bag Predicates
Names Arguments Result
string-is-in An attribute value of http://www.w3.org/2001/XMLSchema#string as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#string as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "string-equal" predicate).
boolean-is-in An attribute value of http://www.w3.org/2001/XMLSchema#boolean as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#boolean as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "boolean-equal" predicate).
integer-is-in An attribute value of http://www.w3.org/2001/XMLSchema#integer as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#integer as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "integer-equal" predicate).
double-is-in An attribute value of http://www.w3.org/2001/XMLSchema#double as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#double as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "double-equal" predicate).
time-is-in An attribute value of http://www.w3.org/2001/XMLSchema#time as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#time as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "time-equal" predicate).
date-is-in An attribute value of http://www.w3.org/2001/XMLSchema#date as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#date as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "date-equal" predicate).
dateTime-is-in An attribute value of http://www.w3.org/2001/XMLSchema#dateTime as the first argument, and a bag of attribute values of http://www.w3.org/2001/XMLSchema#dateTime as the second argument True iff the first argument is equal to one of the attribute values in the bag of the second argument (according to the "dateTime-equal" predicate).
string-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#string True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "string-equal" predicate).
boolean-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#boolean True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "boolean-equal" predicate).
integer-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#integer True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "integer-equal" predicate).
double-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#double True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "double-equal" predicate).
time-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#time True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "time-equal" predicate).
date-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#date True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "date-equal" predicate).
dateTime-at-least-one-value-equal Two bags of attribute values of http://www.w3.org/2001/XMLSchema#dateTime True iff at least one attribute value in the bag of the first argument is equal to one of the attribute values in the bag of the second argument (according to the "dateTime-equal" predicate).
String Match Predicates
Name Arguments Result
regexp-string-match Two attribute values of http://www.w3.org/2001/XMLSchema#string This predicate evaluates a regular expression match. The first argument is a regular expression, and the second argument is a general string. True iff the two values are matched according to the "fn:matches" function [XQuery 1.0 and XPath 2.0 Functions and Operators].

Appendix 6 Technological Context of EPAL

The Platform for Privacy Preferences (P3P)

The Platform for Privacy Preferences from the Worldwide Web Consortium (see P3P ) enables a web-site to describe what kind of data is collected and how this data will be used. A P3P policy may contain the purposes, the recipients, the retention period, and a textual explanation of why this data is needed. P3P defines standardized categories for each kind of information included in a policy. Unlike P3P, EPAL defines the privacy-practices that are implemented inside an enterprise. Since this depends on internal details of the enterprise, it results in much more detailed policies that can be enforced and audited automatically. However, the resulting privacy guarantees can sometimes be simplified as a P3P promise that is offered for the users of the services.

CPExchange

The Customer Profile Exchange Specification (CPExchange, see CPExchange) defines a data format for disclosing customer data from one party (customer/enterprise) to another. It defines basic and complex data types for many different kinds of personal data (e.g., fields for address, name, hobbies, ...). It enables the specification of privacy meta-information as an option. The privacy meta-information includes the exchange partners, the applicable jurisdiction, and a privacy declaration (based on P3P). Both data types are designed in UML and then translated into XML in a standardized way.

The main focus of CPExchange lies in standardizing the data exchange format. The privacy meta-information is less expressive than EPAL. Consequently, data disclosed using CPExchange may be controlled with EPAL policies instead of using their privacy meta-data.

Appendix 7. Complete XML Schema for EPAL

<?xml 
  version="1.0"?>
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!--                                                       -->
<!-- The Enterprise Privacy Authorization Language (EPAL)  -->
<!--                                                       -->
<!--  Authors:                                             -->
<!--      Paul Ashley <pashley at us.ibm.com>              -->
<!--      Satoshi Hada <satoshih at jp.ibm.com>            -->
<!--      G&uuml;nter Karjoth <gka at zurich.ibm.com>      -->
<!--      Calvin Powers <cspowers at us.ibm.com>           -->
<!--      Matthias Schunter <mts at zurich.ibm.com>        -->
<!--                                                       -->
<!--  Abstract: This schema defines the structure of EPAL  -->
<!--      privacy policies.                                -->
<!--                                                       -->
<!--  Version: 1.2                                         -->
<!--                                                       -->
<!-- Copyright (c) 2000-2003                               -->
<!-- International Business Machines Corporation.          -->
<!--                                                       -->
<!--  Id: epal.xsd,v 1.49 2003/11/10 13:45:20 mts Exp      -->
<xs:schema
  xmlns:epal="http://www.research.ibm.com/privacy/epal"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  targetNamespace="http://www.research.ibm.com/privacy/epal"
  xml:lang="en"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  version="b">

  <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  <!--                                                       -->
  <!-- DECLARATION OF REUSABLE TYPES                         -->
  <!--                                                       -->
  <!-- Types needed often are declared here.                 -->

  <!-- Elements which have an identifier should be of this type -->
  <xs:complexType
    name="identifiedObjectType">
    <xs:attribute
      name="id"
      use="required"
      type="xs:NCName"></xs:attribute>
  </xs:complexType>

  <!-- Elements which refer to an identifier should be of this type -->
  <xs:complexType
    name="referringObjectType">
    <xs:attribute
      name="refid"
      use="required"
      type="xs:NCName"></xs:attribute>
  </xs:complexType>

  <!-- Identified Elements which have descriptions should be of this type -->
  <xs:complexType
    name="describedObjectType">
    <xs:complexContent>
      <xs:extension
        base="epal:identifiedObjectType">
        <xs:sequence>
          <xs:element
            name="short-description"
            minOccurs="0"
            maxOccurs="unbounded">
            <xs:complexType>
              <xs:simpleContent>
                <xs:extension
                  base="xs:string">
                  <xs:attribute
                    name="language"
                    use="optional"
                    default="en"
                    type="xs:language"></xs:attribute>
                </xs:extension>
              </xs:simpleContent>
            </xs:complexType>
          </xs:element>
          <xs:element
            name="long-description"
            minOccurs="0"
            maxOccurs="unbounded">
            <xs:complexType>
              <xs:simpleContent>
                <xs:extension
                  base="xs:string">
                  <xs:attribute
                    name="language"
                    use="optional"
                    default="en"
                    type="xs:language"></xs:attribute>
                </xs:extension>
              </xs:simpleContent>
            </xs:complexType>
          </xs:element>
          <xs:element
            name="property"
            minOccurs="0"
            maxOccurs="unbounded">
            <xs:complexType>
              <xs:sequence>
                <xs:element
                  name="value"
                  type="epal:epalSimpleType"
                  minOccurs="0"
                  maxOccurs="unbounded"/>
              </xs:sequence>
              <xs:attribute
                name="id"
                use="required"
                type="xs:NCName"></xs:attribute>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <!-- Elements which can participate in a hierarchy should have this type -->
  <xs:complexType
    name="hierarchicalType">
    <xs:complexContent>
      <xs:extension
        base="epal:describedObjectType">
        <xs:attribute
          name="parent"
          use="optional"
          type="xs:NCName"></xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <!-- Contact information   -->
  <xs:complexType
    name="contactInfoType">
    <xs:sequence>
      <xs:element
        name="name"
        type="xs:string"
        minOccurs="1"
        maxOccurs="1"></xs:element>
      <xs:element
        name="organization"
        type="xs:string"
        minOccurs="1"
        maxOccurs="1"></xs:element>
      <xs:element
        name="e-mail"
        type="xs:string"
        minOccurs="1"
        maxOccurs="1"></xs:element>
      <xs:element
        name="address"
        type="xs:string"
        minOccurs="1"
        maxOccurs="1"></xs:element>
      <xs:element
        name="country"
        type="xs:string"
        minOccurs="1"
        maxOccurs="1"></xs:element>
    </xs:sequence>
  </xs:complexType>

  <!-- A Descriptor of an attribute -->
  <xs:complexType
    name="attributeDefinitionType">
    <xs:complexContent>
      <xs:extension
        base="epal:describedObjectType">
        <xs:attribute
          name="simpleType"
          use="required"
          type="epal:epalSimpleTypeURI"/>
        <xs:attribute
          name="minOccurs"
          type="xs:nonNegativeInteger"
          use="optional"
          default="1"/>
        <xs:attribute
          name="maxOccurs"
          use="optional"
          default="1">
          <xs:simpleType>
            <xs:union
              memberTypes="xs:nonNegativeInteger">
              <xs:simpleType>
                <xs:restriction
                  base="xs:string">
                  <xs:enumeration
                    value="unbounded"/>
                </xs:restriction>
              </xs:simpleType>
            </xs:union>
          </xs:simpleType>
        </xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <!-- A Descriptor of a container attribute -->
  <xs:complexType
    name="containerAttributeDefinitionType">
    <xs:complexContent>
      <xs:extension
        base="epal:attributeDefinitionType">
        <xs:attribute
          name="auditable"
          use="optional"
          type="xs:boolean"
          default="false"/>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

  <!-- Allowed EPAL data types -->
  <xs:simpleType
    name="epalSimpleTypeURI">
    <xs:restriction
      base="xs:anyURI">
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#string"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#boolean"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#double"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#time"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#date"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#dateTime"/>
      <xs:enumeration
        value="http://www.w3.org/2001/XMLSchema#integer"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:simpleType
    name="epalSimpleType">
    <!-- Four data types (dayTimeDuration, yearMonthDuration, x500Name, and
         rfc822Name) are ignored since there are no corresponding simple types.-->
    <xs:union
      memberTypes="xs:string xs:boolean xs:integer xs:double xs:time xs:date
                   xs:dateTime xs:anyURI xs:hexBinary xs:base64Binary"/>
  </xs:simpleType>


  <!-- Information on a policy or a vocabulary -->

  <xs:complexType
    name="infoType">
    <xs:complexContent>
      <xs:extension
        base="epal:describedObjectType">
        <xs:sequence>
          <xs:element
            name="issuer"
            minOccurs="0"
            maxOccurs="1"
            type="epal:contactInfoType"></xs:element>
          <xs:element
            name="location"
            minOccurs="0"
            maxOccurs="1"
            type="xs:anyURI"></xs:element>
          <xs:element
            name="version-info"
            minOccurs="1"
            maxOccurs="1">
            <xs:complexType>
              <xs:attribute
                name="test"
                type="xs:boolean"
                default="false"
                use="optional"></xs:attribute>
              <xs:attribute
                name="start-date"
                type="xs:dateTime"
                use="required"></xs:attribute>
              <xs:attribute
                name="revision-number"
                type="xs:string"
                use="required"></xs:attribute>
              <xs:attribute
                name="last-modified"
                type="xs:dateTime"
                use="required"></xs:attribute>
              <xs:attribute
                name="end-date"
                type="xs:dateTime"
                use="optional"></xs:attribute>
              <xs:attribute
                name="superseded-by-id"
                type="xs:NCName"
                use="optional"></xs:attribute>
              <xs:attribute
                name="superseded-by-revision"
                type="xs:string"
                use="optional"></xs:attribute>
            </xs:complexType>
          </xs:element>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


  <!-- Importing policies and vocabularies -->

  <xs:complexType
    name="importStatementType">
    <xs:complexContent>
      <xs:extension
        base="epal:describedObjectType">
        <xs:attribute
          name="location"
          use="required"
          type="xs:anyURI"></xs:attribute>
        <xs:attribute
          name="revision-number"
          use="optional"
          type="xs:string"></xs:attribute>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>


 <!-- Elements for EPAL functions and predicates -->
 
  <xs:complexType
    name="functionType">
    <xs:sequence>
      <xs:choice
        minOccurs="1"
        maxOccurs="unbounded">
        <xs:element
          name="attribute-value"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension
                base="epal:epalSimpleType">
                <xs:attribute
                  name="simpleType"
                  use="required"
                  type="epal:epalSimpleTypeURI"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="attribute-bag"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:sequence>
              <xs:element
                name="value"
                type="epal:epalSimpleType"
                minOccurs="0"
                maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute
              name="simpleType"
              use="required"
              type="epal:epalSimpleTypeURI"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="attribute-reference"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:attribute
              name="container-refid"
              use="required"
              type="xs:NCName"/>
            <xs:attribute
              name="attribute-refid"
              use="required"
              type="xs:NCName"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="condition-reference"
          minOccurs="1"
          maxOccurs="1">
          <xs:complexType>
            <xs:attribute
              name="refid"
              use="required"
              type="xs:NCName"/>
          </xs:complexType>
        </xs:element>
        <xs:element
          name="predicate"
          type="epal:functionType"
          minOccurs="1"
          maxOccurs="1"/>
        <xs:element
          name="function"
          type="epal:functionType"
          minOccurs="1"
          maxOccurs="1"/>
      </xs:choice>
    </xs:sequence>
    <xs:attribute
      name="refid"
      type="xs:anyURI"
      use="required"/>
  </xs:complexType>

  <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  <!--                                                           -->
  <!-- DECLARATION OF THE <epal-vocabulary> TOPLEVEL ELEMENT     -->
  <!--                                                           -->

  <xs:element
    name="epal-vocabulary">
    <xs:complexType>
      <xs:sequence>
        <xs:element
          name="vocabulary-information"
          minOccurs="1"
          maxOccurs="1"
          type="epal:infoType"></xs:element>
        <xs:element
          name="user-category"
          minOccurs="0"
          maxOccurs="unbounded"
          type="epal:hierarchicalType"></xs:element>
        <xs:element
          name="data-category"
          minOccurs="0"
          maxOccurs="unbounded"
          type="epal:hierarchicalType"></xs:element>
        <xs:element
          name="purpose"
          type="epal:hierarchicalType"
          minOccurs="0"
          maxOccurs="unbounded"></xs:element>
        <xs:element
          name="action"
          type="epal:describedObjectType"
          minOccurs="0"
          maxOccurs="unbounded"></xs:element>
        <xs:element
          name="container"
          minOccurs="0"
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:complexContent>
              <xs:extension
                base="epal:describedObjectType">
                <xs:sequence
                  minOccurs="1"
                  maxOccurs="1">
                  <xs:element
                    name="attribute"
                    type="epal:containerAttributeDefinitionType"
                    minOccurs="1"
                    maxOccurs="unbounded"></xs:element>
                </xs:sequence>
              </xs:extension>
            </xs:complexContent>
          </xs:complexType>
          <!-- Declared attribute id's must be unique within each container -->
          <xs:unique
            name="uniqueAttributeDef">
            <xs:selector
              xpath="./epal:attribute"/>
            <xs:field
              xpath="@id"/>
          </xs:unique>
        </xs:element>
        <xs:element
          name="obligation"
          minOccurs="0"
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:complexContent>
              <xs:extension
                base="epal:describedObjectType">
                <xs:sequence
                  minOccurs="1"
                  maxOccurs="unbounded">
                  <xs:element
                    name="parameter"
                    type="epal:attributeDefinitionType"
                    minOccurs="0"
                    maxOccurs="unbounded"></xs:element>
                </xs:sequence>
              </xs:extension>
            </xs:complexContent>
          </xs:complexType>
          <!-- Declared parameter id's must be unique within each obligation -->
          <xs:unique
            name="uniqueParamDef">
            <xs:selector
              xpath="./epal:parameter"/>
            <xs:field
              xpath="@id"/>
          </xs:unique>
        </xs:element>
      </xs:sequence>
      <xs:attribute
        name="version"
        type="xs:string"
        default="1.2"/>
    </xs:complexType>

    <!-- Key and References for user-category/@id -->
    <xs:key
      name="user-category-identifier">
      <xs:selector
        xpath="./epal:user-category"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:key>

    <xs:keyref
      name="user-category-reference"
      refer="epal:user-category-identifier">
      <xs:selector
        xpath="./epal:user-category"></xs:selector>
      <xs:field
        xpath="@parent"></xs:field>
    </xs:keyref>

    <!-- Key and References for data-category/@id -->
    <xs:key
      name="data-category-identifier">
      <xs:selector
        xpath="./epal:data-category"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:key>

    <xs:keyref
      name="data-category-reference"
      refer="epal:data-category-identifier">
      <xs:selector
        xpath="./epal:data-category"></xs:selector>
      <xs:field
        xpath="@parent"></xs:field>
    </xs:keyref>

    <!-- Key and References for purpose/@id -->
    <xs:key
      name="purpose-identifier">
      <xs:selector
        xpath="./epal:purpose"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:key>

    <xs:keyref
      name="purpose-reference"
      refer="epal:purpose-identifier">
      <xs:selector
        xpath="./epal:purpose"></xs:selector>
      <xs:field
        xpath="@parent"></xs:field>
    </xs:keyref>

    <!-- Declared action id's must be unique -->
    <xs:unique
      name="action-identifier">
      <xs:selector
        xpath="./epal:action"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:unique>

    <!-- Declared container id's must be unique -->
    <xs:unique
      name="container-identifier">
      <xs:selector
        xpath="./epal:container"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:unique>

    <!-- Declared obligation id's must be unique -->
    <xs:unique
      name="obligation-identifier">
      <xs:selector
        xpath="./epal:obligation"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:unique>

  </xs:element>

  <!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
  <!--                                                           -->
  <!-- DECLARATION OF THE <epal-policy> TOPLEVEL ELEMENT         -->
  <!--                                                           -->

  <xs:element
    name="epal-policy">
    <xs:complexType>
      <xs:sequence>
        <xs:element
          name="policy-information"
          minOccurs="1"
          maxOccurs="1"
          type="epal:infoType"></xs:element>
        <xs:element
          name="epal-vocabulary-ref"
          minOccurs="1"
          maxOccurs="1"
          type="epal:importStatementType"/>
        <xs:element
          name="condition"
          minOccurs="0"
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:complexContent>
              <xs:extension
                base="epal:describedObjectType">
                <xs:sequence>
                  <xs:element
                    name="predicate"
                    minOccurs="1"
                    maxOccurs="1"
                    type="epal:functionType"/>
                </xs:sequence>
              </xs:extension>
            </xs:complexContent>
          </xs:complexType>
        </xs:element>

        <xs:element
          name="rule"
          minOccurs="0"
          maxOccurs="unbounded">
          <xs:complexType>
            <xs:complexContent>
              <xs:extension
                base="epal:describedObjectType">
                <xs:sequence>
                  <xs:element
                    name="user-category"
                    type="epal:referringObjectType"
                    minOccurs="1"
                    maxOccurs="unbounded"></xs:element>
                  <xs:element
                    name="data-category"
                    type="epal:referringObjectType"
                    minOccurs="1"
                    maxOccurs="unbounded"></xs:element>
                  <xs:element
                    name="purpose"
                    type="epal:referringObjectType"
                    minOccurs="0"
                    maxOccurs="unbounded"></xs:element>
                  <xs:element
                    name="action"
                    type="epal:referringObjectType"
                    minOccurs="1"
                    maxOccurs="unbounded"></xs:element>
                  <xs:element
                    name="condition"
                    type="epal:referringObjectType"
                    minOccurs="0"
                    maxOccurs="unbounded"></xs:element>
                  <xs:element
                    name="obligation"
                    minOccurs="0"
                    maxOccurs="unbounded">
                    <xs:complexType>
                      <xs:complexContent>
                        <xs:extension
                          base="epal:referringObjectType">
                          <xs:sequence
                            minOccurs="0"
                            maxOccurs="1">
                            <xs:element
                              name="parameter"
                              minOccurs="0"
                              maxOccurs="unbounded">
                              <xs:complexType>
                                <xs:sequence>
                                  <xs:element
                                    name="value"
                                    type="epal:epalSimpleType"
                                    minOccurs="0"
                                    maxOccurs="unbounded"/>
                                </xs:sequence>
                                <xs:attribute
                                  name="refid"
                                  use="required"
                                  type="xs:NCName"></xs:attribute>
                              </xs:complexType>
                            </xs:element>
                          </xs:sequence>
                        </xs:extension>
                      </xs:complexContent>
                    </xs:complexType>
                    <!-- Parameter refid's must be unique within each obligation -->
                    <xs:unique
                      name="uniqueParameter">
                      <xs:selector
                        xpath="./epal:parameter"/>
                      <xs:field
                        xpath="@refid"/>
                    </xs:unique>
                  </xs:element>
                </xs:sequence>
                <xs:attribute
                  name="ruling">
                  <xs:simpleType>
                    <xs:restriction
                      base="xs:string">
                      <xs:enumeration
                        value="allow"/>
                      <xs:enumeration
                        value="deny"/>
                    </xs:restriction>
                  </xs:simpleType>
                </xs:attribute>
              </xs:extension>
            </xs:complexContent>
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute
        name="version"
        type="xs:string"
        default="1.2"/>
      <xs:attribute
        name="global-condition"
        type="xs:NCName"
        use="optional"/>
      <xs:attribute
        name="default-ruling"
        use="required">
        <xs:simpleType>
          <xs:restriction
            base="xs:string">
            <xs:enumeration
              value="allow"/>
            <xs:enumeration
              value="deny"/>
            <xs:enumeration
              value="not-applicable"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>


    <!-- Key and References for condition/@id -->
    <xs:key
      name="condition-identifier">
      <xs:selector
        xpath="./epal:condition"></xs:selector>
      <xs:field
        xpath="@id"></xs:field>
    </xs:key>

    <xs:keyref
      name="condition-reference"
      refer="epal:condition-identifier">
      <xs:selector
        xpath="./epal:rule/epal:condition"></xs:selector>
      <xs:field
        xpath="@refid"></xs:field>
    </xs:keyref>

    <xs:keyref
      name="global-condition-reference"
      refer="epal:condition-identifier">
      <xs:selector
        xpath="."></xs:selector>
      <xs:field
        xpath="@global-condition"></xs:field>
    </xs:keyref>

    <!-- Rule id's must be unique within a policy -->
    <xs:unique
      name="uniqueRuleId">
      <xs:selector
        xpath="./epal:rule"/>
      <xs:field
        xpath="@id"/>
    </xs:unique>

  </xs:element>

 
</xs:schema>

Valid HTML 4.01!