Abstract

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. OUR-HOST Extension
   1. Avoiding Unintentional Matches in Cross-Host Policy Reference Files
   2. HTTP Header Requirement
   3. Cookie Playback
   4. Considerations for Compact Policies
4. Extension to P3P Compact Policy Header
   1. Efficiency Concerns

Introduction

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-REFERENCES>
			<POLICY-REF about="/p3p/policy.xml#corporate">
				<INCLUDE>/*</INCLUDE>
			</POLICY-REF>
		</POLICY-REFERENCES>
    </META>

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

2.3.2.9.1 OUR-HOST Extension

The OUR-HOST element allows sites to declare hosts that are owned by the entity in the associated policy or that are acting as agents of that entity. A user agent may use this extension element to distinguish between such a host and actual third-party hosts.

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.

	our-hosts-extension		=	`<EXTENSION optional="yes">`
							*[our-host]
						`</EXTENSION>`

	our-host			=	`<OUR-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 2.3.2.1.2.

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 OUR-HOST entry for A, then a user agent can verify that both hosts are either owned by the same entity or have an agent relationship.

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. Suppose two distinct hosts A and C refer to a policy reference file on host B, which declares both A and C using our-host. 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 OUR-HOST declaration for hosts in the forinstance.com domain.

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

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

This example.com policy reference file shows several different policies and three OUR-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 our-host declaration, for hosts in the myagent.com domain. Since the forinstance.com domain is not declared 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-REFERENCES>
         <POLICY-REF about="/p3p/policy.xml#corporate">
             <INCLUDE>/*</INCLUDE>
             <EXCLUDE>/surveys/*</EXCLUDE>
             <COOKIE-INCLUDE name="*" value="*"/>
             <COOKIE-EXCLUDE name="Survey*" value="*"/>
             <COOKIE-EXCLUDE name="AgentCookie" value="*" domain=".myagent.com path="/"/>
	         <EXTENSION>
	             <OUR-HOST name="*.forinstance.com" />
	         </EXTENSION>
         </POLICY-REF>
         <POLICY-REF about="/p3p/policy.xml#surveys">
             <INCLUDE>/surveys/*</INCLUDE>
             <COOKIE-INCLUDE name="Survey*" value="*"/>
	         <EXTENSION>
	             <OUR-HOST name="*.forinstance.com" />
	         </EXTENSION>
         </POLICY-REF>
         <POLICY-REF about="/p3p/policy.xml#dataProcessingAgent">
             <COOKIE-INCLUDE name="AgentCookie" value="*" domain=".myagent.com" path="/"/>
             <EXTENSION>
                 <OUR-HOST name="*.myagent.com" />
             </EXTENSION>
         </POLICY-REF>
     </POLICY-REFERENCES>
  </META>

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 our-host declarations; i.e. that information may be cached along with the policy reference information.

The use of the our-host 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 an our-host 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 our-host element will declare forinstance.com. For complex cases, the latter approach may be easier to maintain and reduce the chance of unintentional policy matches.

HTTP Header Requirement

The OUR-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 our-host declarations, they should verify that such a relationship exists at cookie playback time, and not send the cookie if it does not. If not using compact policies, such verification implies re-fetching an expired policy reference file and evaluating its our-host declarations.

Considerations for Compact Policies

Compact policies do not allow the same level of expressiveness as policy reference files. We propose an extension to the compact policy P3P HTTP header to allow a host to declare our-host relationships for use when applying compact policies.

2.3.2.9.2 Extension to P3P Compact Policy Header

Hosts may return an special token ("OHO:") in the P3P compact policy header to indicate our-host relationships. This token is followed by a comma-delimited list of hostname qualifiers that describe hosts that are owned by the same entity as the current host or that are acting as agents of the current host. This list is equivalent to the our-hosts declarations in the policy reference file, but it should only be applied when evaluating compact policies. In the example above, example.com could return the header:

  P3P: CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI OHO:*.example.com"

This token is purely optional and may be ignored by user agents. The syntax for the token is as follows:

	compact-our-host		=	`OHO:` authority *(`,` 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 2.3.2.1.2.

Efficiency Concerns

For purposes of efficiency, hosts should not be required to return all hostname qualifiers in the compact policy for every request. Instead they may tailor the OHO token based on the request context, e.g. if an entity owns 100 different domains, on hosts in forinstance.com, it may return only “*.example.com” if it can glean that the request was referred from example.com.

---

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