Enterprise Privacy Authorization Language (EPAL 1.2)
IBM Research Report
- Latest public version:
- http://www.zurich.ibm.com/security/enterprise-privacy/epal
- $Id: index.html,v 1.126.2.2 2003/11/14 02:36:20 mts Exp $
- Previous versions:
- 1.126: EPAL Version 1.2
- 1.83: EPAL Version 1.1
- EPAL 1.0 published as IBM Research Report RZ 3485 (#93951),
03/03/2003.
- Business Contact:
- Steve Adler, IBM Tivoli Software, adler1 at us.ibm.com
- Editors:
- Calvin Powers, IBM Tivoli
Software, cspowers at us.ibm.com
- Matthias Schunter, IBM
Research, mts at zurich.ibm.com
- Authors:
- Paul Ashley, IBM Tivoli
Software
Satoshi Hada, IBM Research
Günter Karjoth, IBM
Research
Calvin Powers, IBM Tivoli Software
Matthias Schunter, IBM Research
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.
Table of Contents
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.
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.
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.
A company has implemented an privacy enforcement system in their
software package. The privacy enforcement system must enforce the given
set of EPAL rules and the obligations that are defined by the policy.
Implications on EPAL requirements:
- 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.
An independent auditor uses EPAL to model a client's privacy policy
and to perform a privacy audit. The client's goal is to have
demonstrated compliance with privacy legislation and recommended
industry-specific practices. Two options exist for performing a privacy
audit. One method is to generate rulings against the EPAL-modeled
privacy policy from run-time requests. These rulings are logged and
subsequently analyzed for requests which violated the privacy policy.
There is no interference with requests during an audit. An alternative
method is completely separate from the client's run-time system. The
auditor also models the requests. Compliance with the EPAL-modeled
privacy policy is measured against simulated requests.
Implications on EPAL requirements:
- 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.
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.
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.
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 |
| action |
store |
| data category |
customer-record |
| purpose |
order-processing |
| condition |
the customer is older than 13 years of age |
| obligation |
delete the data 3 years from now |
Rules are used to determine if a request is allowed or denied. A
request contains a user category, an action, a data category, and a
purpose. Continuing with the same enterprise as above, consider the
following request.
| request (informal) |
A person acting as a sales agent and an employee requests
to collect a customer's email for order entry. |
| user category |
sales department |
| action |
store |
| data category |
customer-record |
| purpose |
order-processing |
The above rule allows the request, so the sales agent would be
permitted to store the customer's contact information. Additional rules
can then govern how this stored data may be used.
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".
Conventional XML namespace prefixes are used throughout the listings
in this specification to stand for their respective namespaces as
follows, whether or not a namespace declaration is present in the
example:
| Prefix |
Namespace URI |
Notes |
| epal |
http://www.research.ibm.com/privacy/epal |
The EPAL namespace defined in this specification |
| xs |
http://www.w3.org/2001/XMLSchema |
The W3C XML Schema namespace |
| xsi |
http://www.w3.org/2001/XMLSchema-instance |
The W3C XML Schema namespace for instances |
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.
Schema Fragment
<xs:element name="epal-vocabulary">
<xs:complexType>
<xs:sequence>
<xs:element name="vocabulary-information"
minOccurs="1" maxOccurs="1" type="epal:infoType"></xs:element>
<xs:element name="user-category" minOccurs="0"
maxOccurs="unbounded">... </xs:element>
<xs:element name="data-category" minOccurs="0"
maxOccurs="unbounded" type="epal:hierarchicalType"></xs:element>
<xs:element name="purpose" type="epal:hierarchicalType" minOccurs="0"
maxOccurs="unbounded"></xs:element>
<xs:element name="action" type="epal:describedObjectType"
maxOccurs="unbounded"></xs:element>
<xs:element name="container" minOccurs="0"
maxOccurs="unbounded">...</xs:element>
<xs:element name="obligation" minOccurs="0"
maxOccurs="unbounded">...</xs:element>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1.2"/>
</xs:complexType>
</xs:element> |
Example: Structure of a
<epal-vocabulary> element and its sub-elements
<epal-vocabulary version="1.2" xmlns="http://www.research.ibm.com/privacy/epal"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.research.ibm.com/privacy/epal epal.xsd
http://www.w3.org/2001/XMLSchema xs-dummy.xsd ">
<vocabulary-information id="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<issuer>
<name>name</name>
<organization>organization</organization>
<e-mail>e-mail</e-mail>
<address>address</address>
<country>country</country>
</issuer>
<location>http://www.ibm.com</location>
<version-info end-date="2001-12-31T12:00:00"
last-modified="2001-12-31T12:00:00"
revision-number="" start-date="2001-12-31T12:00:00" test="false"/>
</vocabulary-information>
<user-category id="NCName" parent="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<property id="NCName">
<value>value</value>
</property>
</user-category>
<data-category id="NCName" parent="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
</data-category>
<purpose id="NCName" parent="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
</purpose>
<action id="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
</action>
<container id="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<attribute auditable="true" id="NCName" maxOccurs="1" minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
</attribute>
</container>
<obligation id="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<parameter id="NCName" maxOccurs="1" minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
</parameter>
</obligation>
</epal-vocabulary> |
The <vocabulary-information> of type "infoType" contains information about
the vocabulary in the form of three sub-elements. The "id"
attribute defines the Name that identifies the vocabulary. The
<issuer> describes the issuer, the <version-info> the
version and other management information. The "id" attribute
of vocabulary-information together with the "revision-number"
attribute must uniquely identify a vocabulary for each issuer.
Example: Vocabulary
Information inside an EPAL vocabulary
<vocabulary-information
id="sample-policy">
<short-description language="en">Example policy information</short-description>
<long-description language="en">long-description</long-description>
<!-- Entity issuing the policy -->
<issuer>
<name>EPAL Working Group</name>
<organization>IBM Research</organization>
<e-mail>testmail@zurich.ibm.com</e-mail>
<address>Saumerstr. 4, 8838 Ruschlikon</address>
<country>Switzerland</country>
</issuer>
<!-- Policy version. This is so the enterprise
can track versions of its policy. -->
<version-info
start-date="2002-03-19T00:00:00"
test="true"
last-modified="2002-03-19T00:00:00"
revision-number="1.02A"
end-date="2004-03-19T00:00:00"/>
</vocabulary-information> |
User categories represent a category of individuals that can access
data. Examples include single employees, particular roles, employee
groups, other enterprises that may receive data, or the data subject
itself (i.e., the owner who's data is collected).
Syntax: Each <user-category> element defines a
user-category that can be referenced in a rule. The user-category
element is of type "hierarchicalType",
i.e., it inherits the mandatory attribute "id", the optional
attribute "parent", and elements <short-description>,
<long-description>, and <property>
Semantics: The list of <user-category> elements
defines the entities accessing the data. A <user-category>
describes an entity accessing some data and can reference its parent.
This includes individuals, groups of individuals, enterprises,
organizations, or software agents. user categories are structured in a
list of hierarchies. The elements are ordered in hierarchies by a
"parent" attribute that contains the value of the
"id" of its parent <user-category>.
For all hierarchical elements (user-category, purpose, data-category),
the graph that is built by using elements as nodes and drawing edges
from child to parent must be one or more trees, i.e., there must not be
any cycles. The meaning of the hierarchy is a grouping, i.e., the parent
groups all its children. An access to a parent is allowed only if access
to all child categories is allowed.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="user-category"
minOccurs="0"
maxOccurs="unbounded"
type="epal:hierarchicalType">
</xs:element> |
The data categories used in privacy policies are often high-level
classifications of data, such as customer contact information, medical
record, or statistics. These categories are used to distinguish
classifications of collected data that need to be treated differently
from a privacy point of view. Organizing the data categories into a
hierarchy improves the expressiveness of rules. For example, a rule that
mentions a high-level data category applies to all parts. This reduces
the number of rules in an EPAL policy.
Syntax: Each <data-category> element defines a
data-category that can be referenced in a rule. The data-category
element is of type "hierarchicalType",
i.e., it inherits the mandatory attribute "id", the optional
attribute "parent", and elements <short-description>,
<long-description>, and <property>.
Semantics: A <data-category> represents some data
of a given data classification. The elements are ordered in one or more
hierarchies by a "parent" attribute that contains the value of
the "id" attribute of its parent <data-category>.
For all hierarchical elements (user-category, purpose, data-category),
the graph that is built by using elements as nodes and drawing edges
from child to parent must be one or more trees, i.e., there must not be
any cycles. The meaning of the hierarchy is a grouping, i.e., the parent
groups all its children. An access to a parent is allowed only if access
to all child categories is allowed.
Design Notes:
- 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.
Schema Fragment:
<xs:element
name="data-category"
minOccurs="0"
maxOccurs="unbounded"
type="epal:hierarchicalType">
</xs:element> |
Purpose is an important concept in privacy. Information is often
disclosed only for particular purposes. Privacy policies must state the
purposes for which data is used or is going to be used. The purposes
mentioned in privacy policies are often high-level, such as marketing.
More specific rules may deal with more specific purposes that fall under
the domain of a high-level purpose, such as direct marketing by a third
party via e-mail. Organizing the purposes into a hierarchy improves the
expressiveness of rules and allows for compact policies.
Syntax: Each <purpose> element defines one
purpose that can be referenced in rule definitions. Each <purpose>
element is of type "hierarchicalType",
i.e., it inherits the mandatory attribute "id", the optional
attribute "parent", and elements <short-description>,
<long-description>, and <property> .
Semantics: A <purpose> represents the purpose
for which a rule authorizes or denies access. The elements are ordered
in one or more hierarchy by a "parent" attribute that contains
the value of the "id" attribute of its prospective parent.
For all hierarchical elements (user-category, purpose, data-category),
the graph that is built by using elements as nodes and drawing edges
from child to parent must be one or more trees, i.e., there must not be
any cycles. The meaning of the hierarchy is a grouping, i.e., the parent
groups all its children. An access to a parent is allowed only if access
to all child categories is allowed.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="purpose"
type="epal:hierarchicalType"
minOccurs="0"
maxOccurs="unbounded">
</xs:element> |
An enterprise performs certain actions on its data resources. A
privacy policy specifies which actions are allowed and which are denied
under particular circumstances.
Syntax: Each <action> element defines one
privacy-relevant action that can be referenced in rule definitions. Each
<action> element is of type "describedObjectType", i.e., it
inherits the mandatory attribute "id", and elements <short-description>,
<long-description>, and<property> .
Semantics: An <action> represents the action
that is authorized. <action> elements are not
structured in a hierarchy.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="action"
type="epal:describedObjectType"
minOccurs="0"
maxOccurs="unbounded">
</xs:element> |
Privacy authorization can depend on conditions based upon the context
of the request. For example, some data may be used for marketing only if
the person is not a minor or a parent has given consent. Each element <container>
defines a data structure that contains context data that can be
evaluated by conditions. Each container defines a list of context
attributes (variables such as 'age', 'name', 'consentToMarketing',
'timeOfDay', ...) that can later be evaluated by conditions. Each <condition> element in EPAL
policies then implements a condition that evaluates such context
attributes. For efficiency reasons, each condition can specify a subset
of the containers that are actually needed to evaluate this condition.
Based on the actual instances of the attributes in these containers, the
condition then returns 'true' or 'false'.
Syntax: Each <container> element extends the
type "describedObjectType",
i.e., it inherits the mandatory attribute "id", and elements <short-description>,
<long-description>, and <property>. This
type is extended by adding a list of one or more <attribute>
elements of type "containerAttributeDefinitionType".
Each of these elements specifies the syntax of an attribute that is
contained in the container by means of attributes
"simpleType", "minOccurs", "maxOccurs",
and "auditable". The Boolean "auditable" indicates
whether this attribute was collected in an auditable way.
Semantics:
A <container> element defines the data structure of
a container. A container is a set of attributes. An attribute
is multi-valued, i.e., an attribute is a bag of values (as specified by
the minOccurs and maxOccurs attributes). The values in a bag are not
ordered, and some of the values may be duplicates.
Note that container instances are used to evaluate conditions.
We require that all the container instances that are needed for condition
evaluation are available at the time of authorization, i.e.,
if a rule is applicable but the container instance needed to evaluate
the condition is missing, this is defined to be an error.
The EPAL authorization engine requires that each attribute value
validates against the attribute specification of the corresponding container.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="container"
minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension
base="epal:describedObjectType">
<xs:sequence
minOccurs="1"
maxOccurs="1">
<xs:element
name="attribute"
type="epal:containerAttributeDefinitionType"
minOccurs="1"
maxOccurs="unbounded">
</xs:element><
/xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Declared attribute id's must be unique within each container -->
<xs:unique
name="uniqueAttribute">
<xs:selector
xpath="attribute"/>
<xs:field
xpath="@id"/>
</xs:unique>
</xs:element> |
Example: Two Containers
<container
id="DataUserInfo">
<short-description>Information about the user category</short-description>
<long-description>More Infos.</long-description>
<attribute
id="DataUserID"
maxOccurs="1"
minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
<short-description>
The ID of the user category accessing the data.</short-description>
</attribute>
<attribute
id="WorkingOnStations"
maxOccurs="unbounded"
minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
<short-description>A multi-valued attribute describing the
stations on which the nurse is allowed to work.</short-description>
</attribute>
</container>
<container
id="PatientRecord">
<short-description>The record of the patient who's data is accessed.</short-description>
<attribute
id="Station"
maxOccurs="unbounded"
minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
<short-description>A multi-valued attribute describing the
stations on which the patient resides.</short-description>
</attribute>
<attribute
id="PrimaryCarePhysicianID"
maxOccurs="unbounded"
minOccurs="1"
simpleType="http://www.w3.org/2001/XMLSchema#string">
<short-description>A multi-value input defining the IDs of
all primary care physicians of this patient.</short-description>
</attribute>
</container> |
Legislation and privacy policies may state that when a certain action
is performed, the enterprise is obligated to take some additional steps.
An example is that all accesses against a certain type of data for a
given purpose must be logged. Or children's data shall be deleted within
30 days unless parent consent is obtained. In EPAL such consequential
actions are called obligations. EPAL is not designed to encode the logic
of an obligation. The system which evaluates a request against an EPAL
policy must be capable of executing all obligations given the unique
name of the obligation.
Syntax: Each <obligation> element defines one
obligation that can be referenced in rule definitions.
<obligation> elements are not structured in a hierarchy.
The <obligation> elements extend the type "describedObjectType", i.e., it
inherits the mandatory attribute "id", and elements <short-description>,
<long-description>, <property> . This type
is extended by a list of <parameter> elements of type
"attributeDefinitionType"
that specify parameter values to be specified inside the rules.
Semantics: An obligation is opaque and is returned after the
rule is processed. An obligation inside a rule can contain values for
its parameters to be returned together with the obligation identifier.
An obligation parameter is multi-valued, i.e., an obligation parameter
is a bag of values. The values in a bag are not ordered, and some of the
values may be duplicates. These parameter values are of types as
specified by the parameter definition. An obligation shall be returned
if the rule was applied (i.e., either no condition was attached or the
attached condition was satisfied). This holds for "allow" as
well as "deny"-rules.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="obligation"
minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension
base="epal:describedObjectType">
<xs:sequence
minOccurs="1"
maxOccurs="unbounded">
<xs:element
name="parameter"
type="epal:attributeDefinitionType"
minOccurs="0"
maxOccurs="unbounded">
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- Declared parameter id's must be unique within each obligation -->
<xs:unique
name="uniqueParam">
<xs:selector
xpath="parameter"/>
<xs:field
xpath="@id"/>
</xs:unique>
</xs:element> |
Example: An Obligation
<obligation
id="retention">
<short-description>A test obligation</short-description>
<long-description>long-description</long-description>
<property
id="Name">
<value>property</value>
</property>
<parameter
id="days"
simpleType="http://www.w3.org/2001/XMLSchema#integer"
minOccurs="1"
maxOccurs="1"/>
</obligation> |
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.
Design Notes:
- 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.
Schema Fragment
<xs:element name="epal-policy">
<xs:complexType>
<xs:sequence>
<xs:element name="policy-information" minOccurs="1"
maxOccurs="1" type="epal:infoType"></xs:element>
<xs:element name="epal-vocabulary-ref" minOccurs="1"
maxOccurs="1" type="epal:importStatementType"/>
<xs:element name="condition" minOccurs="0"
maxOccurs="unbounded">...</xs:element>
<xs:element name="rule" minOccurs="0"
maxOccurs="unbounded">...</xs:element>
</xs:sequence>
<xs:attribute name="version" type="xs:string" default="1.2"/>
<xs:attribute name="global-condition" type="xs:NCName"
use="optional"/>
<xs:attribute name="default-ruling" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="allow"/>
<xs:enumeration value="deny"/>
<xs:enumeration value="not-applicable"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element> |
Example: An <epal-policy>
<epal-policy default-ruling="allow" global-condition="NCName"
version="1.2" xmlns="http://www.research.ibm.com/privacy/epal"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.research.ibm.com/privacy/epal epal.xsd
http://www.w3.org/2001/XMLSchema xs-dummy.xsd ">
<policy-information id="NCName">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<property id="NCName">
<value>value</value>
</property>
<issuer>
<name>name</name>
<organization>organization</organization>
<e-mail>e-mail</e-mail>
<address>address</address>
<country>country</country>
</issuer>
<location>http://www.ibm.com</location>
<version-info end-date="2001-12-31T12:00:00"
last-modified="2001-12-31T12:00:00"
revision-number="" start-date="2001-12-31T12:00:00" test="false"/>
</policy-information>
<epal-vocabulary-ref id="NCName" location="http://www.ibm.com"
revision-number="NCName"/>
<condition id="NCName">...</condition>
<rule id="NCName" ruling="allow">
<short-description language="en">short-description</short-description>
<long-description language="en">long-description</long-description>
<property id="NCName">
<value>value</value>
</property>
<user-category refid="NCName"/>
<data-category refid="NCName"/>
<purpose refid="NCName"/>
<action refid="NCName"/>
<condition refid="NCName"/>
<obligation refid="NCName">
<parameter refid="NCName">
<value>value</value>
</parameter>
</obligation>
</rule>
</epal-policy> |
The <policy-information> of type "infoType" contains information about
the policy in the form of three sub-elements. The "id"
attribute defines the id of the policy. The <issuer>
describes the issuer, the <version-info> the version and
other management information. The "id" attribute of
policy-information together with the "revision-number"
attribute must uniquely identify a policy for each issuer.
Example: Policy Information
inside an EPAL policy
<policy-information
id="sample-policy">
<short-description
language="en">Example policy information</short-description>
<long-description language="en">long-description</long-description>
<!-- Entity issuing the policy -->
<issuer>
<name>EPAL Working Group</name>
<organization>IBM Research</organization>
<e-mail>testid@zurich.ibm.com</e-mail>
<address>Saumerstr. 4, 8838 Ruschlikon</address>
<country>Switzerland</country>
</issuer>
<!-- Policy version. This is so the enterprise
can track versions of its policy. -->
<version-info
start-date="2002-03-19T00:00:00"
test="true"
last-modified="2002-03-19T00:00:00"
revision-number="1.02A"
end-date="2004-03-19T00:00:00"/>
</policy-information> |
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.
Design Notes:
- 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.
Schema Fragment
<xs:element
name="condition"
minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension
base="epal:describedObjectType">
<xs:sequence>
<xs:element
name="predicate"
type="epal:functionType"
minOccurs="1"
maxOccurs="1"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element> |
Example: Conditions Evaluating
the Example Containers in Section 3.7
For example, assume that we have a container named
"DataUserInfo" and a string-type attribute named
"DataUserID" (See Section 3.7
for the definition). Then the condition that the "DataUserID"
attribute value must be equal to "John Doe" is implemented as
follows:
<condition id="condition1">
<predicate
refid="http://www.research.ibm.com/privacy/epal#string-equal">
<function
refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
<attribute-reference
container-refid="DataUserInfo"
attribute-refid="DataUserID"/>
</function>
<attribute-value
simpleType="http://www.w3.org/2001/XMLSchema#string">John Doe</attribute-value>
</predicate>
</condition> |
In this example, the <attribute-reference> element is
used to reference the bag of the "DataUserID" attribute value
in the "DataUserInfo" container, and then the
"string-bag-to-value" function is used to convert the bag into
an attribute value so that we can use the "string-equal"
function to compare the two string values.
Here is another example, where the condition requires that the
"DataUserID" attribute value is equal to one of "John
Doe", "John Doe2", and "John Doe3".
<condition id="condition2">
<predicate
refid="http://www.research.ibm.com/privacy/epal#string-is-in">
<function
refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
<attribute-reference
container-refid="DataUserInfo"
attribute-refid="DataUserID"/>
</function>
<attribute-bag simpleType="http://www.w3.org/2001/XMLSchema#string">
<value>John Doe</value>
<value>John Doe2</value>
<value>John Doe3</value>
</attribute-bag>
</predicate>
</condition> |
The following example compares two bags, which are specified by the
two <attribute-reference> elements. In this example, the
condition requires that at least one attribute value in the
"WorkingOnStations" bag is equal to one of the attribute
values in the "Station" bag.
<condition id="condition3">
<short-description>This condition checks whether a nurse (data user)
is allowed to access patient data.</short-description>
<long-description>This access is only allowed
if the nurse (data user) is working on a station where the
patient resides.</long-description>
<predicate
refid="http://www.research.ibm.com/privacy/epal#string-at-least-one-value-equal">
<attribute-reference
container-refid="DataUserInfo"
attribute-refid="WorkingOnStations"/>
<attribute-reference
container-refid="PatientRecord"
attribute-refid="Station"/>
</predicate>
</condition> |
The following example uses two <condition-reference> elements to reference the above "condition1" and "condition3" conditions and create a new condition ("condition4"), which requires that both "condition1" and "condition3" are satisfied.
<condition id="condition4">
<predicate
refid="http://www.research.ibm.com/privacy/epal#and">
<condition-reference
refid="condition1"/>
<condition-reference
refid="condition3"/>
</predicate>
</condition> |
The following example uses a <condition-reference> element to reference the above "condition1" condition and create a new condition ("condition5").
<condition id="condition5">
<predicate
refid="http://www.research.ibm.com/privacy/epal#and">
<condition-reference
refid="condition1"/>
<predicate
refid="http://www.research.ibm.com/privacy/epal#string-equal">
<function
refid="http://www.research.ibm.com/privacy/epal#string-bag-to-value">
<attribute-reference
container-refid="PatientRecord"
attribute-refid="Station"/>
</function>
<attribute-value
simpleType="http://www.w3.org/2001/XMLSchema#string">SW4</attribute-value>
</predicate>
</predicate>
</condition> |
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.
Design Notes:
- 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.
Schema Fragment
<xs:element name="rule" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="epal:describedObjectType">
<xs:sequence>
<xs:element name="user-category"
type="epal:referringObjectType"
minOccurs="1"
maxOccurs="unbounded"></xs:element>
<xs:element name="data-category"
type="epal:referringObjectType"
minOccurs="1"
maxOccurs="unbounded"></xs:element>
<xs:element name="purpose"
type="epal:referringObjectType"
minOccurs="0"
maxOccurs="unbounded"></xs:element>
<xs:element name="action"
type="epal:referringObjectType"
minOccurs="1"
maxOccurs="unbounded"></xs:element>
<xs:element name="condition"
type="epal:referringObjectType"
minOccurs="0"
maxOccurs="unbounded"></xs:element>
<xs:element name="obligation" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension
base="epal:referringObjectType">
<xs:sequence minOccurs="0"
maxOccurs="1">
<xs:element name="parameter"
minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="value"
type="epal:epalSimpleType"
minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="refid"
use="required"
type="xs:NCName"></xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="ruling">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="allow"/>
<xs:enumeration value="deny"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element> |
We now describe the precise meaning of an EPAL policy. This is done
by a semantics. The goal is to define for any EPAL policy and any
elements (data-category, user-category, action, purpose) whether the
given user-category is allowed to perform the given action for the given
purpose on the given data category. In order to evaluate the conditions,
this requires the container attribute data to be input. In addition to a
plain answer 'allow' or 'deny', the algorithm may output obligations.
If all elements in the request are leafs of the hierarchy (e.g., a
single purpose), the intuition is straightforward: If the algorithm
outputs 'allow', the given user-category is allowed to perform the given
action for the given purpose on the given data category. If non-leaf
elements are used in the query, the semantics is based on a grouping
(logical and). A access request on non-leaf elements is allowed only if
access for these elements as well as their children are allowed.
E.g., a user-category 'department' can only use data if all its
sub-user-category (e.g., sales department and human resources
department) can use the data. Similarity, a purpose 'marketing' is only
allowed if all its sub-purposes are allowed. The rationale is to, e.g.,
allow access to a complete record if and only if all parts of this
record can be accessed.
Note that we do not mandate any particular implementation or
interface to the algorithm. We give an
example interface that uses XML inputs and outputs as an appendix.
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.
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.
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.
- The action "id" in the request is identical to the
"id" of one of the actions in the rule.
If the request is not in the scope of the rule, the next rule is
processed. Else, the algorithm continues processing this rule:
Checking the Conditions: If the rule has no conditions, the
algorithm continues by acting on this rule. If the rule has one or more
conditions, the conditions are evaluated as described in Section 4.4. If any of the conditions is not
satisfied, the algorithm continues by processing the next rule. Else, it
acts on this rule.
Acting on a rule: If the ruling is "allow" or
"deny", the ruling, the rule-id of the rule, and the
obligations of this rule are returned.
Design Notes:
- 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.
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
The algorithm outputs
- A ruling that is either "allow", "deny", or
"not-applicable".
- 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.
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.
Design Notes:
- 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.
Schema Fragment
<!-- Elements which have an identifier should be of this type -->
<xs:complexType
name="identifiedObjectType">
<xs:attribute
name="id"
type="xs:NCName"
use="required">
</xs:attribute>
</xs:complexType> |
Any element of this type has a required attribute "refid"
of type "NCName". This attribute contains an identifier that
references another element that contains the same value in its
"id" attribute. E.g., a user-category inside a rule contains a
refid field that references the id attribute of a user-category inside
the referenced vocabulary.
Schema Fragment
<!-- Elements which refer to an identifier should be of this type -->
<xs:complexType
name="referringObjectType">
<xs:attribute
name="refid"
type="xs:NCName"
use="required">
</xs:attribute>
</xs:complexType> |
The "describedObjectType" extends the "identifiedObjectType". Elements
of this type contain a sequence of zero or more elements <short-description>
of type "string" that is extended by an attribute 'language'
of simple type "language", zero or more elements <long-description>
of type "string" that is extended by an attribute 'language'
of simple type "language", and zero or more elements <property>.
Each <property> element contains <value>
elements with contents of type "epalSimpleType".
We require that for any 'language', there must be at most one <long-description>
and one <short-description> element.
Property elements can be used to extend the EPAL policy language or to
store any external information that is needed by particular
implementations. Examples of properties include implementation hints, or
expressions describing the element in more detail. The "id"
can be used by implementers to retrieve properties that relate to their
particular implementation. In general, the content of the properties is
not standardized. However, standardizing properties can enable a later
extension of EPAL without changing the core standard. This type is
further refined by the "hierarchicalObjectType" and is used in
the EPAL vocabularies to define and describe non-hierarchical elements
of an EPAL policy.
Schema Fragment
<!-- Identified Elements which have descriptions should be of this type -->
<xs:complexType name="describedObjectType">
<xs:complexContent>
<xs:extension base="epal:identifiedObjectType">
<xs:sequence>
<xs:element name="short-description" minOccurs="0"
maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="language" use="optional"
default="en" type="xs:language"></xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="long-description"
minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="language" use="optional"
default="en" type="xs:language"></xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="property" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="value" type="epal:epalSimpleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="id" use="required"
type="xs:NCName"></xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> |
The "hierarchicalType" extends the "describedObjectType" by adding an
optional "parent" attribute with type "NCName". The
parent attribute points to a unique "id" attribute of another
element.
This type is used in EPAL vocabularies to define hierarchical elements
(such as purpose, or user-category) to define and describe the elements
of an EPAL policy while structuring them into a hierarchy.
Schema Fragment
<!-- Elements which can participate in a hierarchy should have this type -->
<xs:complexType
name="hierarchicalType">
<xs:complexContent>
<xs:extension
base="epal:describedObjectType">
<xs:attribute
name="parent"
type="xs:string"
use="optional">
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType> |
An element of type "contactInfoType" contains a sequence of
exactly one of each of the following required elements of type
"string": <name>, <organization>,
<e-mail>, <address>, and <country>
.
This type is used for stating the mandatory address of the issuer of a
policy and for adding an optional address to a user-category of a
policy.
Schema Fragment
<!-- Contact information -->
<xs:complexType
name="contactInfoType">
<xs:sequence>
<xs:element
name="name"
type="xs:string"
minOccurs="1"
maxOccurs="1"></xs:element>
<xs:element
name="organization"
type="xs:string"
minOccurs="1"
maxOccurs="1"></xs:element>
<xs:element
name="e-mail"
type="xs:string"
minOccurs="1"
maxOccurs="1"></xs:element>
<xs:element
name="address"
type="xs:string"
minOccurs="1"
maxOccurs="1"></xs:element>
<xs:element
name="country"
type="xs:string"
minOccurs="1"
maxOccurs="1"></xs:element>
</xs:sequence>
</xs:complexType> |
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.
- http://www.w3.org/2001/XMLSchema#string
- http://www.w3.org/2001/XMLSchema#boolean
- http://www.w3.org/2001/XMLSchema#integer
- http://www.w3.org/2001/XMLSchema#double
- http://www.w3.org/2001/XMLSchema#date
- http://www.w3.org/2001/XMLSchema#time
- http://www.w3.org/2001/XMLSchema#dateTime
The attribute "minOccurs" defines the minimal number of
values that need to occur in a list. The attribute "maxOccurs"
defines the maximal number of values that need to occur in a list.
"maxOccurs" is either of type "nonNegativeInteger"
or else equal the string 'unbounded'.
Schema Fragment
<!-- A Descriptor of an attribute -->
<xs:complexType
name="attributeDefinitionType">
<xs:complexContent>
<xs:extension
base="epal:describedObjectType">
<xs:attribute
name="simpleType" use="required" type="epal:epalSimpleTypeURI"/>
<xs:attribute
name="minOccurs"
type="xs:nonNegativeInteger"
use="optional"
default="1"/>
<xs:attribute
name="maxOccurs"
use="optional"
default="1">
<xs:simpleType>
<xs:union
memberTypes="xs:nonNegativeInteger">
<xs:simpleType>
<xs:restriction
base="xs:string">
<xs:enumeration
value="unbounded"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="epalSimpleTypeURI">
<xs:restriction
base="xs:anyURI">
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#string"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#boolean"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#double"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#time"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#date"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#dateTime"/>
<xs:enumeration value="http://www.w3.org/2001/XMLSchema#integer"/>
</xs:restriction>
</xs:simpleType> |
An element of type "containerAttributeDefinitionType"
extends the "attributeDefinitionType"
by adding an optional attribute "auditable".
The "auditable" attribute is Boolean and defines whether this
particular attribute must be collected in an auditable way. In practice,
this attribute will be used to distinguish consent like "yes to
direct mailings" (auditable) and enterprise-internal context
"time of day" (not required to be auditable).
Schema Fragment
<xs:complexType name="containerAttributeDefinitionType">
<xs:complexContent>
<xs:extension base="epal:attributeDefinitionType">
<xs:attribute name="auditable" use="optional"
type="xs:boolean" default="false"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
|
An element of type "epalSimpleType" contains values of
simple types that can be tunneled through the EPAL engine. These
primitive types are taken from the XML
Schema Part 2 specification as described in Section 6.6.
Schema Fragment
<xs:simpleType
name="epalSimpleType">
<xs:union
memberTypes="xs:string xs:boolean xs:integer xs:double xs:time xs:date
xs:dateTime xs:anyURI xs:hexBinary xs:base64Binary"/>
</xs:simpleType> |
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