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

Re: Grouping Statements Proposal

From: Lorrie Cranor <lorrie@research.att.com>
Date: Wed, 13 Aug 2003 11:42:40 -0400
Cc: Matthias Schunter <mts@zurich.ibm.com>, "Jeremy Epling" <jepling@windows.microsoft.com>
To: <public-p3p-spec@w3.org>
Message-Id: <C582A353-CDA4-11D7-AF42-000393DC889A@research.att.com>

Matthias and Jeremy,

We discussed this on the call today and would like to move this 
forward. We need a revised proposal. Jeremy, are you going to get us 
something this week? Or perhaps Matthias could revise his proposal to 
incorporate what we've discussed? I would like to have something more 
concrete to discuss before next week's call.

Thanks,

Lorrie



On Monday, August 11, 2003, at 09:52  AM, Lorrie Cranor wrote:

>
>
> 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 Wednesday, 13 August 2003 11:39:42 EDT

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