- From: Matthias Schunter <mts@zurich.ibm.com>
- Date: Mon, 01 Sep 2003 09:09:51 +0200
- To: "Jeremy Epling" <jepling@windows.microsoft.com>, "Jeremy Epling" <jepling@windows.microsoft.com>, "Lorrie Cranor" <lorrie@research.att.com>
- Cc: <public-p3p-spec@w3.org>
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