Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
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.
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 Specification 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 15 December 2000 Candidate Recommendation 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:
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:
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:
The working group limited the scope of APPEL as follows:
In order to facilitate the rapid development of prototype implementations of the language the working group decided to first release a Version 1.0 specification designed to express only basic privacy preferences, and later prepare a more detailed specification that would implement the rest of the requirements outlined above. Specifically, APPEL1.0 limits the requirements to
The remainder of this document will discuss the thus restricted version of APPEL, refered to as the APPEL1.0 specification. See Appendix A: Future Work for a list of possible extensions regarding the full list of requirements given above.
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.
<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1" discuri="http://www.example.com/ourprivacypolicy.html"> <ENTITY> <DATA-GROUP> <DATA ref="#business.name">CatalogExample</DATA> <DATA ref="#business.contact-info.postal.street">123 Main Street</DATA> <DATA ref="#business.contact-info.postal.city">Bethesda</DATA> <DATA ref="#business.contact-info.postal.stateprov">MD</DATA> <DATA ref="#business.contact-info.postal.postalcode">20814</DATA> <DATA ref="#business.contact-info.postal.country">US</DATA> </DATA-GROUP> </ENTITY> <ACCESS> <nonident/> </ACCESS> <DISPUTES-GROUP> <DISPUTES resolution-type="independent" service="http://www.PrivacySeal.example.org" short-description="PrivacySeal.example.org"> <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="Privacy Seal Logo"/> <REMEDIES> <correct/> </REMEDIES> </DISPUTES> </DISPUTES-GROUP> <STATEMENT> <CONSEQUENCE>We tailor our site based on your past visits, preferences, and personal information</CONSEQUENCE> <PURPOSE> <customization/> <develop/> </PURPOSE> <RECIPIENT> <ours/> </RECIPIENT> <RETENTION> <stated-purpose/> </RETENTION> <DATA-GROUP> <DATA ref="#dynamic.cookies"> <CATEGORIES> <state/> </CATEGORIES> </DATA> <DATA ref="#dynamic.miscdata"> <CATEGORIES> <preference/> </CATEGORIES> </DATA> <DATA ref="#user.gender"/> <DATA ref="#user.home-info" optional="yes"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <CONSEQUENCE>We record some information in order to serve your request and to secure and improve our Web site.</CONSEQUENCE> <PURPOSE> <admin/> <develop/> </PURPOSE> <RECIPIENT> <ours/> </RECIPIENT> <RETENTION> <indefinitely/> </RETENTION> <DATA-GROUP> <DATA ref="#dynamic.clickstream"/> <DATA ref="#dynamic.http.useragent"/> </DATA-GROUP> </STATEMENT> </POLICY>
The following definitions (in alphabetical order) reflect the way terms are commonly used in this document.
or
,
and
, non-or
, non-and
,
or-exact
and and-exact
. See section 5.4.1 Connectives for more details.<POLICY>
and
<appel:REQUEST>
elements to be used as top-level expressions in a rule.
<OTHERWISE>
element.
<appel:RULE>
element. In APPEL1.0 , the top-level
expression can only be a <POLICY>
or
<appel:REQUEST>
element, or the degenerate expression.<appel:RULE behavior="..."
...>rule</appel:RULE>
In addition, this specification uses the same words as RFC 2119 [RFC2119] for defining the significance of each particular requirement. These words are:
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
and prompt
attributes) 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 behavior outputs as follows:
HTTP user agents often include a variety of non-essential
headers with their requests. These are optional headers such as the
REFERER
header, and headers that may help the server
provide a response in an appropriate language or format. P3P user
agents that implement APPEL SHOULD, whenever feasible, limit the
use of these non-essential headers, sending them only to sites that
have declared them in P3P policies that trigger the request
behavior when evaluated against the user's preferences. This
may not always be feasible, however, if user agents need to send
requests before a P3P policy is evaluated to prevent performance
problems.
User agents MAY wish to monitor Web forms and
set_cookie
requests from Web sites, to make sure they are
consistent with the site's declared policy. Techniques for
doing this are beyond the scope of this specification.
In addition, applications should interpret the prompt attribute as follows:
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. However, in order to provide a comprehensive list of reasons why a particular behavior got triggered, user agents SHOULD continue evaluation and find additional rules with identical behavior and prompt attribute values. By having access to the combined list of description-message attribute values in all triggered rules, the user can get a comprehensive explanation for the behavior of the user agent.
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 "request" behavior without a prompt.
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:
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):
Element name only:
|
Element name, attributes, contained elements &
connective:
|
Element and attribute:
|
|
Element name, contained elements and
connective:
|
Attribute-expressions may take string or numeric values,
although APPEL will treat all values as simple strings. APPEL1.0
supports only the equality operator in attribute-expressions.
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). Contained expressions can use the
wildcard character anywhere where
#PCDATA
("parsed character data", SGML term
for character data that may contain both &entity;
and markup) can be used, i.e., between the opening and closing of a
tag. Further details are given in sections 5.4.1 Attribute Expressions and 5.4.3 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 six such connectives: or, and,
non-or, non-and¸ or-exact, and
and-exact. If no connective is given, APPEL defaults to
requiring and matches: only if all of the elements in the
evidence can be found in the rule (additional elements are
ignored), 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!
http://www.my-bank.com
, she accepts any data request as
long as her data is not redistributed to other recipients.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.3 Expression
Metacharacters. In row two 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 / Prompt |
Element/Set | URI | Disputes | Purpose | Recipient |
block / no |
category="physical", or category="demographic", or category="uniqueid" |
same, other, delivery, public or unrelated |
|||
request / no |
dynamic.http.useragent, dynamic.clickstream.server | * | |||
request / yes |
user.name.* | "PrivacyProtect" and "TrustUs" | current, admin, customization or develop | ||
request / no |
www.my-bank.com | ours | |||
limited / yes |
[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 block-rule (i.e.,
a rule with the string "block" 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, a "request" 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 seamlessly continues to request the resource if dispute information is available.
A "request" rule featuring a prompt="yes" attribute 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 "limited"-rule
(again using a prompt="yes" attribute)
encapsulating the degenerate
expression "appel:OTHERWISE"
will fire, prompting the user to (cautiously) decide on any policy
that has not been covered by any of the rules above, while using
only the absolutely required headers to make the request, if at
all.
001: <appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" 002: xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" 003: crtdby="W3C" crtdon="1999-11-03T09:21:32-05:00"> 004: <appel:RULE behavior="block" description="Service collects personal 005: data for 3rd parties"> 006: <p3p:POLICY> 007: <p3p:STATEMENT> 008: <p3p:DATA-GROUP> 009: <p3p:DATA> 010: <p3p:CATEGORIES appel:connective="or"> 011: <p3p:physical/> 012: <p3p:demographic/> 013: <p3p:uniqueid/> 014: </p3p:CATEGORIES> 015: </p3p:DATA> 016: </p3p:DATA-GROUP> 017: <p3p:RECIPIENT appel:connective="or"> 018: <p3p:same/> 019: <p3p:other-recipient/> 020: <p3p:public/> 021: <p3p:delivery/> 022: <p3p:unrelated/> 023: </p3p:RECIPIENT> 024: </p3p:STATEMENT> 025: </p3p:POLICY> 026: </appel:RULE> 027: <appel:RULE behavior="request" 028: description="My Bank collects data only for itself 029: and its agents"> 030: <appel:REQUEST-GROUP> 031: <appel:REQUEST uri="http://www.my-bank.com/*"/> 032: </appel:REQUEST-GROUP> 033: <p3p:POLICY> 034: <p3p:STATEMENT> 035: <p3p:RECIPIENT appel:connective="or-exact"> 036: <p3p:ours/> 037: </p3p:RECIPIENT> 038: </p3p:STATEMENT> 039: </p3p:POLICY> 040: </appel:RULE> 041: <appel:RULE behavior="request" 042: description="Service only collects clickstream data"> 043: <p3p:POLICY> 044: <p3p:STATEMENT> 045: <p3p:DATA-GROUP appel:connective="or-exact"> 046: <p3p:DATA ref="#Dynamic.HTTP.UserAgent"/> 047: <p3p:DATA ref="#Dynamic.ClickStream.Server"/> 048: </p3p:DATA-GROUP> 049: </p3p:STATEMENT> 050: <p3p:DISPUTES-GROUP> 051: <p3p:DISPUTES service="*"/> 052: </p3p:DISPUTES-GROUP> 053: </p3p:POLICY> 054: </appel:RULE> 055: <appel:RULE behavior="request" prompt="yes" 056: description="Service only collects your name 057: for non-marketing purposes (assurance 058: from PrivacyProtect and TrustUs)"> 059: <p3p:POLICY> 060: <p3p:STATEMENT> 061: <p3p:PURPOSE appel:connective="or-exact"> 062: <p3p:current/> 063: <p3p:admin/> 064: <p3p:customization/> 065: <p3p:develop/> 066: </p3p:PURPOSE> 067: <p3p:DATA-GROUP appel:connective="or-exact"> 068: <p3p:DATA ref="#User.Name.*"/> 069: </p3p:DATA-GROUP> 070: </p3p:STATEMENT> 071: <p3p:DISPUTES-GROUP> 072: <p3p:DISPUTES service="http://www.privacyprotect.com"/> 073: <p3p:DISPUTES service="http://www.trustus.org"/> 074: </p3p:DISPUTES-GROUP> 075: </p3p:POLICY> 076: </appel:RULE> 077: <appel:RULE behavior="limited" prompt="yes" 078: description="Suspicious Policy. Beware!"> 079: <appel:OTHERWISE/> 080: </appel:RULE> 081: </appel:RULESET>
Using the line numbers in the example above, we will briefly
explain the basic structure of an APPEL ruleset.
Lines | Explanation |
---|---|
000 - 081 |
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:appel="http://www.w3.org/2001/02/APPELv1" ' common-attributes '>' rseq '</appel:RULESET>' [2] rseq = 1*rule |
004 - 026 |
"block" rule. APPEL offers three
distinct kinds of behaviors
for rules:
"request",
"block", and
"limited", each of which can optionally
prompt the user (prompt="yes" ).
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 '"' common-attributes rule-attributes [connective] '>' body '</appel:RULE>' [7] behavior = 'request' | 'block' | 'limited' 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, or could be used for debugging purposes). In
case we want the rule to prompt the user for a decision,
a separate prompt message attribute
( [4] common-attributes = [' crtdby=' quoted-string] [' crtdon="' datetime '"'] [' description=' quoted-string] [5] rule-attributes = [' prompt ="' ('yes'|'no') '"'] [' persona=' quoted-string] [' promptmsg=' quoted-string] |
006 - 025 |
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).
|
007 - 024 | STATEMENT element match. The
"block" 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-recipient/> " 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 block rule
will match regardless of the purpose
(<PURPOSE> ) specified in the
policy. |
010, 017, ... |
Connectives. Using the
appel:connective attribute, the rule author can
explictly specify different matching semantics for the
contained expressions of an element. APPEL supports six
different connectives (or , and ,
non-or , non-and ,
or-exact and and-exact ) that
implement different matching semantics. If no connective
is given, the default matching semantics require an
and match between the rule and the available
evidence.
[12] connective = 'appel:connective="' conn '"' [13] conn = or | and | non-or | non-and | or-exact | and-exact |
027 - 040 | Restricted request-rule. This
"request" 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. |
041 - 054 | request. The "request"
rule should only continue to request the resource 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. |
046 - 047 | Data Elements to match. Because
of the use of the "or-exact "-connective, the
"request" 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 45 and 48
of the ruleset would immediately evaluate the expression to
false (i.e. not accepting the
policy). |
050 - 052 | 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. |
055 - 076 | "prompt and request" 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. |
010, 017, 028, ... | 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. If a number of alternatives should not be matched, the "non-or" connective can be used. |
071 - 074 | 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). Because of
the implied "and" connective (this is the default
connective if no appel:connective attribute is given)
in the enclosing DISPUTES-GROUP element, this
represents a logical AND between the values. |
077 - 080 | "limited" rule. Since
rules in an APPEL ruleset are ordered, the
"limited" 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 prompt for all
incoming policies (see comment below). |
079 |
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 APPEL1.0 language, as well as encoding issues.
The BNF syntax below is just an informal representation of the actual
syntax. Please refer to Appendix C: XML Schema for
the normative description of the APPEL syntax. Detailed explanations can be
found in section 4.2 Elements.
[1] ruleset = '<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" ' common-attributes '>' rseq '</appel:RULESET>' [2] rseq = 1*rule [3] rule = '<appel:RULE behavior="' behavior '"' common-attributes rule-attributes [connective] '>' body '</appel:RULE>' [4] common-attributes= [' crtdby=' quoted-string] [' crtdon="' datetime '"'] [' description=' quoted-string] [5] rule-attributes = [' prompt ="' ('yes'|'no') '"'] [' persona=' quoted-string] [' promptmsg=' quoted-string] [6] body = top-expression | '<appel:OTHERWISE/>' [7] behavior = 'request' | 'block' | 'limited' [8] top-expression = policy | request-group [policy] [9] policy = <[P3P10] policy (including embed. connectives)> [10] request-group = '<appel:REQUEST-GROUP ' [connective] '>' 1*request '</appel:REQUEST-GROUP>' [11] request = '<appel:REQUEST uri="' [URI] as per RFC 2396 '">' [12] connective = 'appel:connective="' conn '"' [13] conn = or | and | non-or | non-and | or-exact | and-exact [14] quoted-string = '"' string '"' [15] string = <[UTF-8] string (with " and & escaped)> [16] datetime = <date/time as per section 3.3 of [RFC 2068]>
Details are described in section 4.2 Elements below. Please see also Appendix A: Future Work.
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>
element<appel:RULESET>
crtdby
crtdon
description
[1] ruleset = '<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" ' common-attributes '>' rseq '</appel:RULESET>' [2] rseq = 1*rule [4] common-attributes= [' crtdby=' quoted-string] [' crtdon="' datetime '"'] [' description=' quoted-string]
<appel:RULE>
element<appel:RULE>
behavior
(mandatory
attribute)crtdby
crtdon
description
prompt
persona
promptmsg
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 whenever a resource from
that particular site is requested, no matter what P3P policy
applies (even if no policy applies). If you want to match
sites that don't have a P3P policy, use the
non-or
or non-and
connectives in the
<appel:RULE>
element, together with a
<POLICY>
element. 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 '"' common-attributes rule-attributes [connective] '>' body '</appel:RULE>' [5] rule-attributes = [' prompt ="' ('yes'|'no') '"'] [' persona=' quoted-string] [' promptmsg=' quoted-string] [6] body = top-expression | '<appel:OTHERWISE/>' [7] behavior = 'request' | 'block' | 'limited' [8] top-expression = policy | request [policy]
<appel:OTHERWISE>
element<appel:OTHERWISE>
<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
request behavior, which would result in indiscriminated access
to all sites not covered by the preceding rules.
[6] body = top-expression | '<appel:OTHERWISE/>'
<appel:REQUEST>
element<appel:REQUEST>
uri
(mandatory
attribute)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.
[8] expression = policy | request | 1*<A chunk of XML code (including embed. connectives)> [9] policy = <[P3P10] policy (including embed. connectives)> [10] request-group = '<appel:REQUEST-GROUP ' [connective] '>' 1*request '</appel:REQUEST-GROUP>' [11] request = '<appel:REQUEST uri="' [URI] as per RFC 2396 '">'
appel:connective
attributeappel:connective
APPEL supports six different kinds of connectives:
or
, and
, non-or
,
non-and
, or-exact
and and-exact
.
Please refer to section 5.4.1
Connectives for a description of their semantics. If no
appel:connective
is given, APPEL's matching semantics
default to an and
match: All of the
containedexpressions must appear in the evidence,
additional elements will be ignored.
[12] connective = 'appel:connective="' conn '"' [13] conn = or | and | non-or | non-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 three standard behaviors
"request", "block" or "limited") that
the calling program should carry out (including any optional
prompt
attribute), 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 SHOULD
optionally return a prompt message (if applicable) and 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 three standard behaviors "request",
"block" or "limited". Each behavior may
optionally require a user prompt, as indicated by the
prompt
attribute. User agents SHOULD if possible support
such prompts.
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 "request".
Each rule contains a number of top-level expressions in
form of a well-formed XML element and features one single
behavior (with an optional prompt
attribute). 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).
Each expression in a rule is implicitly ANDed together with all
of its enclosed attribute expressions.
Contained expressions (including top-level 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!
Even though rules are evauluated strictly in order, independently of their behavior, the working group has found the following ordering to be helpful when (manually) creating APPEL rulesets:
After starting out with all cases which are deemed acceptable (request rules), append all situations under which only limited request should be made (limited rules). The final set of rules cover all cases that should result in a blocked request (block rules). Finally, prepend a list of exceptions (any behavior) to the list of rules, such as special provisions for trusted sites, etc. This ordering has proven to be helpful for members of the working group, both for creating as well as for maintaining rulesets.
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 APPEL1.0 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 top-level and contained
expressions.
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.,
and
) unless another connective
attribute is
used within the contained expression. See section 5.4.1 Connectives for details.
Figure 5.1 below gives the informal definition of the 3 main
types of expressions in APPEL.
[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 '"' [12] conn = or | and | non-or | non-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.
<-- ruleset --> <appel:RULE behavior="request"> <POLICY> <STATEMENT> <RECIPIENT appel:connective="or-exact"> <ours/> </RECIPIENT> <DATA-GROUP appel:connective="or-exact"> <DATA ref="#user.*"/> </DATA-GROUP> </STATEMENT> <STATEMENT> <PURPOSE appel:connective="or-exact"> <customization/> </PURPOSE> <DATA-GROUP> <DATA> <CATEGORIES appel:connective="or-exact"> <online/> </CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY> </appel:RULE> |
<-- evidence (abbreviated) --> <POLICY> ... <STATEMENT> <RECIPIENT><ours/></RECIPIENT> <PURPOSE><customization/></PURPOSE> <DATA-GROUP> <DATA ref="#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-exact
, non-or
or non-and
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
,
and-exact
, non-or
or non-and
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.
When using APPEL1.0 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.1 Connectives below) and can be
summarized as follows:
or
, or-exact
and non-or
connectives)non-or
connective is used, the rule will
fail in the above case, i.e. it only evaluates to
true if none of the contained expressions in the
current expression can be found in a corresponding element of
the evidence.and
,
and-exact
and non-and
connectives)non-and
connective is used, the rule
will fail in the above case, i.e. it only evaluates
to true if all of the contained expressions in the
current expression can be found in a corresponding element of
the evidence.or
, and
,
non-or
and non-and
connectives)or-exact
and and-exact
connectives)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. APPEL1.0 supports the following six connectives:
or
and
non-or
or
match described above:
NOT (... or ... or ...)
.non-and
and
match described above:
NOT (... and ... and ...)
.or-exact
and-exact
Connectives can only be used in <appel:RULE>
elements and below. If no connective is given, an and
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 and
connective applies
again.
The different matching semantics that result from the six
available connectives are summarized in Figure 5.3 below:
Contained expressions are | |||
---|---|---|---|
ORed | ANDed | ||
Additional evidence | is ignored | or , non-or |
and (default), non-and |
is not ignored | or-exact |
and-exact |
An attribute expression matches an attribute-value pair of an XML element in the evidence if and only if:
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. Since some attributes in P3P have a default value that applies when the attribute is not explicitly given in an element, the matching algorithm MUST represent such default attributes with their implicit values, in case a rule explicitly tries to match an attribute with its default value.
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. 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
<DISPUTES>
elements without
resolution-type
attribute), nor that a certain element is
absent from the evidence (e.g. matching policies that do
not include a disputes field).
Please note that attribute expressions match independently from any given connective, that is, no matter which connective is in effect, additional atributes found in the eveidence but not un the rule are always ignored.
APPEL offers a single metacharacter for providing simple regular expression support in its expressions: the asterix ("*") character, which is used to represent a sequence of 0 or more characters. This usage of the asterix character 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 APPEL1.0.
Note that since the asterix is also a legal character in URIs ([URI]), some special conventions have to be followed when encoding such "extended URIs" in an APPEL ruleset:
Please note also that the wildcard character is both allowed
within quoted strings (i.e., in attribute expressions) and between
XML elements (i.e., matching #PCDATA). However, you can not use the
wildcard character to match attribute or element names, as for
example in <DISPUTES res*="service">
or <DISP* resolution-type="service">
!
It can be applied in the above manner to match ranges of data
elements (i.e. subtrees) when used in data-reference expressions
(<DATA ref="#user.*"/>
), or to match a
set of data set leafs: <DATA
ref="#*.zipcode"/>
.
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:
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 ref="#dynamic.cookies">
<CATEGORIES><navigation/></CATEGORIES>
</DATA>
as well as rules that use data reference elements with categories only, such as
<DATA>
<CATEGORIES><preference/></CATEGORIES>
</DATA>
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:
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".
<appel:RULE
behavior="block"> <!-- This rule matches if an element from
the "online" category has
been requested --> <POLICY> <STATEMENT> <DATA-GROUP
appel:connective="or"> <DATA
category="online"/>
</DATA-GROUP> </STATEMENT> </POLICY> </appel:RULE> |
<appel:RULE
behavior="block"> <!-- Explicit representation of the rule on the
left. --> <POLICY> <STATEMENT> <DATA-GROUP
appel:connective="or"> <DATA
ref="#user.home.online.email"/> <DATA
ref="#user.home.online.uri"/> <DATA
ref="#user.business.online.email"/> <DATA
ref="#user.business.online.uri"/> <DATA
ref="#dynamic.cookies"
category="online"/> <DATA
ref="#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
non-or
connective is given in E] none 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
non-and
connective is given in E] not 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 APPEL1.0.
For [ at least one | each ]* expression in the rule, find a match in the evidence such that the following conditions (C1-C3) [ do | do not ]* 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 no connective, or an and
connective:C3b for each nested XML element contained within the expression, C1 through C3 are satisfied. If the expressions features an non-or
connective:C3c for none of the nested XML element contained within the expression, C1 through C3 are satisfied. If the expressions features an non-and
connective:C3d for at least one nested XML element contained within the expression, C1 through C3 are not 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 an and-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 | can not ]* be found for [ at least one | each ]* expression, then the rule fires.
* depending on the appel:connective
used in the
<appel:RULE>
element (compare with C3a-C3d).
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 from the core language (APPEL1.0) 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 future revisions, the working group considers adding the following constructs to the syntax and semantics of the language that have so far been left out (i.e. in APPEL1.0) in order to allow for simple initial implementations:
<POLICY>
elements as well as external elements
such as PICS labels or Protocol features (e.g. "SSL in
use").prompt
and description
messages,
sprintf
-like placeholders can be used within those
attributes-strings and will be replaced by the trust engine
with corresponding values from the matched evidence. Examples
for such placeholders would be:
%cq
(consequence)%op
(other purpose)%oc
(other category)%rd
(recipient description)%si
(site name)Comments to www-p3p-public-comments@w3.org regarding the usability of current and planned features are highly encouraged.
This ruleset provides a nearly anonymous browsing experience.
It prompts the user for a decision about Web sites that make an
access disclosure other than "identifiable data is not
used." It also prompts for Web sites that collect physical
contact information, online contact information, financial account
identifiers, and data described as "other" data. All
prompts imply that all but the absolutely necessary request headers
should be suppressed if the user decides to access the resource. 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.
<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" crtdby="W3C" crtdon="2000-03-15T10:55:32+01:00"> <appel:RULE behavior="limited" prompt="yes" description="Warning! Service collects some kind of identifiable information"> <p3p:POLICY> <p3p:ACCESS appel:connective="non-and"> <p3p:nonident/> </p3p:ACCESS> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Service collects physical and/or online contact information and/or financial account identifiers and/or other data that may be personally-identifiable"> <p3p:POLICY> <p3p:STATEMENT> <p3p:DATA-GROUP> <p3p:DATA> <p3p:CATEGORIES appel:connective="or"> <p3p:physical/> <p3p:online/> <p3p:uniqueid/> <p3p:financial/> <p3p:other-category/> </p3p:CATEGORIES> </p3p:DATA> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" description="Service does not collect identifiable data or share data with other parties"> <p3p:POLICY> <p3p:STATEMENT> <p3p:RECIPIENT appel:connective="and-exact"> <p3p:ours/> </p3p:RECIPIENT> <p3p:PURPOSE appel:connective="non-and"> <p3p:contact/> <p3p:telemarketing/> <p3p:individual-analysis/> <p3p:individual-decision/> <p3p:other-purpose/> </p3p:PURPOSE> <p3p:DATA-GROUP appel:connective="or-exact"> <p3p:DATA ref="#user.*"/> <p3p:DATA ref="#dynamic.*" category="state"/> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" description="Warning! Service requests data from your data repository or has a practice that doesn't match your preferences"> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET>
This ruleset allows users to exchange personal information
needed for electronic commerce activities while providing warning
prompts 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 prompt will also be provided if the site
collects healthcare information. All warnings imply that all but
the absolutely necessary request headers should be suppressed if
the user decides to access the resource. An informational prompt
will be provided at sites that provide no access to identifiable
information.
<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" crtdby="W3C" crtdon="2000-03-15T16:41:21+01:00"> <appel:RULE behavior="limited" prompt="yes" description="Warning! Data may be shared with legal entities following different practices, public fora, or unrelated third parties."> <p3p:POLICY> <p3p:STATEMENT> <p3p:RECIPIENT appel:connective="or"> <p3p:other-recipient/> <p3p:public/> <p3p:unrelated/> </p3p:RECIPIENT> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Data may be used for marketing, profiling or other purposes."> <p3p:POLICY> <p3p:STATEMENT> <p3p:PURPOSE appel:connective="or"> <p3p:contact/> <p3p:profiling/> <p3p:other-purpose/> </p3p:PURPOSE> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Site collects healthcare information."> <p3p:POLICY> <p3p:STATEMENT> <p3p:DATA-GROUP> <p3p:DATA> <p3p:CATEGORIES> <p3p:health/> </p3p:CATEGORIES> </p3p:DATA> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" prompt="yes" description="Service does not provide access to identifiable data it collects"> <p3p:POLICY> <p3p:ACCESS> <p3p:none/> </p3p:ACCESS> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" description="Privacy policy matches Privacy And Commerce preferences"> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET>
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 warning prompts (and suppressing
unnecessary request headers) 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 prompt (again,
suppressing all unnecessary headers) 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.
<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" crtdby="W3C" crtdon="2001-02-19T16:21:21+01:00"> <appel:RULE behavior="request" description="Service has privacy seal and does not share data with unrelated third parties."> <p3p:POLICY> <p3p:DISPUTES-GROUP appel:connective="or"> <p3p:DISPUTES resolution-service="independent" service="http://www.privacyprotect.org/*"/> <p3p:DISPUTES resolution-service="independent" service="http://www.trustus.org/*"/> </p3p:DISPUTES-GROUP> <p3p:STATEMENT> <p3p:RECIPIENT appel:connective="non-and"> <p3p:unrelated/> </p3p:RECIPIENT> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Service collects data needed for e-commerce activities but may share this data with legal entities following different practices, public fora, or unrelated third parties."> <p3p:POLICY> <p3p:STATEMENT> <p3p:PURPOSE appel:connective="and-exact"> <p3p:current/> </p3p:PURPOSE> <p3p:RECIPIENT appel:connective="or"> <p3p:other-recipient/> <p3p:public/> <p3p:unrelated/> </p3p:RECIPIENT> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Service collects data needed for e-commerce activities but may use it also for marketing, profiling, or 'other' purposes."> <p3p:POLICY> <p3p:STATEMENT> <p3p:PURPOSE> <p3p:current/> </p3p:PURPOSE> <p3p:PURPOSE appel:connective="or"> <p3p:contact/> <p3p:profiling/> <p3p:other-purpose/> </p3p:PURPOSE> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" prompt="yes" description="Site collects healthcare information but participates in a seal program."> <p3p:POLICY> <p3p:DISPUTES-GROUP> <p3p:DISPUTES p3p:resolution-service="independent" p3p:service="*"/> </p3p:DISPUTES-GROUP> <p3p:STATEMENT> <p3p:DATA-GROUP> <p3p:DATA> <p3p:CATEGORIES> <p3p:health/> </p3p:CATEGORIES> </p3p:DATA> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Site collects healthcare information but does not participates in a seal program."> <p3p:POLICY> <p3p:STATEMENT> <p3p:DATA-GROUP> <p3p:DATA> <p3p:CATEGORIES> <p3p:health/> </p3p:CATEGORIES> </p3p:DATA> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" description="Service collects data needed for e-commerce activities only, without sharing with legal entities following different practices, public fora or unrelated third parties. A seal program vouches for this."> <p3p:POLICY> <p3p:DISPUTES-GROUP> <p3p:DISPUTES p3p:resolution-service="independent" p3p:service="*"/> </p3p:DISPUTES-GROUP> <p3p:STATEMENT> <p3p:PURPOSE appel:connective="and-exact"> <p3p:current/> </p3p:PURPOSE> <p3p:RECIPIENT appel:connective="or-exact"> <p3p:ours/> <p3p:same/> <p3p:delivery/> </p3p:RECIPIENT> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="limited" prompt="yes" description="Warning! Service does not provide access to identifiable data it collects"> <p3p:POLICY> <p3p:ACCESS> <p3p:none/> </p3p:ACCESS> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" description="Privacy policy matches Look For The Seal preferences"> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET>
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, pseudonymous or
individual profiling, or "other" purposes; share data
with legal entities following different practices, public fora, or
unrelated third parties; or collect healthcare information.
<appel:RULESET xmlns:appel="http://www.w3.org/2001/02/APPELv1" xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" crtdby="W3C" crtdon="2001-02-19T16:04:02+01:00"> <appel:RULE behavior="request" prompt="yes" description="Service collects data for marketing, profiling, or 'other' purposes."> <p3p:POLICY> <p3p:STATEMENT> <p3p:PURPOSE appel:connective="or"> <p3p:contact/> <p3p:telemarketing/> <p3p:pseudo-analysis/> <p3p:pseudo-decision/> <p3p:individual-analysis/> <p3p:individual-decision/> <p3p:other-purpose/> </p3p:PURPOSE> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" prompt="yes" description="Service shares information with legal entities following different practices, public fora, or unrelated third parties."> <p3p:POLICY> <p3p:STATEMENT> <p3p:RECIPIENT appel:connective="or"> <p3p:other-recipient/> <p3p:public/> <p3p:unrelated/> </p3p:RECIPIENT> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" prompt="yes" description="Site collects healthcare information."> <p3p:POLICY> <p3p:STATEMENT> <p3p:DATA-GROUP> <p3p:DATA> <p3p:CATEGORIES> <p3p:health/> </p3p:CATEGORIES> </p3p:DATA> </p3p:DATA-GROUP> </p3p:STATEMENT> </p3p:POLICY> </appel:RULE> <appel:RULE behavior="request" description="Privacy policy matches Information Only preferences"> <appel:OTHERWISE/> </appel:RULE> </appel:RULESET>
This appendix contains the XML schema [XML Schema 1, XML Schema 2] for APPEL ruleset documents. An XML schema may be used to validate the structure and datastruct values used in an instance of the schema given as an XML document. APPEL ruleset documents are XML documents that MUST conform to this schema. The schema is also present as a separate file at the URI http://www.w3.org/2001/02/APPELv1.xsd
<!DOCTYPE schema PUBLIC '-//W3C//DTD XMLSCHEMA 200010//EN' 'http://www.w3.org/2000/10/XMLSchema.dtd' [ <!ATTLIST schema xmlns:appel CDATA #FIXED "http://www.w3.org/2001/02/APPELv1"> ]> <schema targetNamespace="http://www.w3.org/2001/02/APPELv1" xmlns="http://www.w3.org/2000/10/XMLSchema" xmlns:appel="http://www.w3.org/2001/02/APPELv1" elementFormDefault="qualified"> <!-- ********* APPEL Data Types ******** --> <simpleType name="yes_no"> <restriction base="string"> <enumeration value="yes"/> <enumeration value="no"/> </restriction> </simpleType> <simpleType name="connective-value"> <restriction base="string"> <enumeration value="or"/> <enumeration value="and"/> <enumeration value="non-or"/> <enumeration value="non-and"/> <enumeration value="or-exact"/> <enumeration value="and-exact"/> </restriction> </simpleType> <simpleType name="behavior-value"> <restriction base="string"> <enumeration value="request"/> <enumeration value="block"/> <enumeration value="limited"/> </restriction> </simpleType> <attributeGroup name="rule-attributes"> <attribute name="crtdby" type="string" use="optional"/> <attribute name="crtdon" type="timeInstant" use="optional"/> <attribute name="description" type="string" use="optional"/> </attributeGroup> <!-- ************ RULESET ************* --> <element name="RULESET"> <complexType> <sequence> <element ref="appel:RULE" maxOccurs="unbounded"/> </sequence> <attribute name="persona" type="string" use="optional"/> <attributeGroup ref="appel:rule-attributes"/> </complexType> </element> <!-- ************** RULE ************** --> <element name="RULE"> <complexType> <choice> <element ref="appel:OTHERWISE"/> <sequence> <element ref="appel:REQUEST-GROUP" minOccurs="0"/> <any namespace="http://www.w3.org/2000/12/P3Pv1" processContents="strict" minOccurs="0"/> </sequence> </choice> <attribute name="prompt" type="appel:yes_no" use="default" value="no"/> <attribute name="behavior" type="appel:behavior-value" use="required"/> <attribute name="connective" type="appel:connective-value" use="optional"/> <attribute name="promptmsg" type="string" use="optional"/> <attributeGroup ref="appel:rule-attributes"/> </complexType> </element> <!-- ********* REQUEST-GROUP ********** --> <element name="REQUEST-GROUP"> <complexType> <sequence> <element ref="appel:REQUEST" maxOccurs="unbounded"/> </sequence> </complexType> </element> <!-- ************* REQUEST ************ --> <element name="REQUEST"> <complexType> <attribute name="uri" type="uriReference" use="required"/> </complexType> </element> <!-- ************* OTHERWISE ************* --> <element name="OTHERWISE"> <complexType/> </element> </schema>
This appendix contains the DTD for policy documents and for data schemas. The DTD is also present as a separate file at the URI http://www.w3.org/2001/02/APPELv1.dtd
<!-- ************ Entities ************ --> <!ENTITY % URI "CDATA"> <!ENTITY % TIME "CDATA"> <!-- ************ RULESET ************* --> <!ELEMENT RULESET (RULE+)> <!ATTLIST RULESET xmlns CDATA #FIXED 'http://www.w3.org/2001/02/APPELv1' persona CDATA #IMPLIED crtdby CDATA #IMPLIED crtdon %TIME; #IMPLIED description CDATA #IMPLIED > <!-- ************** RULE ************** --> <!ELEMENT RULE ANY> <!ATTLIST RULE connective (or | and | non-or | non-and | or-exact | and-exact) #IMPLIED behavior (request | block | limited) #REQUIRED prompt (yes | no) #IMPLIED promptmsg CDATA #IMPLIED crtdby CDATA #IMPLIED crtdon %TIME; #IMPLIED description CDATA #IMPLIED > <!-- ********* REQUEST-GROUP ********** --> <!ELEMENT REQUEST-GROUP (REQUEST+)> <!-- ************* REQUEST ************ --> <!ELEMENT REQUEST EMPTY> <!ATTLIST REQUEST uri %URI; #REQUIRED >
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)
(
element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string"
or 'string'
Other notations used in the productions are:
/* ... */
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.
Lorrie Cranor | AT&T Labs-Research |
Matthias Enzmann | GMD |
Marit Köhntopp | Independent Center for Privacy Protection Schleswig-Holstein |
Yuichi Koike | NEC |
Marc Langheinrich | ETH Zürich (Editor & Chair) |
Massimo Marchiori | W3C |
Joerg Meyer | IBM |
Joseph Reagle | W3C |
Drummond Reed | OneName |
Rigo Wenning | W3C |
Mary Ellen Zurko | Iris (former Chair) |