W3C home > Mailing lists > Public > public-p3p-spec@w3.org > February 2004

RE: P3P 1.1 Domain Relationships

From: Dobbs, Brooks <bdobbs@doubleclick.net>
Date: Tue, 17 Feb 2004 09:43:30 -0500
Message-ID: <D464F551A951ED4E804B9713B519E6C902941E31@NYC-EX101.doubleclick.net>
To: "'Lorrie Cranor'" <lorrie@cs.cmu.edu>, "Dobbs, Brooks" <bdobbs@doubleclick.net>
Cc: "'Humphrey, Jack'" <JHumphrey@coremetrics.com>, public-p3p-spec@w3.org

Okay phrased badly on my part.  I guess my point is simply that if A and C
both point to the exact same policy (on B and shared by B) using "same
entity", it seems logical to me to infer that A and C are themselves the
same entity?  No?


-----Original Message-----
From: Lorrie Cranor [mailto:lorrie@cs.cmu.edu] 
Sent: Friday, February 13, 2004 10:37 PM
To: Dobbs, Brooks
Cc: 'Humphrey, Jack'; public-p3p-spec@w3.org
Subject: Re: P3P 1.1 Domain Relationships

On Feb 13, 2004, at 2:43 PM, Dobbs, Brooks wrote:

> I think this may present problems for the exact reason you cite, if B
> is an
> agent of A and C then do we truly have a "same entity" relationship? 
> or have
> we mixed in agents again?  The way I read the language in this 
> proposal, it
> implies to me that KNOWN HOSTS should be used only if the entity 
> information
> that would have been listed in separate policy files is (would have 
> been)
> identical.  I think that if a transitive association of policies can be
> implied by this mechanism it should be a requirement that the 
> independent
> policies would have listed materially the same entity information.
> I guess the question becomes, "is known hosts saying that the 
> practices (e.g. Categories, Purpose, Recipient, Retention, Access, 
> Disputes) are the same or is it saying the practices and data 
> controller are the same" (sorry
> I know I used a loaded term with data controller).

My understanding is that KNOWN-HOST lets host A point to a PRF and 
policy on host B instead of declaring their own policy.  So there is no 
other policy to be the same with.


> -Brooks
> -----Original Message-----
> From: public-p3p-spec-request@w3.org 
> [mailto:public-p3p-spec-request@w3.org]
> On Behalf Of Humphrey, Jack
> Sent: Thursday, February 12, 2004 2:36 PM
> To: 'Dobbs, Brooks'; 'Lorrie Cranor'
> Cc: public-p3p-spec@w3.org
> Subject: RE: P3P 1.1 Domain Relationships
> I would say no, a user agent should not make that inference. I can add 
> a
> statement to the spec stating that the user agent can only apply the 
> "ours"
> relationship to the two hosts involved -- that the relationship is not
> transitive due to the possibility of B being an agent for both A and C,
> which are completely separate entities.
> ++Jack++
> -----Original Message-----
> From: Dobbs, Brooks [mailto:bdobbs@doubleclick.net]
> Sent: Wednesday, February 11, 2004 3:26 PM
> To: 'Lorrie Cranor'; Humphrey, Jack
> Cc: public-p3p-spec@w3.org
> Subject: RE: P3P 1.1 Domain Relationships
> Question:
> Does this address A=B, B=C but A<>C?  So imagine the case where hosts 
> on
> different domains www.a.com and www.b.com list each other as reciprocal
> known hosts.  Also imagine www.b.com and www.c.com describe the same
> relationship, should a user agent be able to make inferences about the
> relationship between www.a.com and www.c.com?
> -----Original Message-----
> From: public-p3p-spec-request@w3.org 
> [mailto:public-p3p-spec-request@w3.org]
> On Behalf Of Lorrie Cranor
> Sent: Tuesday, February 10, 2004 4:54 PM
> To: Humphrey, Jack
> Cc: public-p3p-spec@w3.org
> Subject: Re: P3P 1.1 Domain Relationships
> On Feb 9, 2004, at 12:53 AM, Humphrey, Jack wrote:
>> Working Group members,
>> Please read and comment on this latest draft:
>> http://www.w3.org/P3P/2004/02-domain-relationships.html
>> (Apologies, I thought this URL went out with the minutes. Rigo, I
>> don't think it's linked anywhere -- I just guessed the URL.)
> A few concerns:
> - When the HTTP header method is used to refer to a PRF on another
> host, it only makes sense if the other host has the same file structure
> or if the policy applies to * and/or to all cookies. Otherwise you
> could end up with conflicts. Perhaps this should be pointed out.
> - "Any number of KNOWN-HOST elements can be declared inside a
> POLICY-REF  element or inside the POLICY-REFERENCES element. Known host
> declarations at the POLICY-REFERENCES level are considered to apply to
> all policies in the file, excluding those that have specific
> declarations at the POLICY-REF  level." Is this really necessary? For
> simplicity I think it would be better to put KNOWN-HOST elements only
> inside a POLICY-REF element.
> - We should make clear that there is nothing wrong with sites
> continuing to refer to PRFs on other hosts without using the KNOWN-HOST
> extension. The extension just buys you extra information about the
> relationship.
>> Here are the open questions/issues I would like to discuss with the
>> group:
>> 1. For now, we have dropped the HTTP header mechanism seen in previous
>> drafts. There are two reasons: first of all, changing the P3P HTTP
>> header would require approval of a revised P3P header specification by
>> IETF. Secondly, there is a feeling that the PRF-based mechanism should
>> be a feasible way for user agents to discover this new information,
>> even for those user agents that only use compact policies to manage
>> cookie privacy.
> that makes sense
>> 2. The last section in the draft ("Cookie Playback") states:
>> User agents should be aware that if they allow a cookie to be set
>> based on a relationship established by known host declarations, they
>> should verify that such a relationship exists at cookie playback time,
>> and not send the cookie if it does not. Such verification implies
>> re-fetching the policy reference file and evaluating its known host
>> declarations only if the policy reference file has expired.
>> There is a concern that this language would have an impact on section
>> of the P3P spec, which says that a user agent "MAY request a
>> policy reference file from a host before replaying a cookie to that
>> host". Thoughts?
> The only conflict I see is with "Such verification implies re-fetching
> the policy reference file and evaluating its known host declarations
> only if the policy reference file has expired." which suggests that the
> re-verification should not be done if the PRF has not expired. While
> there is no reason to do it if the PRF has not expired, I don't think
> we need to say it shouldn't be done. What if we said instead "Such
> verification implies re-fetching an expired policy reference file and
> evaluating its known host declarations."
>> 3. The section in the draft entitled "HTTP Header Requirement" states:
>> The KNOWN-HOST extension relies on the use of the "P3P: policyref"
>> HTTP header for one site to refer to a policy reference file on
>> another site. Since policy reference files cannot include full URIs in
>> the POLICY-REF INCLUDE elements, sites that rely on placing their
>> policy reference file in the well-known location have no way of
>> referencing policies hosted on other sites.
>> Is it acceptable to require the use the policyref HTTP header for this
>> case? An alternative might be another PRF extension that would allow
>> one PRF to reference another PRF.
> Hmm... this is not ideal, but I think it is the best solution. If we
> were to add another extension than a user agent that was not aware of
> the extension would not be able to apply the policy at all. As it is
> written now, user agents can still figure out what policy applies even
> if they don't know the extension, they just won't know about the ours
> relationship.
> Lorrie
Received on Tuesday, 17 February 2004 09:43:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:18 UTC