RE: Grouping Statements Proposal

I did some more minor revisions. I added a description of the consent 
attribute.

Regards,
  matthias


At 12:34 PM 8/30/2003 +0200, Matthias Schunter wrote:
>Hi Folks,
>
>I reviewed the spec and made the following changes:
>
>STATEMENTS:
>- I deleted the requirement that all statements must have a group
>- I added some text describing an example
>- I added Jerry as an author
>
>GROUP-DEFS:
>- The consent is now "opt-in", "opt-out", "required"
>   The first three must be 'inherited' by all statements in this group.
>- I made it explicit that <Recipient ours> and <purpose current> cannot be 
>used
>   inside statements that are in a group that is declared opt-in or opt-out.
>
>QUESTIONS:
>- I did now allow one statement to belong to multiple groups. I feel that 
>this would
>   be too confusing.
>- I thought about enabling groups that define "consent='mixed'" which 
>enables to group statements that have a mixture of opt-in, opt-out, and 
>required. But I felt that this is not useful.
>
>Regards,
>  matthias
>
>
>
>At 02:34 PM 8/28/2003 -0700, Jeremy Epling wrote:
>>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
>>
>>
>>
>
>
>
>-- 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, 1 September 2003 03:10:13 UTC