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. 2.3.2.9.1 OUR-HOST Extension
   1. Cookie Playback
4. 2.3.2.9.2 Extension to P3P Compact Policy Header

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

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

The OUR-HOST element is declared in the POLICY-REF element. For URIs covered by the associated policy, the user agent can encounter other hosts in different domains serving embedded content, link, or action requests. The user agent may consider such a host to be owned by the same entity or one of its agents if its URI matches an associated OUR-HOST entry. Any number of OUR-HOST elements can be declared inside a POLICY-REF element.

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 are matched by OUR-HOST entries in a policy reference file for 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. The example.com file has an 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>

The following example.com policy reference file shows two policies and two OUR-HOST declarations. The first declaration is for hosts in the forinstance.com domain and applies to all URIs except for ones that begin with "/surveys/". The second our-host declaration is for hosts in the myagent.com domain and applies to all URIs that begin with "/surveys/". Since the forinstance.com domain is not declared with this policy reference, user agents can not verify a relationship between example.com and forinstance.com hosts for the survey URIs.

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

Browsers may cache the policy reference file based on its EXPIRY element. 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. This extension provides more information that user agents may use in applying users' privacy preferences.

Cookie Playback

If a user agent allows a cookie to be set based on a relationship established by our-host declarations, it should verify that such a relationship exists at cookie playback time, and not send the cookie if not. When not using compact policies, such verification implies re-fetching an expired policy reference file and evaluating its our-host declarations.

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 may be applied when only using 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:*.forinstance.com"

Hosts returning embedded content are not required to declare a corresponding OHO token in their compact policies.

This token is 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.

---

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