RE: Grouping Statements Proposal

Attached is my first try at modifying Matthias's proposal to incorporate
mine.

Feedback is welcomed,

Jeremy

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

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.

Jeremy

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

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

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