Abstract
This document complements the P3P1.0 specification by specifying a
language for describing collections of preferences regarding P3P policies
between P3P agents. Using this language, a user can express her preferences
in a set of preference-rules (called a ruleset), which can then be
used by her user agent to make automated or semi-automated decisions
regarding the acceptability of machine-readable privacy policies from P3P
enabled Web sites.
Status of this Document
This section describes the status of this document at the
time of its publication. Other documents may supersede this
document. The latest status of this document series is maintained
at the W3C.
This is a W3C Working Draft of the P3P Preference Interchange
Language Working Group, for review by W3C members and other
interested parties. This document has been produced as part of the
P3P Activity, and may
eventually be advanced toward W3C Recommendation status.
Being a Working Draft document, this specification may be
updated, replaced, or obsoleted by other documents at
any time. It is therefore inappropriate to use W3C Working Drafts
as reference material or to cite them as other than "work in
progress." A list of current W3C working drafts can be found at
http://www.w3.org/TR/.
This Working Group has considered a number of different
approaches to developing a P3P preference interchange language and
has decided to document one approach and solicit feedback on it.
The group may consider other approaches, including more
general-purpose languages (for example, XML or RDF query
languages). We encourage the development of experimental
implementations and prototypes so as to provide feedback on the
specification. However, this Working Group will not allow early
implementations to affect their ability to make changes to future
versions of this document.
This version of the APPEL language relies on ordered rules. The
Working Group is particulary interested in feedback on how to
improve this mechanism in terms of better supporting merging and
editing of rulesets. Please note that the examples in this draft
document are based on the 4 April 2000
version of the P3P Specification and that such examples might need to be
updated should a revised version of the P3P Specification appear.
This draft document will be considered by W3C and its members
according to W3C process. This document is made public for the
purpose of receiving comments that inform the W3C membership and
staff on issues likely to affect the implementation, acceptance,
and adoption of P3P.
Comments should be sent to
www-p3p-public-comments@w3.org. This is the preferred method of
providing feedback. Public comments and their responses can be
accessed at
http://lists.w3.org/Archives/Public/www-p3p-public-comments/.
Alternatively, if you do not wish your comment to be made public,
you can send your comment to p3p-comments@w3.org. In this
case, your comments will only be accessible to W3C members (at
http://lists.w3.org/Archives/Member/p3p-comments/).
This document specifies a language for describing collections of
preferences regarding P3P policies between P3P agents. Using this
language, a user can express her preferences in a set of
preference-rules (called a ruleset), which can then be used
by her user agent to make automated or semi-automated decisions
regarding the acceptability of machine-readable privacy policies
from P3P enabled Web sites.
Note: This language is intended as a transmission format;
individual implementations must be able to read and write their
specifications in this language, but need not use this format
internally.
This language complements the P3P1.0 specification. Much of the
underlying logic is based on PICSRules. We hope in time
that this will merely be an application of XML (XML-data) rules
or query languages.
P3P is designed to inform users about the privacy policies of
services (web sites and applications that declare privacy
practices). When a P3P compliant client requests a resource, a
service sends a link to a machine-readable privacy policy in which
the organization responsible for the service declares its identity
and privacy practices. The privacy policy enumerates the data
elements that the service proposes to collect and explains how each
will be used, with whom data may be shared, and how long the data
will be retained.
Policies can be parsed automatically by user agents -- such as
web browsers, browser plug-ins, or proxy servers -- and compared
with privacy preferences set by the user. Depending on those
preferences, a user agent may then simply display information for
the user, generate prompts or take other actions.
A basic P3P interaction might proceed as follows:
- The agent requests a Web page from a service.
- The service responds by sending a reference to a P3P
policy in the header of its HTTP response. A policy consists
of one or more statements about a service's privacy
practices.
- The agent fetches the policy, evaluates it according to the
user's ruleset (which represents her
preferences) and determines what action to take (e.g., simply
informing the user about the privacy policy in place, or
prompting her for a decision).
In some implementations, a match between the user's preferences
and a site's policy might authorize electronic wallets and
other data repositories to (semi-) automatically release
information to the service.
The P3P1.0 specification provides a syntax for specifying policies
and a mechansim for associating policies with Web resources. It
does not specify requirements upon the graphical user interface
(GUI) or trust engines. However,
there are benefits associated with being able to express user
preferences as captured by the GUI and processed by the trust
engine:
- Sharing and installation of rulesets. Sophisticated
preferences may be difficult for end-users to specify, even
through well-crafted user interfaces. An organization can create
a set of recommended preferences for users. Users who trust that
organization can install a pre-defined ruleset rather than
specifying a new set from scratch. It will be easy to change the
active ruleset on a single computer, or to carry a ruleset to a
new computer.
- Communication to agents, search engines, proxies, or other
servers. Servers of various kinds may wish to tailor their
output to better meet users' preferences, as expressed in a
ruleset. For example, a search service might return only links
that match a user's ruleset, which may specify criteria based
on a variety of factors including quality, privacy, age
suitability, or the safety of downloadable code.
- Portability between products. The same ruleset will
work with any P3P-APPEL enabled product.
Primarily, we envision this language will be used to allow
users to import preference rulesets created by other parties and to
transport their own rulesets files between multiple user
agents. User agent implementors might also choose to use this
language (or some easily-derived variation) to encode user
preferences for use by the rule evaluators that serve as the
decision-making components of their user agents.
In defining the scope of the APPEL language, the working group
generated a large list of possible requirements. The group then
narrowed the scope to eliminate those requirements that were deemed
less important or easier to implement if handled elsewhere. Thus,
this draft is based on the following requirements:
- APPEL rules should allow the expression of preferences over
anything that can be expressed in the P3P base schema as well as
all other XML metadata relevant to P3P decision making (e.g., is
the communication channel secured). (APPEL rules may express
preferences over PICS labels if they are translated into an
appropriate XML schema.)
- APPEL should address situations in which a service does not
offer a P3P policy.
- APPEL rules should be able to prescribe the following set of
behaviors: accept, reject, inform and warn. In addition, APPEL
should include extensibility mechanisms that allow rules to
describe additional behaviors.
- APPEL encoding should be consistent with other P3P work and
leverage members' existing work and code base. As much as
possible, the encoding should be simple and support the efficient
computation of rule matches.
The working group limited the scope of APPEL as follows:
- APPEL rules need not allow the expression of
"sophisticated" rules based on the presence of multiple
data elements within a P3P policy (for example, a rule that would
allow a zipcode to be collected unless a full name is also
collected).
- APPEL need not be capable of expressing rules for ranking
multiple policies. Rather it expresses the rules necessary for
determining whether a single policy triggers a behavior. If more
than one P3P policy is available, they should be submitted to the
rule evaluator individually. It is up to the calling program to
determine what to do if multiple policies are acceptable, or if a
"prompt" behavior (i.e. inform or warn) is returned
while evaluating multiple policies.
- A compact or easy-to-read representation is not
essential.
- APPEL need not be capable of expressing negotiation
strategies.
- APPEL rules need not be able to express preferences based on
state information (unless such information is encoded in XML and
submitted to an APPEL engine as any other metadata would be
submitted).
In order to facilitate the rapid development of prototype
implementations of the language the working group decided to first
release a Level 1 specification designed to express only
basic privacy preferences and later prepare a more detailed
Level 2 specification that would implement the rest of the
requirements outlined above. Specifically, APPEL Level 1
limits the requirements to
- only support four standard
behaviors, accept, reject, inform
and warn (i.e. no custom behaviors).
- only support preferences over P3P policies and a limited set
of metadata.
- only support restricted matching capabilities using a limited
set of comparison operators and wildcards.
The remainder of this document will discuss the thus simplified
version of APPEL, refered to as the Level 1 specification.
See Appendix A for a list of further planned
extensions regarding the full APPEL syntax, from here on refered to
as the Level 2 specification.
Since APPEL rulesets are intended to express preferences over P3P
policies, most of APPEL's synatx and semantics are very much
influenced by the P3P 1.0
Specification. In order to follow many of the examples in this
draft, the working group strongly recommends that you first
familiarize yourself with the P3P 1.0 Specification itself. This
will also allow you to better understand the choices in syntax and
semantics that were made in the APPEL specification.
As a quick reference, the following figure shows an example
policy that features most of the elements and attributes of an XML
P3P 1.0 policy. Please refer to section 3. Policy Syntax and
Semantics of the P3P 1.0 Specification for details on the
individual elements and their usage.
Figure 1.1: P3P example policy
The following definitions (in alphabetical order) reflect the way
terms are commonly used in this document.
- behavior
- The activity taken upon the successful matching of a rule. While APPEL Level 1 only supports
four standard behaviors (accept,
reject, inform and warn), Level 2 also allows user agents
to define custom behaviors.
- behavior, standard
- The four behaviors that have to be supported by every APPEL
user agent: accept, reject, inform and
warn. APPEL Level 2 additionally allows user
agents to define a set of custom behaviors. Please note that
APPEL Level 1 does not allow for custom behaviors.
- connective
- An attribute of an expression that determines how any contained expressions will be matched.
APPEL Level 1 supports four connectives:
or,
and, or-exact and and-exact. See
section 5.4.3 Connectives for
more details.
- data repository
- A mechanism for storing user information under the control of
the user agent.
- evidence
- A P3P application provides an APPEL
rule evaluator with an APPEL
ruleset and various pieces of evidence. This
evidence could for example include the URI of the service and a
P3P policy from the service if present. Evidence should be
presented in the form of XML elements, although implementations
are free to use other formats internally.
- expression
-
A component of a rule that is expressed as an XML element and
that can be evaluated to TRUE or FALSE with respect to some
(piece of) evidence. An expression
consists of
- an element identifier (element name)
- zero or more attribute
expressions
- zero or more contained
expressions
- an optional connective
See sections 2.2 Expressions for a
list of expressions and 5.3
Expressions for details on how they match available evidence. Please note that APPEL
Level 1 only allows for the <POLICY> and
<APPEL:REQUEST> elements to be used as the
(top-level) expression in a rule.
- expression, attribute
- An attribute-value pair contained in an
expression. They can be used to compare the values of two
strings surrounded by quotes (i.e. the value of an attribute) or
test for the presence or absence of a particular attribute
without checking for a particular value (when used with
wildcards). Please see section 5.4.1
Matching Attribute Expressions for more information.
- expression, contained
- An expression that is enclosed in another expression, i.e. an
XML element that is enclosed in another (non-APPEL) XML element.
In order for an expression to match, some or all of its contained
expressions (depending on the
connective used) have to match as well. See section 5.3 Expressions for details.
- expression, degenerate
- An expression that always evaluates
to true. See section 4.2.3 The
<OTHERWISE> element.
- expression, top-level
- The expressions contained immediately below an
<APPEL:RULE> element. In APPEL Level 1, the
top-level expression can only be a <POLICY> or
<APPEL:REQUEST> element, or the degenerate expression.
- persona
- A unique identifier for a set of data element values in the
user's data repository that the
user wants to use during the current browsing session.
Implementations could offer to store multiple values for the same
data element and allow users to conveniently choose between
certain sets of values when giving out information from the
repository (e.g. a set of values to be used in the office and a a
different set to be used on weekends).
- preference (privacy, not
qualified in use)
- The user's desires regarding the collection and treatment
of information exchanged under P3P and HTTP. Privacy preferences
are formally expressed by a set of APPEL
rules and should preferably be captured through a GUI.
- policy (privacy, not qualified in
use)
- A site's privacy practices, as expressed in its P3P policies.
- policy, P3P
- A P3P policy is a collection of one or more privacy statements together with information
asserting the identity, URI, assurances, and disclosures of the
service covered by the policy. The format of such a P3P policy is
defined in the P3P 1.0
Specification
- rule
- The formal expression of a user's preference. Rules
express the users preferences that are then compared to a
services P3P policy. The action
resulting from a successful match is defined by the behavior
specified by the rule. The rule is delimited by an opening and
closing element of the form
<APPEL:RULE
behavior="...">rule</APPEL:RULE>
- rule evaluator
- Process responsible for comparing a user's privacy preferences (for example in form of an
APPEL ruleset) with a P3P policy sent from a service. See also comments
in Appendic C: Trust Engines and Database
Engines.
- ruleset
- A set of rules that define all of the
user's P3P preferences.
- schema, P3P base
- schema defined in the P3P
1.0 Specification.
- service
- A program that issues policies and
(possibly) data requests. By this definition, a service may be a
server (site), a local application, a piece of locally active
code, such as an ActiveX control or Java applet, or even another
user agent. In most cases this will be a P3P-enabled Web
server.
- statement, P3P
- A P3P
statement is a set of privacy practice disclosures relevant
to a collection of data elements, sets, and categories. The
enumerated elements act as an embedded data request. A statement
which references no data, requests no data.
- trust engine
- See rule evaluator.
- user
- An individual (or group of individuals acting as a single
entity) on whose behalf a service is
accessed and for which personal data exists.
- user agent
- A program that acts on a user's behalf. The agent may act
on preferences (rules) for a broad range
of purposes, such as content filtering, trust decisions, or
privacy. For P3P purposes, a user agent acts on a user's privacy preferences. Users may use
different user agents at different times.
In addition, this specification uses the same words as RFC 2119
[RFC2119] for defining the significance of each
particular requirement. These words are:
- MUST
- This word, or the terms "REQUIRED" or
"SHALL", mean that the definition is an absolute
requirement of the specification.
- MUST NOT
- This phrase, or the phrase "SHALL NOT", mean that
the definition is an absolute prohibition of the
specification.
- SHOULD
- This word, or the adjective "RECOMMENDED", mean
that there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
- SHOULD NOT
- This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but
the full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.
- MAY
- This word, or the adjective "OPTIONAL", mean that
an item is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because the
vendor feels that it enhances the product while another vendor
may omit the same item. An implementation which does not include
a particular option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
The following sections give an overview of the basic operations of
an APPEL rule evaluator.
An APPEL rule evaluator is activated by a P3P application. The
activating application provides the evaluator with various pieces
of "evidence" and a rule set for processing them.
Evidence includes the URI of the service and a single P3P policy
from the service if present.
The scope of the rule is determined by the opening and closing
elements of an <APPEL:RULE> element. The
evaluator returns the behavior (as specified in its
behavior attribute) of the rule that fired on the basis of
the evidence discussed above as well as a copy of the policy that
triggered the rule. The latter might not necessarily be identical
with the original policy found in the evidence, particulary if it
contained optional elements that were not matched by the rule. In
addition, the rule evaluator may optionally return an explanation
string (suitable for user display), the name of a persona, and/or
the rule that fired.
Applications should interpret the standard outputs as
follows:
- "accept": the
provided evidence is acceptable. If a P3P policy is provided, it
SHOULD be accepted seamlessly (i.e. without consulting the user).
If a URI is provided, the resource at that URI SHOULD be
accessed. Note that P3P 1.0 does not support the concept of
binding agreements: Acceptance of a policy only indicates a
corresponding user agent behavior (i.e. displaying certain
"acceptance"-symbols), not a legal agreement. This
functionality might be extended if later versions of P3P support
this.
- "reject": the
provided evidence is not acceptable. If a P3P policy is provided,
it SHOULD be rejected seamlessly. If a URI is provided, the
resource at that URI SHOULD NOT be accessed. Note that in some
instances of the P3P 1.0 protocol, the resource URI might have
already been accessed in order to receive a the P3P policy URI.
In these cases it is up to the calling program to determine what
information to present to the user.
- "inform":
information SHOULD be provided to the user. It is up to the
calling program to determine how the information should be
provided. It may be provided, for example, in the form of a
visual or audio signal, or a prompt that requires a user
response. However, the context of the information should be
informational and SHOULD NOT suggest to users that their privacy
preferences are being violated. For example, an inform prompt
might state "x.y.com has requested that your home address be
provided so that your order can be processed. Would you like to
proceed or cancel your request?"
- "warn":
a warning SHOULD be provided to the user. It is up to the calling
program to determine how the user should be warned. It may be
provided, for example, in the form of a visual or audio signal,
or a prompt that requires a user response. However, the context
of the information SHOULD be a warning that the policy may
violate the user's privacy preferences. For example, a warn
prompt might state "Warning: x.y.com has requested that your
home address be provided so that your order can be processed.
Your preferences state that you do not wish to provide your home
address under such circumstances. Would you like to override your
preferences or cancel your request?"
The information described in the following sections is only
intended to give a first overview. Details can be found in section
5 Semantics, and should be referenced from
the corresponding sections below.
Rules are evaluated with respect to the evidence provided. A rule
evaluates to true if all of its enclosed expressions are satisfied.
Basically, an expression is satisfied if any of the
available evidence satisfies it.
Each rule in the ruleset is evaluated in the order in which it
appears. Once a rule evaluates to true, the corresponding behavior
is returned and rule evaluation ends. User Agents that wish to
provide additional information in case a policy is not accepted
(such as listing all reasons why it was rejected, not only the
first one that led to "reject") might require further
evaluation in order to provide such information to the user.
Rulesets should be written so that there is always a rule that
will fire. A rule evaluator should return an error if it is called
without a ruleset, with an empty ruleset, or if no rule fires. It
is up to the calling program to determine what to do if an error is
returned; however, calling programs SHOULD NOT treat an error as
they would a "accept".
Further information on rule processing can be found in sections
5.1 The Rule Evaluator in a nutshell and 5.2 Rules ordering.
APPEL uses 3 basic types of expressions:
- expression: uses attribute- and
contained-expressions to match a full XML element in the
evidence.
- attribute expression: matches a
single attribute and its value in an XML element.
- contained expression:
recursively matches contained subelements of an XML element.
An expression in APPEL is represented by an XML element that can
be evaluated to TRUE or FALSE by matching it against the available
evidence. An expression always consists
of (see figure 2.1 for examples):
- an element identifier (element name)
- zero or more attribute
expressions
- zero or more contained
expressions
- an optional connective
Figure 2.1: Example expressions
|
Element name only:
<CONSEQUENCE></CONSEQUENCE>
|
Element and attribute:
<DISCLOSURE
discuri="*"/>
|
|
Element name, contained elements and
connective:
<RECIPIENT
APPEL:connective="or-exact" >
<ours/>
<same/>
<delivery/>
</RECIPIENT>
|
Element name, attributes, contained elements &
connective:
<POLICY
entity="W3C">
<STATEMENT
APPEL:connective="and">
<PURPOSE
APPEL:connective="or-exact">
<current/></PURPOSE>
</STATEMENT>
</POLICY>
|
Attribute-expressions may take string or numeric values,
although APPEL will treat all values as simple strings. APPEL
Level 1 supports only the equality operator in
attribute-expressions (APPEL Level 2
might additionally offer comparison operators such as
"<" less-than and
">" greater-than for matching numeric
values).
APPEL offers a single wildcard metacharacter "*"
which closely resembles the wildcard character in many operating
system shells. Attribute expressions can use this metacharacter to
match ranges of values such as <DATA
name="User.*"> (any element from the
"User" data set). Further details are given in sections
5.4.1 Attribute Expressions and 5.4.2 Regular Expression Metacharacters.
A special form of expression is the so called degenerate expression
<APPEL:OTHERWISE>. Instead of matching it against the
evidence, the rule evaluator MUST always evaluate this expression
to true. This expression usally appears in the last rule of a
ruleset in order to catch all possible cases that haven't been
matched yet.
A rule includes a behavior, an optional persona, an optional
explanation and a number of expressions. A
rule without any expression always evaluates to false. A rule
containing the degenerate expression
always evaluates to true. Individual expressions are each composed
of attribute expressions and contained expressions, and optionally feature
a connective.
When multiple attribute expressions and/or contained expressions
are placed within the scope of a single expression, all are matched
within the scope of a single piece of evidence. For example, if a
rule contains a <STATEMENT> expression that
contains both a
<PURPOSE><develop/></PURPOSE> expression
and a <RECIPIENT><ours/></RECIPIENT>
expression, then it will only evaluate to true if the P3P policy
contains a statement that both declares local recipients and a
research & development purpose. If both expressions are satisfied, but only in
separate statements, then the expression evaluates to false.
While attribute expressions within an expression are implicitly
ANDed together, a special
connective attribute is used to govern the matching
semantics of contained expressions.
APPEL supports four such connectives: or, and,
or-exact, and and-exact. If no connective is
given, APPEL defaults to requiring and-exact matches: only
if the elements in the evidence are identical to those
given in the rule, a match is triggered.
The matching of attribute and contained expressions is described
in more detail in section 5.4 Matching.
In the following section we will describe a simple APPEL preference
file in order to introduce the different elements of the APPEL
language and illustrate their usage. Although the example is a well
formed APPEL ruleset (i.e. it is enclosed in an <APPEL:RULESET> element), it is only
used to demonstrate a small set of example rules.
We will start with a plain text description of the user's
(admittedly simple) preferences, followed by a tabular overview of
the involved elements and their allowed values. Finally, we will
give an example of the corresponding APPEL encoding. Note that each
listing in this document features line numbers for ease of
reference; they are not part of the actual encoding!
- Requests for personal information which will be given out to
3rd parties should be rejected.
- The user does not mind revealing click-stream and user agent
information to sites that collect no other information. However,
she insists that the service provides some form of
assurance.
- The user is comfortable with giving out her first and last
name, as long as it is for non-marketing purposes. She requires
assurances (i.e., dispute information) from both
"PrivacyProtect and "TrustUs" before trusting such
a statement. However, she always wants to be explicitly informed
about such cases before actually transfering this
information.
- When interacting with her bank's Web site at
http://www.my-bank.com, she accepts any data request as
long as her data is not redistributed to other recipients.
- All other requests for data transfer should be prompted for
(indicating a conflict with her privacy preferences) and will be
decided by the user on a site-by-site basis.
The following table describes the fields the user is referencing in
her privacy preferences, together with the matching conditions and
actions that should be taken (Please refer to the Base data elements
and sets as well as the XML encoding of a policy,
defined in the P3P 1.0
Specification for the list of fields referenced). Do not try to
use it as a lookup table for finding a behavior, given a list of
attributes/elements and their values. Instead one has to step
through the table row by row until the values referenced in the
table match. This is because each row represents an ordered rule in
our ruleset.
Please note that some of the cells feature a wildcard symbol
"*", while others are empty. APPEL
distinguishes between non-referenced attributes and those that
are referenced but contain only wildcards. In the former case, the
user truly does not care about the attribute, even whether it is
included in the policy or not. In the latter case, the user might
not care about the attributes value, but at least expects it to
have some value. For further details see section 5.4.2 Regular Expression Metacharacters. In row
three of our example below, the user does not care about the
purpose of the collected clickstream data (hence the empty
fields in the table), but requires that some form of
dispute-information is present (represented by a wildcard
"*" character).
| Behavior |
Element/Set |
URI |
Disputes |
Purpose |
Recipient |
| reject |
category="physical", or
category="demographic", or
category="uniqueid" |
|
|
|
same, other,
delivery, public
or unrelated |
| accept |
dynamic.http.useragent, dynamic.clickstream.server |
|
* |
|
|
| inform |
user.name.* |
|
"PrivacyProtect" and "TrustUs" |
current, admin, custom or develop |
|
| accept |
|
www.my-bank.com |
|
|
ours |
| warn |
[otherwise] |
|
|
|
|
The following listing illustrates one way to encode the above
preferences into an APPEL ruleset. Five rules are used to handle
all incoming policies from a service. A reject-rule (i.e.,
a rule with the string "reject" in its
behavior attribute) first rejects any policies asking for
identifiable data that is distributed to 3rd parties.
Using an explicit match for the request URL, a second rule then
accepts a policy if, when connecting to
www.my-bank.com, the requested data is only distributed to
the bank and its agents.
Next, an "accept" rule checks to see if only
non-identifiable clickstream data and/or user agent information
(such as browser version, operating system, etc) is collected, and
accepts if dispute information is available.
An "inform" rule then matches any requests for the
user's name for non-marketing purposes and eventually initiates
a prompt informing the user that a site wants to collect her name
under acceptable circumstances.
If none of the other rules matches, a "warn"-rule
encapsulating the degenerate
expression "APPEL:OTHERWISE"
will fire, warning the user to (cautiously) decide on any policy
that has not been covered by any of the rules above.
Figure 3.1: Simple Ruleset in APPEL Level 1
Using the line numbers in the example above, we will briefly
explain the basic structure of an APPEL ruleset.
| Lines |
Explanation |
| 000 - 075 |
APPEL ruleset. Usually a single APPEL ruleset
(i.e., a set of ordered rules enclosed
in an
<APPEL:RULESET> tag) is installed in a
user agent. Implementations might offer to hold different
rulesets depending on the current user of the system, or on
the persona the user wants to use during the current
browsing session. The <APPEL:RULESET> element can be tagged
with additional information such as author or date of creation:
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" '
attributes '>'
rseq
'</APPEL:RULESET>'
[2] rseq = 1*rule
|
| 003 - 018 |
"reject" rule. APPEL offers four
distinct kinds of behaviors for
rules: "accept", "reject", "inform" and "warn". Each rule
consists of an
<APPEL:RULE> element surrounding a set of
expressions or the degenerate
expression
<APPEL:OTHERWISE>.
[3] rule = '<APPEL:RULE behavior="' behavior '"'
attributes '>'
body
'</APPEL:RULE>'
[5] body = top-expression | '<APPEL:OTHERWISE/>'
[6] behavior = 'accept' | 'reject' | 'inform' | 'warn'
Each rule can be augmented by a set of attributes. In
our example we use the description field to supply a human
readable explanation ("Service only collects
clickstream data") in case the rule should fire (this
could be displayed by the user agent during data transfer,
prompting, or could be used for debugging purposes).
[4] attributes = [' persona=' quoted-string]
[' crtby=' quoted-string]
[' crton="' datetime '"']
[' description=' quoted-string]
|
| 006 - 017 |
P3P Policy to match. Most APPEL rules have a P3P
policy as the matching expression inside a
<RULE> element. Elements and attribute values
that the rule should match on are simply spelled out in the
policy, while wildcards ("*") are used to match a
range of values. Omitting an attribute or element
completely allows the attribute/element to be missing from
the policy supplied by the service (or to be included with
any value).
[7] top-expression = policy | request [policy]
[8] policy = <[P3P10] policy (optionally with embedded connectives)>
[9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>'
1*request
'</APPEL:REQUEST-GROUP>'
[10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '"/>'
|
| 007 - 016 |
STATEMENT element match. The
"reject" rule should fire (i.e. reject the policy)
if the service asks for personal data
(<DATA> elements in the categories
physical, demographic or
uniqueid) that is distributes to 3rd parties
(<RECIPIENT> matching
<same/>, <other/>" or
<published/>). Note that rules do not
always feature all required elements of a P3P
policy. Given that both the <DATA> and
<RECIPIENT> element match, this reject
rule will match regardless of the purpose
(<PURPOSE>) specified in the policy. |
| 006 - 008, ... |
Connectives. Using the
APPEL:connective attribute, the rule author can
explictly specify different matching semantics for the
contained expressions of an element. APPEL supports four
different connectives (or, and,
or-exact and and-exact) that
implement different matching semantics. If no connective is
given, the default matching semantics require an
and-exact match between the rule and the available
evidence.
[11] connective = 'APPEL:connective="' conn '"'
[12] conn = or | and | or-exact | and-exact
|
| 020 - 033 |
Restricted Accept-rule. This
"accept" rule only continues to match the policy if
it has been fetched while requesting a Web resource from
www.my-bank.com. This is because of the
additional
<APPEL:REQUEST> element in the rule body,
which evaluates to false unless the user agent is currently
requesting a resource from the uri listed in the element.
This allows users to easily write rules that only apply to
policies from a restricted set of domains. |
| 035 - 048 |
accept. The "accept" rule
should only allow the release of data if the policy sent by
the service at most declares the collection of user agent
and/or clickstream data. Note that the purpose
(<PURPOSE>) and recipient element
(<RECIPIENT>) do not have to
appear in the rule, even though they are required in a P3P
policy statement. |
| 040 - 041 |
Data Elements to match. Because of
the use of the "or-exact"-connective, the "accept" rule
will only match if the statement in the policy does not
contain any additional data references not
contained in the rule. Consequently, a policy requesting any
other element than the ones explicitly enumerated in between
lines 33 and 36 of the ruleset would immediately evaluate the
expression to false (i.e. not accepting the
policy). |
| 044 - 046 |
DISPUTE-resolution information to
match. The user wants to make sure that the service
included a reference to an organization that can provide
assurance about its privacy policy in case disputes should
arise. |
| 050 - 068 |
"inform" rule. Although
the user agrees to releasing her name for non-marketing
purposes to Web Sites that have assurances from both TrustUs
and PrivacyProtect, she wants to supervise each
individual data transfer. Implementations might offer User
Interfaces that allow users to explicitly accept all
subsequent data transfers to a particular site, effectively
prompting the user only for her first visit to a new
site. |
| 013, 056 |
Matching a list of alternatives. In
order to match a number of different purposes or recipients,
we use either the "or" or the "or-exact"
connective and enclose a list of valid alternatives
recipients and purposes elements. |
| 063 - 066 |
Matching conjunctive values. In
order to require both assurances from TrustUs and
PrivacyProtect in the policy, the rule lists the same element
(<DISPUTES>) multiple times (but with
different values in their attributes) together with the
"all" connective in the enclosing
DISPUTES-GROUP element, thus representing a logical
AND between the values. |
| 070 - 073 |
"warn" rule. Since rules
in an APPEL ruleset are ordered, the "warn" rule
only gets evaluated should all preceding rules fail to match
the policy sent by the publisher. If we would reverse the
order of our rules (i.e. putting the
<OTHERWISE> rule at the top), our user agent
would always issue a warning for all incoming policies (see
comment below). |
| 072 |
Degenerate Expression. Using the degenerate
expression <OTHERWISE>, we can create
"catch-all" rules that are always known to
evaluate to true. Rules containing
<OTHERWISE> should usually be placed at the
end of a ruleset, since all following rules will never be
evaluated. Note that empty rules never match anything.
Rulesets should be written so that for any possible
evidence set, there is always a rule that will fire. Thus,
if no rule fires, the rule evaluator should return an
error.
|
The following syntax must be used for implementations to be
compliant. In addition, compliant applications must process rules
according to the semantics defined in section 5.4
Matching Semantics.
This section lists the exact syntax used for the APPEL Level
1 language, as well as encoding issues. The working group
envisions that after initial experiences have been made with
prototypes based on the Level 1 specification, the full
(Level 2) specification can then be revised based on
practical observations before extending the existing systems to
address the full range of requirements outlined in section 1.3 Requirements.
The BNF syntax below is just an informal representation of the
actual syntax. Please refer to the section 4.2
Elements for the normative description of the APPEL syntax.
Figure 4.1:APPEL BNF Syntax, Level 1 (informative)
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" '
attributes '>'
rseq
'</APPEL:RULESET>'
[2] rseq = 1*rule
[3] rule = '<APPEL:RULE behavior="' behavior '"'
attributes '>'
body
'</APPEL:RULE>'
[4] attributes = [' persona=' quoted-string]
[' crtby=' quoted-string]
[' crton="' datetime '"']
[' description=' quoted-string]
[5] body = top-expression | '<APPEL:OTHERWISE/>'
[6] behavior = 'accept' | 'reject' | 'inform' | 'warn'
[7] top-expression = policy | request-group [policy]
[8] policy = <[P3P10] policy (optionally with embedded connectives)>
[9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>'
1*request
'</APPEL:REQUEST-GROUP>'
[10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">'
[11] connective = 'APPEL:connective="' conn '"'
[12] conn = or | and | or-exact | and-exact
[13] quoted-string = '"' string '"'
[14] string = <[UTF-8] string (with " and & escaped)>
[15] datetime = <date/time as per section 3.3 of [RFC 2068]>
Details are described in section 4.2
Elements below. Please see also Appendix 7.3
APPEL Level 2 Specification.
APPEL rulesets are represented as XML documents, following the same
character set conventions as generic XML. Legal characters are tab,
carriage return, line feed, and the legal graphic characters of
Unicode and ISO/IEC 10646. For further details see the character
encoding section in the XML
Recommendation. Note that in XML documents both element and
attribute names are case-sensitive. All element names in
APPEL are in uppercase, while attributes are using all lowercase.
The P3P uses a similar convention, so it should be a uniform format
even for P3P policies. However, please refer to the latest P3P Specification for a
normative definition of case in P3P elements.
In contrast to P3P policies, APPEL rulesets are not intended to
be exchanged in real time by special means such as an HTTP protocol
extension. Instead, they should be treated and downloaded like
simple files, using any means available depending on the hard- and
software setup in use.
Internally, user agents may use any convenient encoding of a
user's ruleset (e.g. in binary form), as long as they provide
methods to synchronize a user's plain text ruleset file with
its internal representation.
This section describes the elements that are used to create an
APPEL ruleset. Each element is given in <>
brackets, followed by the list of attributes that can appear in the
element. All listed attributes are optional, except when tagged as
mandatory. For more information on the actual usage of
these elements, please refer to section 5.
Semantics as well as section 3. Simple
Example Scenario.
<APPEL:RULESET>- This tag is the delimiter that denotes an APPEL file. It
includes a sequence of one or more rules. Each rule features a
certain behavior that is returned to the calling program if the
expressions listed in the rule all evaluate to true.
persona- If the user agent supports multiple user repositories, this
string identifies the data repository that should be used. If no
persona is given, the default persona should be used. Note that
this value can be overridden on the
<RULE>
level.
crtby- Name or ID of the ruleset author (could be the user
agent).
crton- Time & Date of ruleset creation.
description- A short natural language explanation that can be displayed by
the user agent when the ruleset gets selected, or to help
debugging a rulefile.
[1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" '
attributes '>'
rseq
'</APPEL:RULESET>'
[2] rseq = 1*rule
[4] attributes = [' persona=' quoted-string]
[' crtby=' quoted-string]
[' crton="' datetime '"']
[' description=' quoted-string]
<APPEL:RULE>- Contains conditions under which a certain behavior should be
carried out by the calling program.
behavior (mandatory
attribute)- Behavior that should be carried out by the calling program if
the expressions match the evidence.
persona- If the user agent supports multiple user repositories, this
string identifies the data repository that should be used. If no
persona is given, the corresponding value of the enclosing
<RULESET> is used.
crtby- Name or ID of the rule author (could be the user agent).
crton- Time & Date of rule creation.
description- A short natural language explanation that can be displayed by
the user agent when the rule gets executed, or to help debugging
a rulefile.
The top-level expressions directly enclosed by an
<APPEL:RULE> element MUST always be matched with an
exact match (see section
5.4.4 Connectives) -- there is no way in APPEL Level 1
to specify a different matching semantics for the topmost
elements.
A rule that only contains a <POLICY> element,
but no <APPEL:REQUEST> element, will try to
match policies on any site. A rule that contains both a
<POLICY> element and an
<APPEL:REQUEST> element will only match policies at
sites that match the URI given in the
<APPEL:REQUEST> element. A rule that only contains an
<APPEL:REQUEST> element, but no
<POLICY> element, will match if a site does not offer
any P3P policy. A rule with an empty list of expressions will never
get activated. In order to create a default rule which
will trigger if no other (preceding) rule fired, the degenerate
expression <OTHERWISE/> should be used.
[3] rule = '<APPEL:RULE behavior="' behavior '"'
attributes '>'
body
'</APPEL:RULE>'
[4] attributes = [' persona=' quoted-string]
[' crtby=' quoted-string]
[' crton="' datetime '"']
[' description=' quoted-string]
[5] body = top-expression | '<APPEL:OTHERWISE/>'
[6] behavior = 'accept' | 'reject' | 'inform' | 'warn'
[7] top-expression = policy | request [policy]
<APPEL:OTHERWISE>- so called degenerate-expression, which always evaluates to
true. This can be used to craft "catch-all"
rules which match all cases not covered by previous rules.
<APPEL:OTHERWISE> should be the only
expression in a rule. A ruleset should usually contain one and only
one rule featuring the degenerate expression, and such a rule
should be the last one in a ruleset. Users should take care not to
use the <OTHERWISE> element together with a
accept behavior, which would result in unlimited access to a
user's data repository for sites not covered by the preceding
rules! User agents MUST refuse to accept rulesets with such
"catch-all" accept rules.
[5] body = top-expression | '<APPEL:OTHERWISE/>'
<APPEL:REQUEST>- allows the creation of rules that only apply to a certain
resource or domain.
uri (mandatory
attribute)- the URI of the currently requested resource (not the policy
URI).
Together with a <POLICY>-expression, the
<APPEL:REQUEST> element (embedded in an
<APPEL:REQUEST-GROUP> element) can be used to create
rules that only apply to a certain resource or domain. Since both
expressions need to evaluate to true in order for the rule to fire,
any existing <APPEL:REQUEST> element will limit
the application of the <POLICY> expression to
the given URI.
In order to list multiple, alternative resources and/or domains
in a single rule, you can embed multiple
<APPEL:REQUEST> elements in an
<APPEL:REQUEST-GROUP> element and connect them using
an or or or-exact connective.
[7] expression = policy | request | 1*<A chunk of XML code (optionally with embedded connectives)>
[8] policy = <[P3P10] policy (optionally with embedded connectives)>
[9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>'
1*request
'</APPEL:REQUEST-GROUP>'
[10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">'
APPEL:connective- determins how contained expressions are matched when a rule
is compared to the available evidence.
APPEL supports four different kinds of connectives:
or, and, or-exact and
and-exact. Please refer to section 5.4.3 Connectives for a description of
their semantics. If no APPEL:connective is given,
APPEL's matching semantics default to an and-exact
match: All of the containedexpressions must
appear in the evidence, and no additional elements must be
present.
[11] connective = 'APPEL:connective="' conn '"'
[12] conn = or | and | or-exact | and-exact
While section 2. General Operation and
Semantics already gave an overview of the basic operations of
an APPEL rule evaluator, the following sections describe the
semantics of the APPEL language in more detail. We first revisit
the basic operation of an APPEL rule evaluator described in section 2, and then focus on individual
issues concerning rule evaluation: rule ordering, expressions,
matching, and rule expiration.
A P3P user agent or other program will invoke an APPEL rule
evaluator, providing an APPEL ruleset and various pieces of
"evidence" which may include the URI of the
currently requested resource, and a single P3P policy. If multiple
P3P policies are available, the user agent SHOULD call the rule
evaluator repeatedly and feed it each policy separately (in any
order).
The rule evaluator MUST return a behavior (i.e., one of
the four standard behaviors
"accept", "reject", "inform" or
"warn") that the calling program should carry out, as
well as a copy of the policy that triggered the rule. Please note
that the latter might not necessarily be identical with the
original policy found in the evidence, particulary if it contained
optional elements that were not matched by the rule! In addition,
the rule evaluator MAY optionally return an explanation string
(suitable for user display), the name of a persona, and/or the rule
that fired.
A user agent MUST at least support the four standard behaviors "accept",
"reject", "inform" or "warn".
A ruleset consists of an ordered list of rules. Rules
describe conditions under which a certain behavior should be
carried out by the calling program.
Each rule in a ruleset is evaluated in the order in which it
appears. Once a rule evaluates to true, the corresponding behavior
is returned and rule evaluation ends. If no match occurs and all
rules have been processed, an error is returned to the calling
program.
Rulesets should be written so that for any possible evidence
set, there is always a rule that will fire. It is up to the calling
program (usually the user agent) to determine what to do if an
error is returned; however, calling programs should not treat an
error as they would an "accept".
Each rule contains a number of top-level expressions in form
of a well-formed XML element and features one single
behavior. An APPEL compliant user agent MUST at least support
the P3P <POLICY> element, the APPEL
<APPEL:OTHERWISE> element, as well as the
<APPEL:REQUEST> element (representing the URI of the
currently requested resource, not the policy URI).
All top-level expressions in a rule are implicitly ANDed
together. Each expression in turn is implicitly ANDed together with
all of its enclosed attribute
expressions. Contained expressions
are by default also ANDed together, unless the rule author
explicitly specified an alternative matching using the
connective attribute.
All expressions and their sub-expressions (i.e. attribute and
contained expressions) are matched by the rule evaluator against
the elements in the evidence according to the nesting in which they
appear in the rule. For example, a STATEMENT element
nested inside a POLICY element in the rule will only
match a STATEMENT element in the evidence which is
nested inside a matching POLICY element.
A rule containing no expressions always evaluates to false, a
rule containing only the degenerate
expression always evaluates to true.
How APPEL evaluates multiple rules in a ruleset
There is no need for logic operators between multiple rules in an
APPEL ruleset, since all rules in APPEL are evaluated strictly in
order. However, inserting a new rule or changing the order of an
existing list of rules can greatly influence the behavior of the
user agent!
Care should be taken that only a single rule containing the
degenerate expression <OTHERWISE> exists and is
placed at the end of the ruleset.
How to specify what to match in a rule
Every rule in an APPEL ruleset contains a number of top-level expressions which must be in valid XML format.
Each expression tries to match a certain piece of evidence, which
in APPEL Level 1 can only be in the form of a P3P policy or
represent request information such as the resource URI (using the
<APPEL:REQUEST> element).
All sub-expressions of a single expression are per default
always ANDed together, that is, all attribute and
contained expressions have to evaluate to true in order
for the expression to match. However, using the
APPEL:connective attribute, the rule author can explictly
specify different matching semantics for the contained expressions
of an element.
Note that connectives only govern the matching of contained
expressions appearing at this level. Should these
contained expressions in turn contain other expressions, they will
be matched using the default matching semantics (i.e.,
exact) unless another connective attribute is
used within the contained expression. See section 5.4.3 Connectives for details.
Figure 5.1 below gives the informal definition of the 3 main
types of expressions in APPEL.
Figure 5.1: APPEL expressions (informative)
[1] expression = empty-expression | containing-expression
[2] empty-expression = "<" element-name *attribute-expression "/>"
[3] containing-expression = "<" element-name *attribute-expression [connective]">"
1*contained-expression
"</" element-name ">"
[4] element-name = identifier
[5] attribute-expression = attribute_name "=" quoted-string
[6] contained-expression = expression
[7] attribute_name = identifier
[8] identifier = <a valid XML identifier>
[8] quoted-string = `"` string `"`
[9] string = <[UTF-8] string (with " and & escaped)>
[10] connective = 'APPEL:connective="' conn '"'
[11] conn = or | and | or-exact | and-exact
Note that it is possible in APPEL that multiple expressions in
the rule match one and the same element in the evidence. Rule
evaluators do not need to keep track of which part of the rule
matched which part in the evidence. Instead, each expression can
separately be checked against the available evidence, as shown in
the example below: Both STATEMENT-expressions in the
rule independantly match the same <STATEMENT>
element in the evidence.
Figure 5.2: Matching example
<-- ruleset -->
<APPEL:RULE behavior="inform">
<POLICY APPEL:connective="and">
<STATEMENT APPEL:connective="and">
<RECIPIENT APPEL:connective="or-exact">
<ours/>
</RECIPIENT>
<DATA-GROUP APPEL:connective="or-exact">
<DATA name="user.*"/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT APPEL:connective="and">
<PURPOSE APPEL:connective="or-exact">
<custom/>
</PURPOSE>
<DATA-GROUP APPEL:connective="or-exact">
<DATA category="online"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</APPEL:RULE>
|
<-- evidence (abbreviated) -->
<POLICY>
...
<STATEMENT>
<RECIPIENT><ours/></RECIPIENT>
<PURPOSE><custom/></PURPOSE>
<DATA-GROUP>
<DATA name="user.home.online.email"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
|
Expressions over elements that are not in the set of
evidence provided by the calling program always evaluate to
false, unless the rule author explicitly used the
APPEL:connective attribute with either the or
or or-exact flag. For example, a rule using a (contained)
expression to match a disputes
element without any connectives would always fail unless the
evidence would contain such an element.
On the other hand, elements in the evidence that do not have a
corresponding expression in the rule are always ignored, unless the
rule author explicitly used the APPEL:connective
attribute with either the or-exact or
and-exact flag. For example, a rule referencing a P3P policy
containing a disputes element but no disclosure element (and using
no connectives) could possibly match evidence of a P3P policy
featuring both a disputes and a disclosure
element.
Please note that matching any evidence other than a P3P policy
or request information requires the use of APPEL Level 2.
When using APPEL Level 1 all elements other that P3P
policies and APPEL:REQUEST elements will be ignored
(i.e. do not alter rule evaluation). Also remember that if more
than one P3P policy is available, they should be submitted to the
rule evaluator individually (see 5.1 The Rule
Evaluator in a Nutshell).
How APPEL matches expressions against available evidence
Expressions in APPEL are used to match a rule against the
available evidence. For a given element in the rule, an expression
can test whether the evidence contains an identical element
featuring the same attributes, values, and matching sub-elements.
The standard matching semantics for all expressions in APPEL depend
on the choice of connective that is used (see section 5.4.3 Connectives below) and can be
summarized as follows:
- All attribute expressions in a rule are ANDed, additional
attributes are ignored.
Attributes are ANDed within a single element, that is all
attributes in an expression have to appear in a single element in
the evidence. Any attribute in the evidence that can not be found
in the element in the rule is ignored.
-
Contained expressions are...
- ...ORed (
or and or-exact
connectives)
At least one contained expression in the current
expression has to match an element in a corresponding element
of the evidence.
- ...ANDed (
and and
and-exact connectives)
Any contained element listed in the expression has
to appear in a corresponding position in the evidence, with
matching attributes and values.
-
Additional evidence (non-attribute)...
- ...is ignored (
or and
and connectives)
Any element listed in the evidence which can not be found in
the rule (or which can be found but without matching
attributes and values) will be ignored
- ...is not ignored (
or-exact
and and-exact connectives)
Any element listed in the evidence which can not be found in
the rule (or which can be found but without matching
attributes and values) will prompt the rule to fail.
An attribute expression matches an attribute-value pair of
an XML element in the evidence if and only if:
- the attribute names are identical
- AND the values are identical (using string comparison)
Only the = operator may be applied to attribute expressions. All
attribute values are treated as strings in APPEL, even if they
represent numbers (No P3P element features numeric attribute
values, so this shouldn't really matter). In order for an
expression to match, all of the attributes and values listed
in the expression's attribute expressions have to appear in a
single element with the same name in the evidence. Any additional
attributes that are found in the evidence but which are not
referenced in the rule are ignored.
If a rule requires that a particular attribute appears in an
element without restrictions on the value for that attribute
(including the empty value!), the wildcard character
"*" may be used (e.g. as in
attribute="*"). However, if a rule does not
require that a particular attribute appear at all, the attribute
should not appear in the rule at all.
Please note that it is not possible in APPEL to write rules
that require that a certain attribute does not appear in
an element of the evidence set (e.g. matching
<DISCLOSURE> elements without access
attribute), nor that a certain element is absent from the evidence
(e.g. matching policies that do not include a disputes
field).
APPEL offers a single metacharacter for providing simple regular
expression support in its attribute expressions: the star
"*" symbol. The usage of the star symbol is
similar to popular operating system shells under DOS/Windows and
UNIX, but differs from its semantics in standard regular expression
systems such as egrep.
Using metacharacters with strings allows us to specify ranges
of string-values, for example "*.foo.com"
for any host in the foo.com domain, or
"*://*"" for a URI (or at least
something that looks like one). Please note that string values are
always matched from the beginning of the string, unless
the user specified an initial * star symbol. Forcing a
string match from the end is not possible in APPEL Level
1.
Please note also that the wildcard character is only allowed
within quoted strings, not for matching attribute names or element
names, for example such as in <DISPUTES
res*="service"> or <DISP*
resolution-type="service">! While it can be
applied in the above manner to match ranges of data elements (i.e.
subtrees) when used in data-reference expressions (<DATA
name="user.*"/>), it can not be used to
match a set of data set leafs: <DATA
name="*.zipcode"/>!
While attribute-expressions are always ANDed, the matching
of contained-expression is subject to matching connectives
that can be specified as attributes to the enclosing element. APPEL
Level 1 supports the following four connectives:
or- Matches if one or more of the contained expressions
can be found (at the correct position) in the evidence. If the
evidence contains elements not listed in the rule, such
evidence is ignored. Using this connective requires that
at least one of the listed contained expressions appear in the
evidence.
and- Matches if all of the contained expressions can be
found (at the correct position) in the evidence. If the evidence
contains elements not listed in the rule, such evidence
is ignored. Using this connective requires that all of
the listed contained expressions appear in the evidence.
or-exact- Matches if one or more of the contained expressions
can be found (at the correct position) in the evidence. If the
evidence contains elements not listed in the rule,
matching fails. Using this connective ensures that only
those elements listed in the rule appear in the evidence.
and-exact- Matches if one or more of the contained expressions
can be found (at the correct position) in the evidence. If the
evidence contains elements not listed in the rule,
matching fails. Using this connective ensures that the
elements listed in the rule are identical with the evidence -- no
elements are missing, no additional elements appear. This is
the default matching semantics if no connective is
given.
The top level expressions right below the
<APPEL:RULE> element are always matched using
exact matching. Connectives can only be used in elements
below the <APPEL:RULE> element. If no
connective is given, an exact match is performed.
Connectives only govern matching of the immediate
contained-expressions, they do not propagate downward
(inheritance). If these contained-expressions in turn contain other
expressions, new connectives need to be specified at that level, or
the default exact connective applies again.
The different matching semantics that result from the four
available connectives are summarized in Figure 5.3 below:
Figure 5.3: Connectives
|
|
Contained expressions are |
| ORed |
ANDed |
| Additional evidence |
is ignored |
or |
and |
| alters |
or-exact |
and-exact (default) |
Data elements in P3P can be tagged as
optional="yes", indicating that the declared
element is not required. In order to allow APPEL rules to handle
optional data elements, rule evaluators MUST be able to selectively
remove optional elements from a policy in the evidence and
repeatedly compare the user's ruleset with the thus altered
evidence. In case of a match after some alteration, the rule
evaluator MUST return a copy of the (altered) policy that
triggered the rule together with the triggered behavior (as
specified in the rule that fired). This allows the user agent to
determine which of the optional elements need to be omitted from
data transfer in order to match the user's preferences.
A simple mechanism for matching a policy with optional data
elements against a rule is given below. User agent implementors
will probably want to use a more efficient startegy:
-
For each rule in the ruleset
- Make a copy of the original policy and place it into the
pool of evidence.
-
While the policy in the evidence fails to match the
rule and optional data elements exist:
- remove one optional data element at random.
- If the rule matches the (possibly altered) policy,
return both the behavior of the rule and the copy of the
policy.
P3P 1.0 also supports the concept of optional and mandatory
extensions. Such extensions are enclosed in a set of
<EXTENSION>...</EXTENSION> tags and feature an
optional attribute that is used to indicate wheter an
unknown extension can either be safely ignored
(optional="yes") or not.
Such extensions, both mandatory and optional, can be matched in
APPEL in very much the same way as optional
<DATA> elements are matched (compare section 5.4.4 Matching optional data elements): Rule
evaluators MUST be able to selectively remove extension
tags that are tagged as being optional and repeatedly compare the
user's ruleset with the thus altered evidence. In case of a
match after any optional extension has been removed, the rule
evaluator MUST return a copy of the altered policy that triggered
the rule, together with the triggered behavior.
Note that is up to the calling application to determine whether
an extension referenced in a P3P policy file is supported or not.
This should presumably be done before the rule evaluator is
invoked, for example at the same time the available P3P policy is
syntactically validated.
P3P
categories are attributes of data reference elements which
provide hints to users and user agents as to the intended uses of
the data. Categories are vital to making P3P user agents easier to
implement and use; they allow users to express more generalized
preferences and rules over the exchange of their data. Categories
have to be included when defining a new element or referring to
variable abstract elements such as form data or cookies.
The following sections describe the two different cases that
must be supported by an APPEL trust engine: rules that refer to
named data reference elements using explicit categories, for
example as in
<DATA name="dynamic.cookies"
category="navigation"/>,
as well as rules that use data reference elements with categories
only, such as
<DATA category="preference"/>
Most elements of the P3P Base data set
have one or more fixed categories assigned. For example, the
user's birthdate, user.bdate., is assigned to the
"Demographic
and SocioEconomic Data" category, as defined in the P3P 1.0 Specification. For
such elements an explicit (re-)definition of the category both in a
P3P policy, as well as in an APPEL rulefile, does not make sense
and MUST be ignored by the user agent.
However, for a certain number of elements the base data set
does not specify a fixed category but instead requires the author
of a P3P policy to explicitly list the categories this element is
used for in this particular situation. These elements are called
"variable-category data
elements, and only for data reference expressions referencing
those elements the APPEL rule evaluator must support the additional
use of the category attribute.
The following pseudo-code summarizes the steps necessary to
match named data reference elements that optionally feature an
explicit category attribute:
-
Check the P3P base data set for the defined category of the
named data reference element.
- If one or more fixed categories are defined,
ignore any additional category attributes (in both the rule
and the evidence). Alternatively, a user agent could indicate
an error in the rule file, preferably during a preliminary
parsing step right after the rulefile is loaded into the
application.
- If no fixed category is defined in the base set,
or if the element is not part of the base set, require the
use of an explicit category attribute in both the evidence.
Only elements in the rule that correctly match the category
attribute of their corresponding evidence element are allowed
-- all cases where no category is given or where the category
values do not match cause the rule to fail.
- Use the matching process described in 5.4
Matching above to match all data elements in the rule.
While most rules in an APPEL ruleset will explicitly list the names
of all data elements that should be matched against, APPEL
implementations MUST also support the use of category-only data
reference elements in its rules.
Category-only data reference elements are
<DATA> elements that contain only a
category attribute, but no name attribute. Upon
encountering such a category-only data reference element in a rule,
an APPEL rule engine must implicitly translate each referenced
category into the list of base elements that belong into that
category, effectively representing the rule as if every element
from the P3P
base data set belonging to this category had been explicitly
listed instead.
Figure 5.4 below shows an example. In addition to any
fixed-category data element ("user.home.online.*" and
"user.business.online.*") the expansion also needs to
take into account any variable-category data elements
("dynamic.cookies" and "dynamic.miscdata") by
augmenting them with the proper category.
Any custom data schemes that have been introduced by the service
as to belonging to the referenced category will also be matched by
this mechanism. Please note again that user agents MUST NOT allow
services to override the category of fixed category base elements,
such as for example "user.name.first" or
"user.home.postal.city".
Figure 5.4: Category matching
<APPEL:RULE
behavior="reject">
<!-- This rule matches if an element from
the
"online" category has been
requested -->
<POLICY
APPEL:connective="and">
<STATEMENT
APPEL:connective="and">
<DATA-GROUP
APPEL:connective="or">
<DATA
category="online"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</APPEL:RULE> |
<APPEL:RULE
behavior="reject">
<!-- Explicit representation of the rule on the left.
-->
<POLICY
APPEL:connective="and">
<STATEMENT
APPEL:connective="and">
<DATA-GROUP
APPEL:connective="or">
<DATA
name="user.home.online.email"/>
<DATA
name="user.home.online.uri"/>
<DATA
name="user.business.online.email"/>
<DATA
name="user.business.online.uri"/>
<DATA
name="dynamic.cookies"
category="online"/>
<DATA
name="dynamic.miscdata"
category="online"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
</APPEL:RULE> |
It is up to APPEL trust engine implementations whether they
explicitly expand rules containing category-only data reference
elements, or if they instead augment each data reference element in
the evidence with the corresponding category (or with multiple
elements each featuring a different category, if multiple
categories are defined for the element) and simply match the
category attributes directly.
The following section summarizes the different matching semantics
described above and tries to give examples for matching
algrorithms.
The standard matching semantics for rules in APPEL are as follows:
An expression "E" matches a piece of evidence
"X" (i.e. a certain XML element in the evidence)
if and only if all of the following holds:
- the element names of E and X are
identical
- all of E's attribute expressions match
attributes of X (additional attributes in evidence
X which are not referenced in expression E are
ignored)
- [if an
or connective is given in E]
at least one of E's contained expressions
(if any) match X's enclosed elements (additional
enclosed elements in evidence X which are not referenced
in expression E are ignored).
- [if an
and connective is given in E]
all of E's contained expressions (if any)
match X's enclosed elements (additional enclosed
elements in evidence X which are not referenced in
expression E are ignored).
- [if an
or-exact connective is given in
E] at least one of E's contained
expressions (if any) match X's enclosed elements
(additional enclosed elements in evidence X which are
not referenced in expression E are not
ignored).
- [if an
and-exact connective, or if no
connective is given in E] all of E's
contained expressions (if any) match X's enclosed
elements (additional enclosed elements in evidence X
which are not referenced in expression E are
not
In order to better understand the implications of the above
distinctions in the matching process this sections lists a sample
algorithm for implementing the matching semantics of APPEL Level
1.
For each expression in the rule, find a match in the evidence
such that the following conditions (C1-C3) hold:
| C1 |
the matching evidence is the same type of XML element as
the rule expression (i.e. <STATEMENT>, <POLICY>,
etc.) |
| C2 |
for every attribute-expression in the rule expression, an
attriubte-expression exists in the evidence with the same
attribute name and a value that matches according to the
appropriate attribute-expression matching rules |
|
|
If the expressions features an
or connective: |
| C3a |
for at least one nested XML element contained
within the expression, C1 through C3 are satisfied. |
|
|
If the expressions features an
and connective: |
| C3b |
for each nested XML element contained within the
expression, C1 through C3 are satisfied. |
|
|
If the expressions features an
or-exact connective: |
| C3c |
for each nested XML element in the
evidence, C1 through C3 are satisfied. |
|
|
If the expressions features no
connective, or an exact connective: |
| C3d |
for each nested XML element contained within the
expression, and for each nested XML element in
the evidence, C1 through C3 are satisfied. |
If a match can be found for every expression, then the rule
fires.
When the first draft of this document was released, the working
group felt that, although it had met the requirements it had set,
the resulting language was complex and difficult to grasp fully. It
was argued that as long no one actually tried to use this language
in a real world application it would be hard to assess the
suitability of the language design for expressing privacy
preferences.
As mentioned in section 1.3
Requirements above, an effort was made to simplify the
specification in order to facilitate the implementation of early
P3P user agents that would support rulesets expressed in APPEL. By
separating a set of extensions (Level 2) from the core
language (Level 1) the working group hopes to encourage
early adoptions of APPEL, allowing us to gain some first hand
experiences with a privacy preference language before finalizing
the full feature set of APPEL.
In its Level 2 revision, the working group plans to add
the following constructs to the syntax and semantics of the
language that have previously been left out (i.e. in Level
1) in order to allow for simple initial implementations:
- Extensible behaviors: User Agents (e.g. browsers) can
define their own set of behaviors and let rules use them. In
order to preserve portability accross different user agents, a
fallback mechanism guarantees that a known behavior is
always executed.
- Matching external schemas: Expressions can contain
<POLICY> elements as well as external elements
such as PICS labels or Protocol features (e.g. "SSL in
use").
- Optional rules: Rules that are truly cosmetic can be
ignored should a non-standard behavior be unknown to the
particular user agent in use.
- Optional schemas: Expressions can be tagged
optional and thus allow rule execution even if a referenced
schema is not available (e.g. no information about the status of
the Protocol Security, no existing P3P policy, etc).
- Groups & Triggers: Sets of rules can be collated
into groups allowing selective activation of certain
privacy preferences depending on triggers such as URLs,
PICS labels, etc.
- Comparison operators for simple numeric expressions:
Ranges of allowed values can be expressed by using common
mathematical comparison operators such as <, >, <=,
>=, etc.
- Expiration dates: Rules and Groups can be set to
expire at a certain point, allowing user agents (and users) to
create temporary rules.
Although backward compatibility is a high priority, this can not be
guaranteed at this time. Work is currently underway to extend the
APPEL core language (i.e. APPEL Level 1) to use the above
features, and comments to
www-p3p-public-comments@w3.org regarding the usability of
current and planned features are highly encouraged.
B.1 ALMOST ANONYMOUS
This ruleset provides a nearly anonymous browsing experience. It
warns about web sites that make an access disclosure other than
"identifiable data is not used." It warns about web sites
that collect physical contact information, online contact
information, financial account identifiers, and data described as
"other" data. It allows for the collection of other kinds
of data and the use of state management mechanisms as long as this
data will not be shared, will not be used for contacting visitors
for marking, will not be used for individual profiling, and will
not be used for purposes described as "other" uses. Users
wishing to engage in electronic commerce activities that require
the exchange of personal information such as payment and billing
information will have to override these settings on a site by site
basis.
Figure B.1: "Almost Anonymous" Ruleset
B.2 PRIVACY AND COMMERCE
This ruleset allows users to exchange personal information needed
for electronic commerce activities while providing warnings when
that information may be shared with legal entities following
different practices, public fora, or unrelated third parties; or
used for marketing, profiling, or "other" purposes. A
warning will also be provided if the site collects healthcare
information. An informational prompt will be provided at sites that
provide no access
Figure B.2: "Privacy And Commerce" Ruleset
B.3 LOOK FOR THE SEAL
This ruleset allows users to exchange any type of personal
information for any purpose with web sites that have either a
"PrivacyProtect" or "TrustUs" seal as long as
those sites do not share the information with unrelated third
parties. It also allows users to exchange personal information
needed for electronic commerce activities with any site, while
providing warnings when that information may be shared with legal
entities following different practices, public fora, or unrelated
third parties; or used for marketing, profiling, or
"other" purposes by sites that do not have a seal. An
informational prompt will be provided at sites that have seals and
collect healthcare information; a warning will be provided at sites
that do not have seals and collect healthcare information. An
informational prompt will be provided at sites that provide no
access.
Figure B.3: "Look For The Seal" Ruleset
B.4 INFORMATION ONLY
This ruleset allows users to exchange any type of personal
information for any purpose. However, it provides informational
prompts when sites collect data for marketing, profiling, or
"other" purposes; share data with legal entities
following different practices, public fora, or unrelated third
parties; or collect healthcare information.
Figure B.4: "Information Only" Ruleset
While a special-purpose APPEL engine might be built for use in a
P3P user agent, P3P implementors might also consider using an
existing database engine or trust engine for this purpose. For
example, an SQL engine or an engine for the Keynote Trust
Management System [Keynote] might prove
useful. Use of one of these engines would likely require that the
APPEL syntax be translated into the syntax expected by the engine.
This could likely be done trivially by a translation script. The
Working Group encourages experimentation in this area.
The formal grammar of APPEL is given in this specification using
a slight modification of [ABNF]. Please note that such
syntax is only a grammar representative of the XML syntax: all the
syntactic flexibilities of XML are also implicitly included; e.g.
whitespace rules, quoting using either single quote (') or double quote
("), character
escaping, comments, and case sensitivity. In addition, note that
attributes and elements may appear in any order.
The following is a simple description of the ABNF.
-
name = (elements)
- where <name> is the name of the rule, <elements>
is one or more rule names or terminals combined through the
operands provided below. Rule names are
case-insensitive.
-
(element1
element2)
- elements enclosed in parentheses are treated as a single
element, whose contents are strictly ordered.
-
<a>*<b>element
- at least <a> and at most <b> occurrences of the
element.
- (1*4<element> means one to four
elements.)
-
<a>element
- exactly <a> occurrences of the element.
- (4<element> means exactly 4 elements.)
-
<a>*element
- <a> or more elements
- (4*<element> means 4 or more elements.)
-
*<b>element
- 0 to <b> elements.
- (*5<element> means 0 to 5 elements.)
-
*element
- 0 or more elements.
- (*<element> means 0 to infinite
elements.)
-
[element]
- optional element, equivalent to *1(element).
- ([element] means 0 or 1 element.)
-
"string" or 'string'
- matches the literal string given inside double quotes.
Other notations used in the productions are:
- ; or /* ... */
- comment.
| Lorrie Cranor |
AT&T Labs-Research |
| Marc Langheinrich (Editor & Chair) |
ETH Zürich |
| Massimo Marchiori |
W3C |
| Joerg Meyer |
IBM |
| Joseph Reagle |
W3C |
| Drummond Reed |
Intermind |
| Mary Ellen Zurko (former Chair) |
Iris |
- [ABNF]
- D. Crocker, P. Overel. "RFC2234
-- Augmented BNF for Syntax Specifications: ABNF," Internet Mail
Consortium, Demon Internet Ltd., November 1997. See /rfc/rfc2119.txt at http://www.ietf.org/.
- [Keynote]
- Blaze, Feigenbaum, Keromytis, "Keynote
Trust Management System".
- [PicsRules]
- Christopher Evans, Clive D.W. Feather, Alex Hopmann, Martin
Presler-Marshall, Paul Resnick, "PICSRules
Specification" 29 December 1997. See /TR/REC-PICSRules at http://www.w3.org/
- [P3P10]
- Massimo Marchiori (editor), "Platform for Privacy
Preferences 1.0 (P3P1.0) Specification" 11 February 2000
[Work in progress]. See
/TR/P3P/ at
http://www.w3.org/
- [RDF]
- Ora Lassila, Ralph R. Swick (editors), "Resource Description
Framework (RDF) Model and Syntax Specification" 22
February 1999. See /TR/REC-rdf-syntax at
http://www.w3.org/
- [RFC 2068]
- R. Fielding et al,
"Hypertext Transfer Protocol -- HTTP/1.1" January
1997. See
/rfc/rfc2068.txt at
http://www.ietf.org/.
- [RFC 2119]
- S. Bradner,
"Key words for use in RFCs to Indicate Requirement
Levels" See /rfc/rfc2119.txt at http://www.ietf.org/.
- [RFC 822]
- David H. Crocker (editor), Standard for the format
of ARPA Internet text messages See /rfc/rfc822.txt at http://www.faqs.org/.
- [URI]
- T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform
Resource Identifiers (URI): Generic Syntax and Semantics."
1997. (Work in progress; see updates to RFC1738.)
- [UTF-8]
- F. Yergeau.
"RFC 2279 -- UTF-8, a transformation format of ISO
10646." January 1998. See See /rfc/rfc2279.txt at http://www.ietf.org/
