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