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

Re: Grouping Statements Proposal

From: Lorrie Cranor <lorrie@research.att.com>
Date: Mon, 11 Aug 2003 09:52:57 -0400
Cc: "Jeremy Epling" <jepling@windows.microsoft.com>, <public-p3p-spec@w3.org>
To: Matthias Schunter <mts@zurich.ibm.com>
Message-Id: <1D48AD18-CC03-11D7-AF42-000393DC889A@research.att.com>


On Monday, August 11, 2003, at 09:13  AM, Matthias Schunter wrote:

> Hi!
>
> 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.

Yes, that's what I remember too. But the problem still occurs as to 
what to do if people violate this rule. I think we need to define how 
to handle this error case.

> - The issue of the OURS/CURRENT may be resolved by defining that they 
> cannot be included in an
>   opt-in/opt-out group.

I think we may need to include them, but perhaps we can define that the 
opt-in/opt-out doesn't apply to them.

> - 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 
> inside?

I was envisioning the "no-group" would indicate a mix of opt-in's 
opt-out's and required, or all required.

Lorrie


>
> Regards,
>  matthias
>
>
>
>
> 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>
>> <EXTENSION>
>>   <STATEMENT-GROUP id = "fflyer" />
>> </EXTENSION>
>> . . .
>> </STATEMENT>
>>
>> Then somewhere else in the policy
>> <EXTENSION
>>   <STATEMENT-GROUP-DEF id="fflyer"
>>   short-description="Frequent Flyer Club"
>>   consent = "opt-in" />
>> </EXTENSION>
>>
>> Some groups of statements might not be consent groups, in which case 
>> they might use an attribute like consent = "no-group" (which might be 
>> the default).
>>
>> There are also some concerns about consent group that need to be 
>> worked out. In Mathias' proposal it says that all PURPOSE and 
>> RECIPIENT elements in a group have to have the same required 
>> attribute. But ours and current are special cases that don't have 
>> this attribute. This needs to be accounted for (the example in 
>> Mathias' draft is actually incorrect because 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 
>> on this grouping. Mathias, it would be great if you could work with 
>> him on the consent aspect.
>>
>> Lorrie
>>
>>
>> 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 
>>> idea.
>>>
>>> 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 
>>> proposal.
>>>   I don't know how to express this in a nice syntax.
>>>
>>> Why don't we merge both proposals into a "grouping statements" 
>>> proposal?
>>>
>>> Regards,
>>>
>>> matthias
>>>
>>>
>>>
>>> At 07:00 PM 7/29/2003 -0700, Jeremy Epling wrote:
>>>
>>>> Below are the basics of my proposal for statement grouping.
>>>>
>>>>
>>>>
>>>> Problems
>>>>    * 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 
>>>> and 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
>>>>
>>>>
>>>> Goals
>>>>    * Provide a method for showing the sections of the P3P policy 
>>>> that apply to how a user interacts with the site/service
>>>>    * Allow an easy way for policy authors to describe what sections 
>>>> of their P3P policy apply to different user interaction with their 
>>>> site/service
>>>>
>>>>
>>>> Scenarios
>>>>    * 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 
>>>> that since they are not logged in less information is collected 
>>>> about them.
>>>>
>>>>
>>>> Design
>>>>
>>>>
>>>>
>>>> The P3P author decides the name of the statement group which is 
>>>> used in the display of the agent when it translates the nodes to 
>>>> natural language.
>>>>
>>>>
>>>>
>>>> <Statement>
>>>>
>>>>             <extention>
>>>>
>>>>                         <grouping-id>Member</grouping-id>
>>>>
>>>>             </extention>
>>>>
>>>> <statement>
>>>>
>>>>
>>>>
>>>> Issues
>>>>    * 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 Monday, 11 August 2003 09:50:02 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 17 March 2004 17:46:27 EST