W3CWD-P3P-preferences-19980814

A P3P Preference Exchange Language (APPEL)
Working Draft 

 
Latest Version:
http://www.w3.org/TR/WD-P3P-preferences
This version:
http://www.w3.org/TR/1998/WD-P3P-preferences-19980814
Previous Version:
--
Editor
Marc Langheinrich, NEC C&C Media Research Labs <marc@ccm.cl.nec.co.jp>

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensi ng rules apply.


Status of this Document

This is a draft working document of the P3P Preference Interchange Language Working Group, for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and may eventually be advanced toward W3C Recommendation status. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress."

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 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 p3p-comments@w3.org (archived for Members at http://lists.w3.org/Archives/Member/p3p-comments/).


Contents

  1. Introduction
    1. P3P Basics
    2. Goals of a P3P Preference Exchange Language
    3. Requirements
    4. Definitions
  2. General Operation and Semantics
    1. Inputs and Outputs to the Rule Evaluator
    2. Rule Processing & Evaluation
      1. Rule Processing
      2. Rule Evaluation
      3. Expressions
  3. Simple Example Scenarios
    1. User Preferences
    2. Tabular Overview
    3. APPEL ruleset
    4. Example explanation
  4. Technical Definition
    1. Syntax & Encoding
      1. BNF Syntax
      2. Transport & Storage
      3. XML Representation
    2. Elements
      1. APPEL
      2. RULESET
      3. GROUP
      4. TRIGGERS
      5. RULES
      6. RULE
      7. OTHERWISE
      8. OPTIONAL
  5. Semantics
    1. The Rule Evaluator in a nutshell
      1. Behaviors
      2. Rulesets
    2. Rule Ordering
    3. Expressions
      1. Multiple Expressions
      2. Optional Expressions
      3. Sub Elements
    4. Matching
      1. Simple Expressions
      2. Prefix Operators for Simple Expressions
      3. Wildcards
      4. Attribute Matching
      5. Data-Reference Expressions
      6. Category translation support
    5. Rule Expiration
    6. Extensible Behaviors
      1. Behavior Types
      2. Optional Behaviors
  6. Ruleset example
  7. Appendices
    1. Trust Engines and Database Engines
    2. Contributors
  8. References

1. Introduction

This document specifies a language for describing collections of preferences regarding P3P proposals between P3P agents. Using this language, a user can express her preferences in a set of preference-rules (called ruleset), which can then be used by her user-agent to make automated or semi-automated decisions regarding the exchange of data with 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 specifications. Much of the underlying logic is based on PICSRules. We hope in time that this will merely be an application of XML (XML-data) and RDF (RDF schema) definition, rules, or query languages.

1.1 P3P Basics

The P3P specification will enable Web sites to express their privacy practices and users to to exercise preferences over those practices. These preferences are expressed in a syntax akin to predicate logic. P3P products will allow users to be informed of site practices, to delegate decisions to their computer when possible, and allow users to tailor their relationship to specific sites. Sites with practices that fall within the range of a user's preference (as expressed in their ruleset) could, at the option of the user, be accessed "seamlessly." Otherwise users will be notified of a site's practices and have the opportunity to agree to those terms or other terms and continue browsing if they wish.

A basic P3P interaction might proceed as follows:

  1. The agent requests a Web page from a service.
  2. The service responds by sending one or more P3P proposals in an HTTP header or at a specified URI. A proposal consists of one or more statements about a service's privacy practices.
  3. The agent evaluates the proposal according the user's ruleset (which represents her preferences) and determines what action to take (e.g., deny, accept, prompt, or send a counter proposal).
  4. If the proposal is consistent with the user's preferences (either through the ruleset, or through a prompt) an agreement is reached and the agent sends the service a fingerprint of the proposal called an agreementID.
  5. The service sends the contents of the Web page.
  6. The agent displays the Web page for the user.
The proposal may include requests for specific data elements from the user. If these elements are already stored in the user's data repository, and if the request is consistent with the user's ruleset, the agent may send these elements to the site. If these elements are not in the repository, the agent may prompt the user to type in this information.

1.2 Goals of A P3P Preference Exchange Language

The P3P1.0 specification provides a syntax for specifying proposals and a protocol and associated syntax for exchanging information between the Web site and user agent. It does not not specify requirements upon the graphical user interface (GUI) or trust engines. However, there are benefits to being able to express the 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 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.

While we do not expect users to be exposed to the expression of the rules themselves, tools that allow them to test their rules may be useful. For instance, a user could make a query, "under what conditions do I give out identifiable information?"

1.3 Requirements

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:

1.4 Definitions

The following definitions (in alphabetical order) reflect the way terms are commonly used in this document.
behavior
The activity taken upon the completion of processing a rule (e.g., accept, prompt, reject, etc.).
behavior, "accept"ing
A behavior which, when executed by the user agent, results in the seamless transfer of data.
behavior, non-"accept"ing
A behavior which either simply rejects a request for data, or at least requires the user's confirmation before releasing or accepting data.
expression
A component of a rule that is expressed as an XML element and that can be evaluated to TRUE or FALSE. Also see section 5.3 Expressions.
expression, degenerate
An expression that always evaluates to true. See section 4.2.7 The OTHERWISE element.
expression, simple
An attribute-value pair contained in an expression. Three different type of simple expressions are possible in APPEL: Also see section 5.4.1 Simple Expressions (Value Matching).
expression, data-reference
An expression referencing a data reference element of a P3P proposal. Also see section 5.4.5 Data-Reference Expressions (Element Matching) in this draft.
group, active
The group of rules which is used for evaluating the evidence. Only one group and its set of rules can be active at any time.
policy
A site's privacy practices, as expressed in its P3P proposals.
preference (privacy, not qualified in use)
The user's desires regarding the collection and treatment of information exchanged under P3P and HTTP. Privacy preferences are formally expressed by a set of APPEL rules and are often captured through a GUI.
proposal
A proposal is a collection of one or more privacy statements together with information asserting the identity, URI, assurances, and disclosures of the service covered by the proposal. A proposal is always created from the point of view of the service and contains identifying information for the service, but it may be created by the user and sent to the server for approval.
quantifier
An attribute of a rule that determines how any data-reference expressions within the rule will be matched.
rule
The formal expression of a user's preference. Rules express the users preferences that are then compared to a services proposal. The action resulting from the comparison is defined by the behavior specified by the rule. The rule is delimited by a opening and closing element of the form (the behavior attribute is mandatory)
<APPEL:RULE behavior="...">rule</APPEL:RULE>
ruleset
A set of rules that define all of the user's P3P preferences.
schema, external
schema defined by this specification for the purpose of allowing users to express preferences over characteristics not found in the P3P 1.0 Syntax Specification, but which are important to privacy none-the less. (e.g., PICS, SSL, and DSIG).
schema, P3P base
schema defined in the P3P 1.0 Syntax Specification.
service
A program that issues proposals and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent.
statement, P3P
A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements, sets, and categories. The enumerated elements act as an embedded data request. A statement which references no data, requests no data.
triggers
A set of expressions associated with a certain group. Should all expressions listed as triggers of a certain group evaluate to true given the evidence, the group becomes active.
user
An individual (or group of individuals acting as a single entity) on whose behalf a service is accessed and for which personal data exists.
user agent
A program that acts on a user's behalf. The agent may act on preferences (rules) for a broad range of purposes, such as content filtering, trust decisions, or privacy. For P3P purposes, a user agent acts on a user's privacy preferences. Users may use different user agents at different times.
In addition, this specification uses the same words as RFC 2119 [RFC2119] for defining the significance of each particular requirement. These words are:
MUST
This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
MUST NOT
This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
SHOULD
This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT
This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
MAY
This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

2. General Operation and Semantics

The following sections give an overview of the basic operations of an APPEL rule evaluator.

2.1 Inputs and Outputs of the 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 proposal from the service if present. Evaluators may also consider additional metadata (external schema) not found within a P3P proposal but specified within this document. If the application supports non-standard behaviors extensions, it additionally provides the evaluator with a list of supported behaviors.

The scope of the rule is determined by the opening and closing elements of an APPEL RULE element. The evaluator returns the behavior (as specified in its behavior attribute) of the rule that fired on the basis of the evidence discussed above. In addition, the rule evaluator may optionally return an explanation string (suitable for user display), and the name of a persona.

Applications should interpret the standard outputs as follows:

In addition, APPEL supports extending the standard behavior by application specific behaviors. This mechanism is described in more detail in section 5.6 Extensible Behaviors.

2.2 Rule Processing and Evaluation

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.

2.2.1 Rule Processing

Rules are evaluated with respect to the evidence provided. A rule evaluates to true if an expression related to APPEL is satisfied. Basically, a rule is satisfied if any of the available evidence satisfies it.

A ruleset consists of one or more groups, each containing one or more rules. Each group optionally contains an (ordered) list of triggers specifying the conditions under which the group becomes active. Groups and their trigger conditions are evaluated in order they are listed in the ruleset. The first group whose triggers evaluate to true will be the active group and further evaluation of the evidence will use only the rules within the scope of that group (see section 5.1.2 Rulesets for further details).

Each rule in the active group is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned and rule evaluation ends. User Agents that wish to provide additional information in case a proposal is not accepted (such as listing all reasons why it was rejected, not only the first one that led to "reject") might require further evaluation in order to provide such information to the user.

Rulesets should be written so that there is always a group that will become active and a rule within that group that will fire. A rule evaluator should return an error if it is called without a ruleset, with an empty ruleset, if no group becomes active, 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 an "accept".

Further information on rule processing can be found in sections 5.1 "The Rule Evaluator in a nutshell" and 5.2 "Group, triggers and rules ordering".

2.2.2 Rule Evaluation

A rule includes a behavior, an optional persona, an optional explanation and a set of expressions. A rule with an empty set of expressions always evaluates to false. A rule containing only the degenerate expression always evaluates to true. Multiple expressions within a rule are implicitly ANDed together; thus, all must hold true for the rule to evaluate to true. Individual expressions are each composed of simple-expressions and data-reference expressions. Simple-expressions and data-reference-expressions within an expression are implicitly ANDed together as well.

When multiple simple-expressions and/or data-reference expressions are placed within the scope of a single expression, all must hold true within the scope of a single piece of evidence. For example, if a rule contains a P3P:STATEMENT expression that contains a simple-expression purpose="3" and a data-reference-expression name="ID.PUID", the expression will only evaluate to true if the P3P proposal contains a statement that both references the ID.PUID data element and declares a purpose of 3. If both the simple-expression and data-reference expression are satisfied, but only in separate statements, then the expression evaluates to false.

The matching of simple- and data-reference expressions, as well as matching attribute names, is described in more detail in section 5.4 Matching. A brief overview is given in the following paragraph.

2.2.3 Expressions

Simple-expressions may take string or numeric values. Only the = operator may be applied to string-valued simple expressions and multi-numeric-valued simple expressions. The following set of operators may be applied to single-numeric-valued simple expressions: =, <, >, <=, >= . The semantics of each of these operators follows their traditional usage when applied to single values; the result of applying any operator will be a Boolean value, true or false. Further details are described in section 5.4.1 Simple Expressions.

An implicit = operator applies to data-reference-expressions. Furthermore, data-reference-expressions that contain multiple data-references use one of the following quantifiers during matching: ANY, ONLY, ALL, NOT-ONLY. Quantifiers can be defined individually for each rule. However, rules that result in an "accept" behavior always use the semantics of the ONLY quantifier when matching data-reference-expressions, regardless of the specified quantifier. Further details are described in section 5.4.3 Data Reference Expressions.

APPEL supports a simple set of wildcard metacharacters as found in many popular operating system shells. Simple-expressions and data-reference-expressions can use these wildcards to match ranges of values such as <REF name="User.*"> (any element from the "User" data set) or discURI="+" (any non-empty disclosure URI attribute). Details can be found in section 5.4.3 Wildcards.

3 Simple Example Scenario

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:APPEL element), it is only used to demonstrate a small set of example rules. A more realistic example is given in section 6. Ruleset Example.

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. For the sake of clarity, the example will use the full XML namespace syntax, but this can easily be abbreviated for a more compact representation (See section 4.1.3 XML Representation). Also note that each listing in this document features line numbers for ease of reference; they are not part of the actual encoding!

3.1 User Preferences

  1. The user does not mind revealing non-identifiable click-stream and PUID information to sites that collect no other information. However, she insists that the service provides some form of assurance.

  2. All other requests for data transfer should be denied.

3.2 Tabular Overview

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 RDF encoding of a proposal, defined in the P3P-Syntax Working Draft for the list of fields referenced).

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 proposal 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 Wildcards

In 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 assurance is present (represented by a wildcard "*" character).

Behavior Element/Set Ent. Assur. Purp. Recip. Id Act. Disc.
accept ID.PUID, Clickstream.Client_   *     0 R *
reject [otherwise]              

3.3 APPEL ruleset

The following listing illustrates one way to encode the above preferences into an APPEL ruleset. Two rules are used to handle all incoming proposals from a publisher's site. An "accept"-rule (i.e., a rule with the string "accept" in its behavior attribute) first checks to see if only non-identifiable clickstream data and/or a pairwise user ID (PUID) is collected, and accepts if assurance and disclosure information is available. Otherwise, a "reject"-rule encapsulating the degenerate expression "OTHERWISE" will fire, rejecting proposals that contain requests for data transfer.

Alternatively, we could have written an initial "reject"-rule which denied all access to elements other than non-identifiable clickstream and/or the PUID, and then "accept" all proposals that pass the initial reject rule. This method is further explained in section 6. Ruleset Example.

Listing 1: Simple Ruleset in APPEL
001: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P-syntax#" prefix="P3P" ?>
002: <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF" ?>
003: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-APPEL10#" prefix="APPEL" ?>
004: <RDF:RDF>
005: <APPEL:APPEL>
006: <APPEL:RULESET crtdby="APPEL WG" crtdon="Wed, 12-Aug-1998 09:12:32 GMT">

007: <RDF:SEQ>
008:   <RDF:LI>
009:   <APPEL:GROUP description"Default Group">

010:     <!-- We specify OTHERWISE as the only trigger condition here so that
011:          this group is always active -->
012:     <APPEL:TRIGGERS>
013:       <APPEL:OTHERWISE/>
014:     </APPEL:TRIGGERS>

015:     <APPEL:RULES>
016:     <RDF:SEQ>
017:       <RDF:LI>

018:       <!-- The ONLY quantifier is the default for "accept" rules. Any
019:            other quantifier will be ignored. The description attribute
020:            contains optional text that could be displayed by the
021:            user agent during transfer or for debugging purposes. -->
022:       <APPEL:RULE behavior="accept" quant="ONLY"
023:                   description="Service only collects clickstream data">

024:         <!-- Make sure the assurance field is present, but accept
025:              any value. -->
026:         <P3P:PROP assurance="*">
027:           <P3P:USES>

028:           <!-- We only allow read access in non-identifiable form -->
029:           <P3P:STATEMENT action="r" id="0">

030:           <!-- The ONLY quantifier restricts our user agent to only
031:                accept proposals that ask for (any or none of) the two
032:                elements below, but not for any other elements. -->
033:               <P3P:REF name="ID.PUID"/>
034:               <P3P:REF name="ClickStream.Client_"/>
035:           </P3P:STATEMENT>
036:           </P3P:USES>

037:           <!-- We also require a natural language privacy statement -->
038:           <P3P:DISCLOSURE discURI="*"/>
039:         </P3P:PROP>

040:       </APPEL:RULE>
041:       </RDF:LI>

042:       <RDF:LI>
043:       <APPEL:RULE behavior="reject"
044:                   explanation="I don't want to be identified!">
045:           <APPEL:OTHERWISE/>
046:       </APPEL:RULE>
047:       </RDF:LI>

048:     </RDF:SEQ>
049:     </APPEL:RULES>

050:   </APPEL:GROUP>
051:   </RDF:LI>

052: </RDF:SEQ>
053: </APPEL:RULESET>
054: </APPEL:APPEL>
055: </RDF:RDF>

3.4 Example Explanation

Using the line numbers in the example above, we will briefly explain the basic structure of an APPEL ruleset.

Lines Explanation
001 - 003 XML namespace definitions. Every APPEL ruleset uses at least three XML namespaces: The RDF namespace (see below), the APPEL namespace (for its own elements and identifiers), and at least one further namespace to mach upon, usually the P3P namespace in order to match P3P proposals. If other elements should be matched (for example PICS labels or protocol attributes such as SSL), their namespace references should usually appear here.
004, 055 RDF encapsulation. An APPEL ruleset uses the RDF metadata format. Consequently, the ruleset must be enclosed in a corresponding RDF tag.
005 - 054 APPEL ruleset. Usually a single APPEL ruleset (i.e., a set of ordered groups containing triggers and 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. While the APPEL:APPEL element itself does not allow for any further attributes, the APPEL:RULESET can be tagged with additional information such as author or date of creation:
[1] ruleset  = '<RDF:RDF xmlns="http://www.w3.org/RDF">'
               '<APPEL xmlns="http://www.w3.org/APPEL">'
               "<RULESET " attributes ">"
                   gseq
               "</RULESET>"
               "</APPEL>"
               "</RDF:RDF>"

007 - 009 APPEL groups. An APPEL ruleset consists of an ordered list (expressed using the <RDF:SEQ> element) of groups, holding sets of rules that become active if the groups' trigger conditions are met.
[2] gseq  = "<RDF:SEQ>" *("<RDF:LI>" group "</RDF:LI>)
            "</RDF:SEQ>"

[3] group = "<GROUP" attributes ">" 
             "<TRIGGERS>"  tseq "</TRIGGERS>" 
             "<RULES>"     rseq "</RULES>" 
             "</GROUP>"

010 - 011,
018 - 021,
  etc.
Comments. Since an APPEL ruleset is a valid XML document, comments can be embedded just as into any other XML (or HTML) document, using the standard comment tags "<!--" and "-->"
012 - 014 Group triggers. A GROUP element is activated when its trigger conditions match the available evidence. However, groups with the degenerate-expression in their trigger condition (as in our example) become active under any condition and act as default groups. Please note that groups and their trigger conditions are evaluated in the order they are listed in the ruleset, so groups following a default group will never become active!
[4] tseq = "<RDF:BAG>" *("<RDF:LI>" expression "</RDF:LI>")
           "</RDF:BAG>"

015 - 017 Group rules. Each GROUP element contains an ordered list of rules (expressed using the <RDF:SEQ> element) which will be used to evaluate the evidence once the group becomes active. An optional list of trigger conditions can be used to selectively use different groups (and with this different sets of rules) under different conditions (not shown in our example).
[5] rseq = "<RDF:SEQ>" *("<RDF:LI>" rule "</RDF:LI>")
	   "</RDF:SEQ>"

022 - 023 "accept" rule. An APPEL ruleset consists of an ordered list of rules. APPEL offers three distinct kinds of rules, called behaviors: "accept", "reject" and "prompt". Each rule consists of a RULE element surrounding a set of expressions or the degenerate expression "OTHERWISE".
[6] rule = "<RULE>" 
            " behavior=" `"` behavior *("," behavior) `"`
           [" quant=" quantifier] 
              attributes ">" 
                  body
           "</RULE>"

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

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). Additionally, we specify a quantifier which governs the matching of data-reference expressions within P3P proposals.
[7] attributes = [" exp=" '"' datetime '"']
                 [" persona=" quoted-string]
                 [" crtby=" quoted-string]
                 [" crton=" '"' datetime '"']
                 [" description=" quoted-string]

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

[10] quantifier= "any" | "all" | "only" | "not-only"

The value we chose, "ONLY", allows any combination of the elements we list to be present in the proposal (i.e. to be requested by the service), but fails to match if any additional, nonreferenced element is requested. This is also the default for data-reference expression matching in "accept" rules.

026 - 039 P3P Proposal to match. Most APPEL rules will probably have a P3P proposal as the matching expression inside a RULE. Elements and attribute values that the rule should match on are simply spelled out in the proposal, while wildcards ("*") are be used to match a range of values. Omitting an attribute completely allows the attribute to be missing from the proposal supplied by the service (or be included with any value).
[11] optexp     = '<OPTIONAL>' expression '</OPTIONAL>' | expression

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

026 PROP element match. Of the available P3P:PROP attributes, our example user is only interested in having the proposal contain some form of assurance. Hence she specifies assurance="*" and ignores all other attributes.
029 STATEMENT element match. The "accept" rule should only allow the release of data if the proposal sent by the service uses the data in non-identifiable from (id="0") and requests only "read" access (action="r"). Other P3P:STATEMENT attributes, such as purp or recpnt can have any value, or even be omitted.
033 - 034 Data Elements to match. Since the "accept" rule uses the ONLY quantifier (Note: no other quantifiers are allowed for "accept"ing rules. See section 5.4.5 Data-Reference Expressions), it will only match if the statement in the proposal contains no data references not contained in the rule. Consequently, a proposal requesting any other element than the ones explicitly enumerated in lines 33 and 34 of the ruleset would immediately evaluate the expression to false (i.e. not accepting the proposal). The referenced element names are from the P3P Base Data Set, but later examples will demonstrate how to match arbitrary elements not in the base set.
038 DISCLOSURE to match. The user further wants to make sure that the service included a natural language privacy statement.
043 - 044 "reject" rule. Since rules in an APPEL ruleset are ordered, the "reject" rule only gets evaluated should the preceding "accept" rule fail to match the proposal sent by the publisher. If we would reverse the order of our two rules, our user agent would always reject all incoming proposals (see comment below).
045 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.

4. Technical Definition

APPEL allows us to express preferences about P3P proposals. Consequently, we will encapsulate P3P proposals with the behaviors we intend the user agent to exhibit once a matching proposal is encountered.

But APPEL is not limited to matching elements of a P3P proposal only. Any valid XML element can be put as an expression inside an APPEL rule or group in order to test for external schemas (such as PICS label, SSL protocol status, etc.).

4.1 Syntax & Encoding

This section lists the exact syntax used for the APPEL language, as well as encoding issues.

4.1.1 BNF Syntax

Figure 1: APPLE BNF Syntax

[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 value (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]>      

Details are described in section 4.2 Elements below.

4.1.2 Transport & Storage

APPEL rulesets are represented as XML documents, following the same conventions regarding its character set 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 latest XML Proposed Recommendation.

In contrast to P3P proposals, 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 (i.e. in binary form), as long as they provide methods to synchronize a user's plain text ruleset file with its internal representation.

4.1.3 XML Representation

APPEL rules are statements that are properly expressed according to the syntax model of RDF as well-formed XML. However, there are two assumptions, used to make the proposal shorter, that slightly differentiate an APPEL ruleset from standard RDF.
  1. the RDF namespace and <RDF:RDF> tag may be optionally omitted.
  2. a tag without a prefix name space must be assumed to be in the APPEL namespace.

4.2 Elements

This section describes the elements that are used to create an APPEL ruleset. For more information on the actual usage of these elements, please refer to section 5. Semantics as well as section 6. Example Ruleset.

4.2.1 The APPEL element

<APPEL>
This tag is the delimiter that denotes an APPEL file.

The outermost element of an APPEL ruleset takes no additional attributes. It always appears in conjunction with the RULESET tag described below. The use of two tags (<APPEL><RULESET>) instead of just one (<RULESET>) is due to the fact that we are employing the RDF encoding.

4.2.2 The RULESET element

<RULESET>
includes a sequence of one or more groups of rules. Each rule features a certain behavior that is returned to the calling program if the expressions listed in the rule all evaluate to true.
exp
the date on which this ruleset will expire. The default is empty, that is, rulesets never expire.
persona
If the user agent supports multiple user repositories, this string identifies the data repository that should be used. If no persona is given, the default persona should be used. Note that this value can be overridden on both the GROUP and RULE level.
crtby
Name or ID of the ruleset author (could be the user-agent).
crton
Time & Date of ruleset creation.
description
A short natural language explanation that can be displayed by the user-agent when the ruleset gets selected, or to help debugging a rulefile.

[1] ruleset          = '<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>"

[7] attributes       = [" exp=" '"' datetime '"'] ; default is empty value (never)
                       [" persona=" quoted-string]
                       [" crtby=" quoted-string]
                       [" crton=" '"' datetime '"']
                       [" description=" quoted-string]

4.2.3 The GROUP element

<GROUP>
Lists of rules are combined in a group. Rules within a group are only used when the group's trigger condition is matched. Only one group (and with it its rules) can be active at a time. A GROUP block without any trigger condition is simply activated if none of the preceding groups are activated. Such a "default" group should be put at the end of a ruleset. A ruleset should only contain a single default group.
exp
the date on which this group will expire. The default is empty, that is, groups never expire.
persona
If the user agent supports multiple user repositories, this string identifies the data repository that should be used. If no persona is given, the persona of the enclosing RULSET element is used. Note that this value can be overridden by each RULE.
crtby
Name or ID of the group author (could be the user-agent).
crton
Time & Date of group creation.
description
A short natural language explanation that can be displayed by the user-agent when the group gets selected, or to help debugging a rulefile.
[3] group            = "<GROUP" attributes ">" 
                          "<TRIGGERS>"  tseq "</TRIGGERS>" 
                          "<RULES>"     rseq "</RULES>" 
                       "</GROUP>"

[7] attributes       = [" exp=" '"' datetime '"'] ; default is empty value (never)
                       [" persona=" quoted-string]
                       [" crtby=" quoted-string]
                       [" crton=" '"' datetime '"']
                       [" description=" quoted-string]

4.2.4 The TRIGGERS element

<TRIGGERS>
encloses an unordered list of expressions that must (all) be fulfilled in order for the rules in the group to become active.
Trigger expressions can be considered as a sort of selective "if" that checks for some specific conditions to be applied before executing the rules of the group: if a specific group matches the conditions set forth in its triggers, its rules become the active set of rules, and all other rules are ignored for the rest of the evaluation.

All expressions in a TRIGGERS element are implicitly ANDed together.

Please note that a group with an empty list of TRIGGERS will never get activated. In order to create a default group which will become active under any conditions you have to use the degenerate expression <OTHERWISE/>.

[3] group            = "<GROUP" attributes ">" 
                          "<TRIGGERS>"  tseq "</TRIGGERS>"
                          "<RULES>"     rseq "</RULES>" 
                       "</GROUP>"

[4] tseq = "<RDF:BAG>" *("<RDF:LI>" expression "</RDF:LI>") "</RDF:BAG>"

4.2.5 The RULES element

<RULES>
encloses a sequence (i.e., an ordered list) of rules that will be used to evaluate the existing evidence should the group be active.
Only one set of rules enclosed in a RULES element can be active at a time.

[3] group            = "<GROUP" attributes ">" 
                          "<TRIGGERS>"  tseq "</TRIGGERS>"
                          "<RULES>"     rseq "</RULES>" 
                       "</GROUP>"

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

4.2.6 The RULE element

<RULE>
Contains condition under which a certain behavior should be carried out by the calling program.
behavior
Behavior (or list of behaviors) that should be carried out by the calling program if the expressions match the evidence. If multiple behaviors are specified, only the first supported behavior is returned to the calling program. If none of the behaviors is known to the calling program, an empty string is returned.
quant
Quantifier governing the matching of data-reference elements inside a P3P statement.
exp
the date on which this rule will expire. The default is empty, that is, rules never expire.
persona
If the user agent supports multiple user repositories, this string identifies the data repository that should be used. If no persona is given, the corresponding value of the enclosing GROUP or RULESET is used.
crtby
Name or ID of the rule author (could be the user-agent).
crton
Time & Date of rule creation.
description
A short natural language explanation that can be displayed by the user-agent when the rule gets executed, or to help debugging a rulefile.

Please note that 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, you have to use the degenerate expression <OTHERWISE/>.

[6] rule             = "<RULE>" 
                         " behavior=" `"` behavior *("," behavior) `"`
                        [" quant=" quantifier] 
                         attributes ">" 
                            body
                       "</RULE>"
      
[7] attributes       = [" exp=" '"' datetime '"'] ; default is empty value (never)
                       [" persona=" quoted-string]
                       [" crtby=" quoted-string]
                       [" crton=" '"' datetime '"']
                       [" description=" quoted-string]

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

[10] quantifier      = "any" | "all" | "only" | "not-only"

4.2.7 The OTHERWISE element

<OTHERWISE>
so called degenerate-expression, which always evaluates to true. This can be used to craft "catch-all" groups or rules which match all cases not covered by previous group or rules.

OTHERWISE should be the only expression in a list of triggers or 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 in an "accept" behavior, which would result in unlimited access to a user's data repository for sites not covered by the preceding rules! User agents should refuse to accept rulesets with such "catch-all" "accept" rules.

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

4.2.8 The OPTIONAL element

<OPTIONAL>
encloses expressions that can be ignored by the rule evaluator in case no matching element can be found in the evidence.

Optional expressions evaluate to true if the contained element can not be found in the evidence. If one or more elements of the enclosed type are available in the evidence, the APPEL rule evaluator will simply try to match each element with the constraints specified in the expression and evaluate the expression to true or false.
[11] optexp          = '<OPTIONAL>' expression '</OPTIONAL>' | expression

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

5 Semantics

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 details. 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.

5.1 The Rule Evaluator in a nutshell

A P3P user agent or other program will invoke an APPEL rule evaluator, providing an APPEL ruleset, a list of supported behaviors, and various pieces of "evidence" which may include a URI, a single P3P proposal, and RDF metadata. The rule evaluator returns a behavior (i.e., one of the three standard behavior "accept", "reject" or "prompt" or a application defined extension behavior) that the calling program should carry out.

5.1.1 Behaviors

A user agent must at least support the three standard behaviors "accept", "reject" or "prompt". It may supply the rule evaluator with a list of behavior-extensions it supports additionally. Behaviors that result in a seamless release of data must be tagged with an "accept" type (see section 5.6 Extensible Behaviors).

5.1.2 Rulesets

A ruleset consists of rules and groups. Rules describe conditions under which a certain behavior should be carried out by the calling program. Groups allow a set of rules to be grouped together and only activated under certain conditions, which are defined by a set of triggers in the group's body. Rulesets should be written so that for any possible evidence set, there is always a rule that will fire. It is up to the calling program (usually the user agent) to determine what to do if an error is returned; however, calling programs should not treat an error as they would an "accept".

5.2 Group, triggers and rules ordering

How APPEL evaluates multiple groups in a ruleset, or multiple triggers or rules in a group
There is no need for logic operators among multiple groups or rules in an APPEL ruleset, since all expressions in APPEL are evaluated strictly in order. However, changing a groups triggers or changing the order of the groups in the ruleset, as well as inserting a new rule or changing the order of an existing list of rules within a group, can greatly influence the behavior of the user agent!

Care should be taken that triggerless groups (aka "default group") and rules containing the degenerate expression <OTHERWISE> exist only once and are placed at the end of their respective lists.

5.3 Expressions

How to specify what to match in a group trigger or rule
Every rule and trigger in an APPEL ruleset contains a single expression which must be in valid RDF format. Each expression tries to match a certain piece of evidence, in the form of a P3P proposal or other RDF metadata such as a PICS label.

Expressions over elements that are not in the set of evidence provided by the calling program always evaluate to false. For example, a rule containing a P3P proposal expression and an expression over a PICS label will fail if no PICS label could be found in the evidence set, even though the P3P proposal matches.

However, using the <OPTIONAL> element, expressions checking for nonexistent evidence can be ignored by the rule evaluator, just as if they had never been specified.

5.3.1 Multiple Expressions

Multiple expression in a single rule or trigger can be combined by using one of the three RDF collection types, RDF:Seq, RDF:Bag and RDF:Alt. However, since the rule evaluator always ANDs together all available evidence, any collection is always treated as if being an unordered list of nodes (i.e., of type RDF:Bag).

Since multiple expressions are ANDed together, the rule or trigger will evaluate to true if and only if all of its expressions evaluate to true. If only a single expression evaluates to false the rule or trigger must fail. In order to logically OR multiple expressions one has distribute them among multiple rules.

Order does not matter for rule evaluation: the rule evaluator evaluates all expressions one at a time (in any order), trying to find a match for each element in the evidence. The evaluator does not keep track of which part of the evidence has been successfully matched against an expression before, so multiple expressions in a single rule might match the same single element in the evidence set repeatedly (but for example testing different attributes each time).

As a consequence of this, a rule might for example contain multiple proposals, even though only a single proposal will be in the evidence set at any time (see section 2.1 Inputs and Outputs).

Note: While multiple expressions in a single rule can match a single element in the evidence, a single expression can not match multiple elements in the evidence!

Figure 2: Multiple expressions in a rule.
<RULE behavior="accept">
<!-- This rule fails if there is no information on SSL -->

   <RDF:BAG>
      <RDF:LI>	    
         <!-- Expression 1 -->	    
         <P3P:PROP>
            <P3P:USES>
               <P3P:STATEMENT action="rw">
	       ...
               </P3P:STATEMENT>
            </P3P:USES>
         </P3P:PROP>
      </RDF:LI>

      <RDF:LI>	    	    
         <!-- Expression 2. Fails if SSL is inactive (active="no")
                 or the status of SSL is unknown. -->	    	    
         <SSL: PROTOCOL active="yes"/>
      </RDF:LI>	    	    
   </RDF:BAG>
	    
</RULE>

5.3.2 Optional Expressions

Expressions can also be marked as optional by enclosing them in an APPEL:OPTIONAL element. If such an optional expression fails to find a corresponding element in the evidence set, the rule evaluator must simply ignore the expression (i.e. the expression evaluates to true).

However, if a corresponding element can be found in the evidence set, the rule evaluator must try to match the expression given in the rule. If it fails, the expression (and therefor the rule) must evaluate to false.

Figure 3: Optional expressions.
<RULE behavior="accept">
<!-- This rule can match even when there is no PICS label -->

   <RDF:BAG>
      <RDF:LI>	    
         <!-- Expression 1 -->	    
         <P3P:PROP>
            <P3P:USES>
               <P3P:STATEMENT action="r">
	       ...
               </P3P:STATEMENT>
            </P3P:USES>
         </P3P:PROP>
      </RDF:LI>

      <RDF:LI>	    	    
         <!-- Expression 2. If there is no PICS label, this
                 will simply be ignored. -->	    	    
         <OPTIONAL>	    
            <PICS:LABEL>
               <RSACi:RATINGS v="<4">
            </PICS:LABEL>
         </OPTIONAL>
      </RDF:LI>	    	    
   </RDF:BAG>
	    
</RULE>

Please note that every element referred to in an expression should have a corresponding XML namespace reference at the beginning of the APPEL ruleset. The rule evaluator should return an error if it is unable to resolve elements referenced in a rule expression, even if the expression was marked as being optional.

5.3.3 Sub Elements

Elements in a rule expression can contain subelements, which in turn can feature further subelements. Figure 4 lists some examples of expressions containing subelements. Multiple subelements in APPEL are handled the same way as multiple expressions (see section 5.3.1 above).

Figure 4: Sub Elements in expressions.

<RULE behavior="accept">
   <RDF:BAG>

      <RDF:LI>	    
         <!-- Expression 1 -->	    
         <P3P:PROP>
            <P3P:USES>
               <P3P:STATEMENT action="r">
                 ...
               </P3P:STATEMENT>
            </P3P:USES>
            <P3P:USES>
               <P3P:STATEMENT action="rw">
                  ...
               </P3P:STATEMENT>
            </P3P:USES>
         </P3P:PROP>
      </RDF:LI>	    

      <RDF:LI>	    	    
         <!-- Expression 2 -->
         <PICS:LABEL>
            <RDF:BAG>
               <RDF:LI>	    
                  <RSACi:RATINGS v="<4">
               <RDF:LI>	    
                  <RSACi:RATINGS l="<2">
            </RDF:BAG>
         </PICS:LABEL>
      </RDF:LI>

      <RDF:LI>	    	    	    
         <!-- Expression 3 (redundant) -->
         <PICS:LABEL>
            <RSACi:RATINGS v="<4" l="<2">
         </PICS:LABEL>
      </RDF:LI>	    	    

   </RDF:BAG>	    
</RULE>

In figure 4 above, expression 2 and 3 could match the same element in the evidence set, namely a PICS label with an RSACi rating of less than 4 for violence and less than 2 for language. That is because the subelements in expression 2 could be matched to the same single RSACi rating element in the evidence set. However, the two STATEMENT subelements in expression 1 above could only match two different STATEMENT elements in the evidence set because of different values for the action attribute.

5.4 Matching

How APPEL matches expressions against available evidence
APPEL contains multiple levels where matching is done during rule evaluation:

The following subsection will define APPEL's matching process in more detail and how it applies to the three different levels of XML structure.

5.4.1 Simple Expressions (Value Matching)

A simple expression is an attribute-value pair that is given in an expression of an APPEL rule. Three different type of simple expressions are possible in APPEL:

Simple-expressions may take string or numeric values. Only the = operator may be applied to string-valued simple expressions and multi-numeric-valued simple expressions (i.e. simple expressions that test for multiple, numeric values. See below).

Single-numeric-valued simple expressions might also use the following operators: =, <, >, <=, >=. The semantics of each of these operators follows their traditional usage when applied to single values. Note: While the equality operator = is applied outside of the quoted value (i.e. id="0"), all other operators have to appear inside the quotes, preceding the number, in addition to the equality operator outside: purp="<=2". These operators are summarized in table 1 below.

In addition, numeric-valued expressions in APPEL allow for a set of boolean-type operators to govern the type of match, and are described in a special section 5.4.2 Prefix Operators for Simple Expressions below.

The result of applying any operator will be a Boolean value, true or false.

Table 1: Simple Expression Semantics for single-numeric expressions
"x" x must be present, but additional values are allowed.
"<=x" at least one of the element's values must be less than or equal to x.
"<x" at least one of the element's values must be less than x.
">=x" at least one of the element's values must be greater than or equal to x.
">x" at least one of the element's values must be greater than x.

5.4.2 Prefix Operators for Simple Expressions

Multi-numeric-valued attributes in APPEL are per default matched as follows: A list of values is specified by separating them with commas ",". Each value is compared one by one against the list of values in the evidence. Should one of the values in the expression match one of the values in the evidence, the expression evaluates to true. This can be seen as an "OR"ed match, where the multi-valued expression evaluate to true if there is evidence to satisfy at least one of the values given in the expression.

In order to override this standard mechanism, APPEL allows the use of the "AND:" operator prefixing the list of values of a multi-valued expression. Such "AND"ed multi-values evaluate to true only if there is evidence to satisfy every value given in the expression.

For example, the simple-expression purp="AND:3,4" would only evaluate to true if a proposal contains a statement in which purposes 3 and 4 are both declared; while the simple expression purp="3,4" would evaluate to true if a proposal contains a statement in which either purpose 3 or purpose 4 (or both) are declared.

In order to limit the allowed values in the evidence, APPEL supports use of the "ONLY:" operator. When prefixing a list of values with ONLY:, the expression evaluates to true if only the values listed in the expression appear in the evidence. When combining this ONLY: operator with the above AND: operator, we can in effect force an exact match between the specified list in our expression and the list of values in the evidence (order doesn't matter, though).

For example, the simple-expression purp="ONLY:3,4" would evaluate to true if a proposal contained a statement in which only purposes 3 or 4 (or both) are declared; while the simple expression purp="ONLY:AND:3,4" would evaluate to true only if a proposal contained a statement in which both purpose 3 and purpose 4, and no other purposes, were declared.

Finally, both operators (or their combination) can be prefixed by the NOT: operator, effectively negating the expression. Table 2 summarizes the allowed operators for multi-valued Simple Expressions.

Table 2: Simple Expression operators for matching multiple values
"x,y" x or y must be present (but additional values are allowed).
"AND:x,y" both x AND y must be present (but additional values are allowed).
"ONLY:x,y" x or y must be present, and NO additional values are allowed.
"ONLY:AND:x,y" both x AND y must be present, and NO additional values are allowed.
"NOT:x,y" x or y must NOT be present.
"NOT:AND:x,y" both x and y must NOT be present.
"NOT:ONLY:x,y" x or y must be present, and additional values are required.
"NOT:ONLY:AND:x,y" both x AND y must be present, and additional values are required.

Please note again that the standard match performed by the expression attribute="value" tests only for presence of that value (or for the ORed combination of multiple values, if given), not for exclusiveness. This might lead to confusion if the user wants to restrict rule matches to certain values only. In order to attain more restrictive matches (i.e. "Match ONLY") the user has to explicitly make use of the ONLY: operator!

5.4.3 Wildcards

APPEL offers three metacharacters for providing simple regular expression support in its simple expressions: the question mark "?", the plus "+" and the star "*" symbol. The usage of these symbols is similar to popular operating system shells under DOS/Windows and UNIX, but differs from their semantics in standard regular expression systems such as egrep.

Table 3: APPEL regular expression metacharacters
? question mark Matches any one character.
* star Matches zero or more characters.
+ plus Matches one or more characters.
\?, \*, \+ escaped character Matches the corresponding character.

Using these metacharacters with strings allows us to specify ranges of string-values, for example "*.foo.com" for any host in the foo.com domain, or "*://*"" for a URI (or at least something that looks like one). Please note that string values are always matched from the beginning of the string, unless the user specified an initial * star symbol. Forcing a string match from the end is not possible in APPEL.

Using the above symbols with number-valued simple expressions should only be done to replace the whole matching string, such as in <P3P:STATEMENT purp="+"> (for matching a non-empty purpose field in a P3P statement). Wildcard characters can not be used to match single values in a multi-valued string (such as in purp="AND:0,*") or to match part of a number itself (such as in purp="1?").

Please note also that wildcard characters are only allowed within quoted strings, not for matching attribute names or element names! However, they can be applied in the above manner to match ranges of data elements when used in data-reference expressions.

5.4.4 Attribute Matching

If a rule requires that a particularly attribute appears in an element without restrictions on the value for that attribute, the wildcard characters "*" or "+" may be used (e.g. as in attribute="+"). However, if a rule does not require that a particular attribute appear at all, the attribute should not appear in the rule at all.

Please note that is not possible in APPEL to write rules that prevent a certain attribute from appearing in an element of the evidence set.

5.4.5 Data-Reference Expressions (Element Matching)

APPEL allows the user to express which data-reference elements should be matched inside a P3P proposal -- only those specified, all of the specified, at least one of the specified, and so on -- using quantifiers.

Quantifiers are specified within the RULE element of each rule using the quant attribute. Figure 5 shows an example of using a quantifier to restrict the limit of a "reject" rule.

Figure 5: Example using a Quantifier.
<APPEL:RULE behavior="reject" ...quant="ALL"> 
<!-- This rule matches only if both first and lastname are
     requested in the proposal -->
   
  <P3P:PROP>
      <P3P:USES>
         <P3P:STATEMENT ACTION="r">
            <P3P:REF name="User.Name.First"/>
            <P3P:REF name="User.Name.Last"/>
         </P3P:STATEMENT>
      </P3P:USES>
   </P3P:PROP>
</APPEL:RULE>

APPEL supports four different kind of quantifiers, which are listed in table 4 below. However, these quantifiers can only be used with non-"accept"ing rules, such as a "reject" or "prompt" rule (or any behavior extension which is not tagged as being an "accept" type of rule -- see section 5.6 Extensible Behaviors). "Accept"ing rules always use a default ONLY quantifier. User Agents are free to simply ignore quantifiers in "accept"ing rules, but should preferably inform the user that the specified quantifier is being ignored.

Table 4: Data Reference Quantifier
ALLall of the specified elements must be present, but additional elements are allowed.
ANYat least one of the specified elements must be present, but additional elements are allowed. (1 or more) [Default for non-"accept"ing rules]
ONLYonly specified elements can be present in the proposal, no additional elements are allowed. (matches also if proposal contains no elements!) [Default for "accept"ing rules]
NOT-ONLYan element not in the list of specified elements must be present.

The reason for not allowing ANY, ALL or NOT-ONLY qualifiers to be used in an "accept"ing rule is to prevent unwanted release of data from a user's repository. Having the default quantifier of "accept"ing rules set to ONLY, APPEL effectively requires the user to explicitly enumerate all elements that could be released to a service should the corresponding rule fire. Using the ONLY quantifier, any request for an element not listed in the "accept"ing rule would immediately result in a failure to match.

Also, an "accept" rule should intuitively evaluate to true even in case a proposal is less demanding than the proposal specified in the rule, which is the effect when using the ONLY quantifier (since it matches even if less than the listed elements are requested). A "reject" rule on the other hand should evaluate to true even in case the proposal is more demanding than the proposal specified in the rule. This is the case with the default quantifier ANY for non-"accept"ing rules, which matches already if at least one of the listed data elements is requested. However, since non-"accept"ing rules do not release any data without the user's explicit consent (for example in a "prompt" rule), APPEL allows any of the four quantifiers to be used in these cases.

Table 5 summarizes the default quantifiers for the different behavior elements in APPEL.

Table 5: Default Quantifiers
BehaviorDefaultExplanation
"accept" and other "accept"ing behavior extensions.ONLYmatches even if proposals are less demanding (in terms of elements), that is, if they request any subset of the referenced element, but nothing more.
"reject", "prompt" and all other non-"accept"ing behavior extensions.ANYmatches even if proposals ask for more elements than specified.

5.4.6 Category translation support

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 are also often included when defining a new element or referring to form data.

APPEL supports the use of categories in its rules by implicitly translating each referenced category into the list of base elements that belong into that category. Figure 6 below shows an example. 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.

Figure 6: Category matching.
<APPEL:RULE behavior="reject"> 
<!-- This rule matches if
     an element from the unique 
     identifier category has
     been requested -->
   
  <P3P:PROP>
      <P3P:USES>
         <P3P:STATEMENT>
            <P3P:REF category="2"/>
         </P3P:STATEMENT>
      </P3P:USES>
   </P3P:PROP>
</APPEL:RULE>
<APPEL:RULE behavior="reject">
<!-- Explicit representation of
     the rule on the left. -->

  <P3P:PROP>
      <P3P:USES>
         <P3P:STATEMENT>
            <P3P:REF name="ID.PUID"/>
            <P3P:REF name="ID.TUIP"/>
            <P3P:REF name="User.Cert"/>
         </P3P:STATEMENT>
      </P3P:USES>
   </P3P:PROP>
</APPEL:RULE>

5.5 Rule Expiration

APPEL allows rulesets, groups and single rules to expire at a certain point in time. This is mostly used for rules that have been created on-the-fly by the user after being prompted for an action (for example after a "prompt" rule successfully matched). In order to create rules that expire after a certain time period (such as "in six days" or "in two hours") it is necessary to explicitly calculate the expiration time given the current time.

The expires attribute specifies a date string that defines the valid life time of that element. Once the expiration date has been reached, the element (ruleset, group, rule) will no longer be used by the APPEL rule evaluator. Expired groups or rules may either be deleted from the ruleset, moved to a "Removed Items" folder, or simply be kept in the ruleset (maybe until the ruleset reaches a certain size). Expired rulesets should require the user agent to prompt the user for an action (e.g., to extend the expiration time, to download a newer version of the ruleset from a Website, etc.).

The date string is formatted as:

     Wdy, DD-Mon-YYYY HH:MM:SS GMT
This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the only legal time zone is GMT and the separators between the elements of the date must be dashes.

User agents should verify the ruleset after a rule or group has expired in order to detect missing default rules or groups and inform the user if the ruleset thus has become invalid.

Please note that expires is an optional attribute. If not specified, a ruleset, group or rule will never expire.

5.6 Extensible Behaviors

APPEL supports extending the set of behaviors that matching rules can exhibit beyond the three standard behaviors "accept", "reject" and "prompt". Behaviors in APPEL are simple string values specified in the behavior attribute of an APPEL:RULE element and will be returned to the calling program if the corresponding rule should fire:

Figure 6: APPEL rule using a behavior extension.
    <APPLE:RULE behavior="whistle">
    ...
    </APPEL:RULE>

The rule evaluator will simply return the string specified in the behavior attribute and let the calling program (i.e. the user agent) decide what to do. However, in order to better handle behavior extensions that are not supported by all user agents yet, APPEL allows the rule creator to define a list of "fallback" behaviors for unknown extensions. This mechanism is similar to the current face attribute in the FONT element in HTML: A list of behaviors is given, which is evaluated sequentially. The first known behavior is chosen for the rule:

Figure 7: APPEL rule using fallback behaviors.
    <APPLE:RULE behavior="foo,bar,accept">
     ...
    </APPEL:RULE>

If none of the behaviors is known to the calling program, a default "prompt" behavior should be exhibited by the user agent.

In order to know which extensions the particular calling program knows about, the rule evaluator expects a list of extensions together with the rule file and the evidence upon invocation. The evaluator compares the list of behaviors of a rule with this list of known extensions and retains only the first known extension for each rule in the rule's (internal) behavior slot. If no extension matches, the empty string is used as the behavior for this rule, which would force user agent to use the fallback (prompt) behavior, should this rule fire at the end of evaluation.

5.6.1 Behavior types

As described in section 5.4.4 Data-Reference Expressions above, the APPEL rule evaluator discriminates between rules that seamlessly "accept" a proposal (called "accept"ing rules") and those that prompt the user for action or otherwise prohibit data transfer (called non-"accept"ing rules).

In order to know which behavior extensions will seamlessly give out data from the user repository (i.e. "accept" the proposal when the corresponding behavior string is returned), APPEL requires the user agent to "tag" each behavior extension it supports with the suffix ":accept" in case it is handled as an "accept"ing behavior in this particular implementation.

Figure 8: User agent behavior string (non-normative).
Known_Extensions: "whistle,blink:accept,rattle"

Once the rule evaluator has determined the behavior that will be used for a particular rule (see previous paragraphs) it also adjusts the quantifiers for this rule according to the behavior type the user agent reported for this behavior: "accept"ing rules will be set to use the ONLY quantifiers, while non-"accept"ing rules will either use their specified quantifiers, or ANY should no quantifier be given.

5.6.2 Optional rules

In order to support rules that are only used if a certain behavior extension is known, APPEL offers a (otherwise useless) fourth standard behavior called nop. If used as a fallback behavior at the end of a list of extension behaviors, the system simply ignores the rule if none of the preceding behaviors is known.

Please note that rules featuring nop as their only behavior will simply be ignored. User agents should detect such rules and prompt the user for action before installing such a ruleset.

Summary

Let's summarize the above behavior mechanism again:
  1. APPEL rules specify the desired behavior using the behavior tag of the <RULE> element. These behaviors can be one of the four standard behaviors (accept, reject, prompt, or nop), or any other string which would be interpreted as an extension.
  2. In order to allow fallback behaviors for unknown extension, the behavior attribute can contain a comma separated list of behaviors, which are tried sequentially from left to right until a known behavior is found (similar to the FACE attribute in the HTML FONT element):
          <APPEL:RULE behavior="foo,bar,baz,accept">
  3. The calling program (user agent) gives a list of known extension to the rule evaluator. These extension behaviors have to be tagged as an accept type if necessary (order does not matter):
          Known_Extensions: "baz,bar:accept"
  4. The rule evaluator will take this extension list and compare it (sequentially) with the list of behaviors specified for each rule. If a behavior is contained in the list of known extensions that was supplied by the calling program, it is chosen to be the behavior for this rule (all remaining behaviors are ignored). Otherwise it is removed from the list of behaviors for this rule.
  5. If none of the behaviors is known by the calling program, and no standard behaviors were specified, the empty string is chosen as the behavior for this rule. If a "nop" behavior is specified in list, and none of the preceding extensions is known, the rule evaluator will ignore the rule.
  6. If the behavior we found this way is of type "accept", i.e. it is either the "accept" behavior itself or it is tagged ":accept" by the calling program in the list of known extension, the rule evaluator will apply the "ONLY" quantifier to the rule, regardless of the quantifier specified (This quantifier will match zero or more elements, but fail if any unknown element is encountered in the proposal sent.)
  7. The rule is evaluated according to the quantifiers, and if it is a match, the matching behavior is returned to the user agent. Returning an empty behavior for a matching rule should lead the calling program to "prompt" the user that the system encountered a rule with no known behavior.

6 Ruleset Example

In order to get a better idea how to combine multiple rules into a ruleset, this section attempts to encode a set of real-world preferences from a fictional user.

Creating an APPEL ruleset is basically a three step process:

  1. List your privacy preferences in plain English (or your language of choice).
  2. Transcribe each preference into a single (or multiple) APPEL rules.
  3. Collate rules with identical pre-conditions (optional).
These steps are by no means trivial, given the complexity and sensitivity of users' privacy preferences and should preferably be supported by a powerful user interface in the application that uses APPEL rulesets. However, much of the difficulties of steps two and three can be taken out by creating the initial list of preferences (i.e. step one) in a form that is easy to translate into an APPEL ruleset.

The members of this working group have found two alternative approaches to creating rulesets most helpful, and we will describe one of them (the less confusing one) in this section in more detail. Nevertheless, it will be necessary for implementations to support this task with well crafted user interfaces and useful debugging tools in order to avoid the unwanted disclosure of data elements from the user's repository.

6.1 Filtering by Rejection

Our first approach is most suited for user who want to write their own rulesets from scratch and would like to create rulesets that are still manageable in terms of size and complexity.

The main idea in this approach is to start one's privacy preferences with a list of unacceptable conditions, i.e. situations in which we are never to release our data elements. Once we have enumerated all non-conformal conditions, we list those that we are willing to consider (i.e. those that we want to be prompted for), followed by the list of data elements we are willing to give out in all other cases (i.e. when non of our unacceptable conditions holds true).

Figure 9: Fictional User Preferences (using filtering).
  1. Don't give out clickstream data in identifiable form.

  2. Don't give out my zip code in identifiable form or for marketing purposes.

  3. Don't give out demographics (age, gender, income, education) in identifiable form, or over an insecure line.

  4. Don't give out my shipping and billing address for purposes other than the completion of the current activity.

  5. Don't allow solicitation of search text in identifiable form.

  6. Don't allow my bank to read & write to my account number over an insecure line.


  7. I want to be prompted to give out my credit card information over a secure line for completion of current activity purposes only (i.e. billing).

  8. I want to be prompted if form data is collected for marketing purposes, or if it is from the Financial Account Category..


  9. Allow the release of clickstream, zip code, demographics, shipping and billing address and search text if nothing else is collected.

  10. Allow my bank to read & write to my account number.

  11. My Computer Retailer can have read & write access to my computer related information and read access to my home contact information (for any purpose) until my warranty contract expires.

Figure 9 shows a number of fictional user preferences, enumerated according to the recipe described above:

  1. List unacceptable conditions for each data element (or set of elements).
  2. List considerable conditions.
  3. List data elements we are willing to disclose otherwise.

Once we have reached the third part of the list (elements we are willing to disclose), we usually need not specify any more conditions for our rules, since we already filtered out all unacceptable (or questionable) conditions in steps one and two. This can be seen in figure 10, where we translate our preferences above into APPEL pseudo-rules using the three standard behaviors "accept", "reject" and "prompt":

Figure 10: Filtering Rules corresponding to figure 9.
  1. Reject if clickstream data is used in identifiable form.
  2. Reject if zipcode data is used in identifiable form.
    Reject if zipcode data is used for marketing purposes.
  3. Reject if demographics data is used in identifiable form.
    Reject if demographics is collected over an insecure line.
  4. Reject if shipping or billing information is collected for purposes other than completion of current activity purposes.
  5. Reject if search text is collected in identifiable form.
  6. Reject proposals from my bank asking for read & write access to my account number over an insecure line.
  7. Prompt me if credit card information is collected over a secure line for completion of current activity purposes.
  8. Prompt me if form data is collected for marketing purposes or if it asks for elements from the Financial Account Category.
  9. Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data.
  10. Accept proposals from my bank asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data, and read & write access to my account number.
  11. Accept proposals from my computer retailer asking for read access for my home contact information and read & write access to my computer related information, until November 1st, 1999.

Rule 9 summarizes our "generic" preferences (i.e. preferences to apply to all unknown sites; in contrast to "specific" preferences such as rule 10 that applies only to my bank) in a way that it lists all elements we are willing to disclose if none of the above reject rule has fired so far. This is a good demonstration on how rule ordering plays an important role in APPEL: if we would have placed rule 9 somewhere in the middle of the reject rules (or even at the top), we would have accepted proposals even though they wouldn't fulfill our necessary conditions listed in our preferences!

Disjunctive Conditions

When transcribing preferences into rules we naturally have to follow the semantics of the APPEL language as described in the previous sections. Since APPEL rules do not allow for disjunctive conditions, we will have to break up any preference that uses "or" to connect its preconditions. In our example above we had to split preferences 2 and 3 each into two rules:

Don't give out my zip code in identifiable form or for marketing purposes --> Reject if zipcode data is used in identifiable form.
Reject if zipcode data is used for marketing purposes.
 
Don't give out demographics in identifiable form or over an insecure line. --> Reject if demographics data is used in identifiable form.
Reject if demographics is collected over an insecure line.

Disjunctive Elements in "accept"ing rules

Another hurdle during transcription is the combinatorial effects of "accept"ing rules and their data elements. Although writing rules that accept data seems like a straightforward step, not different from writing rules for other kind of behaviors, we have to take some caution when translating such preferences.

Take for example preferences 9 and 10 in figure 9. A straightforward translation of the preferences would have resulted in the following rules:

Although one of these two rules would certainly match if either clickstream or my account number would be requested by my bank, none of them would match if the bank would request both clickstream and my account number in a single proposal!

The solution is to enumerate all allowed data elements for each condition (condition being in our case whether it's my bank requesting the data or not). Thus, we have to duplicate all elements listed in preference 9 and copy them into preference 10:

Collation

An important difference between rules in an APPEL ruleset and the original set of preferences they are derived from is the way similar cases are grouped together: People tend to formulate preferences according the the data elements they concern, and then enumerate the conditions under which they are willing to grant a service access these data elements. When writing corresponding APPEL rules, however, we have to reverse this order and write our rules according to the conditions we are willing to accept, and then enumerate which data elements we are willing to disclose under them.

In an optional step we can now group together rules with identical conditions in order to reduce the overall size of our ruleset, as shown in figure 11 below (in our example this only applies to the "reject"-rules, but it could in practice be applied to all kind of behaviors). Sometimes we can make use of the element hierarchy and collate single elements with their corresponding sets, or group rules with conditions that subsume each other (for example when grouping the second part of rule 2 together with rule 4 of figure 10 into the new rule 2 below).

Figure 11: Collated Filtering Rules.
  1. Reject if clickstream, zipcode, demographics data or search text is used in identifiable form.
  2. Reject if zipcode, shipping or billing information is collected for purposes other than completion of current activity purposes.
  3. Reject if demographics or account information is collected (or written) over an insecure line.
  4. Prompt me if credit card information is collected over a secure line for completion of current activity purposes.
  5. Prompt me if form data is collected for marketing purposes or if it asks for elements from the Financial Account Category.
  6. Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data.
  7. Accept proposals from my bank asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data, and read & write access to my account number.
  8. Accept proposals from my computer retailer asking for read access for my home contact information and read & write access to my computer related information, until November 1st, 1999.

These rules can now be written out as APPEL rules using the syntax described previously. Please note that the listing below also features some additional examples not explicitly described in the previous paragraphs but which are sufficiently documented in the source code:

Listing 2: Example Ruleset in APPEL
000: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-P3P-syntax#" prefix="P3P" ?> 
001: <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF" ?> 
002: <?xml:namespace ns="http://www.w3.org/TR/1998/WD-APPEL10#" prefix="APPEL" ?>

003: <!-- Custom Schemas --> 
004: <?xml:namespace ns="http://www.w3.org/TR/WD-SSL-schema#" prefix="SSL" ?> 
      
005: <RDF:RDF> 
006: <APPEL:APPEL> 
007: <APPEL:RULESET crtdby="APPEL WG" crtdon="Wed, 12-Aug-1998 21:32:02 GMT">

008: <RDF:SEQ> 
009:   <RDF:LI> 
010:   <APPEL:GROUP description"Default Group">

011:     <!-- We specify OTHERWISE as the only trigger condition
012:             here so that this group is always active -->
013:     <APPEL:TRIGGERS>
014:        <APPEL:OTHERWISE/>
015:     </APPEL:TRIGGERS>

016:     <APPEL:RULES> 
017:     <RDF:SEQ> 

018:     <!-- Rule 1: Reject if clickstream, zipcode, demographics
019:                  data or search text is used in identifiable form. -->      
020:       <RDF:LI>
021:       <!-- The ANY quantifier is the default for non-"accept"ing rules,
022:            but we list it here for clarity. --> 
023:       <APPEL:RULE behavior="reject" quant="ANY" 
024:                   description="Service collects clickstream, zipcode,
025:                                demographic data or search text in
026:                                identifiable form"> 
027:         <P3P:PROP> 
028:           <P3P:USES>
029:           <!-- We reject any access to the elements below in
030:                identifiable form. --> 
031:           <P3P:STATEMENT id="1" category="8">
032:               <P3P:REF name="ClickStream.Client_"/>
033:               <P3P:REF name="*.Postal.PostalCode"/>
034:               <P3P:REF category="8"/>   <!-- will be expanded -->
035:               <!-- "8" == "Demographics and SocioEconomic Data" -->
036:               <P3P:REF name="Form.SearchText_"/> 
037:           </P3P:STATEMENT> 
038:           </P3P:USES>
039:         </P3P:PROP>

040:       </APPEL:RULE> 
041:       </RDF:LI>

      
042:     <!-- Rule 2: Reject if zipcode, shipping or billing
043:                  information is collected for purposes other than
044:                  completion of the current activity purposes. -->
045:       <RDF:LI>
046:       <APPEL:RULE behavior="reject"  
047:                   description="Service collects zipcode, shipping 
048:                                or billing information for
049:                                purposes other than completion of
050:                                current activity.">  
051:         <P3P:PROP> 
052:           <P3P:USES>
053:           <!-- We reject any access to the elements below for
054:                non-zero purposes (0 == completion of activities). --> 
055:           <P3P:STATEMENT id="1" purp=">0">
056:               <P3P:REF name="*.Postal.PostalCode"/>
057:               <P3P:REF name="ShipTo.*"/> 
058:               <P3P:REF name="BillTo.*"/> 
059:           </P3P:STATEMENT> 
060:           </P3P:USES>
061:         </P3P:PROP>

062:       </APPEL:RULE> 
063:       </RDF:LI>


064:     <!-- Rule 3: Reject if demographics or account information is
065:                  collected (or written) over an insecure line. -->

066:       <RDF:LI>
067:       <APPEL:RULE behavior="reject"  
068:                   description="Demographics or account
069:                   information is collected (or written) over an
070:                   insecure line.">

071:       <!-- We need to enumerate multiple conditions here, so
072:            we use the RDF:BAG element. -->
073:       <RDF:BAG>
074:         <!-- First, we express what data this rule concerns -->
075:         <RDF:LI>
076:           <P3P:PROP> 
077:             <P3P:USES>
078:             <P3P:STATEMENT action="*">
079:                 <P3P:REF name="*.Postal.PostalCode"/>
080:                 <P3P:REF name="ShipTo.*"/> 
081:                 <P3P:REF name="BillTo.*"/> 
082:             </P3P:STATEMENT> 
083:             </P3P:USES>
084:           </P3P:PROP>
085:         </RDF:LI>
086:         <!-- Next, we identify an insecure line. -->
087:         <RDF:LI>
088:           <!-- Since we want this rule to reject the request
089:                even if the protocol format cannot be established
090:                at all, we enclose the element below in an
091:                OPTIONAL tag. Otherwise a missing SSL extension
092:                would make this rule fail (i.e. _not_ reject). -->
093:           <APPEL:OPTIONAL>
094:             <!-- The SSL data schema is defined in our xml name-
095:                  space header at the beginning of this file. --> 
096:             <SSL:PROTOCOL active="no">
097:           </APPEL:OPTIONAL>		   
098:         </RDF:LI>
099:       </RDF:BAG> 

100:       </APPEL:RULE> 
101:       </RDF:LI>


102:     <!-- Rule 4: Prompt me if credit card information is
103:                  collected over a secure line for completion of 
104:                  the current activities. -->

105:       <RDF:LI>
106:       <APPEL:RULE behavior="prompt"  
107:                   description="Credit Card information is
108:                   collected over a secure line for completion of
109:                   the current activities. You might want to
110:                   consider releasing it.">  

111:       <!-- We need to enumerate multiple conditions here, so
112:            we use the RDF:BAG element. -->
113:       <RDF:BAG>
114:         <!-- Although Credit Card information is not in the P3P
115:              base set of elements, we can simply reference here
116:              any kind of element we expect to be contained in a
117:              proposal. -->
118:         <RDF:LI>
119:           <P3P:PROP> 
120:             <P3P:USES>
121:             <!-- purp="0" == "Completion of current activities" -->
122:             <P3P:STATEMENT action="*" purp="0">
123:                 <!-- matches: "Visa.CreditCard.Number"
124:                      or "MC.CreditCard.ExpirationDate" -->
125:                 <P3P:REF name="*.CreditCard.*"/>
126:                 <!-- we can also use categories for unknown
127:                      elements, although this might match more
128:                      than just credit card information. --> 
129:                 <P3P:REF category="3"/>
130:                 <!-- "3" == "Financial Account Identifiers" -->
131:             </P3P:STATEMENT> 
132:             </P3P:USES>
133:           </P3P:PROP>
134:         </RDF:LI>
135:         <!-- Next, we identify an secure line. -->
136:         <RDF:LI>
137:           <!-- Since we want this rule to prompt only if the
138:                secure protocol can reliably be established, we do
139:                _not_ use OPTIONAL tags. -->
140:           <SSL:PROTOCOL active="yes">
141:         </RDF:LI>
142:       </RDF:BAG> 

143:       </APPEL:RULE> 
144:       </RDF:LI>


145:     <!-- Rule 5: Prompt me if form data is collected for
146:                  marketing purposes or if it asks for elements
147:                  from the Financial Account Category. -->

148:     <!-- "OR"ed rules effectively translate into two separate
149:           rules in APPEL -->
150:       <RDF:LI>
151:       <APPEL:RULE behavior="prompt"  
152:                   description="form data is collected for
153:                                marketing purposes.">  
154:         <P3P:PROP> 
155:           <P3P:USES>
156:           <P3P:STATEMENT purp="4">
157:               <P3P:REF name="Form.Data_"/> 
158:           </P3P:STATEMENT> 
159:           </P3P:USES>
160:         </P3P:PROP>

161:       </APPEL:RULE> 
162:       </RDF:LI>
163:       <RDF:LI>
164:       <APPEL:RULE behavior="prompt"  
165:                   description="form data asks for elements
166:                                from the Financial Account
167:                                Category.">  
168:         <P3P:PROP> 
169:           <P3P:USES>
170:           <P3P:STATEMENT>
171:               <!-- Note that the category in the proposal only
172:                    has to _include_ "3", but can also reference
173:                    other categories. --> 
174:               <P3P:REF name="Form.Data_" category="3"/> 
175:           </P3P:STATEMENT> 
176:           </P3P:USES>
177:         </P3P:PROP>

178:       </APPEL:RULE> 
179:       </RDF:LI>


180:     <!-- Rule 6: Accept proposals asking for read access to
181:                  clickstream data, zipcode, demographics,
182:                  shipping information, billing information,
183:                  search text, credit card information or form
184:                  data.  -->
185:       <RDF:LI>
186:       <APPEL:RULE behavior="accept"  
187:                   description="verified access to clickstream
188:                                data, zipcode, demographics, 
189:                                shipping information, billing
190:                                information, search text, credit
191:                                card information or form data ">  
192:         <P3P:PROP> 
193:           <P3P:USES>
194:           <!-- Make sure we set action to "read" here, otherwise
195:                we might allow write access to the elements below! -->
196:           <P3P:STATEMENT action="r">
197:               <P3P:REF name="ClickStream.Client_"/>
198:               <P3P:REF name="*.Postal.PostalCode"/>
199:               <P3P:REF category="8"/>
200:               <!-- "8" == "Demographics and SocioEconomic Data" -->
201:               <P3P:REF name="ShipTo.*"/> 
202:               <P3P:REF name="BillTo.*"/> 
203:               <P3P:REF name="Form.SearchText_"/> 
204:               <P3P:REF name="*.CreditCard.*"/>
205:               <P3P:REF name="Form.Data_"/> 
206:           </P3P:STATEMENT> 
207:           </P3P:USES>
208:         </P3P:PROP>
209:       </APPEL:RULE> 
210:       </RDF:LI>


211:     <!-- Rule 7: Accept proposals from my bank asking for read
212:                  access to clickstream data, zipcode,
213:                  demographics, shipping information, billing
214:                  information, search text, credit card
215:                  information or form data, and read & write
216:                  access to my account number. -->

217:       <RDF:LI>
218:       <APPEL:RULE behavior="accept"  
219:                   description="bank access to clickstream
220:                                data, zipcode, demographics, 
221:                                shipping information, billing
222:                                information, search text, credit
223:                                card information, form data and
224:                                account information">  
225:         <P3P:PROP realm="*.mybank.com"> 
226:           <P3P:USES>
227:           <!-- Make sure we set action to "read" here, otherwise
228:                we might allow write access to the elements below! -->
229:           <P3P:STATEMENT action="r">
230:               <P3P:REF name="ClickStream.Client_"/>
231:               <P3P:REF name="*.Postal.PostalCode"/>
232:               <P3P:REF category="8"/>
233:               <!-- "8" == "Demographics and SocioEconomic Data" -->
234:               <P3P:REF name="ShipTo.*"/> 
235:               <P3P:REF name="BillTo.*"/> 
236:               <P3P:REF name="Form.SearchText_"/> 
237:               <P3P:REF name="*.CreditCard.*"/>
238:               <P3P:REF name="Form.Data_"/> 
239:           </P3P:STATEMENT> 
240:           <P3P:STATEMENT action="rw">
241:               <P3P:REF category="3"/>
242:               <!-- "3" == "Financial Account Identifiers" -->
243:           </P3P:STATEMENT> 
244:           </P3P:USES>
245:         </P3P:PROP>
246:       </APPEL:RULE> 
247:       </RDF:LI>


248:     <!-- Rule 8: Accept proposals from my computer retailer
249:                  asking for read access for my home contact
250:                  information and read & write access to my
251:                  computer related information, until November
252:                  1st, 1999. -->
253:       <RDF:LI>
254:       <APPEL:RULE behavior="accept"
255:                   expires="Mon, 01-Nov-1998 00:00:00 GMT"
256:                   description="service contract with my
257:                                computer retailer">  
258:         <P3P:PROP realm="*.myretail.com"> 
259:           <P3P:USES>
260:           <!-- Make sure we set action to "read" here, otherwise
261:                we might allow write access to the elements below! -->
262:           <P3P:STATEMENT action="r">
263:               <P3P:REF name="Home.*"/>
264:           </P3P:STATEMENT> 
265:           <P3P:STATEMENT action="rw">
266:               <P3P:REF category="4"/>
267:               <!-- "4" == "Computer Information" -->
268:           </P3P:STATEMENT> 
269:           </P3P:USES>
270:         </P3P:PROP>
271:       </APPEL:RULE> 
272:       </RDF:LI>

273:     <!-- Rule 9: Implicit default reject rule. -->

274:       <RDF:LI> 
275:       <APPEL:RULE behavior="reject" 
276:                   explanation="Proposal not acceptable"> 
277:           <APPEL:OTHERWISE/> 
278:       </APPEL:RULE> 
279:       </RDF:LI>

280:     </RDF:SEQ> 
281:     </APPEL:RULES>

282:   </APPEL:GROUP> 
283:   </RDF:LI>

284: </RDF:SEQ> 
285: </APPEL:RULESET> 
286: </APPEL:APPEL> 
287: </RDF:RDF>

6.2 Explicit Disclosure

The second approach (which we will only outline here) is more helpful for automated processes that want to create rulesets from a declarative list of user preferences over repository data elements, as they would for example result from a simple graphical user interface.

The idea is to use "accept" preferences directly without translating them into "reject"/"accept" pairs first (as described in the previous section). The rulesets created this way grow bigger in size than their counterparts written according to the previous recipe, but have the advantage that we can use positive privacy assertions from the user, which is for many people easier to specify than the filtering rules described above.

However, what has been briefly described before using two accept rules now grows laborious when we have to combine a larger number of "accept"ing rules, due to the combinatorial explosion: For each possible combination of conditions we have to explicitly write an accept rule enumerating the list of elements that should be released under these conditions

That is why the first approach, using reject rules in conjunction with accept rules, will be preferred by human rule authors. Automated processes though should be able to follow a simple mechanical recipe for constructing such rulesets using such explicit disclosure (i.e. "accept"ing/"prompt"ing rules only).

7 Appendices

7.1 Trust Engines and Database Engines

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.

7.2 Working Group Contributors

Lorrie CranorAT&T Labs-Research
Marc Langheinrich (Editor)NEC
Massimo MarchioriW3C
Joseph ReagleW3C
Drummond ReedIntermind
Mary Ellen Zurko (Chair)Iris

References

[PicsRules]
Christopher Evans, Clive D.W. Feather, Alex Hopmann, Martin Presler-Marshall, Paul Resnick, "PICSRules Specification" 29 December 1997. See /TR/REC-PICSRules at http://www.w3.org/
[RDF]
Ora Lassila, Ralph R. Swick (editors), "Resource Description Framework (RDF) Model and Syntax" 16 February 1998. See /TR/WD-rdf-syntax at http://www.w3.org/
[P3P10]
Massimo Marchiori, Dan Jaye (editors), "Platform for Privacy Preferences (P3P) Syntax Specification" 19 May 1998. See /TR/WD-P3P10-syntax at http://www.w3.org/
[RFC 2068]
R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1" January 1997. See /rfc/rfc2068.txt at http://ds.internic.net/.
[RFC 2219]
S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels" See /rfc/rfc2119.txt at http://ds.internic.net/.
[RFC 822]
David H. Crocker (editor), Standard for the format of ARPA Internet text messages See /rfc/rfc822.txt at http://ds.internic.net/.
[URI]
T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." 1997. (Work in progress; see updates to RFC1738.)
[UTF-8]
F. Yergeau. "RFC 2279 -- UTF-8, a transformation format of ISO 10646." January 1998. See See /rfc/rfc2279.txt at http://ds.internic.net/
[Keynote]
Blaze, Feigenbaum, Keromytis, "Keynote Trust Management System".