Source: http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/
Timestamp: 2019-04-20 02:59:09
Document Index: 189545360

Matched Legal Cases: ['art 2', 'art 2', 'art 1', 'art 2', 'art 0', 'art 0']

Enterprise Privacy Authorization Language (EPAL 1.2)
W3C Member Submission 10 November 2003
http://www.w3.org/Submission/2003/SUBM-EPAL-20031110/
http://www.w3.org/Submission/EPAL/
EPAL 1.0 published as IBM Research Report RZ 3485 (#93951), 03/03/2003.
Steve Adler, IBM Tivoli Software, adler1 at us.ibm.com
Calvin Powers, IBM Tivoli Software, cspowers at us.ibm.com
Matthias Schunter, IBM Research, mts at zurich.ibm.com
Paul Ashley, IBM Tivoli Software
Satoshi Hada, IBM Research
Günter Karjoth, IBM Research
Calvin Powers, IBM Tivoli Software
Matthias Schunter, IBM Research
Copyright © 2000-2003 International Business Machines Corporation. All Rights Reserved.
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.
By publishing this document, W3C acknowledges that International Business Machines (IBM) has made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership; please consult the complete list of acknowledged W3C Member Submissions.
1.5 Requirements on the Environment using EPAL
1.6 Relation of EPAL to the W3C Platform for Privacy Preferences (P3P)
1.7 Documentation Conventions and Notation
2 EPAL Overview and Example
2.1 Example of EPAL in Use
2.2 UML Overview on the EPAL Syntax
2.3 XML Schema of EPAL
3. EPAL Vocabularies
3.1 <epal-vocabulary> Top-level Element for an EPAL Vocabulary
3.2 <vocabulary-information>: Information about the Policy
3.3 <user-category>: Definition of the User Category Hierarchies
3.4 <data-category>: Definition of the Data Category Hierarchies
3.5 <purpose>: Definition of the Purpose Hierarchies
3.6 <action>: Definition of a Privacy-relevant Action to be Executed on Data
3.7 <container>: Abstract Definition of the Data to be Evaluated by Conditions
3.8 <obligation>: Definition of an Obligation
4. EPAL Policies
4.1 <epal-policy>: Top-level Element for an EPAL Privacy Policy
4.2 <policy-information>: Information about the Policy
4.3 <epal-vocabulary-ref>: Reference to the <epal-vocabulary> file
4.4 <condition>: Definition of Conditions evaluating Container Attributes
4.5 <rule>: Definition of an Authorization Rule
5. Privacy Authorization - Semantics of an EPAL Policy
5.1 Simple Requests
5.2 Compound Requests
6 EPAL Data Types
6.1 "identifiedObjectType": Elements with unique identifiers
6.2 "referringObjectType": Elements with reference identifiers
6.3 "describedObjectType": Extensible Elements with Descriptions
6.4 "hierarchicalType": Identified elements structured in a hierarchy
6.5 "contactInfoType": A sequence of elements for contact information
6.6 "attributeDefinitionType": Schema-like Definition of Multi-valued Attributes
6.7 "containerAttributeDefinitionType": Schema-like Definition of Multi-valued Container Attributes
6.8 "epalSimpleType": Data Types Allowed in Attributes, Parameters, and Properties.
6.9 "infoType": Information about the Policy or Vocabulary
6.10 "importStatementType": Import of a File
6.11 "functionType": EPAL Functions and Predicates
Appendix 1. References (Normative)
Appendix 2. References (Non-Normative)
Appendix 3. Example Authorization Interface
Appendix 3.1 <epal-query> : EPAL Authorization Request
Appendix 3.2 <epal-ruling> : Authorization Result
Appendix 5: EPAL Functions and Predicates
Appendix 5.1 EPAL Functions
Appendix 5.2 EPAL Predicates
Appendix 6. Technological Context of EPAL
Appendix 7. Complete XML Schema for EPAL
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.
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
enable organizations to be demonstrably compliant with their stated policies;
reduce overhead and the cost of configuring and enforcing data handling policies; and
leverage existing standards and technologies.
The goals for the EPAL language are the following.
Provide the ability to encode an enterprise's privacy-related data-handling policies and practices.
A language that can be imported and enforced by a privacy-enforcement systems.
There are certain situations for which EPAL is not intended as an appropriate language. EPAL was not designed for the following applications:
Directly encoding or enforcing specific privacy legislation in a generic and completely application and enterprise independent way.
Manipulation of EPAL by data subjects to set their preferences: E.g., providing information that enables the creation of user-preferences forms based on the information given in an EPAL policy.
Creation of new mechanisms or syntax for data representation: EPAL should abstract from the data model and should not provide it's own syntax for describing schemas for data.
The limitation of features in EPAL for the sake of conformance to the assumptions, data structures, or features of any particular pre-existing product or tool.
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:
EPAL rules must be expressive enough to reflect the complexity of privacy policy.
EPAL rules must be editable to manage the model of the firm's evolving privacy policy.
The processes of rule creation and rule editing should be intuitive.
Conflicting rules are possible, defined as two EPAL rules in the same privacy policy that may return different rulings for some request.
Some mechanism must be available to resolve conflicting rules.
Assumption: Non-technical users will write EPAL with some rule creation/management tool.
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:
There can be no ambiguity in the rules. All of the elements and rules must be clearly defined so that there is no confusion in the meaning of terms.
All extensions to the language must be carefully considered so that interoperability is still possible even when using extensions.
EPAL must be independent of actual products. In particular, it must not require a specific data model or format in which the collected data is stored.
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.
Rules must consist of abstract types of objects, and not the actual instances of objects. A mapping from the types to the instances is implementation specific, and beyond the scope of EPAL. This makes EPAL deployable in legacy systems.
A set of EPAL rules must be designed to enable software to generate a ruling in real-time from a given request.
The privacy enforcement system must be able to either enforce obligations itself or else distribute obligations to the application that is responsible for enforcing them.
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.
EPAL rules must be designed to enable software to generate a ruling given a request and a set of EPAL rules.
To reduce the cost of the privacy audit, it may be desirable to define the EPAL rules with a "deny" ruling. Together with a default-ruling "allow", any action that is not explicitly denied by an EPAL rule is then allowed by default.
Assumption: Conflicting rules in a set of EPAL rules must first be resolved before performing a privacy audit. This could be a feature of the rule creation and management tool.
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.
The user may specify a default ruling of "allow" or "deny" and may have no default ruling.
Each rule can allow a set of user categories to perform an action in a set of action on a category in a set of category for any purpose in a set of purposes.
Each rule may contain conditions that must be true for the rule to be active.
Each rule may specify obligations that must be performed if the action is performed.
Conflicts may be resolved by assigning precedence.
The author of EPAL must be provided with some flexible means of including comments, parameters, and unforeseen additional information.
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.
The EPAL elements, which constitute a rule, are abstract types. These types are mapped to actual instances of elements during implementation. Not only does this simplify EPAL, but it also ensures that EPAL is deployable in all existing and legacy environments. This implies the following special cases:
EPAL does not define how users are authenticated.
EPAL does not define how privacy-categories and policies are associated with collected data.
EPAL does not define how enterprise activities are mapped onto purposes and privacy-relevant actions.
EPAL does not define how data needed for evaluating conditions is stored.
EPAL does not define how obligations are implemented.
It must be feasible to generate a ruling for a given request from a large set of rules in real-time. Examples of rulings include "allow", "deny", and "not-applicable". The processing of rules and the generation of a ruling is implementation-dependent.
1.4.3 Language Requirements
Since EPAL is intended to be an interoperability language, the syntax must satisfy the following requirements.
The syntax of EPAL must be consistent with widely accepted computer-readable languages to foster simple parsing.
An EPAL-encoded privacy policy should be intuitively understood, not rendered incomprehensible by the syntax or terminology.
EPAL must be extensible to accommodate future changes while supporting backwards compatibility whenever possible.
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
The environment must be able to identify the policy and data-categories that govern a particular protected resource that can be accessed.
Note that EPAL only defines how each data-category is handled. Without this additional information how an actual piece of collected data has been categorized, an EPAL policy cannot be used to evaluate whether collected data is handled in a privacy-friendly way.
The environment must know the elements used in the policy. This includes:
How to reliably authenticate each user-category of the policy.
How to correctly map the current activity onto a purpose and privacy-relevant operation of the policy.
The environment must provide the context data to be input to the EPAL evaluation engine from the actual data-model of the enterprise.
If the context contains choices, this requires being able to identify the data subject (i.e., the individual that provided the data) and retrieve the corresponding opt-in and -out choices.
The environment must provide implementations for all obligations of the policy.
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.
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.
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.
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
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.
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.
As in introduction to EPAL, let us consider one common scenario that makes use of EPAL.
A company BestShoesRUs sells shoes to consumers:
The shoes are sold through stores throughout North America and Asia (thirty of them),
Through a mail catalog that is mailed out to subscribers,
Via a 1-800 type phone service (24 hours a day), and
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:
Notice: The policy is clearly articulated for the customers. This means publishing a privacy notice (e.g. text and P3P) on the BestShoesRUs web site, ensuring that all marketing material and the mail catalog describes the policy in text, and that when the phone sales people are collecting PII data that they make sure the customer is aware of the policy.
Consent: The consent choices that are defined by the EPAL policy can be presented to the customer. The customer can review and update the given consent. For example, the customer should be able to make selections on whether they want to receive email, postal mail or phone calls from BestShoesRUs or decide to opt-out of marketing altogether. These consents must be available via the catalog forms, web, phone and the stores.
Enforcement: At all places in the infrastructure where PII data is collected or used, procedures and software must be in place to enforce the EPAL policy.
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.
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
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".
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
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.
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:
One <vocabulary-information> element of type "infoType" that describes the vocabulary.
Zero or more <user-category> elements that define the user categories of the vocabulary.
Zero or more <data-category> elements that define the data categories of the vocabulary.
Zero or more <purpose> elements that define the purposes of the vocabulary.
Zero or more <action> elements that define the privacy-relevant actions of the vocabulary.
Zero or more <container> elements that define external context data that can be evaluated by conditions.
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:
It enables to fix a vocabulary (and the corresponding deployment) while allowing flexibility in the rules.
It enables compact rules that only reference the elements in the vocabulary.
It enables verbose definitions that contain additional information such as human-readable explanations.
It enables an authorization engine to verify that it is able to interpret a policy by only looking at the vocabularies.
It enables a separation of the stable parts (vocabularies) from the more volatile and customizable parts (rules).
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.
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.
<xs:element name="epal-vocabulary">
<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"
<xs:element name="container" minOccurs="0"
maxOccurs="unbounded">...</xs:element>
<xs:element name="obligation" minOccurs="0"
<xs:attribute name="version" type="xs:string" default="1.2"/>
Example: Structure of a <epal-vocabulary> element and its sub-elements
<epal-vocabulary version="1.2" xmlns="http://www.research.ibm.com/privacy/epal"
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>
<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">
<property id="NCName">
</user-category>
<data-category id="NCName" parent="NCName">
</data-category>
<purpose id="NCName" parent="NCName">
<action id="NCName">
<container id="NCName">
<attribute auditable="true" id="NCName" maxOccurs="1" minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
<obligation id="NCName">
<parameter id="NCName" maxOccurs="1" minOccurs="1"
</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>
<!-- Entity issuing the policy -->
<name>EPAL Working Group</name>
<e-mail>testmail@zurich.ibm.com</e-mail>
<address>Saumerstr. 4, 8838 Ruschlikon</address>
<!-- Policy version. This is so the enterprise
can track versions of its policy. -->
<version-info
start-date="2002-03-19T00:00:00"
last-modified="2002-03-19T00:00:00"
revision-number="1.02A"
end-date="2004-03-19T00:00:00"/>
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.
User categories represent categories of users that are distinct from a privacy perspective.
EPAL requires a user-category for all authorization queries. Therefore, vocabulary authors should always define a user category like "anyOther" that covers all user categories that are not explicitly defined by this vocabulary.
Unlike for 'user-categories', 'allow'-rules in a role hierarchy inherit up instead of down (i.e., unlike groups, parent-roles get more powerful).
If (dynamic) roles are needed, these can either be implemented as a condition that restricts access to certain parties or else by dynamically assigning user-categories to actual users at run-time. In the first case, the condition under which a role is assigned would be explicit in the policy. In the second, it would not be visible. E.g., restricting access to a patient's primary care physician can either be done by a condition that allows the user-category "medical-personnel" to access a record if and only if the user-id of the user-category equals the physician-id stored in the patient's record. Else, the policy defines a dynamic role "primary-care-physician" where the dynamic role needs to be implemented elsewhere.
Note that most policies should include a distinguished user-category called 'data-subject' that represents the data subject who's personal data has been collected. This user-category can then be used to define the access rights of the individual, e.g., whether the individual can read and/or update its data.
The algorithm for processing compound requests uses the sequence of the <user-categories> as precedence to resolve non-determinism: If a user can act as user-category "marketing-manager" and as "marketing-department" and is allowed to perform the actions/purposes on category, the first user-category "marketing-manager" would be used to determine the obligations. In addition, for compound requests, a user-category that is not allowed to perform the actions/purposes is not considered.
name="user-category"
type="epal:hierarchicalType">
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>.
EPAL does not deal with the actual data that is collected. Instead, it uses <data-category> to represent and categorize the data to be accessed. The granularity of the categories is determined by the enterprise.
If actual instances of the data are needed to be evaluated by conditions, they must be defined separately as an data structure called the EPAL container.
The system using EPAL is required to be able to determine the applicable policy as well as the applicable <data-category> for any protected resource. This can, e.g., be done by assigning a <data-category> to each column of a relational data-base while storing an identifier of the applicable policy with each customer-record.
If multiple categories apply to a certain resource, this is covered by rules and/or requests containing multiple categories.
EPAL requires a data-category for all authorization queries. Therefore, vocabulary authors should always define a data category like "otherData" that covers all data that is not explicitly defined by this vocabulary.
name="data-category"
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.
Unlike access control, the <purpose> is part of an EPAL authorization query. Without knowing the purpose of an access, authorization cannot be decided.
As a consequence, any system using EPAL must be able to determine a purpose before asking the EPAL engine to evaluate a given policy.
How to determine the purpose depends on the application. Privacy-aware applications may even state their current purpose or an activity identifier that can be used to easily derive it.
Vocabulary authors should always define a purpose "otherPurpose" that covers all purposes that are not explicitly defined by this vocabulary.
type="epal:hierarchicalType"
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.
Like <data-category>, these privacy-relevant actions abstract from the actual operation on the data. E.g., a file access as well as an SQL query may translate into a <action id="read"/> action. An actual application of EPAL needs to map its own terminology to the privacy-policy-specific one by means of a deployment mapping.
Vocabulary authors should define an action "otherAction" that covers all actions that are not explicitly defined by a vocabulary.
type="epal:describedObjectType"
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.
Auditable attributes are intended for consent choices of the data subject (e.g., opt-in to third-party marketing). An enterprise should collect and record consent to an EPAL policy and its auditable attributes. This should be done such that an enterprise can determine the privacy agreement (i.e., policy and auditable attributes) for any fixed time and data subject.
Note that preparing the container to be input is done by the system using EPAL. In the XML-based interface, the context data is part of the authorization request interface. In a Java-based interface, it may be provided by a call-back interface on request.
Note that containers are mainly a tool for efficiency. In principle, a single container with all required context attributes would be sufficient. Grouping attributes into containers should roughly reflect the cost for fetching the attributes, i.e., the costs for fetching attributes in the same container will usually be less than fetching attributes in different containers. The grouping of attributes was inspired by information services that sell information in containers. E.g., buying a credit-rating will deliver a container containing additional information (such as name, age) virtually 'for free'. As a consequence, conditions should try to minimize the number of containers they evaluate. A particular example is that if an enterprise needs a credit-rating (and the provider always includes the, then a condition should rather use the birth-date from the credit-rating container instead of requiring another 'customer-record' container that needs to be fetched as well.
In some cases, the available containers depend on the data that is accessed. E.g., a container with 'birthdate' may only be available when accessing a customer record. As a consequence, a condition evaluating birthdate can only be associated with rules defining access to "customer record". Ensuring such consistency between the policy and its environment is out of the scope of EPAL. Whenever an EPAL implementation needs a context that is not available, it returns an error.
base="epal:describedObjectType">
type="epal:containerAttributeDefinitionType"
</xs:element><
<!-- Declared attribute id's must be unique within each container -->
name="uniqueAttribute">
xpath="attribute"/>
xpath="@id"/>
Example: Two Containers
id="DataUserInfo">
<short-description>Information about the user category</short-description>
<long-description>More Infos.</long-description>
id="DataUserID"
The ID of the user category accessing the data.</short-description>
id="WorkingOnStations"
<short-description>A multi-valued attribute describing the
stations on which the nurse is allowed to work.</short-description>
id="PatientRecord">
<short-description>The record of the patient who's data is accessed.</short-description>
id="Station"
stations on which the patient resides.</short-description>
id="PrimaryCarePhysicianID"
<short-description>A multi-value input defining the IDs of
all primary care physicians of this patient.</short-description>
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.
Like <data-category>, obligations abstract from the details.
An opaque obligation "retention" with a parameter <days> 30</days> may be used to signal that data shall be deleted after 30 days. Note that the actual implementation of the obligation needs additional inputs (such as the actual data-instance that is accessed). These parameters are not passed through the EPAL engine, i.e., the environment will be required to input additional context into the implementation of the obligations.
We assume that obligations do not interfere with each other. If a rule returns multiple obligations, we assume that it is possible to enforce them all.
type="epal:attributeDefinitionType"
<!-- Declared parameter id's must be unique within each obligation -->
name="uniqueParam">
xpath="parameter"/>
Example: An Obligation
id="retention">
<short-description>A test obligation</short-description>
<long-description>long-description</long-description>
id="Name">
<value>property</value>
simpleType="http://www.w3.org/2001/XMLSchema#integer"
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.
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:
One <policy-information> element of type "infoType" that describes the policy.
One <epal-vocabulary-ref> element of type "importStatementType" that refers to the <epal-vocabulary> to be used.
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.
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.
The default ruling 'not-applicable' allows a policy to implement a 'don't care'. This can simplify combining different policies where each policy only covers a given scope while 'not caring' about other authorizations.
The global condition is a means to select the right policy out of a set of policies that may are applicable.
<xs:element name="epal-policy">
<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"
<xs:element name="rule" minOccurs="0"
<xs:attribute name="global-condition" type="xs:NCName"
<xs:attribute name="default-ruling" use="required">
<xs:enumeration value="not-applicable"/>
Example: An <epal-policy>
<epal-policy default-ruling="allow" global-condition="NCName"
version="1.2" xmlns="http://www.research.ibm.com/privacy/epal"
<policy-information id="NCName">
<epal-vocabulary-ref id="NCName" location="http://www.ibm.com"
revision-number="NCName"/>
<condition id="NCName">...</condition>
<rule id="NCName" ruling="allow">
<user-category refid="NCName"/>
<data-category refid="NCName"/>
<purpose refid="NCName"/>
<action refid="NCName"/>
<condition refid="NCName"/>
<obligation refid="NCName">
<parameter refid="NCName">
</epal-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
<short-description
language="en">Example policy information</short-description>
<e-mail>testid@zurich.ibm.com</e-mail>
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".
"location" a mandatory attribute of type "anyURI" that points to the vocabulary file to be used.
"id" an optional attribute of type "NCName" that signals the expected "id" of the imported vocabulary (the name is stored at vocabulary-information/@id).
"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).
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'.
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:
Each <attribute-reference> element is evaluated to an <attribute-bag> element representing the values of the container attribute identified by the "container-refid" and "attribute-refid" attributes. Note that the actual values must be avalable in the input container instance. The resulting bag of attribute values should be validated against the corresponding definition of the container attribute.
Each <condition-reference> is evaluated to an <attribute-value> element representing the boolean result of the referenced condition. The value of the "simpleType" attribute is http://www.w3.org/2001/XMLSchema#boolean.
Each <predicate> is evaluated to an <attribute-value> element representing the boolean result of the predicate. The value of the "simpleType" attribute is http://www.w3.org/2001/XMLSchema#boolean.
Each <function> is evaluated to an <attribute-value> or <attribute-bag> element representing the evaluation result of the function. Which element it is evaluated to depends on the semantics of the function.
Note that the evaluation of a predicate and a function is recursive because they can take predicates and functions as the arguments.
Multiple conditions in a rule are satisfied if all conditions are satisfied (Boolean AND).
<condition-reference> elements allow policy authors to reuse other conditions to define a new condition.
name="predicate"
type="epal:functionType"
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">
refid="http://www.research.ibm.com/privacy/epal#string-equal">
refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
<attribute-reference
container-refid="DataUserInfo"
attribute-refid="DataUserID"/>
<attribute-value
simpleType="http://www.w3.org/2001/XMLSchema#string">John Doe</attribute-value>
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">
refid="http://www.research.ibm.com/privacy/epal#string-is-in">
<attribute-bag simpleType="http://www.w3.org/2001/XMLSchema#string">
<value>John Doe2</value>
<value>John Doe3</value>
</attribute-bag>
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>
refid="http://www.research.ibm.com/privacy/epal#string-at-least-one-value-equal">
attribute-refid="WorkingOnStations"/>
container-refid="PatientRecord"
attribute-refid="Station"/>
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">
refid="http://www.research.ibm.com/privacy/epal#and">
<condition-reference
refid="condition1"/>
refid="condition3"/>
The following example uses a <condition-reference> element to reference the above "condition1" condition and create a new condition ("condition5").
<condition id="condition5">
simpleType="http://www.w3.org/2001/XMLSchema#string">SW4</attribute-value>
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:
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.
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.
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.
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.
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.
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.
The descending precedence can be used to implement exceptions to subsequent rules. E.g., a rule allowing a particular employee to access some data can be prepended to a rule that disallows the employee's complete department from accessing the data.
For any parameter with id1 inside an obligation with id2 there must be a corresponding parameter declared in the definition of obligation id2. More generally, a rule can only use obligations that are declared. Each actual parameter in an obligation in a rule must comply with the parameter specifications for this particular type of obligation.
The rules in a policy are ordered by precedence. The first rule has highest precedence; the last the lowest.
Subsequent rules on sub-elements of an applicable rule are ignored. As a consequence, exception rules must always precede the general rule. E.g., if sub- category "personal/email" shall be allowed while all other sub-categories of "personal" shall be denied this is formalized by a higher-precedence (=earlier) allow rule on "personal/email" followed by a general deny-rule on "personal".
The order of elements of the same type inside a rule is not relevant.
<xs:extension base="epal:describedObjectType">
<xs:element name="user-category"
type="epal:referringObjectType"
<xs:element name="data-category"
<xs:element name="purpose"
<xs:element name="action"
base="epal:referringObjectType">
<xs:sequence minOccurs="0"
type="epal:epalSimpleType"
<xs:attribute name="refid"
type="xs:NCName"></xs:attribute>
<xs:attribute name="ruling">
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.
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.1 Required Inputs
A simple authorization request contains
a single user-category U that is defined in the vocabulary,
a single data-category T that is defined in the vocabulary,
a single purpose P that is defined in the vocabulary,
a single action A that is defined in the vocabulary, and
the container instance required by this policy that must be valid against the container definition.
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
A ruling that is either "allow", "deny", or "not-applicable".
A single rule "id" that mandated this ruling (or the empty string if the ruling was the default ruling).
The set of obligations specified in the rule.
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:
Are the elements of the authorization request in the scope of this rule?
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
The data-category "id" in the request is either identical to the "id" of one of the data-categories in the rule or else identical to the "id" of a child of a data-category in the rule, and
The user-category "id" in the request is either identical to the "id" of one of the user-categories in the rule or else identical to the "id" of a child of a user-category in the rule, and
The purpose "id" in the request is either identical to the "id" of one of the purposes in the rule or else identical to the "id" of a child of a purpose in the rule, and
The action "id" in the request is identical to the "id" of one of the actions in the rule.
A request is in the scope of a rule where the "ruling" attribute is "deny" iff
The data-category "id" in the request is either identical to the "id" of one of the data-categories in the rule or else identical to the "id" of a child or parent of a data-category in the rule, and.
The user-category "id" in the request is either identical to the "id" of one of the user-categories in the rule or else identical to the "id" of a child or parent of a user-category in the rule, and.
The purpose "id" in the request is either identical to the "id" of one of the purposes in the rule or else identical to the "id" of a child or parent of a purpose in the rule, and.
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.
Note that subsequent rules that are more specific than a given rule are ignored. E.g., a deny-rule on category "personal/email" that is written after an otherwise identical allow-rule on category "personal" will always be ignored.
Note that the different semantics of 'allow' and 'deny' is only relevant if a request contains a non-leaf node of a hierarchy. The reason is the meaning of a request to a parent node: If a request asks for accessing a parent (e.g., a data-category customer record' that is a parent to 'name' and 'email') the intuitive meaning is "Can I access all data inside this customer record [under given conditions]?". As a consequence, if access to a single part (e.g., 'email') is not allowed, the request must be denied. Even though if a part 'email' can be accessed, this does not imply that the whole record can be accessed. Implementation-wise, this desired behavior corresponds to the fact that 'allow' inherits down while 'deny' inherits down and up.
Upward inheritance of 'deny'-rules enables us to process authorization queries containing non-leaf elements. If one would only allow leafs of the hierarchy in the authorization request, up-inheritance would no longer be needed.
Note that if a rule has multiple elements multiple types, it allows/denies all combinations of elements similar to P3P statements. E.g., if a rule allows actions (read, write) for purpose (sale, marketing), it allows any combination (i.e., read/sale, read/marketing, write/sale, write/marketing). The benefit of multiple elements is that it enables more compact policies.
The parameter of the obligation is included such that the policy can define options of the obligation. E.g., retention-time for a "limited-retention" obligation.
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
a non-empty set of user-categories U,
a non-empty set of data-categories T,
a non-empty set of purposes P,
a non-empty set of actions A, and
a container provider as defined above
5.2.2 Desired Outputs
A set of rule "id"s that mandated this ruling (or the empty set if the ruling was the default ruling).
A set of pairs (obligation, rule-id-set) with disjoint obligations (obligations with different parameters are considered to be disjoint) and a list of rule-"id"s that mandated this particular obligation.
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:
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.
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:
If all rulings are 'not-applicable', the ruling is 'not-applicable' with an empty rule-id-set.
Else, if at least one ruling is 'allow' and no ruling is 'deny', the algorithm returns "allow", the allowRules rule-id-set, and the allowObligations set.
Else, (if there is one or more 'deny' rulings), the algorithm returns 'deny', the denyRules rule-id-set, and the denyObligations.
Processing Multiple user categories: Multiple user categories are processed in the order that they are defined inside the vocabulary of the policy:
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.
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.
Else, return the 'not-applicable' ruling with an empty rule-id-set.
If multiple user-categories in the set result in a ruling "allow" or "deny", the algorithm must choose the user category that is the topmost among these user categories inside the vocabulary of the policy. This user category is then used to determine the set of returned obligations and the set of applied rules.
Any algorithm implementing compound requests is free to do this without actual decomposition into simple requests as long as the behavior is preserved.
All simple requests are processed using the same containers, i.e., one assumes that data of the user-category, object, or any other data in the containers is valid for all elements in the compound request.
Note that processing of compound requests does not use precedence to resolve conflicts. i.e., a lowest-level 'deny' on any combination of elements can overrule any highest-level 'allow'.
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.
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.
<!-- Elements which have an identifier should be of this type -->
name="identifiedObjectType">
type="xs:NCName"
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.
<!-- Elements which refer to an identifier should be of this type -->
name="referringObjectType">
name="refid"
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.
<!-- Identified Elements which have descriptions should be of this type -->
<xs:complexType name="describedObjectType">
<xs:extension base="epal:identifiedObjectType">
<xs:element name="short-description" minOccurs="0"
<xs:attribute name="language" use="optional"
default="en" type="xs:language"></xs:attribute>
<xs:element name="long-description"
<xs:element name="value" type="epal:epalSimpleType"
<xs:attribute name="id" use="required"
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.
<!-- Elements which can participate in a hierarchy should have this type -->
name="hierarchicalType">
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.
<!-- Contact information   -->
name="contactInfoType">
maxOccurs="1"></xs:element>
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'.
<!-- A Descriptor of an attribute -->
name="attributeDefinitionType">
name="simpleType" use="required" type="epal:epalSimpleTypeURI"/>
name="minOccurs"
name="maxOccurs"
memberTypes="xs:nonNegativeInteger">
value="unbounded"/>
<xs:simpleType name="epalSimpleTypeURI">
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"/>
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).
<xs:complexType name="containerAttributeDefinitionType">
<xs:extension base="epal:attributeDefinitionType">
<xs:attribute name="auditable" use="optional"
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.
name="epalSimpleType">
memberTypes="xs:string xs:boolean xs:integer xs:double xs:time xs:date
xs:dateTime xs:anyURI xs:hexBinary xs:base64Binary"/>
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:
The optional <issuer> of type "contactInfoType" contains the contact information of the issuer.
The optional <location> element of type "anyURI" points to the location in which the policy or vocabulary is stored.
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.
<xs:element name="issuer" minOccurs="0"
type="epal:contactInfoType"></xs:element>
type="xs:anyURI"></xs:element>
<xs:element name="version-info" minOccurs="1"
<xs:attribute name="test" type="xs:boolean"
<xs:attribute name="start-date"
use="required"></xs:attribute>
<xs:attribute name="revision-number"
<xs:attribute name="last-modified"
<xs:attribute name="end-date"
<xs:attribute name="superseded-by-id"
<xs:attribute name="superseded-by-revision-number"
This type defines the syntax for importing a file (e.g., an EPAL vocabulary file). It contains the following attributes.
"location" a mandatory attribute of type "anyURI" that points to the file to be imported
"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).
"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.
<xs:complexType name="importStatementType">
<xs:attribute name="location" use="required"
type="xs:anyURI"></xs:attribute>
<xs:attribute name="revision-number" use="optional"
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.
A <predicate> of type "functionType" represents a boolean function, i.e., a function that returns a boolean value.
A <function> of type "functionType" represents a non-boolean function.
A <condition-reference> element represents a reference to a particular condition specified by the mandatory attribute "refid".
name="functionType">
name="attribute-value"
base="epal:epalSimpleType">
name="simpleType"
type="epal:epalSimpleTypeURI"/>
name="attribute-bag"
name="attribute-reference"
name="container-refid"
type="xs:NCName"/>
name="attribute-refid"
name="condition-reference"
Example: An EPAL predicate
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/
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/
World Wide Web Consortium. Extensible Markup Language (XML) 1.0, Second Edition. Available at: http://www.w3.org/TR/2000/WD-xml-2e-20000814
World Wide Web Consortium. XML Schema Part 1: Structures. Available at: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
World Wide Web Consortium. XML Schema Part 2: Datatypes. Available at: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
World Wide Web Consortium. XML Schema Requirements. Available at: http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215
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/
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/
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
Didier Martin, et al. Professional XML. Wrox Press Ltd., January 2000.
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".
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.
The interface of this specific implementation defines that the container instance needs to be provided up front. More optimized implementations may retrieve the container on demand by means of a call-back interface. This improves the efficiency in particular if multiple different containers have been defined.
If there is only one container, inputting the data may be preferable. Nevertheless, even in this case, the effort to retrieve and compose the container instance may be wasted if the policy does not contain any applicable rules with conditions.
name="epal-query">
<!-- The user category accessing the data-->
<!-- The category of the accessed data -->
<!-- The stated purpose of the access -->
<!-- The stated operation of the access -->
<!-- The list of XML container instances each corresponding to
a container definition. -->
<xs:attribute name="refid" use="required"
Example: An EPAL Authorization Query
<epal-query
xmlns="http://www.research.ibm.com/privacy/epal/interface"
xmlns:epal="http://www.research.ibm.com/privacy/epal"
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">
</epal-query>
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.
Note that one needs to know the policy in order to be able to interpret this answer.
We require that each obligation with a given ID and given parameter values is only contained once, i.e., all rules that mandated an identical obligation should be collected and output in the list of <originating-rule/> sub-elements of each obligation.
name="epal-ruling">
<!-- The rules that mandated authorized access. -->
name="originating-rule"
type="epal:referringObjectType"/>
<!-- The returned obligations -->
<!-- The rules that mandated this obligation -->
<!-- The XML input for each returned obligation -->
<xs:attribute name="simpleType" use="required"
<xs:attribute name="refid" use="required" type="xs:NCName"/>
name="ruling">
Example: An Authorization Answer
<epal-ruling ruling="allow"
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">
<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>
</epal-ruling>
The action being performed in a rule or a request.
A user category, action, data category, or purpose element.
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.
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.
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.
The condition that indicates when a rule applies. A condition is evaluated on multiple containers.
The container that contains context data represented by a set of attributes.
The data on which the action is being performed in a rule.
The owner whose data is collected and accessed.
An individual, group, organization, or agent performing the action in a rule.
A namespace is a collection of names, identified by a URI reference, which are used in XML documents as element types and attribute names.
A namespace prefix is an alias defined in the namespace declaration.
One or more actions in a rule that must be performed if the action is performed.
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.
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.
The reason that the action is being performed in a rule.
A qualified name has a namespace prefix attached to the name, separated by a colon.
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.
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.
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.
A XML schema that defines the syntax of an XML document.
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.
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.
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.
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 conforms to the basic syntax rules of XML, but there are no other syntactic guarantees.
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.
This appendix specifies the functions and predicates used by EPAL. Every function and predicate is uniquely addressed via a URI Reference constructed as follows:
The base URI is the URI of the EPAL namespace, i.e., http://www.research.ibm.com/privacy/epal.
The fragment identifier is the name of the function/predicate.
For example, to reference the "string-equal" predicate, the URI is:
http://www.research.ibm.com/privacy/epal#string-equal
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.
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.
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.
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.
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.
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
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
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
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].
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
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
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 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.
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.
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!-- 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      -->
targetNamespace="http://www.research.ibm.com/privacy/epal"
version="b">
<!-- DECLARATION OF REUSABLE TYPES                         -->
<!-- Types needed often are declared here.                 -->
name="describedObjectType">
base="epal:identifiedObjectType">
name="short-description"
default="en"
type="xs:language"></xs:attribute>
name="long-description"
<!-- A Descriptor of a container attribute -->
name="containerAttributeDefinitionType">
base="epal:attributeDefinitionType">
name="auditable"
<!-- Allowed EPAL data types -->
name="epalSimpleTypeURI">
value="http://www.w3.org/2001/XMLSchema#string"/>
value="http://www.w3.org/2001/XMLSchema#boolean"/>
value="http://www.w3.org/2001/XMLSchema#double"/>
value="http://www.w3.org/2001/XMLSchema#time"/>
value="http://www.w3.org/2001/XMLSchema#date"/>
value="http://www.w3.org/2001/XMLSchema#dateTime"/>
value="http://www.w3.org/2001/XMLSchema#integer"/>
<!-- Four data types (dayTimeDuration, yearMonthDuration, x500Name, and
rfc822Name) are ignored since there are no corresponding simple types.-->
<!-- Information on a policy or a vocabulary -->
name="infoType">
name="issuer"
name="version-info"
name="revision-number"
name="last-modified"
name="end-date"
name="superseded-by-id"
name="superseded-by-revision"
<!-- Importing policies and vocabularies -->
name="importStatementType">
<!-- Elements for EPAL functions and predicates -->
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
<!--                                                           -->
<!-- DECLARATION OF THE <epal-vocabulary> TOPLEVEL ELEMENT     -->
name="epal-vocabulary">
name="vocabulary-information"
type="epal:infoType"></xs:element>
type="epal:hierarchicalType"></xs:element>
name="uniqueAttributeDef">
xpath="./epal:attribute"/>
name="uniqueParamDef">
xpath="./epal:parameter"/>
default="1.2"/>
<!-- Key and References for user-category/@id -->
name="user-category-identifier">
xpath="./epal:user-category"></xs:selector>
xpath="@id"></xs:field>
name="user-category-reference"
refer="epal:user-category-identifier">
xpath="@parent"></xs:field>
<!-- Key and References for data-category/@id -->
name="data-category-identifier">
xpath="./epal:data-category"></xs:selector>
name="data-category-reference"
refer="epal:data-category-identifier">
<!-- Key and References for purpose/@id -->
name="purpose-identifier">
xpath="./epal:purpose"></xs:selector>
name="purpose-reference"
refer="epal:purpose-identifier">
<!-- Declared action id's must be unique -->
name="action-identifier">
xpath="./epal:action"></xs:selector>
<!-- Declared container id's must be unique -->
name="container-identifier">
xpath="./epal:container"></xs:selector>
<!-- Declared obligation id's must be unique -->
name="obligation-identifier">
xpath="./epal:obligation"></xs:selector>
<!-- DECLARATION OF THE <epal-policy> TOPLEVEL ELEMENT         -->
name="epal-policy">
name="policy-information"
name="epal-vocabulary-ref"
type="epal:importStatementType"/>
type="epal:functionType"/>
<!-- Parameter refid's must be unique within each obligation -->
name="uniqueParameter">
xpath="@refid"/>
value="deny"/>
name="global-condition"
name="default-ruling"
value="not-applicable"/>
<!-- Key and References for condition/@id -->
name="condition-identifier">
xpath="./epal:condition"></xs:selector>
refer="epal:condition-identifier">
xpath="./epal:rule/epal:condition"></xs:selector>
xpath="@refid"></xs:field>
name="global-condition-reference"
xpath="."></xs:selector>
xpath="@global-condition"></xs:field>
<!-- Rule id's must be unique within a policy -->
name="uniqueRuleId">
xpath="./epal:rule"/>