RE: Grouping Statements Proposal

Hi Jerry,

thanks for the update. I'll review it and comment/update it.

The reason why I did the mandatory opt-in was to preserve semantics:
- The semantics of a P3P 1.1 and P3P 1.0 policy should be similar

If the semantics supersedes the opt-in/outs of 1.0 or if there must not be 
any opt-in/outs then it may happen that something is optional in 1.1 that 
is required in 1.0 or vice versa.

Regards,
  matthias

At 12:39 PM 8/28/2003 -0700, Jeremy Epling wrote:

>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

Received on Thursday, 28 August 2003 18:04:52 UTC