Re: P3P 1.1 Domain Relationships

Hmm.... without KNOWN-HOSTS A can use the HTTP header method to 
reference a PRF on B, which is about a policy on B. That policy may or 
may not actually apply to any URIs on B. With KNOWN-HOSTS, B can 
declare that the policy A is referencing is a policy that has been 
established as part of an "ours" relationship. Before we can answer any 
questions about transitivity and what not, perhaps we need to actually 
spell out what an ours relationship is. Probably something like:

- A single entity operates host A and host B, but might possibly have 
different policies for host A and host B
- Host A acts as an agent of host B and all data collection and uses 
are in accordance with host B's policy (or one of host B's policies) 
and are done on behalf of host B - either A or B might be declared as 
the entity in the policy
- Host B acts and an agent of host A and all data collection and uses 
are in accordance with host A's policy (or one of host A's policies) 
and are done on behalf of host A - either A or B might be declared as 
the entity in the policy


Lorrie




On Feb 17, 2004, at 9:43 AM, Dobbs, Brooks wrote:

>
> 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?
>
> -B
>
>
> -----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.
>
> Lorrie
>
>
>
>> -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
>>> 2.3.2.7 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 11:08:45 UTC