WD-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

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.

1.2 Goals of A P3P Preference Exchange Language

• Sharing and installation of rulesets. Sophisticated preferences may be difficult for end-users to specify, even through well-crafted user interfaces. An organization can create a set of recommended preferences for users. Users who trust that organization can install a pre-defined ruleset rather than specifying a new set from scratch. It will be easy to change the active ruleset on a single computer, or to carry a ruleset to a new computer.
• Communication to agents, search engines, proxies, or other servers. Servers of various kinds may wish to tailor their output to better meet users' preferences, as expressed in a ruleset. For example, a search service can return only links that match a user's ruleset, which may specify criteria based on a variety of factors including quality, privacy, age suitability, or the safety of downloadable code.
• Portability between products. The same ruleset will work with any P3P-APPEL enabled product.

Primarily, we envision this language will be used to allow users to import preference rulesets created by other parties and to transport their own rulesets files between multiple user agents. User agent implementors might 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

• APPEL rules should allow the expression of preferences over anything that can be expressed in the P3P base schema as well as all other RDF metadata relevant to P3P decision making (e.g., is the communication channel secured). (APPEL rules may express preferences over PICS labels if they are translated into an appropriate RDF schema.)
• APPEL should address situations in which a service does not offer a P3P proposal.
• APPEL rules should be able to prescribe the following set of behaviors: accept, reject, and prompt. In addition, APPEL should include extensibility mechanisms that allow rules to describe additional behaviors.
• APPEL encoding should be consistent with other P3P work and leverage members' existing work and code base. As much as possible, the encoding should be simple and support the efficient computation of rule matches.

• APPEL rules need not allow the expression of "sophisticated" rules based on the presence of multiple data elements within a P3P proposal (for example, a rule that would allow a zipcode to be collected unless a full name is also collected).
• APPEL need not be capable of expressing rules for ranking multiple proposals. Rather it expresses the rules necessary for determining whether a single proposal triggers a behavior. If more than one P3P proposal is available, they should be submitted to the rule evaluator individually. It is up to the calling program to determine what to do if multiple proposals are acceptable, or if a "prompt" behavior is returned while evaluating multiple proposals.
• A compact or easy-to-read representation is not essential.
• APPEL need not be capable of expressing negotiation strategies.
• APPEL rules need not be able to express preferences based on state information (unless such information is encoded in RDF and submitted to an APPEL engine as any other metadata would be submitted).

1.4 Definitions

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:

• string-valued, e.g. realm="http://www.foo.com"
• single-numeric-valued, e.g. id="0"
• multi-numeric-valued, e.g. purp="AND:0,1,2"

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.

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

2.1 Inputs and Outputs of the Rule Evaluator

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:

• "accept": the provided evidence is acceptable. If a P3P proposal is provided, it should be accepted. If a URI is provided, the resource at that URI should be accessed.
• "prompt": the user should be consulted to determine whether the provided evidence is acceptable. It is up to the calling program to determine how the user should be prompted.
• "reject": the provided evidence is not acceptable. If a P3P proposal is provided, it should be rejected. If a URI is provided, the resource at that URI should not be accessed. When rejecting a proposal, it is up to the calling program to determine whether to ask for another proposal, send a counter proposal, or simply stop interacting with the corresponding site.

2.2 Rule Processing and Evaluation

2.2.1 Rule Processing

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

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

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

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

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

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

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

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

4.1.1 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

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

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

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.

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.

[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

5.1 The Rule Evaluator in a nutshell

5.1.1 Behaviors

5.1.2 Rulesets

• Groups
  A group contains a list of triggers, together with an ordered list of rules. Group's triggers will be evaluated in the order the groups are listed in the ruleset. If a specific group matches the conditions set forth in its triggers, its rules become the active set of rules, all other rules are ignored for the rest of the evaluation.

  A group with only the degenerate-expression in its trigger set is called the "default group". It will become active if none of its preceding groups was triggered. Each APPEL ruleset should have exactly one (and only one) default group, placed at the end of the list of groups.

• Rules
  Each rule contains one or more expressions and features one or more behaviors. All expressions in a rule are implicitly ANDed together and are matched by the rule evaluator against the elements in the evidence. A rule containing no expressions always evaluates to false, a rule containing only the degenerate expression always evaluates to true.

  Each rule in a ruleset or group is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned (also see section 5.6 Extensible Behaviors) and rule evaluation ends. If no match occurs and all rules have been processed, an error is returned to the calling program.

5.2 Group, triggers and rules ordering

How APPEL evaluates multiple groups in a ruleset, or multiple triggers or rules in a group

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

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

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

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

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

• Value matching (Simple Expressions)
  Anything between quotes, for example <PROP realm="*.bank.com">.
• Attribute matching
  Any attribute of an XML element, for example <PROP realm="*.bank.com">.
• Element matching (Data Reference Expressions)
  Data-reference elements inside a P3P proposal, for example <REF name="User.*">.

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)

• string-valued, e.g. realm="http://www.foo.com"
• single-numeric-valued, e.g. id="0"
• multi-numeric-valued, e.g. purp="AND:0,4,2"

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

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

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

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)

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

ALL all of the specified elements must be present, but additional elements are allowed. ANY at least one of the specified elements must be present, but additional elements are allowed. (1 or more) [Default for non-"accept"ing rules] ONLY only 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-ONLY an 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
Behavior Default Explanation "accept" and other "accept"ing behavior extensions. ONLY matches 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. ANY matches even if proposals ask for more elements than specified.

5.4.6 Category translation support

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

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

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

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

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

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

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

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

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

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

Don't give out clickstream data in identifiable form. Don't give out my zip code in identifiable form or for marketing purposes. Don't give out demographics (age, gender, income, education) in identifiable form, or over an insecure line. Don't give out my shipping and billing address for purposes other than the completion of the current activity. Don't allow solicitation of search text in identifiable form. Don't allow my bank to read & write to my account number over an insecure line. 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). I want to be prompted if form data is collected for marketing purposes, or if it is from the Financial Account Category.. Allow the release of clickstream, zip code, demographics, shipping and billing address and search text if nothing else is collected. Allow my bank to read & write to my account number. 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.

Reject if clickstream data is used in identifiable form. Reject if zipcode data is used in identifiable form. Reject if zipcode data is used for marketing purposes. Reject if demographics data is used in identifiable form. Reject if demographics is collected over an insecure line. Reject if shipping or billing information is collected for purposes other than completion of current activity purposes. Reject if search text is collected in identifiable form. Reject proposals from my bank asking for read & write access to my account number over an insecure line. Prompt me if credit card information is collected over a secure line for completion of current activity purposes. Prompt me if form data is collected for marketing purposes or if it asks for elements from the Financial Account Category. Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data. 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. 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

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

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

• Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data.
• Accept proposals from my bank asking for read & write access to my account number.

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:

• Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data.
• 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.

Collation

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.

Reject if clickstream, zipcode, demographics data or search text is used in identifiable form. Reject if zipcode, shipping or billing information is collected for purposes other than completion of current activity purposes. Reject if demographics or account information is collected (or written) over an insecure line. Prompt me if credit card information is collected over a secure line for completion of current activity purposes. Prompt me if form data is collected for marketing purposes or if it asks for elements from the Financial Account Category. Accept proposals asking for read access to clickstream data, zipcode, demographics, shipping information, billing information, search text, credit card information or form data. 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. 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 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

7.2 Working Group Contributors

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