The Platform for Privacy Preferences 1.0 (P3P1.0)
Specification
The Platform for Privacy Preferences 1.0 (P3P1.0)
Specification
W3C Recommendation 16 April 2002
obsoleted 30 August 2018
This Version:
Latest Version:
Previous Version:
Editor:
Massimo Marchiori
W3C
MIT
University of Venice
, (
massimo@w3.org
Authors:
Lorrie Cranor
, AT&T
Marc Langheinrich
, ETH
Zurich
Massimo Marchiori
, W3C
/ MIT / University of Venice
Martin Presler-Marshall
IBM
Joseph
Reagle
, W3C/MIT
Please refer to the
errata
for this document, which may include some normative corrections.
See also
translations
W3C
MIT
INRIA
Keio
), All Rights Reserved. W3C
liability
trademark
document
use
and
software
licensing
rules apply.
Abstract
This is the specification of the Platform for Privacy Preferences (P3P).
This document, along with its normative references, includes all the
specification necessary for the implementation of interoperable P3P
applications.
Status of This Document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The latest status of
this document series is maintained at the W3C.
This specification is obsolete and should no longer be used as a basis for implementation.
The P3P specification became a
W3C Recommendation
in April 2002. It was designed to enable "Web sites to express their privacy
practices in a standard format that can be retrieved automatically and interpreted easily by user agents," and "P3P user agents"
to inform users of these practices as a basis for decisions. Both detailed ("full") policy expressions and performance-optimized
"compact" policy expressions were specified.
It was envisioned that P3P would enable an expanded ecosystem in which web sites would consistently inform web user agents of
personal data collection intentions and web users would configure their individual user agents to accept some practices automatically
without the user having to read the policy or to prompt the user for further instruction when the site's practice exceeded the users' prior
election.
Since 2002 P3P has had only limited deployment; its utility depends both on adoption by web sites and informative implementation in
user agents. When Microsoft Internet Explorer was updated to use the presence of a compact P3P policy as a broad gate for deciding on
the user's behalf to allow or reject third-party cookies, web site administrators chose to copy general policies rather than encode specific
policies that reflected their sites' own privacy practices. In addition, no enforcement action followed when a site's policy expressed in
P3P failed to reflect their actual privacy practices.
In 2018, according to
BuiltWith metrics
, fewer than 6% of the 10,000 most frequently visited websites support P3P. Though there was an
increase among the top million sites at the beginning of 2018, that increase quickly leveled off. No current (2018) user agents are
known to provide interpretation of or implement decisions based upon P3P policies. While new data protection regulations taking effect in
2018 may bring new interest in machine-processable mechanisms similar to P3P, W3C concludes that P3P itself has not seen sufficient ecosystem
uptake to continue to recommend that the community implement the 2002 specification.
For purposes of the W3C Patent Policy this
Obsolete Recommendation
has the same status as an active Recommendation; it retains licensing
commitments and remains available as a reference for old implementations but is no longer recommended for future implementation.
A list of current public W3C Technical Reports can be found at
Table of Contents
Introduction
The P3P1.0 Specification
Goals and Capabilities of
P3P1.0
Example of P3P in Use
P3P Policies
P3P User Agents
Implementing P3P1.0 on Servers
Future Versions of P3P
About this Specification
Terminology
Referencing Policies
Overview and Purpose of Policy
References
Locating Policy Reference Files
Well-Known Location
HTTP Headers
The HTML
link
Tag
The XHTML
link
Tag
HTTP ports and other
protocols
Policy Reference File Syntax and Semantics
Example Policy Reference
File
Policy Reference File Definition
Policy reference file
processing
Significance of
order
Wildcards in policy
reference files
The
META
and
POLICY-REFERENCES
elements
Policy reference file lifetimes
and the
EXPIRY element
Motivation and
mechanism
The
EXPIRY
element
Use of HTTP
headers
Error handling for policy
reference file lifetimes
The
POLICY-REF
element
The
INCLUDE
and
EXCLUDE
elements
The
HINT
element
The
COOKIE-INCLUDE
and
COOKIE-EXCLUDE
elements
The
METHOD
element
Applying a Policy to a URI
Forms and Related Mechanisms
Additional Requirements
Non-ambiguity
Multiple Languages
The Safe Zone
Policy and Policy Reference File
Processing by User Agents
Security of Policy Transport
Policy Updates
Absence of Policy Reference
File
Asynchronous
Evaluation
Example Scenarios
Policy Syntax and Semantics
Example policies
English language policies
XML encoding of policies
Policies
The
POLICIES
element
The
POLICY
element
The
TEST
element
The
ENTITY
element
The
ACCESS
element
The
DISPUTES
element
The
REMEDIES
element
Statements
The
STATEMENT
element
The
CONSEQUENCE
element
The
NON-IDENTIFIABLE
element
The
PURPOSE
element
The
RECIPIENT
element
The
RETENTION
element
The
DATA-GROUP
and
DATA
elements
Categories and the
CATEGORIES
element
Extension Mechanism: the
EXTENSION
element
User Preferences
Compact Policies
Referencing Compact
Policies
Compact Policies Vocabulary
Compact
ACCESS
Compact
DISPUTES
Compact
REMEDIES
Compact
NON-IDENTIFIABLE
Compact
PURPOSE
Compact
RECIPIENT
Compact
RETENTION
Compact
CATEGORIES
Compact
TEST
Compact Policy Scope
Compact Policy Lifetime
Transforming a P3P Policy to a Compact
Policy
Transforming a Compact Policy to a P3P
Policy
Data schemas
Natural Language Support for Data
Schemas
Data Structures
The
DATA-DEF
and
DATA-STRUCT
elements
Categories in P3P Data
Schemas
P3P Data Schema Example
Use of data element names
Persistence of data
schemas
Basic Data Structures
Dates
Names
Logins
Certificates
Telephones
Contact Information
Postal
Telecommunication
Online
Access Logs and Internet
Addresses
URI
ipaddr
Access Log Information
Other HTTP Protocol
Information
The base data schema
User Data
Third Party Data
Business Data
Dynamic Data
Categories and Data
Elements/Structures
Fixed-Category Data
Elements/Structures
Variable-Category Data
Elements/Structures
Using Data Elements
Appendices
Appendix 1: References (Normative)
Appendix 2: References
(Non-normative)
Appendix 3: The P3P base data schema Definition
(Normative)
Appendix 4: XML Schema Definition
(Normative)
Appendix 5: XML DTD Definition (Non-normative)
Appendix 6: ABNF Notation (Normative)
Appendix 7: P3P Guiding Principles
(Non-normative)
Appendix 8: Working Group Contributors
(Non-normative)
1.
Introduction
The Platform for Privacy Preferences Project (P3P) enables Web sites to
express their privacy practices in a standard format that can be retrieved
automatically and interpreted easily by user agents. P3P user agents will
allow users to be informed of site practices (in both machine- and
human-readable formats) and to automate decision-making based on these
practices when appropriate. Thus users need not read the privacy policies at
every site they visit.
Although P3P provides a technical mechanism for ensuring that users can be
informed about privacy policies before they release personal information, it
does not provide a technical mechanism for making sure sites act according to
their policies. Products implementing this specification MAY provide some
assistance in that regard, but that is up to specific implementations and
outside the scope of this specification. However, P3P is complementary to laws
and self-regulatory programs that can provide enforcement mechanisms. In
addition, P3P does not include mechanisms for transferring data or for
securing personal data in transit or storage. P3P may be built into tools
designed to facilitate data transfer. These tools should include appropriate
security safeguards.
1.1
The P3P1.0 Specification
The P3P1.0 specification defines the syntax and semantics of P3P privacy
policies, and the mechanisms for associating policies with Web resources. P3P
policies consist of statements made using the P3P
vocabulary
for
expressing privacy practices. P3P policies also reference elements of the P3P
base data schema
-- a standard set of
data elements that all P3P user agents should be aware of. The P3P
specification includes a mechanism for defining new data elements and data
sets, and a simple mechanism that allows for extensions to the P3P
vocabulary.
1.1.1 Goals and Capabilities of P3P1.0
P3P version 1.0 is a protocol designed to inform Web users of the
data-collection practices of Web sites. It provides a way for a Web site to
encode its data-collection and data-use practices in a machine-readable XML
format known as a
P3P policy
. The P3P specification defines:
A standard schema for data a Web site may wish to collect, known as the
"P3P base data schema"
A standard set of uses, recipients, data categories, and other privacy
disclosures
An XML format for expressing a privacy policy
A means of associating privacy policies with Web pages or sites, and
A mechanism for transporting P3P policies over HTTP
The goal of P3P version 1.0 is twofold. First, it allows Web sites to
present their data-collection practices in a standardized, machine-readable,
easy-to-locate manner. Second, it enables Web users to understand what data
will be collected by sites they visit, how that data will be used, and what
data/uses they may "opt-out" of or "opt-in" to.
1.1.2 Example of P3P in Use
As an introduction to P3P, let us consider one common scenario that makes
use of P3P. Claudia has decided to check out a store called CatalogExample,
located at http://www.catalog.example.com/. Let us assume that CatalogExample
has placed P3P policies on all their pages, and that Claudia is using a Web
browser with P3P built in.
Claudia types the address for CatalogExample into her Web browser. Her
browser is able to automatically fetch the P3P policy for that page. The
policy states that the only data the site collects on its home page is the
data found in standard HTTP access logs. Now Claudia's Web browser checks this
policy against the preferences Claudia has given it. Is this policy acceptable
to her, or should she be notified? Let's assume that Claudia has told her
browser that this is acceptable. In this case, the homepage is displayed
normally, with no pop-up messages appearing. Perhaps her browser displays a
small icon somewhere along the edge of its window to tell her that a privacy
policy was given by the site, and that it matched her preferences.
Next, Claudia clicks on a link to the site's online catalog. The catalog
section of the site has some more complex software behind it. This software
uses cookies to implement a "shopping cart" feature. Since more information is
being gathered in this section of the Web site, the Web server provides a
separate P3P policy to cover this section of the site. Again, let's assume
that this policy matches Claudia's preferences, so she gets no pop-up
messages. Claudia continues and selects a few items she wishes to purchase.
Then she proceeds to the checkout page.
The checkout page of CatalogExample requires some additional information:
Claudia's name, address, credit card number, and telephone number. Another P3P
policy is available that describes the data that is collected here and states
that her data will be used only for completing the current transaction, her
order.
Claudia's browser examines this P3P policy. Imagine that Claudia has told
her browser that she wants to be warned whenever a site asks for her telephone
number. In this case, the browser will pop up a message saying that this Web
site is asking for her telephone number, and explaining the contents of the
P3P statement. Claudia can then decide if this is acceptable to her. If it is
acceptable, she can continue with her order; otherwise she can cancel the
transaction.
Alternatively, Claudia could have told her browser that she wanted to be
warned only if a site is asking for her telephone number and was going to give
it to third parties and/or use it for uses other than completing the current
transaction. In that case, she would have received no prompts from her browser
at all, and she could proceed with completing her order.
Note that this scenario describes one hypothetical implementation of P3P.
Other types of user interfaces are also possible.
1.1.3
P3P Policies
P3P policies use an XML with namespaces (cf. [
XML
] and
XML-Name
]) encoding of the P3P vocabulary to provide
contact information for the legal entity making the representation of privacy
practices in a policy, enumerate the types of data or data elements collected,
and explain how the data will be used. In addition, policies identify the data
recipients, and make a variety of other disclosures including information
about dispute resolution, and the address of a site's human-readable privacy
policy. P3P policies must cover all relevant data elements and practices.
However, legal issues regarding law enforcement demands for information are
not addressed by this specification. It is possible that a site that otherwise
abides by its policy of not redistributing data to others may be required to
do so by force of law. P3P declarations are positive, meaning that sites state
what they do, rather than what they do not do. The P3P vocabulary is designed
to be descriptive of a site's practices rather than simply an indicator of
compliance with a particular law or code of conduct. However, user agents may
be developed that can test whether a site's practices are compliant with a law
or code.
P3P policies represent the practices of the site. Intermediaries such as
telecommunication providers, Internet service providers, proxies and others
may be privy to the exchange of data between a site and a user, but their
practices may not be governed by the site's policies. In addition, note that
each P3P policy is applied to specific Web resources (Web pages, images,
cookies, etc.) listed in a policy reference file. By placing one or more P3P
policies on a Web site, a company or organization does not make any statements
about the privacy practices associated with other Web resources not mentioned
in their policy reference file, with other online activities that do not
involve data collected on Web sites covered by their P3P policy, or with
offline activities that do not involve data collected on Web sites covered by
their P3P policy.
In cases where the P3P vocabulary is not precise enough to describe a Web
site's practices, sites should use the vocabulary terms that most closely
match their practices and provide further explanations (as stated in
Section 3.2
). However, policies MUST NOT make false or
misleading statements.
1.1.4
P3P User Agents
P3P1.0 user agents can be built into Web browsers, browser plug-ins, or
proxy servers. They can also be implemented as Java applets or JavaScript; or
built into electronic wallets, automatic form-fillers, or other user data
management tools. P3P user agents look for references to a P3P policy at a
well-known location, in P3P headers in HTTP responses, and in P3P
link
tags embedded in HTML content. These references indicate the
location of a relevant P3P policy. User agents can fetch the policy from the
indicated location, parse it, and display symbols, play sounds, or generate
user prompts that reflect a site's P3P privacy practices. They can also
compare P3P policies with privacy preferences set by the user and take
appropriate actions. P3P can perform a sort of "gate keeper" function for data
transfer mechanisms such as electronic wallets and automatic form fillers. A
P3P user agent integrated into one of these mechanisms would retrieve P3P
policies, compare them with user's preferences, and authorize the release of
data only if a) the policy is consistent with the user's preferences and b)
the requested data transfer is consistent with the policy. If one of these
conditions is not met, the user might be informed of the discrepancy and given
an opportunity to authorize the data release themselves.
The P3P1.0 Specification places few requirements on the user interfaces of
P3P user agents. Thus user agent implementers may each make their own choices
about what words and symbols to present to users to provide information about
a Web site's privacy policy. Implementers need not use the definitions found
in this specification verbatim in their user interfaces. They should, however,
make sure that whatever information they present to the user accurately
represents the P3P policies described, as per Appendix 7, "
P3P Guiding Principles
".
1.1.5
Implementing P3P1.0 on Servers
Web sites can implement P3P1.0 on their servers by translating their
human-readable privacy policies into P3P syntax and then publishing the
resulting files along with a policy reference file that indicates the parts of
the site to which the policy applies. Automated tools can assist site
operators in performing this translation. P3P1.0 can be implemented on
existing HTTP/1.1-compliant Web servers without requiring additional or
upgraded software. Servers may publish their policy reference files at a
well-known location
, or they may reference
their P3P policy reference files in HTML/XHTML content using a
link
tag. Alternatively, compatible servers may be configured to
insert a P3P extension header into all HTTP responses that indicates the
location of a site's P3P policy reference file.
Web sites have some flexibility in how they use P3P: they can opt for one
P3P policy for their entire site or they can designate different policies for
different parts of their sites. A P3P policy MUST cover all data generated or
exchanged as part of a site's HTTP interactions with visitors. In addition,
some sites may wish to write policies that cover all data an entity collects,
regardless of how the data is collected.
1.1.6
Future Versions of P3P
Significant sections were removed from earlier drafts of the P3P1.0
specification in order to facilitate rapid implementation and deployment of a
P3P first step. A future version of the P3P specification might incorporate
those features after P3P1.0 is deployed. Such specification would likely
include improvements based on feedback from implementation and deployment
experience as well as four major components that were part of the original P3P
vision but not included in P3P1.0:
a mechanism to allow sites to offer a choice of P3P policies to
visitors
a mechanism to allow visitors (through their user agents) to explicitly
agree to a P3P policy
mechanisms to allow for non-repudiation of agreements between visitors
and Web sites
a mechanism to allow user agents to transfer user data to services
1.2
About this Specification
This document, along with its normative references, includes all the
specification necessary for the implementation of interoperable P3P
applications.
The following key words are used throughout the document and have to be
read as interoperability requirements. This specification uses words as
defined in
RFC2119
KEY
] for defining the significance of each particular
requirement. These words are:
MUST or MUST NOT
This word or the adjective "required" means that the item is an
absolute requirement of the specification.
SHOULD or SHOULD NOT
This word or the adjective "rcommended" means that there may exist
valid reasons in particular circumstances to ignore this item, but the
full implications should be understood and the case carefully weighed
before choosing a different course.
MAY
This word or the adjective "optional" means that this item is truly
optional. One vendor may choose to include the item because a particular
marketplace requires it or because it enhances the product, for example;
another vendor may omit the same item.
The P3P specification defines, with the exception of
section 2.2.2
section 2.2.3
and
section 4
, an
XML with namespaces
syntax (cf. [
XML
] and [
XML-Name
]).
In the following, for the sake of brevity we will liberally talk about "XML",
meaning the more accurate "XML with namespaces".
A BNF-like notation is also used thorough the specification: the [
ABNF
] notation used in this specification is specified in
RFC2234
and summarized in
Appendix 6
. However, note that in the case of
XML syntax, such ABNF syntax is only a grammar representative used to enhance
readability (lacking, for example, all the syntactic flexibilities that are
implicitly included in XML, e.g. whitespace rules, quoting using either single
quote (') or double quote ("),
character escaping
comments, case sensitivity, order of attributes, namespace handling), and as
such it has no normative value. All the XML syntax defined in this
specification MUST conform to the XML Schema for P3P (see
Appendix 4)
, which, together with the other
constraints expressed in this specification using natural
language, constitutes the
normative
definition.
The (non-normative) DTD provided in
Appendix 5
MAY be
used to verify that P3P files are valid. However, there are some valid files
that may be rejected if checked against the DTD due to their use of
namespaces.
As far as the non-XML syntax defined in this specification is concerned (
section 2.2.2
defining P3P's HTTP header,
section 2.2.3
defining usage of P3P in HTML, and
section 4
defining compact policies), instead,
the ABNF notation (together with the other constraints expressed in this
specification using natural language) constitutes the
normative
definition.
1.3
Terminology
Character
Strings consist of a sequence of zero or more characters, where a
character is defined as in the XML Recommendation [
XML
]. A single character in P3P thus corresponds to a
single Unicode abstract character with a single corresponding Unicode
scalar value (see [
UNICODE
]).
Data Element
An individual data entity, such as last name or telephone number. For
interoperability, P3P1.0 specifies a base set of data elements.
Data Category
A significant attribute of a
data element
or
data set
that may be used by a trust engine
to determine what type of element is under discussion, such as physical
contact information. P3P1.0 specifies a set of
data categories
Data Set
A known grouping of
data elements
, such
as "
user.home-info.postal
". The
P3P1.0 base data schema specifies a number of data sets.
Data Schema
A collection of data elements and sets defined using the P3P1.0
DATASCHEMA
element. P3P1.0 defines a standard data schema
called the
P3P base data schema
Data Structure
A hierarchical description of a set of data elements. A data set can
be described according to its data structure. P3P1.0 defines a set of
basic datastructures that are used to describe the data sets in the P3P
base data schema.
Equable Practice
A practice that is very similar to another in that the purpose and
recipients are the same or more constrained than the original, and the
other disclosures are not substantially different. For example, two
sites with otherwise similar practices that follow different -- but
similar -- sets of industry guidelines.
Identified Data
Data that reasonably can be used by the data collector to identify an
individual.
Policy
A collection of one or more privacy statements together with
information asserting the identity, URI, assurances, and dispute
resolution procedures of the service covered by the policy.
Practice
The set of disclosures regarding data usage, including purpose,
recipients, and other disclosures.
Preference
A rule, or set of rules, that determines what action(s) a user agent
will take. A preference might be expressed as a formally defined
computable statement (e.g., the [
APPEL
] preference
exchange language).
Purpose
The reason(s) for data collection and use.
Repository
A mechanism for storing user information under the control of the user
agent.
Resource
A network data object or service that can be identified by a URI.
Resources may be available in multiple representations (e.g. multiple
languages, data formats, size, and resolutions) or vary in other
ways.
Safe Zone
Part of a Web site where the service provider performs only minimal
data collection, and any data that is collected is used only in ways
that would not reasonably identify an individual.
Service
A program that issues policies and (possibly) data requests. By this
definition, a service may be a server (site), a local application, a
piece of locally active code, such as an ActiveX control or Java applet,
or even another user agent. Typically, however, a service is usually a
Web site. In this specification the terms "service" and "Web site" are
often used interchangeably.
Service Provider (Data Controller, Legal Entity)
The person or legal entity which offers information, products or
services from a Web site, collects information, and is responsible for
the representations made in a practice statement.
Statement
A P3P statement is a set of privacy practice disclosures relevant to a
collection of data elements.
URI
A Uniform Resource Identifier used to locate Web resources. For
definitive information on
URI
syntax and semantics,
see [
URI
]. URIs that appear within XML or HTML have
to be treated as specified in [
CHARMODEL
],
section
Character
Encoding in URI References
. This does not apply to URIs appearing in
HTTP header fields; the URIs there should always be fully escaped.
User
An individual (or group of individuals acting as a single entity) on
whose behalf a service is accessed and for which personal data exists.
P3P policies describe the collection and use of personal data about this
individual or group.
User Agent
A program whose purpose is to mediate interactions with services on
behalf of the user under the user's preferences. A user may have more
than one user agent, and agents need not reside on the user's desktop,
but
any agent must be controlled by and act on behalf of only the
user
. The trust relationship between a user and his or her agent
may be governed by constraints outside of P3P. For instance, an agent
may be trusted as a part of the user's operating system or Web client,
or as a part of the terms and conditions of an ISP or privacy
proxy.
2. Referencing Policies
2.1 Overview and Purpose of Policy
References
Locating a P3P policy is one of the first steps in the operation of the P3P
protocol. Services use policy references to state what policy applies to a
specific URI or set of URIs. User agents use policy references to locate the
privacy policy that applies to a Web resource, so that they can process that
policy for the benefit of their user.
Policy references are used extensively as a performance optimization. P3P
policies are typically several kilobytes of data, while a URI that references
a privacy policy is typically less than 100 bytes. In addition to the
bandwidth savings, policy references also reduce the need for computation:
policies can be uniquely associated with URIs, so that a user agent need only
parse and process a policy once rather than process it with every document to
which the policy applies. Furthermore, by placing the information about
relevant policies in a centralized location, Web site administration is
simplified.
A policy reference file is used to associate P3P policies with certain
regions of URI-space. The policy reference file is an XML with namespaces (see
XML
] and [
XML-Name
]) file that can
specify the policy for a single Web document, portions of a Web site, or for
an entire site. The policy reference file may refer to one or more P3P
policies; this allows for a single reference file to cover an entire site,
even if different P3P policies apply to different portions of the site.The
policy reference file is used to make any or all of the following
statements:
The URI where a P3P policy is found
The URIs or regions of URI-space covered by this policy
The URIs or regions of URI-space not covered by this policy
The regions of URI-space for embedded content on other servers that are
covered by this policy
The cookies that are or are not covered by this policy
The access methods for which this policy is applicable
The period of time for which these claims are considered to be
valid
All of these statements are made in the body of the policy reference
file.
2.2 Locating Policy Reference Files
This section describes the mechanisms used to indicate the location of a
policy reference file. Detailed syntax is also given for the supported
mechanisms.
The location of the policy reference file can be indicated using one of
four mechanisms. The policy reference file
may be located in a predefined
"well-known" location
, or
a document may indicate a policy reference file through an HTML
link
tag, or
a document may indicate a policy reference file through an XHTML
link
tag, or
through an HTTP header.
Note that if user agents support retrieving HTML (resp. XHTML) content over
HTTP, they MUST handle mechanisms 1, 2 and 3 (resp. 4) listed above
interchangeably. See also the requirements for
non-ambiguity
Policies are applied at the level of resources. A "page" from the user's
perspective may be composed of multiple HTTP resources; each may have its own
P3P policy associated with it. As a practical note, however, placing many
different P3P policies on different resources on a single page may make
rendering the page and informing the user of the relevant policies difficult
for user agents. Additionally, services are recommended to attempt to craft
their policy reference files such that a single policy reference file covers
any given "page"; this will speed up the user's browsing experience.
For a user agent to process the policy that applies to a given resource, it
must locate the policy reference file for that resource, fetch the policy
reference file, parse the policy reference file, fetch any required P3P
policies, and then parse the P3P policy or policies.
This document does not specify how P3P policies may be associated with Web
resources retrieved by means other than HTTP. However, it does not preclude
future development of mechanisms for associating P3P policies with resources
retrieved using other protocols. Furthermore, additional methods of
associating P3P policies with HTTP resources may be developed in the
future.
2.2.1 Well-Known Location
Web sites using P3P MAY (and, are strongly encouraged to) place a policy
reference file in a "well-known" location. To do this, a policy reference file
would be made available on the site at the path
/w3c/p3p.xml
Note that sites are not required to use this mechanism; however, by using
this mechanism, sites can ensure that their P3P policy will be accessible to
user agents before any other resources are requested from the site. This will
reduce the need for user agents to access the site using safe zone practices.
Additionally, if a site chooses to use this mechanism, the policy reference
file located in the well-known location is not required to cover the entire
site. For example, sites where not all of the content is under the control of
a single organization MAY choose not to use this mechanism, or MAY choose to
post a policy reference file which covers only a limited portion of the
site.
Use of the well-known location for a policy reference file does not
preclude use of other mechanisms for specifying a policy reference file.
Portions of the site MAY use any of the other supported mechanisms to specify
a policy reference file, so long as the
non-ambiguity
requirements
are met.
For example, imagine a shopping-mall Web site run by the MallExample
company. On their Web site (
mall.example.com
), companies offering
goods or services at the mall would get a company-specific subtree of the
site, perhaps in the path
/companies/
company-name
. The
MallExample company may choose to put a policy reference file in the
well-known location which covers all of their site except the
/companies
subtree. Then if the ShoeStoreExample company has some
content in
/companies/shoestoreexample
, they could use one of the
other mechanisms to indicate the location of a policy reference file covering
their portion of the
mall.example.com
site.
One case where using the well-known location for policy reference files is
expected to be particularly useful is in the case of a site which has divided
its content across several hosts. For example, consider a site which uses a
different logical host for all of its Web-based applications than for its
static HTML content. The other mechanisms allowed for specifying the location
of a policy reference file require that some URI on the host being accessed
must be fetched to locate the policy reference file. However, the well-known
location mechanism has no such requirement. Consider the example of an HTML
form located on
www.example.com
. Imagine that the action URI on
that form points to server
cgi.example.com
. The policy reference
file that covers the form is unable to make any statements about the action
URI that processes the form. However, the site administrator publishes a
policy reference file at
that
covers the action URI, thus enabling a user agent to easily locate the P3P
policy that applies to the action URI before submitting the form contents.
2.2.2 HTTP Headers
Any document retrieved by HTTP MAY point to a policy reference file through
the use of a new response header, the
P3P
header ([
P3P-HEADER
]). If a site is using P3P headers, it SHOULD
include this on responses for all appropriate request methods, including
HEAD
and
OPTIONS
requests.
The P3P header gives one or more comma-separated directives. The syntax
follows:
[1]
p3p-header
`P3P: ` p3p-header-field *(`,` p3p-header-field)
[2]
p3p-header-field
policy-ref-field | compact-policy-field | extension-field
[3]
policy-ref-field
`policyref="` URI-reference `"`
[4]
extension-field
token
[`=` (token | quoted-string) ]
Here,
URI-reference
is defined
as per
RFC 2396
URI
],
token
and
quoted-string
are defined by [
HTTP1.1
].
In keeping with the rules for other HTTP headers, the name of the P3P
header may be written with any casing. The contents should be specified using
the casing precisely as specified in this document.
The
policyref
directive gives a URI which specifies the
location of a policy reference file which may reference the P3P policy
covering the document that pointed to the reference file, and possibly others
as well. When the
policyref
attribute is a relative URI, that URI
is interpreted relative to the request URI. Note that fetching the URI given
in the
policyref
directive MAY result in a 300-class HTTP return
code (redirection); user agents MUST interpret those redirects with normal
HTTP semantics. Services should note, of course, that use of redirects will
increase the time required for user agents to find and interpret their
policies. The
policyref
URI MUST NOT be used for any other
purpose beyond locating and referencing P3P policies.
The
compact-policy-field
is used to specify "compact
policies". This is described in
Section 4
User agents which find unrecognized directives (in the
extension-field
s) MUST ignore the unrecognized directives. This
is to allow easier deployment of future versions of P3P.
Example 2.1:
1. Client makes a
GET
request.
GET /index.html HTTP/1.1
Host: catalog.example.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)
2. Server returns content and the
P3P
header pointing to the
policy of the resource.
HTTP/1.1 200 OK
P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18
2.2.3 The HTML
link
Tag
Servers MAY serve HTML content with embedded
link
tags (cf.
HTML
]) that indicate the location of the relevant P3P
policy reference file. This use of P3P does not require any change in the
server behavior.
The
link
tag encodes the policy reference information that
could be expressed using the
P3P
header. The
link
tag takes the following form (here, we just produce one possible ABNF format
for the link tag, and suppose the [
HTML
] syntax rules can
be used when using such a tag into an HTML file):
[5]
p3p-link-tag
``
Here,
URI
is defined as per
RFC 2396
URI
].
When the
href
attribute is a relative URI, that URI is
interpreted relative to the request URI.
In order to illustrate with an example the use of the
link
tag, we consider the policy reference expressed in
Example 2.1
using HTTP headers. That example can be
equivalently expressed using the link tag with the following piece of
HTML:
href="http://catalog.example.com/P3P/PolicyReferences.xml">
Finally, note that since the
p3p-link-tag
is embedded in an
HTML document, its character encoding will be the same as that of the HTML
document. In contrast to P3P policy and policy reference documents (see
section 2.3
and
section 3
below), the
p3p-link-tag
need not be encoded using [
UTF-8
]. Note also that the
link
tag is not case
sensitive.
2.2.4 The XHTML
link
tag
Correspondingly to the HTML
link
tag, P3P also supports XHTML
(cf. [
XHTML-MOD
]). Servers MAY serve XHTML content
that, using the
XHTML Link Module
(cf.
Section
5.19
of [
XHTML-MOD
]), indicates the location of
the relevant P3P policy reference file with an embedded XHTML
link
tag. Like in the HTML case, an XHTML
link
tag
can be used to encode the policy reference information that could be expressed
using the
P3P
header, by:
setting its
rel
attribute to "
P3Pv1
setting its
href
attribute to the URI of the relevant P3P
policy reference file
2.2.5 HTTP ports and other protocols
The mechanisms described here MAY be used for HTTP transactions over any
underlying protocol. This includes plain-text HTTP over TCP/IP connections or
encrypted HTTP over SSL connections, as well as HTTP over any other
communications protocol designers wish to implement.
URIs MAY contain network port numbers, as specified in
RFC 2396
URI
]. For the purposes of P3P, different ports on a single
host MUST be considered to be separate "sites". Thus, for example, the policy
reference file at the well-known location for www.example.com on port 80
(http://www.example.com/w3c/p3p.xml) would not give any information about the
policies which apply to www.example.com when accessed over SSL (as the SSL
communication would take place on a different port, 443 by default).
This document does not specify how P3P policies may be associated with
resources retrieved by means other than HTTP. However, it does not preclude
future development of mechanisms for associating P3P policies with resources
retrieved over other protocols. Furthermore, additional methods of associating
P3P policies with resources retrieved using HTTP may be developed in the
future.
2.3 Policy Reference File Syntax and Semantics
This section explains the contents of policy reference files in detail.
2.3.1 Example Policy Reference File
Consider the case of a Web site wishing to make the following
statements:
P3P policy
/P3P/Policies.xml#first
applies to the entire
site, except resources whose paths begin with
/catalog
/cgi-bin
, or
/servlet
P3P policy
/P3P/Policies.xml#second
applies to all
resources whose paths begin with
/catalog
P3P policy
/P3P/Policies.xml#third
applies to all resources
whose paths begin with
/cgi-bin
or
/servlet
except for
/servlet/unknown
No statement is made about what P3P policy applies to
/servlet/unknown
These statements are valid for 2 days.
These statements can be represented by the following XML:
Example 2.2:
Note this example also includes via
EXPIRY
a relative expiry time in the
document (cf.
Section 2.3.2.3.2
).
2.3.2 Policy Reference File Definition
This section defines the syntax and semantics of P3P policy reference
files. All policy reference files MUST be encoded using [
UTF-8
]. P3P servers MUST encode their policy reference files
using this syntax.
2.3.2.1 Policy reference file
processing
2.3.2.1.1 Significance of order
A policy reference file has the
META
element as root. It may
contain multiple
POLICY-REF
elements. If it does contain more
than one element, they MUST be processed by user agents in the order given in
the file. When a user agent is attempting to determine what policy applies to
a given URI, it MUST use the first
POLICY-REF
element in the
policy reference file which applies to that URI.
Note that each
POLICY-REF
may contain multiple
INCLUDE
EXCLUDE
METHOD
COOKIE-INCLUDE
, and
COOKIE-EXCLUDE
elements and that
all of these elements within a given
POLICY-REF
MUST be
considered together to determine whether the
POLICY-REF
applies
to a given URI. Thus, it is not sufficient to find an
INCLUDE
element that matches a given URI, as
EXCLUDE
or
METHOD
elements may serve as modifiers that cause the
POLICY-REF
not to match.
2.3.2.1.2 Wildcards in policy reference
files
Policy reference files make statements about what policy applies to a given
URI. Policy reference files support a simple wildcard character to allow
making statements about regions of URI-space. The character asterisk
('
') is used to represent a sequence of 0 or more of any
character. No other special characters (such as those found in regular
expressions) are supported.
Note that since the asterisk is also a legal character in URIs ([
URI
]), some special conventions have to be followed when
encoding such "extended URIs" in a policy reference file:
URIs represented in policy reference files MUST be properly escaped, as
described in [
URI
],
except
Literal '
's in URIs MUST be escaped in policy
reference files (i.e., they MUST be represented as
%2A
"). Any '
' present in a URI within a
policy reference file will be taken as representing the asterisk
wildcard character.
Consequently, P3P user agents MUST properly un-escape a URI given in
a policy reference file, according to [
URI
], before
trying to match it against an internally represented URI, but only
after recognizing any literal '
' present as the asterisk
wildcard character.
URI escaping and unescaping is very much dependant on the actual scheme
used, and might even differ between individual components within a single
scheme, so no simple rule for which characters need to be escaped can be given
here. Please refer directly to [
URI
] for details on the
standard escaping process. Note that P3P user agents MAY ignore any URI
pattern that does not conform to [
URI
].
The wildcard character MAY be used in the
INCLUDE
and
EXCLUDE
elements, in the
COOKIE-INCLUDE
and
COOKIE-EXCLUDE
elements, and in the
HINT
element.
2.3.2.2 The
META
and
POLICY-REFERENCES
elements
The
META
element contains a complete policy reference
file. Optionally, one
POLICIES
element can follow.
META
can also contain one or more one or more
EXTENSION
elements
(cf.
section 3.5
), as well as an
xml:lang
attribute (see
section 2.4.2
), to indicate the
language in which its content is expressed.
POLICY-REF
(policy
reference) elements. It MAY also contain one
EXPIRY
element
(indicating
their expiration time), one or more
HINT
element
, and one or more
EXTENSION
element
(cf.
section 3.5
).
[6]
prf
``
*extension
policyrefs
[policies]
*extension
""
[7]
policyrefs
"
[expiry]
*policyref
*hint
*extension
"
Here
PCDATA
is defined in [
XML
].
2.3.2.3 Policy reference file lifetimes and
the
EXPIRY
element
2.3.2.3.1 Motivation and
mechanism
It is desirable for servers to inform user agents about how long they can
use the claims made in a policy reference file. By enabling clients to cache
the contents of a policy reference file, it reduces the time required to
process the privacy policy associated with a Web resource. This also reduces
load on the network. In addition, clients that don't have a valid policy
reference file for a URI will need to use
"safe zone"
practices
for their requests. If clients have policy reference files that
they know are still valid, then they can make more informed decisions on how
to proceed.
In order to achieve these benefits, policy reference files SHOULD contain
an
EXPIRY
element, which indicates the lifetime of the policy
reference file. If the policy reference file does not contain an
EXPIRY
element, then it defaults to 24-hour lifetime.
The lifetime of a policy reference file tells user agents how long they can
rely on the claims made in the policy reference file. By setting the lifetime
of a policy reference file, the publishing site agrees that the policies
mentioned in the policy reference file are appropriate for the lifetime of the
policy reference file. For example, if a policy reference file has a lifetime
of 3 days, then a user agent need not reload that file for 3 days, and can
assume that the references made in that policy reference file are good for 3
days. All of the policy references made in a single policy reference file will
receive the same lifetime. The only way to specify different lifetimes for
different policy references is to use separate policy reference files.
The same mechanism used to indicate the lifetime of a policy reference file
is also used to indicate the lifetime of a P3P policy. Thus P3P
POLICIES
elements SHOULD have an
EXPIRY
element
associated with them as well. This lifetime applies to all P3P policies
contained within that
POLICIES
element. If there is no
EXPIRY
element associated with a P3P policy, then it defaults to
24-hour lifetime.
When picking a lifetime for policies and policy reference files, sites need
to pick a lifetime which balances two competing concerns. One concern is that
the lifetime ought to be long enough to allow user agents to receive
significant benefits from caching. The other concern is that the site would
like to be able to change their policy for new data collection without waiting
for an extremely long lifetime to expire. It is expected that lifetimes in the
range of 1-7 days would be a reasonable balance between these two competing
desires. Sites also need to remember the
policy
update requirements
when updating their policies.
When a policy reference file has expired, the information in the policy
reference file MUST NOT be used by a user agent until that user agent has
successfully revalidated the policy reference file, or has fetched a new copy
of the policy reference file.
Note that while user agents are not obligated to revalidate policy
reference files or policy files that have not expired, they MAY choose to
revalidate those files before their expiry period has passed in order to
reduce the need for using
"safe zone" practices
. A
valid P3P user agent implementation does not need to contain a cache for
policies and policy reference files, though the implementation will have
better performance if it does.
2.3.2.3.2 The
EXPIRY
element
The
EXPIRY
element can be used in a policy reference file
and/or in a
POLICIES
element to state how long the policy
reference file (or
policies
) remains valid. The expiry
is given as either an absolute expiry time, or a relative expiry time. An
absolute expiry time is a time, given in GMT, until which the policy reference
file (or
policies
) is valid. A relative expiry time
gives a number of seconds for which the policy reference file (or
policies
) is valid. This expiry time is relative to the
time the policy reference file (or
policies
) was
requested or last revalidated by the client. This computation MUST be done
using the time of the original request or revalidation, and the current time,
with both times generated from the client's clock. Revalidation is defined in
section 13.3 of [
HTTP1.1
].
The minimum amount of time for any relative expiry time is 24 hours, or
86400 seconds. Any relative expiration time shorter than 86400 seconds MUST be
treated as being equal to 86400 seconds in a client implementation. If a
client encounters an absolute expiration time that is in the past, it MUST act
as if NO policy reference file (or policy) is available. See section 2.4.7 "
Absence of Policy Reference File
" for the required
procedure in such cases.
[8]
expiry
"
[9]
absdate
`date="` HTTP-date `"`
[10]
reldate
`max-age="` delta-seconds `"`
Here, HTTP-date is defined in section 3.3.1 of [
HTTP1.1
], and delta-seconds is defined in
section 3.3.2 of [
HTTP1.1
].
2.3.2.3.3 Requesting Policies and Policy
Reference Files
In a real-world network, there may be caches which will cache the contents
of policies and policy reference files. This is good for increasing the
overall network performance, but may have deleterious effects on the operation
of P3P if not used correctly. There are two specific concerns:
When a user agent receives a policy reference file (or policy), if it
was served from a caching proxy (see e.g. [
CACHING
]) the user agent needs to know how long the
policy reference file or policy resided in the caching proxy. This time
MUST be subtracted from the lifetime of the policy or policy reference
file which uses relative expiry.
When a user agent needs to revalidate a policy reference file (or
policy), it needs to make sure that the revalidation fetches a current
version of the policy reference file (or policy). For example, consider
the case where a user agent holds a policy reference file with a 1 day
relative expiry. If the user agent refetches it from a caching proxy, and
the file has been residing in the caching proxy for 3 days, then the
resulting file is useless.
HTTP 1.1 [
HTTP1.1
] contains powerful
cache-control mechanisms to allow clients to place requirements on the
operations of network caches; these mechanisms can resolve the problems
mentioned above. The specific method will be discussed below.
HTTP 1.0, however, does not provide those more sophisticated cache control
mechanisms. An HTTP 1.0 caching proxy will, in all likelihood, compute a cache
lifetime for the policy reference file (or policies) based on the file's
last-modified date; the resulting cache lifetime could be significantly longer
than the lifetime specified by the
EXPIRY
element. The caching
proxy could then serve the policy reference file (or policies) to clients
beyond the lifetime in the
EXPIRY
; the result would be that
user-agents would receive a useless policy reference file (or policies).
The second problem with an HTTP 1.0 caching proxy is that a user agent has
no way to know how long the reference file may have been stored by the caching
proxy. If the policy reference file (or policies) relies on relative expiry,
it would then be impossible for the user agent to determine if the reference
file's lifetime has already expired, or when it will expire.
Thus, if a user agent is requesting a policy reference file or a policy,
and does not know for certain that there are no HTTP 1.0 caches in the path to
the origin server, then the request MUST force an end-to-end revalidation.
This can be done with the
Pragma: no-cache
HTTP request-header. Note
that neither HTTP nor P3P define a way to determine if there is a HTTP
1.0-compliant cache in any given network path, so unless the user agent has
this information derived from an outside source, it MUST force the end-to-end
revalidation.
If the user agent has some way to know that all caches in the network path
to the origin server are compliant with HTTP 1.1 (or that there are no caches
in the network path to the origin server), then the client MAY do the
following instead of forcing an end-to-end revalidation:
Use cache-control request-headers to ensure that the received response
is not older than its lifetime. This is done with the max-age
cache-control setting, with a maximum age significantly less than the
lifetime of the policy reference file (or policies). For example, a user
agent could send Cache-Control: max-age=43200, thus ensuring that the
response is no more than 12 hours old.
Subtract the age of the response from the lifetime of the policy
reference file (or policies), if it uses a relative expiry time. The age
of the response is given by the Age: HTTP response-header.
Note that it is impossible for a client to accurately predict the amount of
latency that may affect an HTTP request. Thus, if the policy reference file
covering a request is going to expire soon, clients MAY wish to consider
warning their users and/or revalidating the policy reference file before
continuing with the request.
2.3.2.3.4 Error handling for policy reference
file and policy lifetimes
The following situations have their semantics specifically defined:
An absolute expiry date in the past renders the policy reference file
(or policies) useless, as does an invalid or malformed expiry date,
whether relative or absolute. In this case, user agents MUST act as if NO
policy reference file (or
policies
) is available.
See section 2.4.7 "
Absence of Policy Reference
File
" for the required procedure in such cases.
A relative expiration time shorter than 86400 seconds (1 day) is
considered to be equal to 86400 seconds.
When a policy reference file contains more than one
EXPIRY
element, the first one takes precedence for determining the lifetime of
the policy reference file.
2.3.2.4 The
POLICY-REF
element
A policy reference file may refer to multiple P3P policies, specifying
information about each. The
POLICY-REF
element describes
attributes of a single P3P policy. Elements within the
POLICY-REF
element give the location of the policy and specify the areas of URI-space
(and cookies) that each policy covers.
POLICY-REF
contains information about a single P3P policy.
about
(mandatory
attribute)
URI reference
([
URI
]), where the fragment
identifier part denotes the
name
of the policy (given in its
name
attribute), and the URI part denotes the URI where the
policy resides (a policy file, or a policy reference file, see
Section 3.2
). If this is a relative URI reference,
it is interpreted relative to the URI of the policy reference file it
resides in.
[11]
policy-ref
`
*include
*exclude
*cookie-include
*cookie-exclude
*method-element
*extension
`
Here,
URI-reference
is defined as per
RFC 2396
URI
].
2.3.2.5 The
INCLUDE
and
EXCLUDE
elements
Each
INCLUDE
or
EXCLUDE
element specifies one
local URI or set of local URIs. A set of URIs is specified if the
wildcard character '*'
is used in the
URI-pattern. These elements are used to specify the portion of the Web site
that is covered by the policy referenced by the enclosing
POLICY-REF
element.
When
INCLUDE
(and optionally,
EXCLUDE
) elements
are present in a
POLICY-REF
element, it means that the policy
specified in the
about
attribute of the
POLICY-REF
element applies to all the URIs at the requested host corresponding to the
local-URI(s) matched by any of the
INCLUDE
s, but not matched by
an
EXCLUDE
element.
A policy referenced in a policy reference file can be applied only to URIs
on the DNS (Domain Name System) host that references it. Thus, for example, a
policy reference file at the well-known location of host www.example.com can
apply policies only to resources on www.example.com. However, if
foo.example.com includes a P3P HTTP header in its responses that references a
policy reference file on bar.example.com, that policy reference file would be
applied to resources on foo.example.com (not bar.example.com or
www.example.com). The same policy reference file might be referenced in P3P
HTTP headers sent by multiple hosts, in which case it may be applied to each
host that references it. The
INCLUDE
and
EXCLUDE
elements MUST specify URI patterns relative to the root of the DNS host to
which they are applied. This requirement does NOT apply to the location of the
P3P policy file (the about attribute on the
POLICY-REF
element).
If a
METHOD
element (
section
2.3.2.8
) specifies one or more methods for an enclosing policy reference,
it follows that all methods
not
mentioned are consequently
not
covered by this policy. In the case that this is the only policy
reference for a given URI prefix, user agents MUST assume that NO policy is in
effect for all methods NOT mentioned in the policy reference file. It is legal
but pointless to supply a
METHOD
element without any
INCLUDE
or
COOKIE-INCLUDE
elements.
It is legal, but pointless, to supply an
EXCLUDE
element
without any
INCLUDE
elements; in that case, the
EXCLUDE
element MUST be ignored by user agents.
Note that the set of URIs specified with
INCLUDE
and
EXCLUDE
does not include cookies that might be set or replayed
when requesting one of such URIs: in order to associate policies with cookies,
the
COOKIE-INCLUDE
and
COOKIE-EXCLUDE
elements are needed.
[12]
include
"
[13]
exclude
"
Here,
relativeURI
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
2.3.2.6 The
HINT
element
Policy reference hints are a performance optimization that can be used
under certain conditions. A site may declare a policy reference for itself
using the well-known location, the P3P response header, or the HTML/XHTML
link
tag. It MAY further provide a hint to additional policy
references, such as those declared by other sites.
For example, an HTML page might hint at policy references for its
hyperlinks, embedded content, and action URIs. User agents MAY use the hint
mechanism to discover policy reference files before requesting the affected
URIs when the policy references are not available from the well-known
location.
User agents which use hints to retrieve policies MUST NOT apply them to any
site other than the one which contains the hinted policy reference file.
Any policy reference file MAY contain zero or more policy reference hints.
Each hint is contained in a
HINT
element with two attributes,
scope
and
path
The
scope
attribute is used to specify a URI scheme and
authority to which the hinted policy reference can be applied. If the
authority component (cf. [
URI
]) is a server component
(e.g., a hostname or IP address) the host part of the authority MAY begin with
wildcard
, as defined in Section 2.3.2.1.2.
The
scope
attribute MUST NOT contain a wildcard in any other
position, MUST be encoded according to the conventions in Section 2.3.2.1.2,
and MUST NOT contain a path, query or fragment URI component. Additionally,
if the authority is a server, it SHOULD NOT contain a userinfo part.
For example, legal values for
scope
include:
ftp://ftp.example.org
The following are illegal values for the
scope
attribute:
; the wildcard can only be at the
start
; the trailing slash is not
allowed
www.example.com
; the scheme must be stated
*://www.example.com
; the scheme cannot contain a
wildcard
; the port cannot contain a
wildcard
The
path
attribute is used to locate the policy reference file
on the hinted site. It is a relative URI whose base is the URI scheme and
authority matched in the
scope
attribute. The
path
attribute MUST NOT be an absolute URI, so that the policy reference file is
always retrieved from the same site that it is applied to.
Example 2.3:
[14]
hint
`
domain
attribute (and thus have domain equivalent to the request
host as per
RFC 2965
([
STATE
]).
Cookies that omit the path attribute have the default path of the request
URI that generated the set-cookie response as per
RFC 2965
STATE
]. The
path
attribute of a
COOKIE-INCLUDE
should be matched against this default value if a
cookie omits the
path
attribute.
All four attributes are optional. If an attribute is absent, the
COOKIE-INCLUDE
(resp.
COOKIE-EXCLUDE
) will match
cookies that have that attribute set to any value.
When
COOKIE-INCLUDE
(and optionally,
COOKIE-EXCLUDE
) elements are present in a
POLICY-REF
element, the policy specified in the
about
attribute of the
POLICY-REF
element applies to every cookie that is matched by
any
COOKIE-INCLUDE
's, and not matched by a
COOKIE-EXCLUDE
element.
User agents MUST interpret
COOKIE-INCLUDE
and
COOKIE-EXCLUDE
elements in a policy reference file to determine
the policy that applies to cookies set by or replayed to the host to which the
policy reference file applies. While the domain attribute of a
COOKIE-INCLUDE
may match more broadly (for example, if the domain
attribute is omitted it defaults to matching any domain value), user agents
MUST limit their application of the policy to domains that could be legally
used in a cookie set by the host to which the policy reference file applies.
For example, if abc.xyz.example.com declares a policyref with
, this would be
matched to cookies with domains such as .abc.xyz.example.com and
.xyz.example.com, but not .example.com or .xyz.sample.com.
A P3P policy can be associated with a cookie by the host that set that
cookie as well as by any or all of the hosts to which it might be replayed. A
user agent MAY fetch a cookie policy at the time a cookie is set and apply it
later when the cookie is replayed, perhaps to other hosts in the domain. A
user agent MAY request a policy reference file from a host before replaying a
cookie to that host, and if the policy reference file contains an appropriate
COOKIE-INCLUDE
, a policy will be applied to that cookie even if
the cookie was not set by that host. Any host to which the cookie may be
replayed MUST be able to honor all the policies associated with the cookie,
regardless of whether that host declares a policy for that cookie. Thus sites
that set cookies that may be replayed to multiple hosts within a domain need
to coordinate to make sure all the hosts can follow the declared policy. In
addition, sites should be cautious with their use of wildcards to make sure
that they do not inadvertently apply a policy to cookies to which it should
not be applied (including previously set cookies that are still in use and
cookies set by other hosts in the domain).
The policy that applies to a cookie applies until the policy expires, even
if the associated policy reference file expires prior to policy expiry (but
after the cookie was set). If the policy associated with a cookie has expired,
then the user agent SHOULD reevaluate the cookie policy before sending the
cookie. In addition, user agents MUST use only non-expired policies and policy
reference files when evaluating new set-cookie events.
Example 2.4 states that
/P3P/Policies.xml#first
applies to all
cookies.
Example 2.4:
Example 2.5 states that
/P3P/Policies.xml#first
applies to all
cookies, except cookies with the cookie name value of
obnoxious-cookie
", a domain value of
.example.com
", and a path value of "
", and that
/P3P/Policies.xml#second
applies to all cookies with the cookie
name of "
obnoxious-cookie
", a domain value of
.example.com
", and a path value of "
".
Example 2.5:
[15]
cookie-include
"
[` value="` token `"`] ; matches the cookie's VALUE
[` domain="` token `"`] ; matches the cookie's Domain
[` path="` token `"`] ; matches the cookie's Path
"/>"
[16]
cookie-exclude
"
[` value="` token `"`] ; matches the cookie's VALUE
[` domain="` token `"`] ; matches the cookie's Domain
[` path="` token `"`] ; matches the cookie's Path
"/>"
Here,
token
NAME
VALUE
Domain
and
Path
are
defined as per
RFC
2965
STATE
], with the addition that the
' character is to be treated as a wildcard, as defined
in
section 2.3.2.1.2
Note that [
STATE
] states default values for the
domain and path attributes of cookies: these should be used in the comparison
if those attributes are not found in a specific cookie. Also, conforming to
STATE
], if an explicitly specified
Domain
value does not start with a full stop ("
"),
the user agent MUST prepend a full stop for it; and, note that every
Path
begins with the "
" character.
2.3.2.8 The
METHOD
element
By default, a policy reference applies to the stated URIs regardless of the
method used to access the resource. However, a Web site may wish to define
different P3P policies depending on the method to be applied to a resource.
For example, a site may wish to collect more data from users when they are
performing
PUT
or
DELETE
methods than when
performing
GET
methods.
The
METHOD
element in a policy reference file is used to state
that the enclosing policy reference only applies when the specified methods
are used to access the referenced resources. The
METHOD
element
may be repeated to indicate multiple applicable methods. If the
METHOD
element is not present in a
POLICY-REF
element, then that
POLICY-REF
element covers the resources
indicated regardless of the method used to access them.
So, to state that
/P3P/Policies.xml#first
applies to all
resources whose paths begin with
/docs/
for
GET
and
HEAD
methods, while
/P3P/Policies.xml#second
applies
for
PUT
and
DELETE
methods, the following policy
reference would be written:
Example 2.6:
Note that HTTP requires the same behavior for
GET
and
HEAD
requests, thus it is inappropriate to specify different P3P
policies for these methods. The syntax for the
METHOD
element
is:
[17]
method-element
`
Here,
Method
is defined in the section
5.1.1 of [
HTTP1.1
].
Finally, note that the
METHOD
element is designed to be used
in conjunction with
INCLUDE
or
COOKIE-INCLUDE
elements. A
METHOD
element by itself will never apply a
POLICY-REF
to a URI.
2.3.3 Applying a Policy to a URI
A policy reference file specifies the policy which applies to a given URI.
In other words, the indicated policy describes all effects of dereferencing
the given URI (in some cases, with the appropriately specified
METHOD
).
There is a general rule which describes what it means for a P3P policy to
cover a URI:
the referenced policy MUST cover actions that the user's
client software is expected to perform as a result of requesting that URI
Obviously, the policy must describe all data collection performed by site as a
result of processing the request for the URI. Thus, if a given URI is covered
for terms of
GET
requests, then the policy given by the policy
reference file MUST describe all data collection performed by the site when
that URI is dereferenced. Likewise, if a URI is covered for
POST
requests, then any data collection that occurs as a result of POSTing a form
or other content to that URI MUST be described by the policy.
The concept of "actions that the client software is expected to perform"
includes the setting of client-side cookies or other state-management
mechanisms invoked by the response. If executable code is returned when a URI
is requested, then the P3P policy covering that URI MUST cover certain actions
which will occur when that code is executed. The covered actions are any
actions which could take place without the user explicitly invoking them. If
explicit user action causes data to be collected, then the P3P policy covering
the URI for that action would disclose that data collection.
Some specific examples:
Fetching a URI returns an HTML page which contains a form, and the form
contents are sent to a second URI when the user clicks a "Submit" button.
The P3P policy covering the second URI MUST disclose all data collected by
the form. The P3P policy covering the first URI (the URI the form was
loaded from) MAY or MAY NOT disclose any of the data that will be
collected on the form.
An HTML page includes JavaScript code which tracks how long the page is
displayed and whether the user moved the mouse over a certain object on
the page; when the page is unloaded, the JavaScript code sends that
information to the server where the HTML page originated. The activity of
the JavaScript code MUST be covered by the P3P policy of the HTML page.
The reasoning is that this activity takes place without the user's
knowledge or consent, and it occurs automatically as a result of loading
the page.
A resource returns an executable for an electronic mail program. In
order to use the email program, the user must run an installation program,
start the email program, and use its facilities. The P3P policy covering
URI from where the email program was downloaded is not required to make a
statement about the data which could be collected by using the email
program. Installing and running the email program is clearly outside the
Web browsing experience, so it is not covered by this specification. A
separate protocol could be designed to allow downloaded applications to
present a P3P policy, but this is outside the scope of this
specification.
An HTML page containing a form includes a reference to an executable
which provides a custom client-side control. The data in the control is
submitted to a site when the form is submitted. In this case, the URI for
the HTML page and the URI for the custom control is not required to make a
statement about the data the custom control represents. However, the URI
to which the form contents are posted MUST cover the data from the custom
control, just as it would cover any other data collected by processing the
form. This behavior is similar to the way HTML forms are handled when they
use only standard HTML controls: the control itself collects no data, and
the data is collected when the form is posted. Note that this example
assumes that the form is only posted when the user actively presses a
"submit" or similar button. If the form were posted automatically (for
example, by some JavaScript code in the page), then this example would be
similar to example #2, and the data collected by the form MUST be
described in the P3P policy which covers the HTML form.
Requests to a URI are redirected to a third party. If the first party
embeds previously collected personal data in the query string or other
part of the redirect URI, the privacy policy for the first party's URI
MUST describe the types of data transmitted and include the third party as
a recipient.
2.3.4
Forms and Related Mechanisms
Forms deserve special consideration, as they often link to CGI scripts or
other server-side applications in their action URIs (the
action URI
is the URI given in the action attribute of the HTML
Now we shall define a "meeting" data element, which has a time and place
for the meeting:
structref="#date"/>
Since
meeting.place
does not reference a structure, it is of
an unstructured type, and has no child elements. The
meeting.time
element uses the
date
structure. By declaring this, the following
sub-elements are created:
meeting.time.ymd.year
meeting.time.ymd.month
meeting.time.ymd.day
meeting.time.hms.hour
meeting.time.hms.minute
meeting.time.hms.second
A P3P policy can now declare that it collects the
meeting
data
element, which implies that it collects all of the sub-elements of
meeting
, or it can use data elements lower down the hierarchy -
meeting.time
, for example, or
meeting.time.ymd.day
5.3 The
DATA-DEF
and
DATA-STRUCT
elements
and
Define a data element or a data structure, respectively. Data
structures are reusable structured type definitions that can be used to
build data elements. Data elements are declared within a
in a P3P policy to describe data covered
by that statement.
The following attributes are common to these two elements:
name
mandatory attribute)
Indicates the name of the data element or data structure. Remember
that names of data element and data structures are
case-sensitive
, so, for example,
user.gender
is different from
USER.GENDER
or
User.Gender
. Furthermore, in names of data elements and
structures no number character can appear immediately following a
dot.
structref
URI reference
([
URI
]), where the fragment
identifier part denotes the
structure
, and the URI part denotes
the corresponding
data schema
where it is defined. The default
base URI is a same-document reference ([
URI
]). Data elements or data
structures without a
structref
attribute (and, so, without
an associated structure) are called
unstructured
short-description
a string denoting the short display name of the data element or
structure, no more than 255
characters
The
DATA-DEF
and
DATA-STRUCT
elements can also
contain a long description of the data element or structure, using the
LONG-DESCRIPTION
element.
[64]
datadef
"
">"
[categories] ; the
categories
of the data element.
[longdescription] ; the long description of the data element
"
[65]
datastruct
"
">"
[categories] ; the
categories
of the Data Structure.
[longdescription] ; the long description of the Data Structure
"
Here,
URI-reference
is defined
as in [
URI
].
Data elements can be structured, much like in common programming languages:
structures are hierarchical (tree-like) descriptions of data elements: this
hierarchical description is performed in the
name
attribute using
a dot ("
") character as separator.
P3P provides the
P3P base data
schema
, which has built-in definitions of a number of widely
used structures and data elements. All P3P implementations are required to
understand the P3P base data schema, so the structures and elements it defines
are always available to P3P implementers.
A data schema may include multiple
DATA-STRUCT
elements that
together describe a structure. For example, there is no single
DATA-STRUCT
for the
uri
data structure (cf.
section 5.5.7.1
) in the P3P base data schema.
Instead
uri.authority
uri.stem
, and
uri.querystring
are interpreted together to define this
structure.
5.3.1 Categories in P3P Data
Schemas
Categories can be assigned to data structures or data elements. The
following rules define how those category definitions are meant to be
used:
elements MAY include category
definitions. If a structure definition includes categories, then all uses
of those structures in data definitions and data structures pick up those
categories. If a structure contains no categories, then the categories for
that structure MAY be defined when it is used in another structure or data
element. Otherwise, a data element using this structure is a
variable-category element. Any uses of a variable-category data element in
a policy require that its categories be listed in the policy.
with an unstructured type is a
variable-category data element if no categories are defined in the
, and has exactly those categories listed in
the
if any categories are included.
or
with
a structured type which has no categories defined on that structure
produces a variable-category data element/structure if no categories are
defined in the
or
. If the
or
does have categories listed, then those
categories are applied to that data element, and all of its sub-elements.
In other words, categories are pushed down into sub-elements when defining
a data element to be of a structured type, and the structured type does
not define any categories.
using a structured type which has
categories defined on that structure picks up all the categories listed on
the structure. In addition, categories may be listed in the
, and these are added to the categories
defined in the structure. These categories are defined only at the level
of that data element, and are not "pushed down" to any sub-elements.
that has no categories assigned to
it, and which is using a structured subtype which has categories defined
on the subtype picks up all the categories listed on the subtype.
that has categories assigned to it,
and which is using a structured subtype replaces all of the categories
listed on the subtype.
There is a "bubble-up" rule for categories when referencing data
elements: data elements, must at a minimum, include all categories defined
by any of its children. This rule applies recursively, so for example, all
categories defined by data elements
foo.a.w
foo.a.y
, and
foo.b.z
MUST be considered to apply
to data element
foo
cannot be defined with some
variable-category elements and some fixed-category elements. Either all of
the sub-elements of a structure must be in the variable category, or else
all of them must have one or more assigned categories.
with some variable-category elements and
some fixed-category elements MUST NOT be referenced. Note, this means that
the
dynamic
structure (cf. section 5.6.4 "
Dynamic Data
"), existing in the basedata schema,
cannot be referenced in a policy (each of its sub-elements
dynamic.clickstream
dynamic.http
, etc. can be
referenced individually).
5.3.2 P3P Data Schema Example
Consider the case where the company HyperSpeedExample wishes to describe
the features of a vehicle, using a structure called
vehicle
. This
structure includes:
The vehicle's model type (
vehicle.model
),
The vehicle's color (
vehicle.color
),
The vehicle's year of manufacture (
vehicle.built.year
),
and
The vehicle's price (
vehicle.price
).
If HyperSpeedExample also wants to include in the definition of a vehicle
the location of manufacture, it could add other fields to the structure with
all the relevant data like country, street address, postal code, and so on.
But, each part of a structure can use other structures as well:
structures
can be composed
. In this case, the
P3P base data
schema
already provides a structure
postal
describing all the postal information of a location. So, the final definition
of the structure vehicle is
vehicle.model
(unstructured)
vehicle.color
(unstructured)
vehicle.price
(unstructured)
vehicle.built.year
(unstructured)
vehicle.built.where
(with structure
postal
from the base data schema)
The structure
postal
has fields
postal.street
postal.city
, and so on. Since we have applied the structure
postal
to
vehicle.built.where
, it means that we can
access the street and city of a vehicle using the descriptions
vehicle.built.where.street
and
vehicle.built.where.city
respectively. So, by applying a
structure (in this case,
postal
) we can build very complex
descriptions in a modular way.
HyperSpeedExample wants to declare that all of the vehicle information will
be in the
category. The
vehicle.model,
vehicle.color, vehicle.price,
and
vehicle.built.year
fields are all unstructured types, so assigning them to the
category accomplishes this for those fields.
Since vehicle is a structure definition, assigning the
category to
vehicle.built.where
will override (replace) the categories defined on all of the sub-elements of
vehicle.built.where
, placing all of them in the
category, even though the
postal
structure was originally defined as being in other categories.
As said, structures do not contain data elements; they are just abstract
data types. We can use them to rapidly build structured collections of data
elements. Going on with the example, HyperSpeedExample needs this abstract
description of the features of a vehicle because it wants to actually exchange
data about cars and motorcycles. So, it could define two data elements called
car
and
motorcycle
, both with the above structure
vehicle
This description of the data elements and data structures is encoded in XML
using a data schema. In the HyperSpeedExample case, it would be something
like:
short-description="Construction Place">
Continuing with the example, in order to reference a car model and
construction year, HyperSpeedExample
or any other service
could send
the following references inside a P3P policy:
Using the
base
attribute, the
above references can be written in an even more compact way:
Alternatively, the data schema could be
embedded
directly into a
policy file. In this case, the policy file could look like:
short-description="Construction Place">
...
...
Note that in any case there MUST NOT be more than one data schema per
file.
5.3.3 Use of data element names
Note that the data element names specified in the base data schema or in
extension data schemas may be used for purposes other than P3P policies. For
example, Web sites may use these names to label HTML form fields. By referring
to data the same way in P3P policies and forms, automated form-filling tools
can be better integrated with P3P user agents.
5.4 Persistence of data
schemas
An essential requirement on data schemas is the
persistence of
data schemas
: data schemas that can be fetched at a certain URI
can only be changed by extending the data schema in a
backward-compatible
way (that is to say, changing the data schema
does not change the meaning of any policy using that schema). This way, the
URI of a policy acts in a sense like a unique identifier for the data elements
and structures contained therein: any data schema that is not
backward-compatible
must therefore use a new different URI
Note that a useful application of the persistence of data schema is given
for example in the case of multi-lingual sites: multiple language versions
(translations) of the same data schema can be offered by the server, using the
HTTP "
Content-Language
" response header field to properly
indicate that a particular language has been used for the data schema.
5.5
Basic Data Structures
The Basic Data Structures are structures used by the P3P base data schema
(and possibly, due to their basic nature, they should be reused as much as
possible by other different data schemas). All P3P-compliant user agent
implementations MUST be aware of the Basic Data Structures. Each table below
specifies the elements of a basic data structure, the categories associated,
their structures, and the display names shown to users. More than one category
may be associated with a fixed data element. However, each base data element
is assigned to only one category whenever possible. Data schema designers are
recommended to do the same.
5.5.1
Dates
The
date
structure specifies a date. Since date
information can be used in different ways, depending on the context, all
date
information is tagged as being of "variable" category
(see
Section 5.7.2
). For example, schema definitions
can explicitly set the corresponding category in the element referencing this
data structure, where soliciting the birthday of a user might be "Demographic
and Socioeconomic Data", while the expiration date of a credit card might
belong to the "Purchase Information" category.
date
Category
Structure
Short display name
ymd.year
variable-category
unstructured
Year
ymd.month
variable-category
unstructured
Month
ymd.day
variable-category
unstructured
Day
hms.hour
variable-category
unstructured
Hour
hms.minute
variable-category
unstructured
Minute
hms.second
variable-category
unstructured
Second
fractionsecond
variable-category
unstructured
Fraction of Second
timezone
variable-category
unstructured
Time Zone
The "time zone" information is for example described in the time standard
ISO8601
]. Note that "date.ymd" and "date.hms" can be
used to fast reference the year/month/day and hour/minute/second blocks
respectively.
5.5.2
Names
The
personname
structure specifies information about the
naming of a person.
personname
Category
Structure
Short display name
prefix
Demographic and Socioeconomic Data
unstructured
Name Prefix
given
Physical Contact Information
unstructured
Given Name (First Name)
family
Physical Contact Information
unstructured
Family Name (Last Name)
middle
Physical Contact Information
unstructured
Middle Name
suffix
Demographic and Socioeconomic Data
unstructured
Name Suffix
nickname
Demographic and Socioeconomic Data
unstructured
Nickname
5.5.3
Logins
The
structure specify information (IDs and
passwords) for computer systems and Web sites which require authentication.
Note that this data element should not be used for computer systems or Web
sites which use digital certificates for authentication: in those cases, the
certificate
structure should be used.
Category
Structure
Short display name
id
Unique Identifiers
unstructured
Login ID
password
Unique Identifiers
unstructured
Login Password
The "id" field represents the ID portion of the login information for a
computer system. Often, user IDs are made public, while passwords are kept
secret. IDs do not include any type of biometric authentication
mechanisms.
The "password" field represents the password portion of the login
information for a computer system. This is a secret data value, usually a
character string, that is used in authenticating a user. Passwords are
typically kept secret, and are generally considered to be sensitive
information
5.5.4
Certificates
The
certificate
structure is used to specify identity
certificates (like, for example, X.509).
certificate
Category
Structure
Short display name
key
Unique Identifiers
unstructured
Certificate Key
format
Unique Identifiers
unstructured
Certificate Format
The "format" field is used to represent the information of an IANA
registered public key or authentication certificate format, while the "key"
field is used to represent the corresponding certificate key.
5.5.5
Telephones
The
telephonenum
structure specifies the characteristics
of a telephone number.
telephonenum
Category
Structure
Short display name
intcode
Physical Contact Information
unstructured
International Telephone Code
loccode
Physical Contact Information
unstructured
Local Telephone Area Code
number
Physical Contact Information
unstructured
Telephone Number
ext
Physical Contact Information
unstructured
Telephone Extension
comment
Physical Contact Information
unstructured
Telephone Optional Comments
5.5.6
Contact Information
The
contact
structure is used to specify contact
information. Services can specify precisely which set of data they need,
postal, telecommunication, or online address information.
contact
Category
Structure
Short display name
postal
Physical Contact Information, Demographic and
Socioeconomic Data
postal
Postal Address Information
telecom
Physical Contact Information
telecom
Telecommunications Information
online
Online Contact Information
online
Online Address Information
5.5.6.1
Postal
The
postal
structure specifies a postal mailing
address.
postal
Category
Structure
Short display name
name
Physical Contact Information, Demographic and
Socioeconomic Data
personname
Name
street
Physical Contact Information
unstructured
Street Address
city
Demographic and Socioeconomic Data
unstructured
City
stateprov
Demographic and Socioeconomic Data
unstructured
State or Province
postalcode
Demographic and Socioeconomic Data
unstructured
Postal Code
country
Demographic and Socioeconomic Data
unstructured
Country Name
organization
Demographic and Socioeconomic Data
unstructured
Organization Name
The "country" field represents the information of the name of the country
(for example, one among the countries listed in [
ISO3166
]).
5.5.6.2
Telecommunication
The
telecom
structure specifies telecommunication
information about a person.
telecom
Category
Structure
Short display name
telephone
Physical Contact Information
telephonenum
Telephone Number
fax
Physical Contact Information
telephonenum
Fax Number
mobile
Physical Contact Information
telephonenum
Mobile Telephone Number
pager
Physical Contact Information
telephonenum
Pager Number
5.5.6.3
Online
The
online
structure specifies online information about a
person or legal entity.
online
Category
Structure
Short display name
email
Online Contact Information
unstructured
Email Address
uri
Online Contact Information
unstructured
Home Page Address
5.5.7
Access Logs and Internet
Addresses
Two structures used for representing forms of Internet addresses are
provided. The
uri
structure covers Universal Resource Identifiers
(URI), which are defined in [
URI
]. The
ipaddr
structure represents IP addresses and Domain Name System (DNS) hostnames.
5.5.7.1
URI
uri
Category
Structure
Short display name
authority
variable-category
unstructured
URI Authority
stem
variable-category
unstructured
URI Stem
querystring
variable-category
unstructured
Query-string Portion of URI
The authority of a URI is defined as the
authority
component
in [
URI
]. The stem of a URI is defined as the information
contained in the portion of the URI after the authority and up to (and
including) the first '?' character in the URI, and the querystring is the
information contained in the portion of the URI after the first '?' character.
For URIs which do not contain a '?' character, the stem is the entire URI, and
the querystring is empty.
Since URI information can be used in different ways, depending on the
context, all the fields in the
uri
structure are tagged as being
of "variable" category. Schema definitions MUST explicitly set the
corresponding category in the element referencing this data structure.
5.5.7.2
ipaddr
The
ipaddr
structure represents the hostname and IP address of
a system.
ipaddr
Category
Structure
Short display name
hostname
Computer Information
unstructured
Complete Host and Domain Name
partialhostname
Demographic
unstructured
Partial Hostname
fullip
Computer Information
unstructured
Full IP Address
partialip
Demographic
unstructured
Partial IP Address
The
hostname
element is used to represent collection of either
the simple hostname of a system, or the full hostname including domain name.
The
partialhostname
element represents the information of a
fully-qualified hostname which has had
at least
the host portion
removed from the hostname. In other words, everything up to the first '.' in
the fully-qualified hostname MUST be removed for an address to quality as a
"partial hostname".
The
fullip
element represents the information of a full IP
version 4 or IP version 6 address. The
partialip
element
represents an IP version 4 address (only - not a version 6 address) which has
had
at least
the last 7 bits of information removed. This removal
MUST be done by replacing those bits with a fixed pattern for all visitors
(for example, all 0's or all 1's).
Certain Web sites are known to make use not of the visitor's entire IP
address or hostname, but rather make use of a reduced form of that
information. By collecting only a subset of the address information, the site
visitor is given some measure of anonymity. It is certainly not the intent of
this specification to claim that these "stripped" IP addresses or hostnames
are impossible to associate with an individual user, but rather that it is
significantly more difficult to do so. Sites which perform this data reduction
MAY wish to declare this practice in order to more-accurately reflect their
practices.
5.5.7.3 Access Log Information
The
loginfo
structure is used to represent information
typically stored in Web-server access logs.
loginfo
Category
Structure
Short display name
uri
Navigation and click-stream data
uri
URI of Requested Resource
timestamp
Navigation and click-stream data
date
Request Timestamp
clientip
Computer Information, Demographic and Socioeconomic
Data
ipaddr
Client's IP Address or Hostname
other.httpmethod
Navigation and click-stream data
unstructured
HTTP Request Method
other.bytes
Navigation and click-stream data
unstructured
Data Bytes in Response
other.statuscode
Navigation and click-stream data
unstructured
Response Status Code
The resource in the HTTP request is captured by the
uri
field.
The time at which the server processes the request is represented by the
timestamp
field. Server implementations are free to define this
field as the time the request was received, the time that the server began
sending the response, the time that sending the response was complete, or some
other convenient representation of the time the request was processed. The IP
address of the client system making the request is given by the
clientip
field.
The
other
data fields represent other information commonly
stored in Web server access logs.
other.httpmethod
is the HTTP
method (such as
GET
POST
, etc) in the client's
request.
other.bytes
indicates the number of bytes in the
response-body sent by the server.
other.statuscode
is the HTTP
status code on the request, such as 200, 302, or 404 (see section 6.1.1 of [
HTTP1.1
] for details).
5.5.7.4
Other HTTP Protocol Information
The
httpinfo
structure represents information carried by the
HTTP protocol which is not covered by the
loginfo
structure.
httpinfo
Category
Structure
Short display name
referer
Navigation and click-stream data
uri
Last URI Requested by the User
useragent
Computer Information
unstructured
User Agent Information
The
useragent
field represents the information in the HTTP
User-Agent
header (which gives information about the type and
version of the user's Web browser), and/or the HTTP
accept
headers.
The
referer
field represents the information in the HTTP
Referer
header, which gives information about the previous page
visited by the user. Note that this field is misspelled in exactly the same
way as the corresponding HTTP header.
5.6
The base data schema
All P3P-compliant user agent implementations MUST be aware of the data
elements in the P3P base data schema. The P3P base data schema includes the
definition of the basic data structures, and four data element sets:
user
thirdparty
business
and
dynamic
. The
user
thirdparty
and
business
sets include elements that
users and/or businesses might provide values for, while the
dynamic
set includes elements that are dynamically generated in
the course of a user's browsing session. User agents may support a variety of
mechanisms that allow users to provide values for the elements in the
user
set and store them in a data repository, including
mechanisms that support multiple personae. Users may choose not to provide
values for these data elements.
The formal XML definition of the P3P base data schema is given in
Appendix 3
. In the following sections, the base data
elements and sets are explained one by one. In the future there will be in all
likelihood
demand for the creation of other data sets and elements.
Obvious applications include catalogue, payment, and agent/system attribute
schemas (an extensive set of system elements is provided for example in
.)
Each table below specifies a
set
, the elements within the
set, the category associated with the element, its structure, and the display
name shown to users. More than one category may be associated with a fixed
data element. However, each base data element is assigned to only one category
whenever possible. It is recommended that data schema designers do the
same.
5.6.1
User Data
The
user
data set includes general
information about the user.
user
Category
Structure
Short display name
name
Physical Contact Information, Demographic and
Socioeconomic Data
personname
User's Name
bdate
Demographic and Socioeconomic Data
date
User's Birth Date
Unique Identifiers
User's Login Information
cert
Unique Identifiers
certificate
User's Identity Certificate
gender
Demographic and Socioeconomic Data
unstructured
User's Gender (Male or Female)
employer
Demographic and Socioeconomic Data
unstructured
User's Employer
department
Demographic and Socioeconomic Data
unstructured
Department or Division of Organization where User is
Employed
jobtitle
Demographic and Socioeconomic Data
unstructured
User's Job Title
home-info
Physical Contact Information, Online Contact
Information, Demographic and Socioeconomic Data
contact
User's Home Contact Information
business-info
Physical Contact Information, Online Contact
Information, Demographic and Socioeconomic Data
contact
User's Business Contact Information
Note, that this data set includes elements that are actually sets of data
themselves. These sets are defined in the
Data
Structures
subsection of this document. The short display name for an
individual element contained within a data set is defined as the concatenation
of the short display names that have been defined for the set and the element,
separated by a separator appropriate for the language/script in question, e.g.
a comma for English. For example, the short display name for
user.home-info.postal.postalcode
could be "User's Home Contact
Information, Postal Address Information, Postal code". User agent
implementations may prefer to develop their own short display names rather
than using the concatenated names when displaying information for the
user.
5.6.2
Third Party Data
The
thirdparty
data set allows users and
businesses to provide values for a related third party. This can be useful
whenever third party information needs to be exchanged, for example when
ordering a present online that should be sent to another person, or when
providing information about one's spouse or business partner. Such information
could be stored in a user repository alongside the
user
data set.
User agents may offer to store multiple such
thirdparty
data sets
and allow users to select the appropriate values from a list when
necessary.
The
thirdparty
data set is identical with the
user
data set. See section
5.6.1 User
Data
for details.
5.6.3
Business Data
The
business
data set features a subset of
user
data relevant for describing legal entities. In P3P1.0, this
data set is primarily used for declaring the policy entity, although it should
also be applicable to business-to-business interactions.
business
Category
Structure
Short display name
name
Demographic and Socioeconomic Data
unstructured
Organization Name
department
Demographic and Socioeconomic Data
unstructured
Department or Division of Organization
cert
Unique Identifiers
certificate
Organization Identity Certificate
contact-info
Physical Contact Information, Online Contact
Information, Demographic and Socioeconomic Data
contact
Contact Information for the Organization
5.6.4
Dynamic Data
In some cases, there is a need to specify data elements that do not have
fixed values that a user might type in or store in a repository. In the P3P
base data schema, all such elements are grouped under the
dynamic
data set. Sites may refer to the types of data they collect using the dynamic
data set only, rather than enumerating all of the specific data elements.
dynamic
Category
Structure
Short display name
clickstream
Navigation and Click-stream Data, Computer
Information
loginfo
Click-stream Information
http
Navigation and Click-stream Data, Computer
Information
httpinfo
HTTP Protocol Information
clientevents
Navigation and Click-stream Data
unstructured
User's Interaction with a Resource
variable-category
unstructured
Use of HTTP Cookies
miscdata
variable-category
unstructured
Miscellaneous Non-base Data Schema Information
searchtext
Interactive Data
unstructured
Search Terms
interactionrecord
Interactive Data
unstructured
Server Stores the Transaction History
These elements are often implicit in navigation or Web interactions. They
should be used with categories to describe the type of information collected
through these methods. A brief description of each element follows.
clickstream
The
clickstream
element is expected to apply to
practically all Web sites. It represents the combination of information
typically found in Web server access logs: the IP address or hostname of
the user's computer, the URI of the resource requested, the time the
request was made, the HTTP method used in the request, the size of the
response, and the HTTP status code in the response. Web sites that
collect standard server access logs as well as sites which do URI path
analysis can use this data element to describe how that data will be
used. Web sites that collect only some of the data elements listed for
the
clickstream
element MAY choose to list those specific
elements rather than the entire
dynamic.clickstream
element. This allows sites with more limited data-collection practices
to accurately present those practices to their visitors.
http
The
http
element contains additional information
contained in the HTTP protocol. See the definition of the
httpinfo
structure for descriptions of specific elements.
Sites MAY use the
dynamic.http
field as a shorthand to
cover all the elements in the
httpinfo
structure if they
wish, or they MAY reference the specific elements in the
httpinfo
structure.
clientevents
The
clientevents
element represents data about how the
user interacts with their Web browser while interacting with a resource.
For example, an application may wish to collect information about
whether the user moved their mouse over a certain image on a page, or
whether the user ever brought up the help window in a Java applet. This
kind of information is represented by the dynamic.clientevents data
element. Much of this interaction record is represented by the events
and data defined by the Document Object Model (DOM) Level 2 Events [
DOM2-Events
]. The
clientevents
data element also covers any other data regarding the user's interaction
with their browser while the browser is displaying a resource. The
exception is events which are covered by other elements in the base data
schema. For example, requesting a page by clicking on a link is part of
the user's interaction with their browser while viewing a page, but
merely collecting the URL the user has clicked on does not require
declaring this data element;
clickstream
covers that event.
However, the DOM event
DOMFocusIn
(representing the user
moving their mouse over an object on a page) is not covered by any other
existing element, so if a site is collecting the occurrence of this
event, then it needs to state that it collects the dynamic.clientevents
element. Items covered by this data element are typically collected by
client-side scripting languages, such as JavaScript, or by client-side
applets, such as ActiveX or Java applets. Note that while the previous
discussion has been in terms of a user viewing a resource, this data
element also applies to Web applications which do not display resources
visually - for example, audio-based Web browsers.
The
element should be used whenever HTTP cookies
are set or retrieved by a site. Please note that
is
variable data element
and requires the explicit declaration
of usage categories in a policy.
miscdata
The
miscdata
element references information collected by
the service that the service does not reference using a specific data
element. Categories have to be used to better describe these data: sites
MUST reference a separate
miscdata
element in their
policies for each category of miscellaneous data they collect.
searchtext
The
searchtext
element references a specific type of
solicitation used for searching and indexing sites. For example, if the
only fields on a search engine page are search fields, the site only
needs to disclose that data element.
interactionrecord
The
interactionrecord
element should be used if the
server is keeping track of the interaction it has with the user (i.e.
information other than clickstream data, for example account
transactions, etc).
5.7 Categories and Data
Elements/Structures
5.7.1
Fixed-Category Data Elements/Structures
Most of the elements in the base data schema are so called
"fixed"
data elements: they belong to one or at most two category classes. By
assigning a category invariably to elements or structures in the base data
schema, services and users are able to refer to entire groups of elements
simply by referencing the corresponding category. For example, using [
APPEL
], the privacy preferences exchange language, users can
write rules that warn them when they visit a site that collects any data
element in a certain category.
When creating data schemas for fixed data elements, schema creators have to
explicitly enumerate the categories that these element belong to. For
example:
If an element or structure belongs to multiple categories, multiple
elements referencing the appropriate categories can be used. For example, the
following piece of XML can be used to declare that the data elements in
user.name have both category "physical" and "demographic":
Please note that the category classes of fixed data elements/structures can
not
be overridden, for example by writing rules or policies
that assign a different category to a known fixed base data element. User
agents MUST ignore such categories and instead use the original category (or
set of categories) listed in the schema definition. User agents MAY preferably
alert the user that a fixed data element is used together with a non-standard
category class.
5.7.2
Variable-Category Data
Elements/Structures
Not all data elements/structures in the base data schema belong to a
pre-determined category class. Some can contain information from a range of
categories, depending on a particular situation. Such elements/structures are
called
variable-category data elements/structures
(or "variable data
element/structure" for short). Although most variable data elements in the P3P
base data schema are combined in the
dynamic
element set,
they can appear in any data set, even mixed with
fixed-category data
elements
When creating a schema definition for such elements and/or structures,
schema authors MUST NOT list an explicit category attribute, otherwise the
element/structure becomes
fixed
. For example when specifying the
"Year"
Data Structure
, which can take various categories depending on
the situation (e.g. when used for a credit card expiration date vs. for a
birth date), the following schema definition can be used:
This allows new schema extensions that reference such variable-category
Data Structures
to assign a specific category to derived elements,
depending on their usage in that extension. For example, an e-commerce schema
extension could thus define a credit card expiration date as follows:
Under these conditions, the variable Data Structure
date
is assigned a fixed category
"Purchase Information
when being used for specifying a credit card expiration date.
Note that while user preferences can list such variable data elements
without any additional category information (effectively expressing
preferences over
any
usage of this element), services MUST always
explicitly specify the categories that apply to the usage of a variable data
element in their particular policy. This information has to appear as a
category element in the corresponding
DATA
element listed in the
policy, for example as in:
...
...
where a service declares that cookies are used to recognize the user at
this site (i.e. category
Unique Identifiers
).
If a service wants to declare a data element that is in multiple
categories, it simply declares the corresponding categories (as shown in the
above section
):
...
...
With the above declaration a service announces that it uses cookies both to
recognize the user at this site
and
for storing user preference data.
Note that for the purpose of P3P there is no difference whether this
information is stored in two separate cookies or in a single one.
Finally, note that categories can be inherited as well:
Categories
inherit downward when a field is structured, but only into fields which have
no predefined category.
Therefore, we suggest to schema authors that they
do their best to insure that all applicable categories are applied to new data
elements they create.
5.6
Using Data Elements
P3P offers Web sites a great deal of flexibility in how they describe the
types of data they collect.
Sites may describe data generally using the
dynamic.miscdata
element and the appropriate
categories.
Sites may describe data specifically using the data elements defined in
the base data schema.
Sites may describe data specifically using data elements defined in new
data schemas.
Any of these three methods may be combined within a single policy.
By using the
dynamic.miscdata
element, sites
can specify the types of data they collect without having to enumerate every
individual data element. This may be convenient for sites that collect a lot
of data or sites belonging to large organizations that want to offer a single
P3P policy covering the entire organization. However, the disadvantage of this
approach is that user agents will have to assume that the site might collect
any data element belonging to the categories referenced by the site. So, for
example, if a site's policy states that it collects
dynamic.miscdata
of the physical contact
information category, but the only physical contact information it collects is
business address, user agents will nonetheless assume that the site might also
collect telephone numbers. If the site wishes to be clear that it does not
collect telephone numbers or any other physical contact information other than
business address, than it should disclose that it collects
user.business-info.contact.postal
. Furthermore,
as user agents are developed with automatic form-filling capabilities, it is
likely that sites that enumerate the data they collect will be able to better
integrate with these tools.
By defining new data schemas, sites can precisely specify the data they
collect beyond the base data set. However, if user agents are unfamiliar with
the elements defined in these schemas, they will be able to provide only
minimal information to the user about these new elements. The information they
provide will be based on the category and display names specified for each
element.
Regardless of whether a site wishes to make general or specific data
disclosures, there are additional advantages to disclosing specific elements
from the
dynamic
data set. For example, by
disclosing
dynamic.cookies
a site can indicate
that it uses cookies and explain the purpose of this use. User agent
implementations that offer users cookie control interfaces based on this
information are encouraged. Likewise, user agents that by default do not send
the HTTP_REFERER header, might look for the
dynamic.http.referer
element in P3P policies and
send the header if it will be used for a purpose the user finds
acceptable.
6.
Appendices
Appendix 1:
References
(Normative)
ABNF
D. Crocker, P. Overel. "
Augmented BNF for Syntax
Specifications: ABNF
," RFC2234, IETF, November 1997.
Available at
CHARMODEL
M. Dürst,
et al.
(Eds.), "
Character Model for the World Wide
Web
,"
World Wide Web Consortium
Working Draft. 20 February 2002.
Latest version available at
DOM2-Events
T. Pixley (Ed.), "
Document Object Model
(DOM) Level 2 Events Specification
,"
World Wide Web Consortium
, Recommendation.
13 November 2000.
Available at
HTTP1.0
T. Berners-Lee, R. Fielding, H. Frystyk, "
Hypertext Transfer Protocol
-- HTTP/1.0
," RFC1945, IETF, May 1996.
Available at
HTTP1.1
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach,
T. Berners-Lee, "
Hypertext
Transfer Protocol -- HTTP/1.1
," RFC2616, IETF, June 1999. [Updates
RFC2068
Available at
HTML
D. Raggett, A. Le Hors, and I. Jacobs (Eds.). "
HTML 4.01 Specification
World Wide Web Consortium
, Recommendation.
24 Dicember 1999.
Available at
KEY
S. Bradner. "
Key words
for use in RFCs to Indicate Requirement Levels
." RFC2119, IETF,
March 1997.
Available at
LANG
H. Alvestrand, "
Tags for
the Identification of Languages.
" RFC1766, IETF, 1995.
Available at
STATE
D. Kristol, L. Montulli, "
HTTP State Management
Mechanism
." RFC2695, IETF, October, 2000 [Obsoletes
RFC2109
Available at
URI
T. Berners-Lee, R. Fielding, and L. Masinter. "
Uniform Resource Identifiers
(URI): Generic Syntax and Semantics
." RFC2396, IETF, August 1998.
[Updates
RFC1738
Available at
UTF-8
F. Yergeau. "
UTF-8, a
transformation format of ISO 10646
." RFC2279, IETF, January
1998.
Available at
XHTML-MOD
M. Altheim,
et al.
(Eds.). "
Modularization of
XHTML
".
World Wide Web Consortium
Recommendation. 10 April 2000.
Available at
XML
T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.Maler (Eds.). "
Extensible Markup Language (XML) 1.0
Specification (Second Edition)
."
World
Wide Web Consortium
, Recommendation. 6 October 2000.
Available at
XML-Name
T. Bray, D. Hollander, A. Layman (Eds.). "
Namespaces in XML.
World Wide Web Consortium
, Recommendation.
14 January 1999.
Available at
XML-Schema1
H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Eds.). "
XML Schema Part 1:
Structures
World Wide Web
Consortium
Recommendation. 2 May 2001.
Available at
XML-Schema2
P. Biron, A. Malhotra (Eds.). "
XML Schema Part 2:
Datatypes
World Wide Web
Consortium
Recommendation. 2 May 2001.
Available at
Appendix 2:
References
(Non-Normative)
APPEL
M. Langheinrich (Ed.). "
A P3P Preference Exchange
Language (APPEL)
."
World Wide Web
Consortium
Working Draft. 26 February 2001.
Available at
CACHING
I. Cooper, I. Melve, G. Tomlinson. "
Internet Web Replication and
Caching Taxonomy
." RFC3040, IETF, January 2001.
Available at
Persistent
Client State -- HTTP Cookies
," Preliminary Specification, Netscape,
1999.
Available at
ISO3166
"ISO3166: Codes for The Representation of Names of Countries."
International Organization for Standardization.
ISO8601
"ISO8601: Data elements and interchange formats -- Information
interchange -- Representation of dates and times." International
Organization for Standardization.
P3P-HEADER
M. Marchiori, R. Lotenberg (Eds.), "The HTTP header for the Platform
for Privacy Preferences 1.0 (P3P1.0)." IETF Internet Draft, 2002.
Latest version available as text at
Latest version available as HTML at
Latest version available as XML at
P3P-RDF
B. McBride, R.Wenning, L.Cranor. "
An RDF Schema for P3P
."
World Wide Web Consortium
, Note. 25
January 2002.
Latest version available at
RDF
O. Lassila and R. Swick (Eds.). "
Resource Description
Framework (RDF) Model and Syntax Specification.
World Wide Web Consortium
, Recommendation.
22 February 1999.
Available at
UNICODE
Unicode Consortium. "
The Unicode
Standard
Available at
Appendix 3: The P3P base data schema Definition
(Normative)
The data schema corresponding to the P3P base data schema follows for easy
reference. The schema is also present as a separate file at the URI
structref="#telephonenum">
structref="#telephonenum">
structref="#telephonenum">
structref="#telephonenum">
structref="#postal">
structref="#telecom">
structref="#online">
structref="#uri">
structref="#date">
structref="#ipaddr">
structref="#uri">
structref="#loginfo">
structref="#httpinfo">
information"/>
structref="#personname">
structref="#date">
structref="#login">
structref="#certificate">
structref="#contact">
structref="#contact">
structref="#personname">
structref="#date">
structref="#login">
structref="#certificate">
structref="#contact">
structref="#contact">
structref="#certificate">
structref="#contact">
Appendix 4: XML Schema Definition
(Normative)
This appendix contains the XML schema for P3P policy reference files, for
P3P policy documents, and for P3P data schema documents. P3P policy reference
files, P3P policy documents and P3P data schema documents are XML documents
that MUST conform to this schema. Note that this schema is based on the XML
Schema specification [
XML-Schema1
][
XML-Schema2
]. The schema is also present as a separate
file at the URI
xmlns:p3p='http://www.w3.org/2002/01/P3Pv1'
targetNamespace='http://www.w3.org/2002/01/P3Pv1'
elementFormDefault='qualified'>
Appendix 5: XML DTD Definition (Non-normative)
This appendix contains the DTD for P3P policy reference files, for P3P
policy documents, and for P3P data schema documents. This DTD MAY be used to
verify that P3P files are valid (although, note that there are some valid
files that may be rejected if checked against the DTD). The DTD is also
present as a separate file at the URI
EXCLUDE*,
COOKIE-INCLUDE*,
COOKIE-EXCLUDE*,
METHOD*,
EXTENSION*)>
about %URI; #REQUIRED >
scope CDATA #IMPLIED
path CDATA #IMPLIED >
max-age %NUMBER; #IMPLIED
date CDATA #IMPLIED >
POLICY*)>
name CDATA #IMPLIED
value CDATA #IMPLIED
domain CDATA #IMPLIED
path CDATA #IMPLIED>
name CDATA #IMPLIED
value CDATA #IMPLIED
domain CDATA #IMPLIED
path CDATA #IMPLIED>
TEST?,
ENTITY,
ACCESS,
DISPUTES-GROUP?,
STATEMENT+,
EXTENSION*)>
name ID #REQUIRED
discuri %URI; #REQUIRED
opturi %URI; #IMPLIED
xml:lang NMTOKEN #IMPLIED>
(nonident
| all
| contact-and-other
| ident-contact
| other-ident
| none),
EXTENSION*)>
( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*)
| (IMG, REMEDIES?, EXTENSION*)
| (REMEDIES, EXTENSION*) )?)>
resolution-type (service | independent | court | law) #REQUIRED
service %URI; #REQUIRED
verification CDATA #IMPLIED
short-description CDATA #IMPLIED >
src %URI; #REQUIRED
width %NUMBER; #IMPLIED
height %NUMBER; #IMPLIED
alt CDATA #REQUIRED >
CONSEQUENCE?,
((PURPOSE,RECIPIENT,RETENTION,DATA-GROUP+)|
(NON-IDENTIFIABLE,PURPOSE?,RECIPIENT?,RETENTION?,DATA-GROUP*)),
EXTENSION*)>
(current
| admin
| develop
| customization
| tailoring
| pseudo-analysis
| pseudo-decision
| individual-analysis
| individual-decision
| contact
| historical
| telemarketing
| other-purpose)+,
EXTENSION*)>
"required (always | opt-in | opt-out) #IMPLIED">
(ours
| same
| other-recipient
| delivery
| public
| unrelated)+,
EXTENSION*)>
(no-retention
| stated-purpose
| legal-requirement
| indefinitely
| business-practices),
EXTENSION*)>
base %URI; "http://www.w3.org/TR/P3P/base" >
ref %URI; #REQUIRED
optional (yes | no) "no" >
name ID #REQUIRED
structref %URI; #IMPLIED
short-description CDATA #IMPLIED >
name ID #REQUIRED
structref %URI; #IMPLIED
short-description CDATA #IMPLIED >
| online
| uniqueid
| purchase
| financial
| computer
| navigation
| interactive
| demographic
| content
| state
| political
| health
| preference
| location
| government
| other-category)+>
optional (yes | no) "yes" >
Appendix 6: ABNF Notation
(Normative)
The formal grammar of P3P is given in this specification using a slight
modification of [
ABNF
]. The following is a simple
description of the ABNF.
name = (elements)
where
more rule names or terminals combined through the operands provided
below. Rule names are case-insensitive.
element1 element2)
elements enclosed in parentheses are treated as a single element,
whose contents are strictly ordered.
*element
at least and at most occurrences of the
element.
(1*4
element
exactly occurrences of the element.
(4
*element
or more elements
(4*
*element
0 to elements.
(*5
*element
0 or more elements.
(*
[element]
optional element, equivalent to *1(element).
([element] means 0 or 1 element.)
"string"
or
'string'
matches the literal string given inside double quotes.
Other notations used in the productions are:
or
/* ... */
comment.
Appendix 7: P3P Guiding Principles
(Non-normative)
This appendix describes the intent of P3P development and recommends
guidelines regarding the responsible use of P3P technology. An earlier version
was published in the W3C Note "
P3P Guiding Principles
).
The Platform for Privacy Preferences Project (P3P) has been designed to be
flexible and support a diverse set of user preferences, public policies,
service provider polices, and applications. This flexibility will provide
opportunities for using P3P in a wide variety of innovative ways that its
designers had not imagined. The P3P Guiding Principles were created in order
to: express the intentions of the members of the P3P Working Groups when
designing this technology and suggest how P3P can be used most effectively in
order to maximize privacy and user confidence and trust on the Web. In keeping
with our goal of flexibility, this document does not place requirements upon
any party. Rather, it makes recommendations about 1) what
should
be
done to be consistent with the intentions of the P3P designers and 2) how to
maximize user confidence in P3P implementations and Web services. P3P was
intended to help protect privacy on the Web. We encourage the organizations,
individuals, policy-makers and companies who use P3P to embrace the guiding
principles in order to reach this goal.
Information Privacy
P3P has been designed to promote privacy and trust on the Web by enabling
service providers to disclose their information practices, and enabling
individuals to make informed decisions about the collection and use of their
personal information. P3P user agents work on behalf of individuals to reach
agreements with service providers about the collection and use of personal
information. Trust is built upon the mutual understanding that each party will
respect the agreement reached.
Service providers should preserve trust and protect privacy by applying
relevant laws and principles of data protection and privacy to their
information practices. The following is a list of privacy principles and
guidelines that helped inform the development of P3P and may be useful to
those who use P3P:
CMA Code
of Ethics & Standards of Practice: Protection of Personal
1981
Council of Europe Convention For the Protection of Individuals with Regard
to Automatic Processing of Personal Data
CSA
--Q830-96 Model Code for the
Protection of Personal Information
Directive
95/46/EC of the European Parliament and of the Council of 24 October 1995
on the protection of individuals with regard to the processing of personal
data and on the free movement of such data
The
DMA's Marketing Online Privacy Principles and Guidance
and
The
DMA Guidelines for Ethical Business Practice
OECD
Guidelines on the Protection of Privacy and Transborder Flows of Personal
Data
Online
Privacy Alliance Guidelines for Online Privacy Policies
In addition, service providers and P3P implementers should recognize and
address the special concerns surrounding children's privacy.
Notice and Communication
Service providers should provide timely and effective notices of their
information practices, and user agents should provide effective tools for
users to access these notices and make decisions based on them.
Service providers should:
Communicate explicitly about data collection and use, expressing the
purpose for which personal information is collected and the extent to
which it may be shared.
Use P3P privacy policies to communicate about all information they
propose to collect through a Web interaction.
Prominently post clear, human-readable privacy policies.
User agents should:
Provide mechanisms for displaying a service's information practices to
users.
Provide users an option that allows them to easily preview and agree to
or reject each transfer of personal information that the user agent
facilitates.
Not be configured by default to transfer personal information to a
service provider without the user's consent.
Inform users about the privacy-related options offered by the user
agent.
Choice and Control
Users should be given the ability to make meaningful choices about the
collection, use, and disclosure of personal information. Users should retain
control over their personal information and decide the conditions under which
they will share it.
Service providers should:
Limit their requests to information necessary for fulfilling the level
of service desired by the user. This will reduce user frustration,
increase trust, and enable relationships with many users, including those
who may wish to have an anonymous, pseudonymous, customized, or
personalized relationship with the service.
Obtain informed consent prior to the collection and use of personal
information.
Provide information about the ability to review and if appropriate
correct personal information.
User agents should:
Include configuration tools that allow users to customize their
preferences.
Allow users to import and customize P3P preferences from trusted
parties.
Present configuration options to users in a way that is neutral or
biased towards privacy.
Be usable without requiring the user to store user personal information
as part of the installation or configuration process.
Fairness and Integrity
Service providers should treat users and their personal information with
fairness and integrity. This is essential for protecting privacy and promoting
trust.
Service providers should:
Accurately represent their information practices in a clear and
unambiguous manner -- never with the intention of misleading users.
Use information only for the stated purpose and retain it only as long
as necessary.
Ensure that information is accurate, complete, and up-to-date.
Disclose accountability and means for recourse.
For as long as information is retained, continue to treat information
according to the policy in effect when the information was collected,
unless users give their informed consent to a new policy.
User agents should:
Act only on behalf of the user according to the preferences specified by
the user.
Accurately represent the practices of the service provider.
Security
While P3P itself does not include security mechanisms, it is intended to be
used in conjunction with security tools. Users' personal information should
always be protected with reasonable security safeguards in keeping with the
sensitivity of the information.
Service providers should:
Provide mechanisms for protecting any personal information they
collect.
Use appropriate trusted protocols for the secure transmission of
data.
User agents should:
Provide mechanisms for protecting the personal information that users
store in any data repositories maintained by the agent.
Use appropriate trusted protocols for the secure transmission of
data.
Warn users when an insecure transport mechanism is being used.
Appendix 8: Working Group Contributors
(Non-normative)
This specification was produced by the P3P Specification Working Group. The
following individuals participated in the P3P Specification Working Group,
chaired by Lorrie Cranor (AT&T): Mark Ackerman (University of California,
Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage), Joe Coco
(Microsoft), Brooks Dobbs (DoubleClick), Rajeev Dujari (Microsoft), Matthias
Enzmann (GMD), Patrick Feng (RPI), Aaron Goldfeder (Microsoft), Dan Jaye
(Engage), Marit Koehntopp (Privacy Commission of Land Schleswig-Holstein,
Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte
(Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Ran
Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE), Christine McKenna
(Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry (Microsoft), Jules
Polonetsky (DoubleClick), Martin Presler-Marshall (IBM), Joel Reidenberg
(Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Noboru Shimizu
(ENC), Rob Smibert (Jotter Technologies Inc.), Tri Tran (AvenueA), Mark
Uhrmacher (DoubleClick), Danny Weitzner (W3C), Michael Wallent (Microsoft),
Rigo Wenning (W3C), Betty Whitaker (NCR), Allen Wyke (Engage), Kevin Yen
(Netscape), Sam Yen (Citigroup), Alan Zausner (American Express).
The P3P Specification Working Group inherited a large part of the
specification from previous P3P Working Groups. The Working Group would like
to acknowledge the contributions of the members of these previous groups
(affiliations shown are the members' affiliations at the time of their
participation in each Working Group).
The P3P Implementation and Deployment Working Group, chaired by Rolf Nelson
(W3C) and Marc Langheinrich (NEC/ETH Zurich): Mark Ackerman (University of
California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft), Lorrie Cranor
(AT&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse
(Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer
(Citibank), Betty Whitaker (NCR).
The P3P Syntax Working Group, chaired by Steve Lucas (Matchlogic): Lorrie
Cranor (AT&T), Melissa Dunn (Microsoft), Daniel Jaye (Engage
Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max
Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM),
Drummond Reed (Intermind), Joseph Reagle (W3C).
The P3P Vocabulary Harmonization Working Group, chaired by Joseph Reagle
(W3C): Liz Blumenfeld (America Online), Ann Cavoukian (Information and Privacy
Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor (AT&T),
Jim Crowe (Direct Marketing Association), Josef Dietl (W3C), David Duncan
(Information and Privacy Commission/Ontario), Melissa Dunn (Microsoft),
Patricica Faley (Direct Marketing Association), Marit Köhntopp (Privacy
Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong Privacy
Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser (America
Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for Democracy and
Technology), Nick Platten (Data Protection Consultant, formerly of DG XV,
European Commission), Ari Schwartz (Center for Democracy and Technology),
Jonathan Stark (TRUSTe).
The P3P Protocols and Data Transport Working Group, chaired by Yves Leroux
(Digital): Lorrie Cranor (AT&T), Philip DesAutels (Matchlogic), Melissa
Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye
(Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers
(VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph Reagle
(W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds).
The P3P Vocabulary Working Group, chaired by Lorrie Cranor (AT&T): Mark
Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph
Reagle (W3C), Upendra Shardanand (Firefly).
The P3P Architecture Working Group, chaired by Martin Presler-Marshall
(IBM): Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C),
Melissa Dunn (Microsoft), Joseph Reagle (W3C).
Finally,
Appendix 7
is drawn from the W3C
Note "
P3P Guiding
Principles
", whose signatories are: Azer Bestavros (Bowne Internet
Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada),
Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye
(Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey
(Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT),
Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel
Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for
Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind),
Lawrence C. Stewart (Open Market, Inc.).