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: Fri, 13 Feb 2004 14:43:38 -0500
Message-ID: <D464F551A951ED4E804B9713B519E6C902941E24@NYC-EX101.doubleclick.net>
To: "'Humphrey, Jack'" <JHumphrey@coremetrics.com>, "'Lorrie Cranor'" <lorrie@cs.cmu.edu>
Cc: public-p3p-spec@w3.org

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).


-----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.


-----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


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 

> 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 

Received on Friday, 13 February 2004 14:43:56 UTC

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