Proposal: Same-Entity Domain Relationships


This Document is deprecated and replaced by the domain-relationsship document

Prepared for W3C P3P 1.1 Working Group

Jack Humphrey (

Revised October 2003


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

This document contains an overview of the proposed modifications but not the specification-level details of the modifications, which will be provided in a subsequent document.

Limitations of Current Policy Reference File Syntax

Consider the web sites and, which are owned by the same company and share some web site content, hosted on Some of that content includes “internal” banner ads that are generated by a servlet on and promote certain features on 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. We refer to this situation as a “same entity” relationship, as in “ is an owned by the same entity as”

A simple policy reference is deployed in the well-known location (/w3c/p3p.xml) on It looks like this:

<META xmlns="">


<POLICY-REF about="/p3p/policy.xml#corporate">




</META> is configured to return the HTTP header

P3P: policyref=""

When a web browser visits a page on, the user agent applies the policy at the URI If an image on that page is served by, 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 no extra privacy restrictions should be applied for the image request to the different domain.

If the hosts were flipped, and was serving the page and 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, 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 policy when in fact it is not. Without an additional mechanism in P3P, the user agent would not be capable of verifying the “same entity” relationship and the burden would fall on to be sure that third parties referenced in its site were referencing appropriate policies.

Proposed Additions to Policy Reference Files

The proposed mechanism allows sites to declare hosts owned by the same entity in the policy reference file. These declarations would allow user agents to recognize and verify “same entity” relationships automatically.

Since references’s policy reference file, that file would have an additional KNOWN-HOSTS section:

<META xmlns="">


<POLICY-REF about="/p3p/policy.xml#corporate">





<HOST name="*" entity-type="SAME"/>



The new KNOWN-HOSTS section would allow to declare hosts who may refer to this policy reference file. The HOST name attribute above denotes that hosts are allowed to refer to this policy reference file, and the entity-type attribute denotes that they are owned by the same entity.

Proposed Additions to Support Compact Policies

Some user agents choose to only use compact policies to apply privacy preferences to cookies. Since compact policies do not allow the same level of expressiveness as policy reference files, they require a parallel mechanism to allow expression of “same entity” relationships. The proposed mechanism calls for the addition of a new HTTP P3P header “same-entity.”

P3P same-entity Header

The P3P same-entity header allows a host to specify a list of space-delimited hostname qualifiers that describe hosts owned by the same entity as the current host. This list must match the list of known hosts of type SAME in the policy reference file. In the “same entity” example, would return the header:

P3P: same-entity="*"

and would return the header:

P3P: same-entity="*"

When using these headers while evaluating compact policies, a user agent should only consider two hosts to belong to the same entity if each host has a matching same-entity hostname qualifier for the other host. For simplicity of implementation, user agents should allow the trivial case of including the current host in the same-entity list.

Efficiency Concerns

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

Implications for User Agents

To take advantage of the new expressiveness provided by the proposed modifications, user agents should implement the following high-level rules:

  1. Same Entity: Hosts A and B should be considered to belong to the same entity if:

    1. Host A refers to a policy reference file on host B, and that policy reference file contains a matching KNOWN-HOSTS entry for host B with type SAME, or

    2. During compact policy evaluation, host A has a matching hostname qualifier in the P3P same-entity header for the host B, and vice versa.

  2. In the event of a verified “same entity” relationship, no extra privacy restrictions should be applied to either host.

“Agents and P3P”position paper presented to the W3C Workshop on the Future of P3P