Re: Grouping Statements Proposal

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
>

Received on Wednesday, 6 August 2003 11:55:59 UTC