W3C P3P 1.1 Domain Relationships

This version:
$Revision: 1.3 $ on $Date: 2003/12/16 13:10:49 $ GMT by $Author: rigo $
Latest version:
Previous version:
Drafts for same-entity and agent-relationsships
Jack Humphrey <jhumphrey at coremetrics.com>

Rigo Wenning <rigo at w3.org>

Jack Humphrey <jhumphrey at coremetrics.com>
See participants


This document specifies the expression of relationsships between different hosts by extending the syntax and semantics of the Policy Reference File.

Status of this document

This is an editors' draft with no standing. We are proposing that this document be folded into the P3P 1.1 specification in the places as indicated by the section numbers here.

Table of contents

  1. Introduction
  2. Limitations of P3P 1.0 Policy Reference File Syntax
  3. KNOWN-HOST Extension
    1. Avoiding Unintentional Matches in Cross-Host Policy Reference Files
    2. A Note on Compact Policies
    3. HTTP Header Requirement
    4. Cookie Playback


As part of the P3P 1.1 effort, this document describes an extension to P3P 1.0 to allow user agents to recognize when hosts in different domains are owned by the same entity or entities acting as agents for one another. These modifications would allow user agents to more intelligently apply privacy preferences, addressing implementation issues that have plagued many P3P deployments.1

Limitations of P3P 1.0 Policy Reference File Syntax

Consider the web sites example.com and forinstance.com, which are owned by the same company and share some web site content, hosted on example.com. Some of that content includes “internal” banner ads that are generated by a servlet on example.com and promote certain features on example.com. Both sites are owned by the same company and wish to deploy a single P3P policy that describes their single corporate policy on data collection and usage.

A simple policy reference file is deployed in the well-known location (/w3c/p3p.xml) on example.com:

    <META xmlns="http://www.w3.org/2002/01/P3Pv1">
			<POLICY-REF about="/p3p/policy.xml#corporate">

forinstance.com is configured to return the HTTP header

    P3P: policyref="http://www.example.com/w3c/p3p.xml"

When a web browser visits a page on forinstance.com, the user agent applies the policy at the URI http://www.example.com/p3p/policy.xml#corporate. If an image on that page is served by example.com, the same policy would be applied to that image request, after looking up the policy reference file at the well-known location.

Since both the page request and the image request are covered by the same privacy policy, the user agent should be able to understand that any data collected (via cookies or otherwise) is being collected and used by the same entity, and therefore may decide that no extra privacy restrictions should be applied for the image request to the different domain.

If the hosts were flipped, and example.com was serving the page and forinstance.com the image, the same logic should hold with the exact same P3P deployment. This possibility brings up an interesting point. Third-party sites should not be able to “spoof” being covered by the first party privacy policy if they are not. If, in our example, forinstance.com was not part of the same company, and had different data collection and usage policies, this mechanism could allow it to claim to be covered by the example.com policy when in fact it is not. Without an extension to P3P 1.0, the user agent would not be capable of verifying the relationship and the burden would fall on example.com to be sure that other sites referencing its privacy policies were doing so legitimately.

The same principle would apply if forinstance.com, instead of being owned by the same entity as example.com, were instead an agent of example.com. Agent is defined by the P3P 1.0 specification as “a third party that processes data only on behalf of the service provider for the completion of the stated purposes.”2 Note that the <ours> element of P3P does not distinguish between “ourselves” and “entities acting as our agents,”. KNOWN-HOST Extension

The KNOWN-HOST element allows sites to declare hosts that are allowed to refer to a policy or policies in a policy reference file. A user agent may use this extension element to verify that both sites acknowledge the sharing of a policy reference file.

The attribute name is a host name qualifier that can be a full individual host/domain name (e.g. www.example.com) or a wildcard qualifier describing a set of hosts/domains.

	known-hosts-extension		=	`<EXTENSION optional="yes">`
`</EXTENSION>` known-host = `<KNOWN-HOST`
[`name="` authority `"`]

Here, authority is defined as per RFC 2396 [URI], with the addition that the '*' character is to be treated as a wildcard, as defined in section

When one host (A) uses the "policyref" P3P HTTP header to refer to a policy reference file on another host (B), and B's policy reference file contains a matching KNOWN-HOST entry for A, then a user agent can verify that both hosts have acknowledged a relationship. The type of the relationship between A and B is not described by this mechanism, however if may be broadly inferred by the RECIPIENTS element in the applicable policy. For example, the ours recipient element would indicate that either A and B are owned by the same entity or that one is the agent of the other, whereas the unrelated recipient element could indicate that A and B are owned by completely unrelated parties.

Any relationships inferred by this mechanism are valid only in the context of the policy reference file and policy for which they were discovered -- this is not a mechanism for declaring globally that two hosts have a relationship in all contexts. By extension, the relationships are not transitive; if two distinct known hosts A and C refer to a policy reference file on host B, even if the same policy applies to both, nothing may be inferred about the relationship between A and C for use in other contexts.

In this example, forinstance.com and example.com are owned by the same company, and forinstance.com has referenced example.com's policy reference file. The example.com file would therefore have a KNOWN-HOST declaration for hosts in the forinstance.com domain. All such hosts would be allowed to reference the single policy declared in this file, which applies to all URIs and all cookies.

  <META xmlns="http://www.w3.org/2002/01/P3Pv1">
         <POLICY-REF about="/p3p/policy.xml#corporate">
             <COOKIE-INCLUDE name="*" value="*"/>

Any number of KNOWN-HOST elements can be declared inside a POLICY-REF element.

This example.com policy reference file shows several different policies and three KNOWN-HOST declarations. The first two declarations are for hosts in the forinstance.com domain and apply to the first two policy references("#corporate" and "#surveys). The third policy ("#dataProcessingAgent") covers a particular cookie set by an agent site that example.com has contracted with to provide data collection and processing services. This policy reference has a different known-host declaration, for hosts in the myagent.com domain. Since the forinstance.com domain is not declared as a known host for this policy, user agents can not verify a relationship between example.com and forinstance.com hosts as it applies to this policy.

  <META xmlns="http://www.w3.org/2002/01/P3Pv1">
         <POLICY-REF about="/p3p/policy.xml#corporate">
<COOKIE-INCLUDE name="*" value="*"/>
<COOKIE-EXCLUDE name="Survey*" value="*"/>
<COOKIE-EXCLUDE name="AgentCookie" value="*" domain=".myagent.com path="/"/>
<EXTENSION> <KNOWN-HOST name="*.forinstance.com" /> </EXTENSION> </POLICY-REF> <POLICY-REF about="/p3p/policy.xml#surveys"> <INCLUDE>/surveys/*</INCLUDE> <COOKIE-INCLUDE name="Survey*" value="*"/>
<EXTENSION> <KNOWN-HOST name="*.forinstance.com" /> </EXTENSION> </POLICY-REF>
<POLICY-REF about="/p3p/policy.xml#dataProcessingAgent"> <COOKIE-INCLUDE name="AgentCookie" value="*" domain=".myagent.com" path="/"/>
<EXTENSION> <KNOWN-HOST name="*.myagent.com" /> </EXTENSION> </POLICY-REF>

Browsers may cache the policy reference file based on an EXPIRY element in the policy reference file. The expiration information associated with that element should also be considered to apply to the known-hosts declarations; i.e. known host information may be cached along with the policy reference information.

The use of the known hosts extension is optional. Sites may continue to refer to policy reference files on other hosts without using this extension. This extension provides more information that user agents may use in apply users' privacy preferences.

Avoiding Unintentional Matches in Cross-Host Policy Reference Files

When a host uses the HTTP header mechanism to refer to the policy reference file on another host, the host of that policy reference file should be extremely careful to avoid unintentional policy matches based on the INCLUDE, EXCLUDE, COOKIE-INCLUDE, and COOKIE-EXCLUDE elements. As a best practice, sites should tailor host-specific policy reference files to avoid such conflicts.

For example, suppose that example.com has a very simple policy reference file with a single policy reference, which matches for all URI paths ("/*") and all cookies. Now they need to include an image on their site from forinstance.com ("http://forinstance.com/banner"). That image request will return the policy reference HTTP header to refer to a policy reference file on example.com.

If the existing example.com policy can be applied to this forinstance.com image request, then the header can refer to the existing reference file and a known hosts element can be added to that policy's reference in the file. If that policy does not apply, then example.com can either add a new policy reference to the existing file or create a new policy reference file for forinstance.com. In either case, the known hosts element will declare forinstance.com. For complex cases, the latter approach may be easier to maintain and reduce the chance of unintentional policy matches.

A Note on Compact Policies

Since the proposed mechanism relies on modifications to the policy reference file, user agents that rely solely on compact policies can not verify these domain relationships.

HTTP Header Requirement

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.

Cookie Playback

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 an expired policy reference file and evaluating its known host declarations.

1 back http://www.w3.org/2002/p3p-ws/pp/coremetrics.pdf
“Agents and P3P”position paper presented to the W3C Workshop on the Future of P3P

2 back P3P 1.0, section 3.3.5: <RECIPIENTS> element