- From: Lorrie Cranor <lorrie@research.att.com>
- Date: Fri, 29 Aug 2003 09:08:17 -0400
- To: Matthias Schunter <mts@zurich.ibm.com>
- Cc: "Jeremy Epling" <jepling@windows.microsoft.com>, <public-p3p-spec@w3.org>
I agree with Matthias' comments about the opt-in/opt-out. Other than that, the proposal looks conceptually ok. I would like to see a sentence or two giving an example of what this is useful for. Also, the BNF and policy syntax fragments need to be done properly. Lorrie On Thursday, August 28, 2003, at 06:02 PM, Matthias Schunter wrote: > > 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 Friday, 29 August 2003 09:05:06 UTC