W3C home > Mailing lists > Public > public-p3p-spec@w3.org > August 2003

RE: Grouping Statements Proposal

From: Jeremy Epling <jepling@windows.microsoft.com>
Date: Thu, 28 Aug 2003 14:34:30 -0700
Message-ID: <C0289E3872DEC2498185DD1743006C2E029891CF@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
To: "Jeremy Epling" <jepling@windows.microsoft.com>, "Matthias Schunter" <mts@zurich.ibm.com>, "Lorrie Cranor" <lorrie@research.att.com>
Cc: <public-p3p-spec@w3.org>
Attached is my first try at modifying Matthias's proposal to incorporate

Feedback is welcomed,


-----Original Message-----
From: public-p3p-spec-request@w3.org
[mailto:public-p3p-spec-request@w3.org] On Behalf Of Jeremy Epling
Sent: Thursday, August 28, 2003 12:40 PM
To: Matthias Schunter; Lorrie Cranor
Cc: public-p3p-spec@w3.org
Subject: RE: Grouping Statements Proposal

I think that these could just be one proposal once the paradigms are

Can we just deprecate the opt-in, opt-out, and required attributes and
say that if used the agent with take precedence with the consent tag.


-----Original Message-----
From: Matthias Schunter [mailto:mts@zurich.ibm.com] 
Sent: Monday, August 11, 2003 6:13 AM
To: Lorrie Cranor; Jeremy Epling
Cc: public-p3p-spec@w3.org
Subject: Re: Grouping Statements Proposal


The proposal looks good. Once Jerry contacts me, I'll work with him to 
resolve the remaining issues. Some initial ideas/remarks:
- the opt-in or opt-in elements inside all elements of an opt-in/out-out

group where included
   to preserve backward compatibility of the semantics.
- The issue of the OURS/CURRENT may be resolved by defining that they 
cannot be included in an
   opt-in/opt-out group.
- Does it makes sense to use "required" instead of "no-group" or do you 
envision that with
   consent="no-group", one can nevertheless have opt-in's and out's


At 11:58 AM 8/6/2003 -0400, Lorrie Cranor wrote:

>We discussed  this on today's call, minutes should be forthcoming. My 
>quick summary is:
>- combining these two group concepts probably makes sense
>- we probably want an extension that looks something like the following

>that can be inserted into all statement's that belong to a group:
>   <STATEMENT-GROUP id = "fflyer" />
>. . .
>Then somewhere else in the policy
>   <STATEMENT-GROUP-DEF id="fflyer"
>   short-description="Frequent Flyer Club"
>   consent = "opt-in" />
>Some groups of statements might not be consent groups, in which case
>might use an attribute like consent = "no-group" (which might be the
>There are also some concerns about consent group that need to be worked

>out. In Mathias' proposal it says that all PURPOSE and RECIPIENT
>in a group have to have the same required attribute. But ours and
>are special cases that don't have this attribute. This needs to be 
>accounted for (the example in Mathias' draft is actually incorrect
>of this). Also we need to be clear on how to handle errors. What if 
>someone uses consent group but then uses different required attributes 
>(which is incorrect)? Does that invalidate the policy? Perhaps if that 
>happens the user agent should treat it as if it is consent = "no-group"
>In any case, Jeremy is going to put together a more specific proposal
>this grouping. Mathias, it would be great if you could work with him on

>the consent aspect.
>On Wednesday, July 30, 2003, at 02:53  AM, Matthias Schunter wrote:
>>Hi Jeremy,
>>thanks for your design. I feel that grouping statements is a good
>>The actual syntax for grouping is elaborated in our earlier draft on 
>>consent choices:
>>  http://www.w3.org/P3P/2003/05-cc-changes-to-P3P.html
>>I feel that grouping statements is a good idea for multiple purposes.
>>Therefore, I feel that we should have a general group mechanism where 
>>each group should have multiple properties:
>>- opt-in opt-out or always (from consent choices)
>>   syntactically this can be implicit: either all statements are 
>> always/opt-in, or opt-out.
>>- target (something specifying whether it's the ebay or amazon part)
>>   The target is something that might be useful to add to your
>>   I don't know how to express this in a nice syntax.
>>Why don't we merge both proposals into a "grouping statements"
>>At 07:00 PM 7/29/2003 -0700, Jeremy Epling wrote:
>>>Below are the basics of my proposal for statement grouping.
>>>    * Policies are not relevant to how a user interacts with the site
>>>        * Users don t know what part of a P3P policy applies to them
>>> there activities on a site
>>>        * Users understand scenarios of how they interact with a site

>>> better than a series of statements related to a feature of the site
>>>    * Policy authors have to make highest common denominate policies 
>>> that could look more privacy impacting than they are for most users
>>>    * Provide a method for showing the sections of the P3P policy
>>> apply to how a user interacts with the site/service
>>>    * Allow an easy way for policy authors to describe what sections
>>> their P3P policy apply to different user interaction with their
>>>    * User browses to ebay and views the P3P policy. They are able to

>>> skip to the buyer section of the P3P policy since that is what
applies to them.
>>>    * User browses to amazon and views the P3P policy. The can see
>>> since they are not logged in less information is collected about
>>>The P3P author decides the name of the statement group which is used
>>>the display of the agent when it translates the nodes to natural
>>>             <extention>
>>>                         <grouping-id>Member</grouping-id>
>>>             </extention>
>>>    * Do agents now show conflicts per grouping?
>>>Jeremy Epling
>>>Windows - Privacy and Trust UX
>>><BLOCKED::>wpihelp - where to go for all your privacy questions
>>-- Dr. Matthias Schunter <mts (at) zurich.ibm.com> ---
>>IBM Zurich Research Laboratory,   Ph. +41 (1) 724-8329
>>Fax +41-1-724 8953; More info at www.semper.org/sirene
>>PGP Fingerprint    989AA3ED 21A19EF2 B0058374 BE0EE10D

-- Dr. Matthias Schunter <mts (at) zurich.ibm.com> ---
IBM Zurich Research Laboratory,   Ph. +41 (1) 724-8329
Fax +41-1-724 8953; More info at www.semper.org/sirene
PGP Fingerprint    989AA3ED 21A19EF2 B0058374 BE0EE10D

Received on Thursday, 28 August 2003 17:36:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:17 UTC