Goals and Features

    APPEL is a language for describing collections of preferences regarding P3P proposals between P3P agents. Using this language, a user can express his preferences in a set of preference-rules (called a ruleset), which can then be used by his user-agent to make automated or semi-automated decisions regarding the exchange of data with P3P enabled Web sites. APPEL complements the P3P specification as described in Appendix B, Platform for Privacy Preferences Project (P3P) .

    APPEL can be seen as an ordered rule-based language to express a user's preferences regarding the release of personal information. In comparison, the P3P 1.0 specification provides a syntax for specifying proposals and a protocol and associated syntax for exchanging information between Web sites and user agents. The concept behind using P3P in conjunction with APPEL is that of a rule evaluator. In a P3P transaction, the rule evaluator checks incoming P3P proposals against a user's preferences which are expressed in APPEL. The result of rule evaluation determines which action the user agent will take in the current P3P transaction. This can vary between a seamless acceptance of the proposal, a warning or a seamless rejection, among others. The current APPEL working draft specifies the following things:

  1. A grammar to express a user's preferences.
  2. The concept of rule evaluation and the algorithm describing how to perform rule evaluation.
  3. In addition to this, it is APPEL's goal to support and provide

  4. sharing and installation of rulesets,
  5. the communication to agents, search engines, proxies, or other servers and
  6. the portability between products.

Technical Specification

    APPEL defines a user's preferences with one or more rules, a so-called ruleset. These rulesets are represented as XML [14] documents which follow the same conventions as generic XML. Whereas P3P is exchanged in real time, there is no such intention for APPEL rulesets to be exchanged by special means such as the HTTP extension mechanism.

    In order to facilitate the rapid development of prototype implementations of APPEL, the respective W3C working group decided to divide APPEL into a Level 1 specification (basic privacy preferences) and a more sophisticated and detailed Level 2 specification (the rest of the requirements of the latest working draft). The following sections give an overview of APPEL level 1 and 2 and explain the differences.

    Both levels share the same denotion of a rule. A rule is defined by a behavior and one or more expressions. During rule evaluation, the rule's expressions will be checked against the evidence (usually a P3P proposal). If all the expressions evaluate to true, the rule's behavior specifies the action to be taken by the user agent. The two APPEL levels differ in the structure of rulesets as well as the number of attributes and values ruleset elements can have. The following sections illustrate the two grammars and the concept of rule evaluation.

APPEL Level 1 Grammar

    A level 1 APPEL ruleset consists of one or more rules in a so-called ruleset (1).

    [1] ruleset = '<APPEL xmlns="http://www.w3.org/APPEL">'

    "<RULESET " attributes ">" rseq "</RULESET>"

    "</APPEL>"

    [2] rseq = "<RDF:SEQ>" *("<RDF:LI>" rule "</RDF:LI>") "</RDF:SEQ>"

    (note: this might be further simplified by future RDF specs)

    The rules (rule, 3) in the ruleset are encapsulated by XML elements. These elements follow the syntax model of the Resource Description Framework (RDF) [16] . Each of the APPEL rules specifies a behavior (6), other optional attributes (4), and at least one expression (7).

    [3] rule = "<RULE behavior=" `"` behavior `"`

    attributes ">"

    body

    "</RULE>"

    [4] attributes = [" persona=" quoted-string]

    [" crtby=" quoted-string]

    [" crton=" '"' datetime '"']

    [" description=" quoted-string]

    [5] body = expression | '<OTHERWISE/>'

    [6] behavior = "seamless-accept" | "seamless-reject" |

    "info-prompt" | "warn-prompt"

    [7] expression = <A chunk of RDF code>

    [8] quoted-string = `"` string `"`

    [9] string = <[UTF-8] string (with " and & escaped)>

    [10] datetime = <date/time as per section 3.3 of [RFC 2068]>

    As shown above, APPEL level 1 specifies four predefined behaviors.

APPEL Level 1 Rule Evaluation

    An APPEL rule evaluator will be invoked by a P3P enabled application. This application activates the rule evaluator by providing various pieces of evidence (a P3P proposal, a Unified Resource Identifier (URI), etc.) and an APPEL ruleset.

    Rule evaluation is performed with respect to the evidence provided. Each rule is checked against the evidence in the order in which the rules appear in the ruleset. Rule evaluation ends when a rule fires (is satisfied) or when there are no more rules to evaluate. If a rule fires during rule evaluation, the rule's behavior will be returned by the rule evaluator. If no rule fires during rule evaluation the rule evaluator should return an error. A rule can fire if any of the available evidence satisfies the rule. A piece of evidence satisfies a rule when all of the rule's expressions evaluate to true. APPEL level 1 features two types of expressions which can be used in a rule to match available evidence. Simple Expressions are used to match attributes of arbitrary XML elements and their respective values, such as

<P3P:PROP realm="*.myBank.com"> or <P3P:STATEMENT VOC:purp="0,1,2">.

    The other type of expressions are Data Reference Expressions, which are special expressions to match data reference elements inside P3P proposals, such as

<DATA:REF name="user.name.*"> 1 .

    The way rule evaluation is performed on these expressions varies depending on the rule's behavior. For example if the rule's behavior is seamless-accept rule evaluation uses a much stricter matching process for multi-valued simple expressions. In such a rule, VOC:purp="0,1,2" can only be matched by a proposal that specifies only the values 0, 1, or 2 (or any combination of these) but will not be matched by any proposal that specifies other values. The other types of rules (seamless-reject, info-prompt, and warn-prompt) would be matched even if the evidence contained values other than 0, 1 or 2, as long as at least one of the values is present. This can be understood as an ONLY-OR matching for seamless-accept rules and a simple OR matching for the other types of rules. Rule evaluation also differs for data reference expression matching (ONLY-OR-NONE compared to OR). APPEL's matching semantics are the most complex part of the APPEL specification. The sensitive nature of APPEL's domain, i.e. personal information, made it necessary to make a number of exceptions to the standard matching semantics. A complete description of these semantics would exceed the scope of this introduction. For more detailed information about rule evaluation, please refer to the latest APPEL working draft at the W3C Web site and the next section which illustrates a sample APPEL level 1 ruleset.

Sample Ruleset

    The following APPEL level 1 ruleset illustrates the use of the four kinds of APPEL rules. The rules are self-descriptive (see description-attributes). For information about thevarious P3P elements and attributes please refer to the P3P specification at the W3C Web site or see Appendix B, A P3P Preference Exchange Language (APPEL) .

    APPEL level 1 sample ruleset.

    <APPEL:APPEL xmlns="http://www.w3.org/APPEL" Order="RDF:Seq">

    <APPEL:RULESET crtdby="APPEL WG" crtdon="Wed, 12-Aug-1998 09:12:32 GMT">

    <RDF:SEQ> <!-- Might be simplified by later versions of RDF -->

    <RDF:LI>

    <APPEL:RULE behavior="seamless-accept"

    description="Service only collects clickstream data">

    <P3P:PROP>

    <P3P:USES><P3P:STATEMENT action="r" VOC:id="0">

    <DATA:REF name="ID.PUID"/>

    <DATA:REF name="ClickStream.Client_"/>

    </P3P:STATEMENT></P3P:USES>

    <VOC:DISCLOSURE discURI="*"/>

    </P3P:PROP>

    </APPEL:RULE>

    </RDF:LI>

    <RDF:LI>

    <APPEL:RULE behavior="info-prompt"

    description="Service collects your

    name for non-marketing purposes">

    <P3P:PROP VOC:purp="0,1,2,3">

    <P3P:USES><P3P:STATEMENT action="r">

    <DATA:REF name="user.name.*"/>

    </P3P:STATEMENT></P3P:USES>

    </P3P:PROP>

    </APPEL:RULE>

    </RDF:LI>

    <RDF:LI>

    <APPEL:RULE behavior="seamless-reject"

    description="Service collects identifiable

    data for 3rd parties">

    <P3P:PROP>

    <P3P:USES><P3P:STATEMENT VOC:id="1" VOC:recpnt="1,2,3">

    </P3P:STATEMENT></P3P:USES>

    </P3P:PROP>

    </APPEL:RULE>

    </RDF:LI>

    <RDF:LI>

    <APPEL:RULE behavior="warn-prompt"

    description="Suspicious Proposal. Beware!">

    <APPEL:OTHERWISE/>

    </APPEL:RULE>

    </RDF:LI>

    </RDF:SEQ>

    </APPEL:RULESET></APPEL:APPEL>

    The first rule (seamless-accept) of the APPEL level 1 ruleset as shown in Figure C-1 on page 113 will fire if the P3P proposal in the evidence collects only the user's clickstream data, and an automatically created identifer (ID.PUID). The rule only allows read access in a non-identifiable matter. Furthermore, it requires the P3P proposal to specify a disclosure statement. If a P3P proposal matches all of the above conditions, the rule evaluator will return the behavior seamless-accept and the user agent can agree to the proposal automatically.

    The second rule (info-prompt) will fire if a P3P proposal asks for any part of a user's name for the specified purposes [17] . The behavior indicates that the proposal is not violating the user's privacy preferences, but the user agent should inform the user and have the user decide whether to accept the proposal or not.

    The third rule (seamless-reject) will be satisfied by every proposal which indicates that it collects data which is then be used in an identifiable manner and given out to third parties. When this rule is satisified, it indicates that the provided evidence is not acceptable and that the user agent should either abort the current transaction automatically or seamlessly reject the received P3P proposal (by sending a SORRY message).

    The last rule (warn-prompt) will fire in any case where the evidence does not satisfy any of the previous rules. If this rule fires during rule evaluation, the user agent should inform the user that the rule evaluator detected a potential for violations of the user's privacy preferences in the received proposal. It is still the user's decision though whether to agree to the proposal or not.

APPEL Level 2 Grammar

    APPEL level 2 provides a set of extensions to APPEL level 1. The following list explains these extensions briefly:

  1. Whereas level 1 only allows the user to express preferences regarding P3P proposals, APPEL level 2 allows users to express their preferences regarding P3P as well as other RDF metadata (external schemas) relevant to P3P decision making. For example, a rule could contain a statement such as <SSL:PROTOCOL active="yes"> which requires a secure connection for the rule to be satisfied.
  2. APPEL level 2 provides an extension mechanism for rule behaviors. In addition to the four standard behaviors in APPEL level 1, user agents can define their own sets of behaviors.
  3. Expressions inside a rule can be marked as optional. Thus, rule execution would be possible even if a referenced schema is not available.
  4. An additional level of structure is added to a ruleset. Sets of rules can be grouped together. Groups allow selective activation of certain privacy preferences depending on triggers. A trigger contains one or more expressions and determines whether a group can become active during rule evaluation.
  5. Comparison operators and quantifiers provide a more sophisticated syntax for simple expressions. Ranges of values (<P3P:STATEMENT purp="<=2">) or groupings of values (<P3P:STATEMENT purp="AND:0,1,2">) can be expressed using additional keywords. APPEL level 2 also offers extended wildcard matching (*,+,?,\*,\+,\?).
  6. Data references can be marked to match if at least one, all or no additional data references match. These markers are called data reference quantifiers.
  7. By providing expiration dates, APPEL level 2 allows users and their agents to use temporary rules.
  8. The above mentioned extensions result in an extended grammar for APPEL level 2:

    [1] ruleset = '<RDF:RDF xmlns="http://www.w3.org/RDF">'

    '<APPEL xmlns="http://www.w3.org/APPEL">'

    "<RULESET " attributes ">"

    gseq

    "</RULESET>"

    "</APPEL>"

    "</RDF:RDF>"

    [2] gseq = "<RDF:SEQ>" *("<RDF:LI>" group "</RDF:LI>) "</RDF:SEQ>"

    [3] group = "<GROUP" attributes ">"

    "<TRIGGERS>" tseq "</TRIGGERS>"

    "<RULES>" rseq "</RULES>"

    "</GROUP>"

    [4] tseq = "<RDF:BAG>"

    *("<RDF:LI>" expression "</RDF:LI>")

    "</RDF:BAG>"

    [5] rseq = "<RDF:SEQ>" *("<RDF:LI>" rule "</RDF:LI>") "</RDF:SEQ>"

    [6] rule = "<RULE>" " behavior=" `"` behavior *("," behavior) `"`

    [" quant=" quantifier]

    attributes ">"

    body

    "</RULE>"

    [7] attributes = [" exp=" '"' datetime '"'] ; default is empty=never

    [" persona=" quoted-string]

    [" crtby=" quoted-string]

    [" crton=" '"' datetime '"']

    [" description=" quoted-string]

    [8] body = *optexp | '<OTHERWISE/>'

    [9] behavior = "accept" | "reject" | "prompt" | "nop" | string

    [10] quantifier = "ANY" | "ALL" | "ONLY" | "NOT-ONLY"

    [11] optexp = '<OPTIONAL>' expression '</OPTIONAL>' | expression

    [12] expression = <A chunk of RDF code>

    [13] quoted-string = `"` string `"`

    [14] string = <[UTF-8] string (with " and & escaped)>

    [15] datetime = <date/time as per section 3.3 of [RFC 2068]>

    Not listed in the extended grammar are the comparison operators (<,>,<=,>=) and quantifiers (AND:, ONLY:, ONLY:AND:, NOT:, NOT:, NOT:AND:, NOT:ONLY:AND:, NOT:ONLY:) for simple expressions.

Rule Evaluation

    Basically, rule evaluation in APPEL level 2 works the same way as in APPEL level 1. Because of the additional structural information in APPEL level 2 rulesets (i.e., groups), rule evaluation first tries to find the right group by checking the respective triggers. The groups are checked in the order in which they appear in the ruleset. Once a trigger evaluates to true, the respective rule becomes active and its rules are evaluated in the order in which they appear in the group. All other groups and their rules are ignored for the rest of the process, even if no rule of the active group can fire. If no rule within the active group can fire or no group can become active, the rule evaluator returns with an error. Evaluating the rules of the active group works as in level 1 with a few modifications due to the additional quantifiers, operators and optional rules, expressions, and behaviors. The following section illustrates a sample APPEL level 2 ruleset.

Sample Ruleset

    The APPEL level 2 ruleset listed below shows the structural differences compared to an APPEL level 1 file. It contains two groups.

    APPEL level 2 sample ruleset.

    <RDF:RDF><APPEL:APPEL><APPEL:RULESET crtdby="APPEL WG"

    crtdon="Wed, 12-Aug-1998 09:12:32 GMT">

    <RDF:SEQ>

    <RDF:LI>

    <APPEL:GROUP description"Default Group">

    <APPEL:TRIGGERS>

    <P3P:PROP realm="www.myBank.com*">

    <SSL:PROTOCOL active="yes">

    </APPEL:TRIGGERS>

    <APPEL:RULES>

    ...

    </APPEL:RULES>

    </APPEL:GROUP>

    <APPEL:GROUP description"Default Group">

    <APPEL:TRIGGERS> <APPEL:OTHERWISE/> </APPEL:TRIGGERS>

    <APPEL:RULES>

    <RDF:SEQ>

    <RDF:LI>

    <APPEL:RULE behavior="seamless-accept"

    quant="ONLY-OR-NONE"

    description="Service only collects clickstream data">

    <P3P:PROP>

    <P3P:USES><P3P:STATEMENT action="r" VOC:id="0">

    <P3P:REF name="ID.PUID"/>

    <P3P:REF name="ClickStream.Client_"/>

    </P3P:STATEMENT></P3P:USES>

    <P3P:DISCLOSURE discURI="*"/>

    </P3P:PROP>

    </APPEL:RULE>

    </RDF:LI>

    <RDF:LI>

    <APPEL:RULE behavior="reject"

    description="I don't want to be identified!">

    <APPEL:OTHERWISE/>

    </APPEL:RULE>

    </RDF:LI>

    </RDF:SEQ>

    </APPEL:RULES>

    </APPEL:GROUP>

    </RDF:LI>

    </RDF:SEQ>

    </APPEL:RULESET></APPEL:APPEL></RDF:RDF>

    The first group will become active during rule evaluation if the current transaction is performed over a secure connection and the received proposal covers the realm of my bank. The rules of the first group were omitted for clarity. The second group is the default group which will always become active if the first group could not become active. This group should always be at the end of the ruleset, otherwise the groups listed after the default group will never become active. Please refer to the latest APPEL working draft [6] available at the W3C Web site. This document covers all the details about the different APPEL levels as well as a more sophisticated APPEL level 2 ruleset.


1. As one can see in the examples, APPEL level 1 offers simple wildcard matching. The only wildcard character available is *.


April 9, 1999 · Jörg Meyer · jmeyer@almaden.ibm.com