You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8087 lines
325 KiB
8087 lines
325 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
|
|
"http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
<HTML>
|
|
<HEAD>
|
|
<META content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
|
|
<STYLE type="text/css">
|
|
code { font-family: monospace }
|
|
|
|
@media print {
|
|
th.propindex { font-size: 8pt }
|
|
td.propindex { font-size: 8pt }
|
|
}
|
|
div.css-cited-thin { border: solid thin ; padding: 5pt }
|
|
div.css-cited-medium { border: solid medium ; padding: 5pt }
|
|
div.figure { page-break-inside: avoid }
|
|
|
|
|
|
</STYLE>
|
|
<TITLE>The Platform for Privacy Preferences 1.0 (P3P1.0) Specification</TITLE>
|
|
<LINK rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-CR">
|
|
</HEAD>
|
|
<BODY bgcolor="white">
|
|
<DIV class="head">
|
|
<A href="http://www.w3.org/"><IMG alt="W3C" height="48" src="http://www.w3.org/Icons/w3c_home"
|
|
width="72"></A>
|
|
<H1>
|
|
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
|
|
</H1>
|
|
<H2>
|
|
W3C Candidate Recommendation 15 December 2000
|
|
</H2>
|
|
<DL>
|
|
<DT>
|
|
This Version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/2000/CR-P3P-20001215/">http://www.w3.org/TR/2000/CR-P3P-20001215</A>
|
|
<DT>
|
|
Latest Public Version:
|
|
<DD>
|
|
<A href="http://www.w3.org/TR/P3P/">http://www.w3.org/TR/P3P</A>
|
|
<DT>
|
|
Previous Version:
|
|
<DD>
|
|
<A HREF="http://www.w3.org/TR/2000/WD-P3P-20001018/">http://www.w3.org/TR/2000/WD-P3P-20001018
|
|
</A>
|
|
<DT>
|
|
Editor:
|
|
<DD>
|
|
<A href="http://www.w3.org/People/Massimo/">Massimo Marchiori</A>, <A href="http://www.w3.org/">W3C</A>/<A href="http://www.mit.edu/">MIT</a>/<a href="http://www.unive.it">UNIVE</A>,
|
|
(<A href="mailto:massimo@w3.org">massimo@w3.org</A>)
|
|
<DT>
|
|
Authors:
|
|
<DD>
|
|
<A href="http://www.research.att.com/~lorrie/">Lorrie Cranor</A>, AT&T
|
|
<DD>
|
|
<A href="http://www.inf.ethz.ch/~langhein/">Marc Langheinrich</A>, ETH Zurich
|
|
<DD>
|
|
<A href="http://www.w3.org/People/Massimo/">Massimo Marchiori</A>, W3C/MIT/UNIVE
|
|
<DD>
|
|
<A href="mailto:mpresler@us.ibm.com">Martin Presler-Marshall</A>, IBM
|
|
<DD>
|
|
<A href="http://www.w3.org/People/Reagle/Overview.html">Joseph Reagle</A>,
|
|
W3C/MIT
|
|
</DL>
|
|
<P class="copyright">
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</A>
|
|
©2000
|
|
<A href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></A><SUP>®</SUP>
|
|
(<A href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of
|
|
Technology">MIT</abbr></A>,
|
|
<A href="http://www.inria.fr/"><abbr lang="fr" title="Institut National de
|
|
Recherche en Informatique et Automatique">INRIA</abbr></A>,
|
|
<A href="http://www.keio.ac.jp/">Keio</A>), All Rights Reserved. W3C
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
|
|
use</A> and
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
|
|
licensing</A> rules apply.
|
|
<P>
|
|
<HR title="Separator for header">
|
|
</DIV>
|
|
<H2>
|
|
Abstract
|
|
</H2>
|
|
<P>
|
|
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.
|
|
<H2>
|
|
Status of This Document
|
|
</H2>
|
|
<P>
|
|
<EM>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. </EM>
|
|
<P>
|
|
This is the 15 December 2000
|
|
<A HREF="http://www.w3.org/Consortium/Process/Process-19991111/tr.html#RecsCR">Candidate
|
|
Recommendation </A>of the Platform for Privacy Preferences 1.0 (P3P1.0)
|
|
Specification. This means that the P3P Specification Working Group (Members-only)
|
|
considers the specification to be stable and encourages implementation and
|
|
comment on the specification during this period. The Candidate Recommendation
|
|
review period ends once the milestones below are achieved. Input from
|
|
implementors will be accepted at least through 15 March 2001.
|
|
</P>
|
|
<P>The milestones are:
|
|
<OL>
|
|
<LI>
|
|
at least one P3P user agent implementation integrated into an HTTP user agent
|
|
capable of fetching HTML files that includes all of the functionality required
|
|
and recommended by this specification
|
|
<LI>
|
|
a second P3P user agent implementation of each specified function (these
|
|
functions may be demonstrated across several partial P3P implementations
|
|
or they may be demonstrated in a second full P3P implementation)
|
|
<LI>
|
|
at least one special-purpose tool for generating P3P policies and policy
|
|
reference files
|
|
<LI>
|
|
at least one tool for converting full P3P policies to compact policies
|
|
<LI>
|
|
at least 10 P3P-enabled production web sites
|
|
<LI>
|
|
at least one web site that illustrates each of the example scenarios in
|
|
<A HREF="#example_scenarios">Section 2.5</A> of the P3P1.0 specification
|
|
as well as at least one web site that uses mini-policies (these may be either
|
|
production web sites or demonstration sites)
|
|
</OL>
|
|
<P>
|
|
Furthermore during the Candidate Recommendation review period, the Working
|
|
Group will:
|
|
<OL>
|
|
<LI>
|
|
Prepare a W3C Note describing RDF data models representing P3P policies and
|
|
policy reference files.
|
|
<LI>
|
|
Submit an Internet Draft to the IETF describing the P3P header and request
|
|
that an RFC be issued documenting this header.
|
|
<LI>
|
|
Prepare a set of test policies and policy reference files that user agent
|
|
implementers can use to demonstrate that their implementations behave correctly.
|
|
This should include examples of policies that contain syntax errors.
|
|
<LI>
|
|
Specify the appropriate behavior for user agents upon encountering a
|
|
policy with invalid syntax.
|
|
</OL>
|
|
<P>
|
|
The working group also encourages implementors to explore the possibility
|
|
of implementations in web proxies and mobile devices, as well as implementations
|
|
that can import user preferences using the [<A HREF="#APPEL">APPEL</A>]
|
|
language.
|
|
<P>
|
|
Please send review comments to
|
|
<A HREF="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</A>
|
|
(<A HREF="http://lists.w3.org/Archives/Public/www-p3p-public-comments/">publicly
|
|
archived</A>).
|
|
<P>
|
|
Should this specification prove very difficult or impossible to implement,
|
|
the Working Group will return the document to Working Draft status and make
|
|
necessary changes. Otherwise, the Working Group anticipates asking the W3C
|
|
Director to advance this document to Proposed Recommendation.
|
|
<P>
|
|
A <A HREF="#changelog">change log</A> with a summary of the modifications
|
|
occurred from the <A HREF="http://www.w3.org/TR/2000/WD-P3P-20001018/">18
|
|
October 2000 Last Call Working Draft</A> is included at the end of this document
|
|
for convenience.
|
|
<P>
|
|
A list of current public W3C Working Drafts can be found at
|
|
<A HREF="http://www.w3.org/TR/">http://www.w3.org/TR</A>.
|
|
<P>
|
|
<P>
|
|
<EM>Summary of required functionality:</EM>
|
|
<P>
|
|
User agents MUST be able to:
|
|
<OL>
|
|
<LI>
|
|
Check for a policy reference file in the well-known location
|
|
<LI>
|
|
Check for a policy reference file in the HTTP response header
|
|
<LI>
|
|
Check for a policy reference file in the embedded <CODE>LINK</CODE> tags
|
|
(required only for those that fetch HTML files)
|
|
<LI>
|
|
Fetch a policy reference file
|
|
<LI>
|
|
Parse a policy reference file and identify the location of an applicable
|
|
policy -- must also be able to handle inline policies
|
|
<LI>
|
|
Fetch a P3P policy
|
|
<LI>
|
|
Fetch and parse data schemas
|
|
<LI>
|
|
Parse a policy and compare with user preferences (and take whatever action
|
|
is appropriate based on policy and preferences)
|
|
<LI>
|
|
Use policy and policy reference file expiration to determine when new policy
|
|
and/or policy reference files must be fetched
|
|
<LI>
|
|
Properly handle web pages that include multiple objects (with possibly different
|
|
policies) and embedded content by fetching all necessary policies and policy
|
|
reference files and behaving appropriately
|
|
<LI>
|
|
Import user preferences using a documented mechanism
|
|
</OL>
|
|
<P>
|
|
<EM>Summary of recommended functionality:</EM>
|
|
<P>
|
|
User agents SHOULD be able to:
|
|
<OL>
|
|
<LI>
|
|
Comply with all guiding principles for user agents
|
|
<LI>
|
|
Export user preferences
|
|
<LI>
|
|
Enforce safezone requirements (suppress cookies and headers)
|
|
<LI>
|
|
Recognize and parse compact policies and take appropriate actions
|
|
</OL>
|
|
<P>
|
|
<P>
|
|
<HR>
|
|
<H2>
|
|
Table of Contents
|
|
</H2>
|
|
<P>
|
|
<OL>
|
|
<LI>
|
|
<A href="#Introduction">Introduction</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#P3P1.0">The P3P1.0 Specification</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#goals_and_capabs">Goals and Capabilities of P3P1.0</A>
|
|
<LI>
|
|
<A href="#intro_example">Example of P3P in Use</A>
|
|
<LI>
|
|
<A href="#P3PPolicies">P3P Policies</A>
|
|
<LI>
|
|
<A href="#UserAgents">P3P User Agents</A>
|
|
<LI>
|
|
<A href="#Implementing">Implementing P3P1.0 on Servers</A>
|
|
<LI>
|
|
<A href="#Future">Future Versions of P3P</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#About">About this Specification</A>
|
|
<LI>
|
|
<A href="#Terminology">Terminology</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Referencing">Referencing Policies</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#overview_of_prfs">Overview and Purpose of Policy References</A>
|
|
<LI>
|
|
<A href="#ref_syntax">Locating Policy Reference Files</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#Well_Known_Location">Well-Known Location</A>
|
|
<LI>
|
|
<A href="#syntax_ext">HTTP Headers</A>
|
|
<LI>
|
|
<A href="#syntax_link">The HTML <CODE>link</CODE> Tag</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#ref_file">Policy Reference File Syntax and Semantics</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#ref_file_example">Example Policy Reference File</A>
|
|
<LI>
|
|
<A href="#ref_file_syntax">Policy Reference File Definition</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#ref_file_processing">Policy reference file processing</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#ref_file_ordering">Significance of order</A>
|
|
<LI>
|
|
<A href="#ref_file_wildcards">Wildcards in policy reference files</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#ref_file_refs">The <CODE>META</CODE> and
|
|
<CODE>POLICY-REFERENCES</CODE> elements</A>
|
|
<LI>
|
|
<A href="#ref_file_lifetime">Policy reference file lifetimes and the
|
|
<CODE>EXPIRY element</CODE></A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#motivation_and_mechanism">Motivation and mechanism</A>
|
|
<LI>
|
|
<A href="#the_expiry_element">The <CODE>EXPIRY</CODE> element</A>
|
|
<LI>
|
|
<A href="#use_of_http_headers">Use of HTTP headers</A>
|
|
<LI>
|
|
<A href="#error_handling">Error handling for policy reference file
|
|
lifetimes</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#ref_file_policyref">The <CODE>POLICY-REF</CODE> element</A>
|
|
<LI>
|
|
<A href="#ref_file_preexc">The <CODE>INCLUDE</CODE> and <CODE>EXCLUDE</CODE>
|
|
elements</A>
|
|
<LI>
|
|
<A href="#embedded_tags">The <CODE>EMBEDDED-INCLUDE</CODE> and
|
|
<CODE>EMBEDDED-EXCLUDE</CODE> elements</A>
|
|
<LI>
|
|
<A HREF="#cookies">The <CODE>COOKIE-INCLUDE</CODE> and
|
|
<CODE>COOKIE-EXCLUDE</CODE> elements</A>
|
|
<LI>
|
|
<A href="#ref_file_method">The <CODE>METHOD</CODE> element</A>
|
|
</OL>
|
|
<LI>
|
|
<A HREF="#active_content">Applying a Policy to a URI</A>
|
|
<LI>
|
|
<A href="#forms">Forms and Related Mechanisms</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#additional_requirements">Additional Requirements</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#non-ambiguity">Non-ambiguity</A>
|
|
<LI>
|
|
<A href="#multiple">Multiple Languages</A>
|
|
<LI>
|
|
<A href="#safezone">The Safe Zone</A>
|
|
<LI>
|
|
<A href="#discrimination">Non-discrimination of Policies</A>
|
|
<LI>
|
|
<A href="#security">Security of Policy Transport</A>
|
|
<LI>
|
|
<A href="#policy_updates">Policy Updates</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#example_scenarios">Example Scenarios</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#P3P_markup">Policy Syntax and Semantics</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#Example_policy">Example policies</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#English">English language policies</A>
|
|
<LI>
|
|
<A href="#encoding">XML encoding of policies</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Policies">Policies</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#POLICIES">The <CODE>POLICIES</CODE> element</A>
|
|
<LI>
|
|
<A href="#POLICY">The <CODE>POLICY</CODE> element</A>
|
|
<LI>
|
|
<A HREF="#test">The <CODE>TEST</CODE> element</A>
|
|
<LI>
|
|
<A href="#ENTITY">The <CODE>ENTITY</CODE> element</A>
|
|
<LI>
|
|
<A href="#ACCESS">The <CODE>ACCESS</CODE> element</A>
|
|
<LI>
|
|
<A href="#DISPUTES">The <CODE>DISPUTES</CODE> element</A>
|
|
<LI>
|
|
<A href="#REMEDIES">The <CODE>REMEDIES</CODE> element</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Statements">Statements</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#STATEMENT">The <CODE>STATEMENT</CODE> element</A>
|
|
<LI>
|
|
<A href="#CONSEQUENCE">The <CODE>CONSEQUENCE</CODE> element</A>
|
|
<LI>
|
|
<A HREF="#NON-IDENTIFIABLE">The <CODE>NON-IDENTIFIABLE</CODE> element</A>
|
|
<LI>
|
|
<A href="#PURPOSE">The <CODE>PURPOSE</CODE> element</A>
|
|
<LI>
|
|
<A href="#RECPNT">The <CODE>RECIPIENT</CODE> element</A>
|
|
<LI>
|
|
<A href="#RETENTION">The <CODE>RETENTION</CODE> element</A>
|
|
<LI>
|
|
<A href="#DATA">The <CODE>DATA-GROUP</CODE> and <CODE>DATA</CODE> elements</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Categories">Categories</A>
|
|
<LI>
|
|
<A href="#extension">Extension Mechanism</A>
|
|
<LI>
|
|
<A HREF="#PREFERENCES">Import and Export of User Preferences</A>
|
|
</OL>
|
|
<LI>
|
|
<A HREF="#compact_policies">Compact Policies</A>
|
|
<OL>
|
|
<LI>
|
|
<A HREF="#referencing_compact_policies">Referencing Compact Policies</A>
|
|
<LI>
|
|
<A HREF="#compact_policy_vocabulary">Compact Policies Vocabulary</A>
|
|
<OL>
|
|
<LI>
|
|
<A HREF="#compact_purposes">Compact <CODE>PURPOSE</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_recipients">Compact <CODE>RECIPIENT</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_retention">Compact <CODE>RETENTION</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_categories">Compact <CODE>CATEGORIES</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_non_identifiable">Compact
|
|
<CODE>NON-IDENTIFIABLE</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_disputes">Compact <CODE>DISPUTES</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_access">Compact <CODE>ACCESS</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_remedies">Compact <CODE>REMEDIES</CODE></A>
|
|
<LI>
|
|
<A HREF="#compact_test">Compact <CODE>TEST</CODE></A>
|
|
</OL>
|
|
<LI>
|
|
<A HREF="#compact_policy_scope">Compact Policy Scope</A>
|
|
<LI>
|
|
<A HREF="#compact_policy_lifetime">Compact Policy Lifetime</A>
|
|
<LI>
|
|
<A HREF="#full_into_compact">Transforming a P3P Policy to a Compact Policy</A>
|
|
<LI>
|
|
<A HREF="#compact_into_full">Transforming a Compact Policy to a P3P Policy</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Data_Schemas">Data Schemas</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#DATA-DEF-TYPE">The <CODE>DATA-DEF</CODE> and
|
|
<CODE>DATA-STRUCT</CODE> elements</A>
|
|
<LI>
|
|
<A href="#dataschemas_immutability">Persistence of Data Schemas</A>
|
|
<LI>
|
|
<A href="#Data_Types">Basic Data Structures</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#Dates">Dates</A>
|
|
<LI>
|
|
<A href="#Names">Names</A>
|
|
<LI>
|
|
<A href="#Certificates">Certificates</A>
|
|
<LI>
|
|
<A href="#Telephones">Telephones</A>
|
|
<LI>
|
|
<A href="#Contact_Information">Contact Information</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#Postal">Postal</A>
|
|
<LI>
|
|
<A href="#Telecommunication">Telecommunication</A>
|
|
<LI>
|
|
<A href="#Online">Online</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Internet_Addresses">Access Logs and Internet Addresses</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#URI_data_structure">URI</A>
|
|
<LI>
|
|
<A href="#IPaddress_data_structure">ipaddr</A>
|
|
<LI>
|
|
<A href="#access_log">Access Log Information</A>
|
|
<LI>
|
|
<A href="#other_http_info">Other HTTP Protocol Information</A>
|
|
</OL>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Base_Data_Schema">The Base Data Schema</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#User_Data">User Data</A>
|
|
<LI>
|
|
<A href="#Third-Party-Data">Third Party Data</A>
|
|
<LI>
|
|
<A href="#Business-Data">Business Data</A>
|
|
<LI>
|
|
<A href="#Dynamic_Data">Dynamic Data</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#categories_and_data">Categories and Data Elements/Structures</A>
|
|
<OL>
|
|
<LI>
|
|
<A href="#fixed">Fixed-Category Data Elements/Structures</A>
|
|
<LI>
|
|
<A href="#variable">Variable-Category Data Elements/Structures</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#using_data_elements">Using Data Elements</A>
|
|
</OL>
|
|
<LI>
|
|
<A href="#Appendices">Appendices</A> <BR>
|
|
<A href="#References_normative">Appendix 1: References (Normative)</A><BR>
|
|
<A href="#References_nonnormative">Appendix 2: References
|
|
(Non-normative)</A><BR>
|
|
<A href="#basedataxml">Appendix 3: The P3P Base Data Schema Definition
|
|
(Normative)</A><BR>
|
|
<A href="#Appendix_schema">Appendix 4: XML Schema Definition
|
|
(Normative)</A><BR>
|
|
<A href="#DTD">Appendix 5: XML DTD Definition (Normative)</A><BR>
|
|
<A href="#Appendix_Notation">Appendix 6: ABNF Notation
|
|
(Non-normative)</A><BR>
|
|
<A href="#guiding_principles">Appendix 7: P3P Guiding Principles
|
|
(Non-normative)</A><BR>
|
|
<A href="#Appendix_Working">Appendix 8: Working Group Contributors
|
|
(Non-normative)</A>
|
|
</OL>
|
|
<P>
|
|
<HR>
|
|
<H1>
|
|
1. <A name="Introduction">Introduction</A>
|
|
</H1>
|
|
<P>
|
|
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.
|
|
<P>
|
|
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.
|
|
<H2>
|
|
1.1 <A name="P3P1.0">The P3P1.0 Specification</A>
|
|
</H2>
|
|
<P>
|
|
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 <EM>vocabulary</EM>
|
|
for expressing privacy practices. P3P policies also reference elements of
|
|
the P3P <EM>base data schema</EM> -- 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.
|
|
<H3>
|
|
<A name="goals_and_capabs">1.1.1 Goals and Capabilities of P3P1.0</A>
|
|
</H3>
|
|
<P>
|
|
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 <EM>P3P policy</EM>. The P3P specification defines:
|
|
<UL>
|
|
<LI>
|
|
A standard schema for data a Web site may wish to collect, known as the "P3P
|
|
base data schema"
|
|
<LI>
|
|
A standard set of uses, recipients, data categories, and other privacy
|
|
disclosures
|
|
<LI>
|
|
An XML format for expressing a privacy policy
|
|
<LI>
|
|
A means of associating privacy policies with Web pages or sites, and cookies
|
|
<LI>
|
|
A mechanism for transporting P3P policies over HTTP
|
|
</UL>
|
|
<P>
|
|
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.
|
|
<H3>
|
|
<A name="intro_example">1.1.2 Example of P3P in Use</A>
|
|
</H3>
|
|
<P>
|
|
As an introduction to P3P, let us consider one common scenario that makes
|
|
use of P3P. Sheila 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 Sheila is using a Web
|
|
browser with P3P built in.
|
|
<P>
|
|
Sheila 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 Sheila's Web browser checks this policy against
|
|
the preferences Sheila has given it. Is this policy acceptable to her, or
|
|
should she be notified? Let's assume that Sheila 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.
|
|
<P>
|
|
Next, Sheila 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 Sheila's preferences, so she gets no pop-up messages.
|
|
Sheila continues and selects a few items she wishes to purchase. Then she
|
|
proceeds to the checkout page.
|
|
<P>
|
|
The checkout page of CatalogExample requires some additional information:
|
|
Sheila'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.
|
|
<P>
|
|
Sheila's browser examines this P3P policy. Imagine that Sheila 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. Sheila 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.
|
|
<P>
|
|
Alternatively, Sheila 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.
|
|
<P>
|
|
Note that this scenario describes one hypothetical implementation of P3P.
|
|
Other types of user interfaces are also possible.
|
|
<H3>
|
|
1.1.3 <A name="P3PPolicies">P3P Policies</A>
|
|
</H3>
|
|
<P>
|
|
P3P policies use an <A href="#XML">XML</A> encoding of the P3P vocabulary
|
|
to identify 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
|
|
(but note that 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.
|
|
<P>
|
|
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.
|
|
<H3>
|
|
1.1.4 <A name="UserAgents">P3P User Agents</A>
|
|
</H3>
|
|
<P>
|
|
P3P1.0 user agents can be built into Webbrowsers, 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 <CODE>link</CODE>
|
|
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.
|
|
<H3>
|
|
1.1.5 <A name="Implementing">Implementing P3P1.0 on Servers</A>
|
|
</H3>
|
|
<P>
|
|
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
|
|
<A href="#Well_Known_Location">well-known location</A>, or they may reference
|
|
their P3P policy reference files in HTML content using a
|
|
<CODE>link</CODE> 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.
|
|
<P>
|
|
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.
|
|
<H3>
|
|
1.1.6 <A name="Future">Future Versions of P3P</A>
|
|
</H3>
|
|
<P>
|
|
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:
|
|
<UL>
|
|
<LI>
|
|
a mechanism to allow sites to offer a choice of P3P policies to visitors
|
|
<LI>
|
|
a mechanism to allow visitors (through their user agents) to explicitly agree
|
|
to a P3P policy
|
|
<LI>
|
|
mechanisms to allow for non-repudiation of agreements between visitors and
|
|
Web sites
|
|
<LI>
|
|
a mechanism to allow user agents to transfer user data to services
|
|
</UL>
|
|
<H2>
|
|
1.2 <A name="About">About this Specification</A>
|
|
</H2>
|
|
<P>
|
|
This document, along with its normative references, includes all the
|
|
specification necessary for the implementation of interoperable P3P applications.
|
|
<P>
|
|
The [<A href="#ABNF">ABNF</A>] notation used in this specification is specified
|
|
in
|
|
<A href="http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt">RFC2234</A>
|
|
and summarized in <A href="#Appendix_Notation">Appendix 7</A>. However, note
|
|
that such syntax is only a grammar representative of the XML syntax: all
|
|
the syntactic flexibilities of XML are also implicitly included; e.g. whitespace
|
|
rules, quoting using either single quote (') or double quote ("),
|
|
<A href="http://www.w3.org/TR/REC-xml#dt-chardata">character escaping</A>,
|
|
comments, case sensitivity, order of attributes. Note that while XML allows
|
|
flexibility in the ordering of element attributes, it does not allow flexibility
|
|
in the ordering of elements. XML elements MUST be given in the order represented
|
|
by the document type definitions (DTDs).
|
|
<P>
|
|
In the sections that follow a number of XML elements are introduced. Each
|
|
element is given in angle brackets ("<CODE><element></CODE>"), followed
|
|
by a list of valid attributes. All listed attributes are optional, except
|
|
when tagged as <EM>mandatory</EM>. Note that many XML elements are shown
|
|
in the BNF with separate beginning and ending tags to allow optional elements
|
|
inside them. If no elements are included, then, following standard XML rules,
|
|
a self-closing element may be used instead.
|
|
<P>
|
|
The following key words are used throughout the document and should be read
|
|
as interoperability requirements. This specification uses words as defined
|
|
in
|
|
<A href="http://info.internet.isi.edu/in-notes/rfc/files/rfc2119.txt">RFC2119</A>
|
|
[<A href="#KEY">KEY</A>] for defining the significance of each particular
|
|
requirement. These words are:
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
MUST or MUST NOT
|
|
<DD>
|
|
This word or the adjective "required" means that the item is an absolute
|
|
requirement of the specification.
|
|
<DT>
|
|
SHOULD or SHOULD NOT
|
|
<DD>
|
|
This word or the adjective "recommended" 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.
|
|
<DT>
|
|
MAY
|
|
<DD>
|
|
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.
|
|
</DL>
|
|
<H2>
|
|
1.3 <A name="Terminology">Terminology</A>
|
|
</H2>
|
|
<DL>
|
|
<DT>
|
|
<A name="character"><STRONG>Character</STRONG></A>
|
|
<DD>
|
|
Strings consist of a sequence of zero or more characters, where a character
|
|
is defined as in the XML Recommendation [<A href="#XML">XML</A>]. A single
|
|
character in P3P thus corresponds to a single Unicode abstract character
|
|
with a single corresponding Unicode scalar value (see
|
|
[<A href="#UNICODE">UNICODE</A>]).
|
|
<DT>
|
|
<A name="Data_Elements"><STRONG>Data Element</STRONG></A>
|
|
<DD>
|
|
An individual data entity, such as last name or telephone number. For
|
|
interoperability, P3P1.0 specifies a base set of data elements.
|
|
<DT>
|
|
<A name="Data_Category"><STRONG>Data Category</STRONG></A>
|
|
<DD>
|
|
A significant attribute of a <A href="#Data_Elements">data element</A> or
|
|
<A href="#Data_Sets">data set</A> 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 <A href="#Categories">data categories</A>.
|
|
<DT>
|
|
<A name="Data_Sets"><STRONG>Data Set</STRONG></A>
|
|
<DD>
|
|
A known grouping of <A href="#Data_Elements">data elements</A>, such as
|
|
"<A href="#Postal"><CODE>user.home.postal</CODE></A>". The P3P1.0 base data
|
|
schema specifies a number of data sets.
|
|
<DT>
|
|
<STRONG>Equable Practice</STRONG>
|
|
<DD>
|
|
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.
|
|
<DT>
|
|
<STRONG>Personally Identifiable Data</STRONG>
|
|
<DD>
|
|
Any information relating to an identified or identifiable individual.
|
|
<DT>
|
|
<STRONG>Policy</STRONG>
|
|
<DD>
|
|
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.
|
|
<DT>
|
|
<STRONG>Practice</STRONG>
|
|
<DD>
|
|
The set of disclosures regarding data usage, including purpose, recipients,
|
|
and other disclosures.
|
|
<DT>
|
|
<STRONG>Preference</STRONG>
|
|
<DD>
|
|
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 [<A href="#APPEL">APPEL</A>] preference exchange language).
|
|
<DT>
|
|
<STRONG>Purpose</STRONG>
|
|
<DD>
|
|
The reason(s) for data collection and use.
|
|
<DT>
|
|
<STRONG>Repository</STRONG>
|
|
<DD>
|
|
A mechanism for storing user information under the control of the user agent.
|
|
<DT>
|
|
<STRONG>Safe Zone</STRONG>
|
|
<DD>
|
|
Part of a Web site where the service provider performs only minimal data
|
|
collection, and any data that is collected is used only in non-identifiable
|
|
ways.
|
|
<DT>
|
|
<STRONG>Service</STRONG>
|
|
<DD>
|
|
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.
|
|
<DT>
|
|
<STRONG>Service Provider (Data Controller, Legal Entity)</STRONG>
|
|
<DD>
|
|
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.
|
|
<DT>
|
|
<A name="Statement"><STRONG>Statement</STRONG></A>
|
|
<DD>
|
|
A P3P statement is a set of privacy practice disclosures relevant to a collection
|
|
of data elements.
|
|
<DT>
|
|
<STRONG>URI</STRONG>
|
|
<DD>
|
|
A Uniform Resource Identifier used to identify Web resources. For definitive
|
|
information on <A href="#URI">URI</A> syntax and semantics, see
|
|
[<A href="#URI">URI</A>]. URIs that appear within XML or HTML have to be
|
|
treated as specified in [<A href="#CHARMODEL">CHARMODEL</A>], section
|
|
<A href="http://www.w3.org/TR/charmod/#URIs">Character Encoding in URI
|
|
References</A>. This does not apply to URIs appearing in HTTP header fields;
|
|
the URIs there should always be fully escaped.
|
|
<DT>
|
|
<STRONG>User</STRONG>
|
|
<DD>
|
|
An individual (or group of individuals acting as a single entity) on whose
|
|
behalf a service is accessed and for which personal data exists.
|
|
<DT>
|
|
<STRONG>User Agent</STRONG>
|
|
<DD>
|
|
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 <EM>any agent
|
|
must be controlled by and act on behalf of only the user</EM>. 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.
|
|
</DL>
|
|
<H1>
|
|
<A name="Referencing">2. Referencing Policies</A>
|
|
</H1>
|
|
<H2>
|
|
<A name="overview_of_prfs">2.1 Overview and Purpose of Policy References</A>
|
|
</H2>
|
|
<P>
|
|
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 page, so that they can process that
|
|
policy for the benefit of their user.
|
|
<P>
|
|
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.
|
|
<P>
|
|
A policy reference file is used to associate P3P policies with certain regions
|
|
of URI-space. The policy reference file is used to make any or all of the
|
|
following statements:
|
|
<UL>
|
|
<LI>
|
|
The URI where a P3P policy is found
|
|
<LI>
|
|
The URIs or regions of URI-space covered by this policy
|
|
<LI>
|
|
The URIs or regions of URI-space not covered by this policy
|
|
<LI>
|
|
The regions of URI-space for embedded content on other servers that are covered
|
|
by this policy
|
|
<LI>
|
|
The cookies that are or are not covered by this policy
|
|
<LI>
|
|
The access methods for which this policy is applicable
|
|
<LI>
|
|
The period of time for which these claims are considered to be valid
|
|
</UL>
|
|
<P>
|
|
All of these statements are made in the body of the policy reference file.
|
|
The last can also be made using HTTP expiration headers on the policy reference
|
|
file. See <A href="#ref_file">section 2.3</A> for examples and explanations.
|
|
<H2>
|
|
<A name="ref_syntax">2.2 Locating Policy Reference Files</A>
|
|
</H2>
|
|
<P>
|
|
This section describes the mechanisms used to indicate the location of a
|
|
policy reference file. Detailed syntax is also given for the supported
|
|
mechanisms.
|
|
<P>
|
|
The location of the policy reference file can be indicated using one of three
|
|
mechanisms. The policy reference file may be located in a predefined
|
|
<A href="#Well_Known_Location">"well-known" location</A>, or a document may
|
|
indicate a policy reference file through an HTML <CODE>LINK</CODE> tag, or
|
|
through an HTTP header. The policy reference file specifies the P3P policy
|
|
that applies to that document, and possibly to other URIs as well. The policy
|
|
reference file is an XML (see [<A href="#XML">XML</A>]) 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.
|
|
<P>
|
|
Note that if user agents support retrieving HTML content over HTTP, they
|
|
MUST handle all three mechanisms listed above interchangeably; none of the
|
|
mechanisms overrides the other. See also the requirements for
|
|
<A href="#non-ambiguity">non-ambiguity</A>.
|
|
<P>
|
|
Note that policies are applied at the level of HTTP entities. An entity,
|
|
retrieved by fetching a URI, has a P3P policy associated with it. A "page"
|
|
from the user's perspective may be composed of multiple HTTP entities; each
|
|
entity may have its own P3P policy associated with it. As a practical note,
|
|
however, placing many different P3P policies on different entities on a single
|
|
page may make rendering the page and informing the user of the relevant policies
|
|
difficult for user agents. Additionally, services SHOULD 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.
|
|
<P>
|
|
For a user agent to process the policy that applies to a given entity, it
|
|
must locate the policy reference file for that entity, fetch the policy reference
|
|
file, parse the policy reference file, fetch any required P3P policies, and
|
|
then parse the P3P policy or policies.
|
|
<P>
|
|
This document does not specify how P3P policies may be associated with documents
|
|
retrieved by means other than HTTP. However, it does not preclude future
|
|
development of mechanisms for associating P3P policies with documents retrieved
|
|
over other protocols. Furthermore, additional methods of associating P3P
|
|
policies with documents retrieved using HTTP may be developed in the future.
|
|
<H3>
|
|
<A name="Well_Known_Location">2.2.1 Well-Known Location</A>
|
|
</H3>
|
|
<P>
|
|
Web sites using P3P SHOULD place a policy reference file in a "well-known"
|
|
location. To do this, a policy reference file would be placed in the site's
|
|
<CODE>/w3c</CODE> directory, under the name <CODE>p3p.xml</CODE>. Thus a
|
|
user agent could request this policy reference file by using a
|
|
<CODE>GET</CODE> request for the resource <CODE>/w3c/p3p.xml</CODE>.
|
|
<P>
|
|
Note that sites are not required to use this mechanism; however, by using
|
|
this mechanism, sites can ensure that their P3P policy will be accessable
|
|
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.
|
|
<P>
|
|
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 <A href="#non-ambiguity">non-ambiguity
|
|
requirements</A> are met.
|
|
<P>
|
|
For example, imagine a shopping-mall Web site run by the MallExample company.
|
|
On their Web site (<CODE>mall.example.com</CODE>), companies offering goods
|
|
or services at the mall would get a company-specific subtree of the site,
|
|
perhaps in the path <CODE>/companies/<EM>company-name</EM></CODE>. The
|
|
MallExample company may choose to put a policy reference file in the well-known
|
|
location which covers all of their site except the <CODE>/companies</CODE>
|
|
subtree. Then if the ShoeStoreExample company has some content in
|
|
<CODE>/companies/shoestoreexample</CODE>, they could use one of the other
|
|
mechanisms to indicate the location of a policy reference file covering their
|
|
portion of the <CODE>mall.example.com</CODE> site.
|
|
<P>
|
|
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 <CODE>www.example.com</CODE>. Imagine that the action URI
|
|
on that form points to server <CODE>cgi.example.com</CODE>. 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 <CODE>http://cgi.example.com/w3c/p3p.xml</CODE>
|
|
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.
|
|
<H3>
|
|
<A name="syntax_ext">2.2.2 HTTP Headers</A>
|
|
</H3>
|
|
<P>
|
|
Any document retrieved by HTTP MAY point to a policy reference file through
|
|
the use of a new response header, the <CODE>P3P</CODE> header
|
|
([<A href="#P3P-HEADER">P3P-HEADER</A>]). If a site is using P3P headers,
|
|
it SHOULD include this on responses for all appropriate request methods,
|
|
including <CODE>HEAD</CODE> and <CODE>OPTIONS</CODE> requests.
|
|
<P>
|
|
The P3P header gives one or more comma-separated directives. The syntax follows:
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[1]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>p3p-header
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`P3P: ` p3p-header-field *(`,` p3p-header-field)
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[2]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>p3p-header-field
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>policy-ref-field | compact-policy-field | extension-field
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[3]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>policy-ref-field
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`policyref="` URI `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[4]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>extension-field
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>token
|
|
[`=` (token | quoted-string) ]
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" colspan="4" bgcolor="#F5DCB3" width="775">Here,
|
|
<CODE>URI</CODE> is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>], <CODE>token</CODE> and <CODE>quoted-string</CODE>
|
|
are defined by [<A href="#HTTP1_1_ref">HTTP1.1</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
In keeping with the rules for other HTTP headers, the <CODE>P3P</CODE> portion
|
|
of this header may be written in any case.
|
|
<P>
|
|
The <CODE>policyref</CODE> directive gives a URI which specifies the location
|
|
of the policy reference file which will state the P3P policy covering the
|
|
document that pointed to the reference file, and possibly others as well.
|
|
Note that fetching the URI given in the <CODE>policyref</CODE> 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 <CODE>policyref</CODE> URI
|
|
MUST NOT be used for any other purpose beyond identifying and referencing
|
|
P3P policies.
|
|
<P>
|
|
The <CODE>compact-policy-field</CODE> is used to specify "compact policies".
|
|
This is described in <A HREF="#compact_policies">Section 4</A>.
|
|
<P>
|
|
User agents which find unrecognized directives (in the
|
|
<CODE>extension-field</CODE>s) MUST ignore the unrecognized directives. This
|
|
is to allow easier deployment of future versions of P3P.
|
|
<P>
|
|
<STRONG><A name="example_header">Example 2.1:</A></STRONG>
|
|
<P>
|
|
1. Client makes a <CODE>GET</CODE> request.
|
|
<BLOCKQUOTE>
|
|
<PRE>GET /index.html HTTP/1.1
|
|
Host: catalog.example.com
|
|
Accept: */*
|
|
Accept-Language: de, en
|
|
User-Agent: WonderBrowser/5.2 (RT-11)
|
|
</PRE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
2. Server returns content and the <CODE>P3P</CODE> header pointing to the
|
|
policy of the page.
|
|
<BLOCKQUOTE>
|
|
<PRE>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
|
|
</PRE>
|
|
</BLOCKQUOTE>
|
|
<H3>
|
|
<A name="syntax_link">2.2.3 The HTML <CODE>link</CODE> Tag</A>
|
|
</H3>
|
|
<P>
|
|
Servers MAY serve HTML content with embedded <CODE>link</CODE> tags that
|
|
indicate the location of the relevant P3P policy reference file. This use
|
|
of P3P does not require any change in the server behavior.
|
|
<P>
|
|
The <CODE>link</CODE> tag encodes the information that could be expressed
|
|
using the <CODE>P3P</CODE> header. The link tag takes the following form:
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[5]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>p3p-link-tag
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`<link rel="P3Pv1" href="` URI `">`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>URI</CODE> is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
In order to illustrate with an example the use of the <CODE>link</CODE> tag,
|
|
we consider the policy reference expressed in <A href="#example_header">Example
|
|
2.1</A> using HTTP headers. That example can be equivalently expressed
|
|
using the link tag with the following piece of HTML:
|
|
<BLOCKQUOTE>
|
|
<PRE><link rel="P3Pv1"
|
|
href="http://catalog.example.com/P3P/PolicyReferences.xml">
|
|
</PRE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
Finally, note that since the <CODE>p3p-link-tag</CODE> 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
|
|
<A href="#ref_file">section 2.3 </A>and <A href="#P3P_markup">section 3</A>
|
|
below), the <CODE>p3p-link-tag</CODE> need not be encoded using
|
|
[<A href="#UTF-8">UTF-8</A>].
|
|
<H2>
|
|
<A name="ref_file">2.3 Policy Reference File Syntax and Semantics</A>
|
|
</H2>
|
|
<P>
|
|
This section explains the contents of policy reference files in detail.
|
|
<H3>
|
|
<A name="ref_file_example">2.3.1 Example Policy Reference File</A>
|
|
</H3>
|
|
<P>
|
|
Consider the case of a Web site wishing to make the following statements:
|
|
<OL>
|
|
<LI>
|
|
P3P policy <CODE>/P3P/Policy1.xml</CODE> applies to the entire site, except
|
|
the subtrees <CODE>/catalog</CODE>, <CODE>/cgi-bin</CODE>, and
|
|
<CODE>/servlet</CODE>.
|
|
<LI>
|
|
P3P policy <CODE>/P3P/Policy2.xml</CODE> applies to all documents in the
|
|
<CODE>/catalog</CODE> directory (and its subdirectories).
|
|
<LI>
|
|
P3P policy <CODE>/P3P/Policy3.xml</CODE> applies to all documents in the
|
|
<CODE>/cgi-bin</CODE> and <CODE>/servlet</CODE> directories (and their
|
|
subdirectories), except for <CODE>/servlet/unknown</CODE>.
|
|
<LI>
|
|
No statement is made about what P3P policy applies to
|
|
<CODE>/servlet/unknown</CODE>.
|
|
<LI>
|
|
These statements are valid for 2 days.
|
|
</OL>
|
|
<P>
|
|
These statements could be represented by the following piece of XML:
|
|
<P>
|
|
<STRONG><A name="example_prf">Example 2.2:</A></STRONG>
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<EXPIRY max-age="172800"/>
|
|
|
|
<POLICY-REF about="/P3P/Policy1.xml">
|
|
<INCLUDE>/*</INCLUDE>
|
|
<EXCLUDE>/catalog/*</EXCLUDE>
|
|
<EXCLUDE>/cgi-bin/*</EXCLUDE>
|
|
<EXCLUDE>/servlet/*</EXCLUDE>
|
|
</POLICY-REF>
|
|
|
|
<POLICY-REF about="/P3P/Policy2.xml">
|
|
<INCLUDE>/catalog/*</INCLUDE>
|
|
</POLICY-REF>
|
|
|
|
<POLICY-REF about="/P3P/Policy3.xml">
|
|
<INCLUDE>/cgi-bin/*</INCLUDE>
|
|
<INCLUDE>/servlet/*</INCLUDE>
|
|
<EXCLUDE>/servlet/unknown</EXCLUDE>
|
|
</POLICY-REF>
|
|
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
This example includes a relative <A href="#the_expiry_element">expiry time</A>
|
|
in the document. The expiry time could also be expressed through HTTP headers:
|
|
<OL>
|
|
<LI>
|
|
The origin server serving this page could return a <CODE>Cache-Control:
|
|
max-age=172800</CODE> header with this file, <STRONG>or</STRONG>
|
|
<LI>
|
|
The origin server could generate an <CODE>Expires</CODE> header dated 2 days
|
|
past the <CODE>Date</CODE> header in the response.
|
|
</OL>
|
|
<H3>
|
|
<A name="ref_file_syntax">2.3.2 Policy Reference File Definition</A>
|
|
</H3>
|
|
<P>
|
|
This section defines the syntax and semantics of P3P policy reference files.
|
|
All policies MUST be encoded using [<A href="#UTF-8">UTF-8</A>]. P3P servers
|
|
MUST encode their policy references using this syntax. P3P user agents MUST
|
|
be able to parse this syntax.
|
|
<P>
|
|
One significant point to make about the syntax of policy reference files
|
|
is that the syntax defined here does not have an extension mechanism. The
|
|
syntax for P3P policies has a powerful <A href="#extension">extension
|
|
mechanism</A>, but that mechanism is not supported for policy reference files.
|
|
<H4>
|
|
<A name="ref_file_processing">2.3.2.1 Policy reference file processing</A>
|
|
</H4>
|
|
<H5>
|
|
<A name="ref_file_ordering">2.3.2.1.1 Significance of order</A>
|
|
</H5>
|
|
<P>
|
|
A policy reference file may contain multiple <CODE>POLICY-REF</CODE> 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
|
|
<CODE>POLICY-REF</CODE> element in the policy reference file which applies
|
|
to that URI.
|
|
<H5>
|
|
<A name="ref_file_wildcards">2.3.2.1.2 Wildcards in policy reference files</A>
|
|
</H5>
|
|
<P>
|
|
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 asterix ("*")
|
|
is used to represent a sequence of 0 or more of any character. No other special
|
|
characters (such are those found in regular expressions) are supported. Note
|
|
that since the asterix is also a legal character in URIs
|
|
([<A href="#URI">URI</A>]), some special conventions have to be followed
|
|
when encoding such "extended URIs" in a policy reference file:
|
|
<UL>
|
|
<LI>
|
|
URIs represented in policy-ref files MUST be properly escaped, as in
|
|
[<A href="#URI">URI</A>].
|
|
<LI>
|
|
P3P user agents MUST escape any characters which should be escaped, as according
|
|
to [<A href="#URI">URI</A>], before attempting to match a URI for a policy.
|
|
<LI>
|
|
P3P user agents MUST un-escape any escaped sequences which resolve to URI-legal
|
|
characters, according to [<A href="#URI">URI</A>], before attempting to match
|
|
a URI for a policy, EXCEPT
|
|
<LI>
|
|
Literal '*'s in URIs MUST be escaped by P3P user agents before attempting
|
|
to match a URI for a policy.
|
|
<LI>
|
|
P3P user agents MUST ignore any URI pattern that do not conform to
|
|
[<A href="#URI">URI</A>]
|
|
</UL>
|
|
<P>
|
|
The wildcard character MAY be used in the <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE> elements, in the <CODE>EMBEDDED-INCLUDE</CODE> and
|
|
<CODE>EMBEDDED-EXCLUDE</CODE> elements, and in the
|
|
<CODE>COOKIE-INCLUDE</CODE> and <CODE>COOKIE-EXCLUDE</CODE> elements.
|
|
<H4>
|
|
<A name="ref_file_refs">2.3.2.2 The <CODE>META</CODE> and
|
|
<CODE>POLICY-REFERENCES</CODE> elements</A>
|
|
</H4>
|
|
<P>
|
|
The <CODE>META</CODE> element contains a complete policy reference file.
|
|
Exactly one <CODE>POLICY-REFERENCES</CODE> element MUST be in a policy reference
|
|
file. Optionally, one <CODE>POLICIES</CODE> element can follow. Additionally,
|
|
other XML markup MAY follow the <CODE>POLICY-REFERENCES</CODE> (or
|
|
<CODE>POLICIES</CODE>, if present) element, although that markup MUST be
|
|
ignored by any P3P1.0 user agent.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><POLICY-REFERENCES</CODE>></STRONG>
|
|
<DD>
|
|
This element MAY contain one or more <CODE>POLICY-REF</CODE> (policy reference)
|
|
elements. It MAY also contain one
|
|
<A href="#the_expiry_element"><CODE>EXPIRY</CODE> element</A> (indicating
|
|
their expiration time), and also some <A href="#POLICIES">in-line policies</A>.
|
|
</DL>
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" bgcolor="#F5DCB3">[6]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>prf
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`<META xmlns="http://www.w3.org/2000/12/P3Pv1">`
|
|
policyrefs
|
|
[policies]
|
|
PCDATA
|
|
"</META>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[7]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>policyrefs
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<POLICY-REFERENCES>"
|
|
[expiry]
|
|
*policyref
|
|
"</POLICY-REFERENCES>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here <CODE>PCDATA</CODE> is defined in
|
|
[<A href="#XML">XML</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H4>
|
|
<A name="ref_file_lifetime">2.3.2.3 Policy reference file lifetimes and the
|
|
<CODE>EXPIRY</CODE> element</A>
|
|
</H4>
|
|
<H5>
|
|
<A name="motivation_and_mechanism">2.3.2.3.1 Motivation and mechanism</A>
|
|
</H5>
|
|
<P>
|
|
It is desirable for servers to inform user agents 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 page. 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 <A href="#safezone">"safe zone" practices</A>
|
|
for their requests. If clients have policy reference files which they know
|
|
are still valid, then they can make more informed decisions on how to proceed.
|
|
<P>
|
|
The lifetime of a policy reference file tells user agents how long they can
|
|
rely on the claims made in the 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 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 P3P policies is to use separate policy reference files for
|
|
each policy.
|
|
<P>
|
|
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 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 <A href="#policy_updates">policy update
|
|
requirements</A> when updating their policies.
|
|
<P>
|
|
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.
|
|
<P>
|
|
As stated in section 2.3, there are two mechanisms for specifying the lifetime
|
|
of policy reference files. Two different mechanisms are provided to give
|
|
sites additional flexibility in deploying policy reference files. A policy
|
|
reference file MAY contain an <CODE>EXPIRY</CODE> element, which gives the
|
|
lifetime for the file. If there is no <CODE>EXPIRY</CODE> element in the
|
|
policy reference file, then the HTTP cache control headers associated with
|
|
the policy reference file give the lifetime of the policy reference file.
|
|
<P>
|
|
Note that while user agents are not obligated to refetch 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 <A href="#safezone">"safe zone" practices</A>.
|
|
<H5>
|
|
<A name="the_expiry_element">2.3.2.3.2 The <CODE>EXPIRY</CODE> element</A>
|
|
</H5>
|
|
<P>
|
|
The <CODE>EXPIRY</CODE> element can be used in a policy reference file and/or
|
|
in a <A href="#Policies">P3P policy</A> to state how long the policy reference
|
|
file (or <A href="#Policies">policy</A>) 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 <A href="#Policies">policy</A>) is valid. A relative expiry time gives
|
|
a number of seconds for which the policy reference file (or
|
|
<A href="#Policies">policy</A>) is valid. This expiry time is relative to
|
|
the time the response was sent from the origin server (as stated by the
|
|
<CODE>Date:</CODE> header in the response).
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[8]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>expiry
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<EXPIRY" (absdate|reldate) "/>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[9]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>absdate
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`date="` HTTP-date `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[10]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>reldate
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`max-age="` delta-seconds `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, HTTP-date is defined in section 3.3.1 of
|
|
[<A href="#HTTP1_1_ref">HTTP1.1</A>], and delta-seconds is defined in section
|
|
3.3.2 of [<A href="#HTTP1_1_ref">HTTP1.1</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H5>
|
|
<A name="use_of_http_headers">2.3.2.3.3 Use of HTTP headers</A>
|
|
</H5>
|
|
<P>
|
|
When a policy reference file contains no <CODE>EXPIRY</CODE> element, the
|
|
HTTP headers served with the policy reference file determine its lifetime.
|
|
However, user agents MUST NOT use heuristic expiration based on last-modified
|
|
to compute a lifetime for the reference file. When using the HTTP headers
|
|
to determine the lifetime of a policy reference file, user agents MUST compute
|
|
that lifetime for the policy reference file based on <CODE>Expires</CODE>,
|
|
<CODE>Cache-Control</CODE>, or <CODE>Pragma</CODE> headers served with the
|
|
file if they are available. The semantics of these headers are defined by
|
|
[<A href="#HTTP1_1_ref">HTTP</A>]. If none of these headers is available,
|
|
the lifetime MUST be set to 24 hours from the time the document was sent
|
|
from the origin server. Origin servers SHOULD use either the
|
|
<CODE>EXPIRY</CODE> element or one of the HTTP headers listed above to give
|
|
an explicit lifetime for their policy reference files.
|
|
<P>
|
|
The possible presence of caches in the network and the heuristic expiration
|
|
mechanism in HTTP considerably complicates lifetime considerations. Consider
|
|
the case of policy reference files that have no explicit cache lifetime defined
|
|
by the origin server (i.e., none of the headers listed above are included
|
|
in the response). A network cache will, in all likelihood, compute a cache
|
|
lifetime for the policy reference file based on its last-modified date; the
|
|
resulting cache lifetime could be significantly longer that 24 hours. If
|
|
a cache implements HTTP/1.0, then when a user agent then retrieves this policy
|
|
reference file, the user agent has no way to know how long the reference
|
|
file may have been in the cache. 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. HTTP/1.1 caches improve the situation somewhat, as
|
|
the HTTP protocol states that HTTP/1.1-compliant caches MUST send an
|
|
<CODE>Age</CODE> header when serving a request from their cache. However,
|
|
even this is not sufficient; the cache could return a file with an age exceeding
|
|
the 24-hour lifetime defined here, resulting in a useless policy reference
|
|
file. To avoid these problems, user agents MUST insure that they load a fresh
|
|
copy of the policy reference file when it is fetched. Thus, a user agent
|
|
MUST include either a <CODE>Pragma: no-cache</CODE> or a <CODE>Cache-Control:
|
|
no-cache</CODE> request-header when fetching a policy reference file. The
|
|
former is suggested for compatibility with HTTP/1.0 caches.
|
|
<P>
|
|
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.
|
|
<H5>
|
|
<A name="error_handling">2.3.2.3.4 Error handling for policy reference file
|
|
lifetimes</A>
|
|
</H5>
|
|
<P>
|
|
The following situations have their semantics specifically defined:
|
|
<OL>
|
|
<LI>
|
|
When a policy reference file contains an <CODE>EXPIRY</CODE> element, and
|
|
it is served with one of the HTTP headers listed in
|
|
<A href="#use_of_http_headers">the previous subsection 2.3.2.3.3</A>, the
|
|
<CODE>EXPIRY</CODE> header takes precedence for determining the lifetime
|
|
of the policy reference file.
|
|
<LI>
|
|
An absolute expiry date in the past renders the policy reference file stale.
|
|
This covers a date in an <CODE>Expires:</CODE> HTTP header as well as one
|
|
in an expires-date attribute of an <CODE>EXPIRY</CODE> element.
|
|
<LI>
|
|
An invalid or malformed expiry date, whether relative or absolute, should
|
|
be considered to be in the past. This would result in the policy reference
|
|
file being stale.
|
|
<LI>
|
|
When a policy reference file contains more than one <CODE>EXPIRY</CODE> element,
|
|
the first one takes precedence for determining the lfetime of the policy
|
|
reference file.
|
|
</OL>
|
|
<H4>
|
|
<A name="ref_file_policyref">2.3.2.4 The <CODE>POLICY-REF</CODE> element</A>
|
|
</H4>
|
|
<P>
|
|
A policy reference file may refer to multiple P3P policies, specifying
|
|
information about each. The <CODE>POLICY-REF</CODE> element describes attributes
|
|
of a single P3P policy. Elements within the <CODE>POLICY-REF</CODE> element
|
|
give the location of the policy and specify the areas of URI-space that each
|
|
policy covers.
|
|
<DL>
|
|
<DT>
|
|
<CODE>POLICY-REF</CODE>
|
|
<DD>
|
|
contains information about a single P3P policy.
|
|
<DT>
|
|
<CODE>about</CODE> <STRONG><EM>(mandatory attribute)</EM></STRONG>
|
|
<DD>
|
|
URI of the P3P policy. If this is a relative URI, it is interpreted relative
|
|
to the URI of the policy reference file. Note that this MAY be a reference
|
|
to a policy included in this policy reference file. To do this, the policy
|
|
URI is given by <CODE>#<EM>policy-name</EM></CODE>, where
|
|
<CODE><EM>policy-name</EM></CODE> is the value given on the <CODE>name</CODE>
|
|
attribute of a policy in this policy reference file.
|
|
</DL>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[11]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>policy-ref
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`<POLICY-REF about="` URI `">`
|
|
*include
|
|
*exclude
|
|
*cookie-include
|
|
*cookie-exclude
|
|
*embedded-include
|
|
*embedded-exclude
|
|
*method-element
|
|
`</POLICY-REF>`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>URI</CODE> is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H4>
|
|
<A name="ref_file_preexc">2.3.2.5 The <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE> elements</A>
|
|
</H4>
|
|
<P>
|
|
Each <CODE>INCLUDE</CODE> or <CODE>EXCLUDE</CODE> 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
|
|
<CODE>POLICY-REF</CODE> element.
|
|
<P>
|
|
When <CODE>INCLUDE</CODE> (and optionally, <CODE>EXCLUDE</CODE>) elements
|
|
are present in a <CODE>POLICY-REF</CODE> element, it means that the policy
|
|
specified in the <CODE>about</CODE> attribute of the <CODE>POLICY-REF</CODE>
|
|
element applies to all the URIs at the requested host corresponding to the
|
|
local-URI(s) matched by any of the <CODE>INCLUDE</CODE>s, but not matched
|
|
by an <CODE>EXCLUDE</CODE> element.
|
|
<P>
|
|
If a <CODE>METHOD</CODE> element (<A href="#ref_file_method">section
|
|
2.3.2.8</A>) specifies one or more methods for an enclosing policy reference,
|
|
it follows that all methods <EM>not</EM> mentioned are consequently
|
|
<EM>not</EM> 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.
|
|
<P>
|
|
It is legal, but pointless, to supply an <CODE>EXCLUDE</CODE> element without
|
|
any <CODE>INCLUDE</CODE> elements; in that case, the <CODE>EXCLUDE</CODE>
|
|
element MUST be ignored by user agents.
|
|
<P>
|
|
A policy reference file can only cover URIs on the same host as the reference
|
|
file. Therefore, the <CODE>INCLUDE</CODE> and <CODE>EXCLUDE</CODE> elements
|
|
MUST specify only local URI prefixes; they MUST NOT refer to URIs on other
|
|
hosts. This requirement does NOT apply to the location of the P3P policy
|
|
file (the <CODE>about</CODE> attribute on the <CODE>POLICY-REF</CODE> element).
|
|
<P>
|
|
Note that the set of URIs specified with <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE> does not include cookies that might be triggered when
|
|
requesting one of such URIs: in order to associate policies with cookies,
|
|
the <A HREF="#cookies"><CODE>COOKIE-INCLUDE</CODE> and
|
|
<CODE>COOKIE-EXCLUDE</CODE></A> elements are needed.
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[12]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>include
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<INCLUDE>" relativeURI "</INCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[13]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>exclude
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<EXCLUDE>" relativeURI "</EXCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>relativeURI</CODE> is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>], with the addition that the '<CODE>*</CODE>' character
|
|
is to be treated as a wildcard, as defined in
|
|
<A href="#ref_file_wildcards">section 2.3.2.1.2</A>.</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H4>
|
|
<A name="embedded_tags">2.3.2.6 The <CODE>EMBEDDED-INCLUDE</CODE> and<CODE>
|
|
EMBEDDED-EXCLUDE</CODE> elements</A>
|
|
</H4>
|
|
<P>
|
|
HTML pages often contain links to other resources that are embedded directly
|
|
in the page, such as images, sounds, layers or frames. Thus, in order to
|
|
render the page, the user agents may need to make additional requests that
|
|
might or might not be covered by the policy in effect for the page that is
|
|
currently laid out. Because embedded content could be served by a third-party
|
|
server (and <CODE>INCLUDE</CODE> and <CODE>EXCLUDE</CODE> MUST specify only
|
|
local URI prefixes) additional elements are needed to associate a policy
|
|
with that content.
|
|
<P>
|
|
Each <CODE>EMBEDDED-INCLUDE</CODE> or <CODE>EMBEDDED-EXCLUDE</CODE> element
|
|
specifies a third-party <EM>absolute URI</EM> (see [<A href="#URI">URI</A>]).
|
|
These prefixes are used to specify (similarly to <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE>) the third-party servers who are covered by the policy
|
|
specified by the <CODE>about</CODE> attribute when their content is embedded
|
|
within the documents on the Web site where the policy reference file resides.
|
|
However, the HTTP <CODE>Referer</CODE> header is used to limit the scope
|
|
of when an absolute URI should be considered "embedded":
|
|
<BLOCKQUOTE>
|
|
When <CODE>EMBEDDED-INCLUDE</CODE> (and optionally,
|
|
<CODE>EMBEDDED-EXCLUDE</CODE>) elements are present in a
|
|
<CODE>POLICY-REF</CODE> element, it means that the policy specified in the
|
|
<CODE>about</CODE> attribute of the <CODE>POLICY-REF</CODE> element applies
|
|
to all the URI(s) matched by any <CODE>EMBEDDED-INCLUDE</CODE>'s, and not
|
|
matched by an <CODE>EMBEDDED-EXCLUDE</CODE> element, <EM>when those
|
|
URIs are normally requested with a <CODE>Referer</CODE> header that contains
|
|
a URI from a resource which is covered by the policy reference file containing
|
|
the embedded URI.</EM>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
This means that the policy will be applied to objects embedded or linked
|
|
to, but not objects which are embedded in them. Proxy implementations will
|
|
be able to examine the HTTP <CODE>Referer</CODE> header generated by the
|
|
user agent, locate the policy applying to the <CODE>Referer</CODE> object,
|
|
and then determine if an embedded content policy is in effect. Such policy
|
|
association SHOULD NOT be used for content that will generate a redirect.
|
|
<P>
|
|
P3P user agents are not required to send <CODE>Referer</CODE> headers to
|
|
Web sites; indeed, depending on user preferences and safe zone issues, a
|
|
user agent may discard the <CODE>Referer</CODE> after using it to determine
|
|
whether an <CODE>EMBEDDED-INCLUDE</CODE> policy applies.
|
|
<P>
|
|
User agents MUST interpret <CODE>EMBEDDED-INCLUDE</CODE> and
|
|
<CODE>EMBEDDED-EXCLUDE</CODE> elements in a policy reference file to determine
|
|
the policy that applies to any third-party content that user agent may retrieve.
|
|
<P>
|
|
Example 2.5 states that<CODE> /P3P/Policy1.xml</CODE> applies to all documents
|
|
in the subtree <CODE>/docs/</CODE> plus the file
|
|
<CODE>/other/index.html</CODE>. In addition, that policy applies to embedded
|
|
documents requested from the <CODE>/ads/</CODE> directory -- but not the
|
|
<CODE>/network/</CODE> subdirectory -- on hosts in the
|
|
<CODE>adserver.example.com</CODE> domain.
|
|
<P>
|
|
<STRONG>Example 2.5:</STRONG>
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<POLICY-REF about="/P3P/Policy1.xml">
|
|
<INCLUDE>/docs/*</INCLUDE>
|
|
<INCLUDE>/other/index.html</INCLUDE>
|
|
<EMBEDDED-INCLUDE>http://*.adserver.example.com/ads/*</EMBEDDED-INCLUDE>
|
|
<EMBEDDED-EXCLUDE>http://*.adserver.example.com/ads/network/*</EMBEDDED-EXCLUDE>
|
|
</POLICY-REF>
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
The syntax for the <CODE>EMBEDDED-INCLUDE</CODE> and
|
|
<CODE>EMBEDDED-EXCLUDE</CODE> elements is:
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[16]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>embedded-include
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<EMBEDDED-INCLUDE>"
|
|
absoluteURI
|
|
"</EMBEDDED-INCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[17]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>embedded-exclude
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<EMBEDDED-EXCLUDE>"
|
|
absoluteURI
|
|
"</EMBEDDED-EXCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>absoluteURI</CODE> is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>], with the addition that the '*' character is to
|
|
be treated as a wildcard, as defined in <A href="#ref_file_wildcards">section
|
|
2.3.2.1.2</A></TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Note that sites MAY choose not to specify a policy for some or all of their
|
|
embedded content. In those cases P3P user agents SHOULD attempt to obtain
|
|
a P3P policy directly from the site hosting the embedded content.
|
|
<P>
|
|
Also note that, just like in the case of <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE>, the set of URIs specified with
|
|
<CODE>EMBEDDED-INCLUDE</CODE> and <CODE>EMBEDDED-EXCLUDE</CODE> does not
|
|
include cookies that might be triggered when requesting one of such URIs:
|
|
in order to associate policies with cookies, the <CODE>COOKIE-INCLUDE</CODE>
|
|
and <CODE>COOKIE-EXCLUDE</CODE> elements are needed.
|
|
<H4>
|
|
<A NAME="cookies">2.3.2.7 The <CODE>COOKIE-INCLUDE</CODE> and
|
|
<CODE>COOKIE-EXCLUDE</CODE> elements</A>
|
|
</H4>
|
|
<P>
|
|
The <CODE>COOKIE-INCLUDE</CODE> and <CODE>COOKIE-EXCLUDE</CODE> elements
|
|
are used to associate policies to cookies.
|
|
<P>
|
|
A cookie policy MUST cover any data (within the scope of P3P) that is stored
|
|
in that cookie or linked via that cookie. It MUST also reference all purposes
|
|
associated with data stored in that cookie or enabled by that cookie. In
|
|
addition, any data/purpose stored or linked via a cookie MUST also be put
|
|
in the cookie policy. In addition, if that linked data is collected by HTTP,
|
|
then the policy that covers that
|
|
<CODE>GET</CODE>/<CODE>POST</CODE>/whatever request must cover that data
|
|
collection. For example, when CatalogExample asks customers to fill out a
|
|
form with their name, billing, and shipping information, the P3P policy that
|
|
covers the form submittal will disclose that CatalogExample collects this
|
|
data and explain how it is used. If CatalogExample sets a cookie so that
|
|
it can identify its customers and observe their behavior on its web site,
|
|
it would have a separate policy for this cookie. However, if this cookie
|
|
is also linked to the user's name, billing, and shipping information -- perhaps
|
|
so CatalogExample can generate custom catalog pages based on where the customer
|
|
lives -- then that data must also be disclosed in the cookie policy.
|
|
<P>
|
|
For the purpose of this specification, state management mechanisms use either
|
|
<CODE>SET-COOKIE</CODE> or <CODE>SET-COOKIE2</CODE> headers, and cookie-namespace
|
|
is defined as the value of the NAME, Domain and Path attributes, specified
|
|
in [<A HREF="#ref_COOKIES">COOKIES</A>] and [<A HREF="#ref_STATE">STATE</A>].
|
|
<P>
|
|
Each <CODE>COOKIE-INCLUDE</CODE> or <CODE>COOKIE-EXCLUDE</CODE> element specifies
|
|
a cookie-namespace, consisting of three tokens separated by white spaces.
|
|
These three tokens are used to match (similarly to <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE>) the NAME, Domain and Path components of a cookie,
|
|
expressing the cookie-namespaces which are covered by the policy specified
|
|
by the <CODE>about</CODE> attribute when the cookies are set from the documents
|
|
on the Web site where the policy reference file resides.
|
|
<P>
|
|
When <CODE>COOKIE-INCLUDE</CODE> (and optionally,
|
|
<CODE>COOKIE-EXCLUDE</CODE>) elements are present in a
|
|
<CODE>POLICY-REF</CODE> element, the policy specified in the
|
|
<CODE>about</CODE> attribute of the <CODE>POLICY-REF</CODE> element applies
|
|
to every cookie whose cookie-namespace is matched by any
|
|
<CODE>COOKIE-INCLUDE</CODE>'s, and not matched by a
|
|
<CODE>COOKIE-EXCLUDE</CODE> element.
|
|
<P>
|
|
A site cannot declare policies for cookies unless the cookies are on its
|
|
own site, or they are set from elements that are embedded (in the sense of
|
|
<A HREF="#embedded_tags">Section 2.3.2.6</A>) on its own site. User agents
|
|
MUST accordingly interpret <CODE>COOKIE-INCLUDE</CODE> and
|
|
<CODE>COOKIE-EXCLUDE</CODE> elements in a policy reference file to determine
|
|
the policy that applies to cookies. Note that <CODE>COOKIE-INCLUDE</CODE>
|
|
and <CODE>COOKIE-EXCLUDE</CODE> are the only mechanisms for associating policies
|
|
with cookies in policy reference files (see <A HREF="#compact_policies">Section
|
|
4</A>).
|
|
<P>
|
|
The policy which applies to a cookie applies until the policy expires. If
|
|
the policy associated with a cookie has expired, or if the user agent preferences
|
|
are changed, then the user agent SHOULD reevaluate the cookie policy before
|
|
sending the cookie.
|
|
<P>
|
|
Example 2.3 states that <CODE>/P3P/Policy1.xml</CODE> applies to all cookies.
|
|
<P>
|
|
<STRONG>Example 2.3:</STRONG>
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<POLICY-REF about="/P3P/Policy1.xml">
|
|
<COOKIE-INCLUDE>* * *</COOKIE-INCLUDE>
|
|
</POLICY-REF>
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
Example 2.4 states that <CODE>/P3P/Policy1.xml</CODE> applies to all cookies,
|
|
except cookies with the cookie name value of
|
|
"<CODE>obnoxious-cookie</CODE>", a domain value of
|
|
"<CODE>.example.com</CODE>", and a path value of "<CODE>/</CODE>", and that
|
|
<CODE>/P3P/Policy2.xml</CODE> applies to all cookies with the cookie name
|
|
of "<CODE>obnoxious-cookie</CODE>", a domain value of
|
|
"<CODE>.example.com</CODE>", and a path value of "<CODE>/</CODE>".
|
|
<P>
|
|
<STRONG>Example 2.4:</STRONG>
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<POLICY-REF about="/P3P/Policy1.xml">
|
|
<COOKIE-INCLUDE>* * *</COOKIE-INCLUDE>
|
|
<COOKIE-EXCLUDE>obnoxious-cookie .example.com /</COOKIE-EXCLUDE>
|
|
</POLICY-REF>
|
|
<POLICY-REF about="/P3P/Policy2.xml">
|
|
<COOKIE-INCLUDE>obnoxious-cookie .example.com /<COOKIE-INCLUDE>
|
|
</POLICY-REF>
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[14]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>cookie-include
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<COOKIE-INCLUDE>"
|
|
token ; matches the cookie's NAME
|
|
" "
|
|
token ; matches the cookie's Domain
|
|
" "
|
|
token ; matches the cookie's Path
|
|
"</COOKIE-INCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[15]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>cookie-exclude
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"<COOKIE-EXCLUDE>"
|
|
token ; matches the cookie's NAME
|
|
" "
|
|
token ; matches the cookie's Domain
|
|
" "
|
|
token ; matches the cookie's Path
|
|
"</COOKIE-EXCLUDE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>token</CODE>, <CODE>NAME</CODE>,
|
|
<CODE>Domain</CODE> and <CODE>Path</CODE> are defined as per
|
|
<A HREF="http://www.ietf.org/rfc/rfc2965.txt">RFC 2965</A>
|
|
[<A HREF="#ref_STATE">STATE</A>], with the addition that the '<CODE>*</CODE>'
|
|
character in <CODE>token</CODE>'s is to be treated as a wildcard, as defined
|
|
in <A HREF="#ref_file_wildcards">section 2.3.2.1.2</A>.</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Note that, conforming to [<A HREF="#ref_STATE">STATE</A>], if an explicitly
|
|
specified <CODE>Domain</CODE> value does not start with a full stop
|
|
("<CODE>.</CODE>"), the user agent MUST prepend a full stop for it. Also,
|
|
note that every <CODE>Path</CODE> begins with the "<CODE>/</CODE>" symbol.
|
|
<H4>
|
|
<A name="ref_file_method">2.3.2.8 The <CODE>METHOD</CODE> element</A>
|
|
</H4>
|
|
<P>
|
|
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 <CODE>PUT</CODE> or <CODE>DELETE</CODE> methods than when performing
|
|
<CODE>GET</CODE> methods.
|
|
<P>
|
|
The <CODE>METHOD</CODE> 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 <CODE>METHOD</CODE> element
|
|
may be repeated to indicate multiple applicable methods. If the
|
|
<CODE>METHOD</CODE> element is not present in a <CODE>POLICY-REF</CODE> element,
|
|
then that <CODE>POLICY-REF</CODE> element covers the resources indicated
|
|
regardless of the method used to access them.
|
|
<P>
|
|
So, to state that <CODE>/P3P/Policy1.xml</CODE> applies to all documents
|
|
in the subtree <CODE>/docs/</CODE> for <CODE>GET</CODE> and <CODE>HEAD</CODE>
|
|
methods, while <CODE>/P3P/Policy2.xml</CODE> applies for <CODE>PUT</CODE>
|
|
and <CODE>DELETE</CODE> methods, the following policy reference would be
|
|
written:
|
|
<P>
|
|
<STRONG>Example 2.6:</STRONG>
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<POLICY-REF about="/P3P/Policy1.xml">
|
|
<INCLUDE>/docs/*</INCLUDE>
|
|
<METHOD>GET</METHOD>
|
|
<METHOD>HEAD</METHOD>
|
|
</POLICY-REF>
|
|
<POLICY-REF about="/P3P/Policy2.xml">
|
|
<INCLUDE>/docs/*</INCLUDE>
|
|
<METHOD>PUT</METHOD>
|
|
<METHOD>DELETE</METHOD>
|
|
</POLICY-REF>
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
Note that HTTP requires the same behavior for <CODE>GET</CODE> and
|
|
<CODE>HEAD</CODE> requests, thus it is inappropriate to specify different
|
|
P3P policies for these methods. The syntax for the <CODE>METHOD</CODE> element
|
|
is:
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[18]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>method-element
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`<METHOD>` Method `</METHOD>`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4">Here, <CODE>Method</CODE> is defined in the section 5.1.1
|
|
of [<A href="#HTTP1_1_ref">HTTP1.1</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A NAME="active_content">2.3.3 Applying a Policy to a URI</A>
|
|
</H3>
|
|
<P>
|
|
A policy reference file specifies the policy which applies to a given URI.
|
|
The meaning of this is that the indicated policy describes all effects of
|
|
performing any of the methods listed in the policy reference file against
|
|
the given URI.
|
|
<P>
|
|
There is a general rule which describes what it means for a P3P policy to
|
|
cover a URI: <I>the referenced policy MUST cover actions that the user's
|
|
client software is expected to perform as a result of requesting that URI</I>.
|
|
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 <CODE>GET</CODE> requests, then the policy given by
|
|
the policy reference file MUST describe all data collection performed by
|
|
the site when that URI is fetched. Likewise, if a URI is covered for
|
|
<CODE>POST</CODE> 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.
|
|
<P>
|
|
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.
|
|
<P>
|
|
Some specific examples:
|
|
<OL>
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
A response is an installable image 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.
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
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.
|
|
</OL>
|
|
<H3>
|
|
2.3.4 <A name="forms">Forms and Related Mechanisms</A>
|
|
</H3>
|
|
<P>
|
|
Forms deserve special consideration, as they often link to CGI scripts or
|
|
other server-side applications in their action URIs. It is often the case
|
|
that those action URIs are covered by a different policy than the form itself.
|
|
<P>
|
|
If a user agent is unable to find a matching prefix for a given <EM>action
|
|
URI</EM> in the policy reference file that was referenced from the page,
|
|
it SHOULD assume that <EM>no</EM> policy is in effect. Under these circumstances,
|
|
user agents SHOULD check the <A href="#Well_Known_Location">well-known
|
|
location</A> on the host of the action URI to attempt to find a policy reference
|
|
file that covers the action URI. If this does not provide a P3P policy to
|
|
cover the action URI, then a user agent MAY try to issue a <CODE>HEAD</CODE>
|
|
request to an action URI before actually submitting any data in order to
|
|
find the policy in effect. Services SHOULD ensure that server-side applications
|
|
can properly respond to such <CODE>HEAD</CODE> requests and return the
|
|
corresponding policy reference link in the headers. In case the underlying
|
|
application does not understand the <CODE>HEAD</CODE> request and <EM>no</EM>
|
|
policy has been predeclared for the action URI in question, user agents MUST
|
|
assume that <EM>no</EM> policy is in effect and SHOULD inform the user about
|
|
this or take the corresponding actions according to the user's preferences.
|
|
<P>
|
|
Note that services might want to make use of the
|
|
<CODE><METHOD></CODE> element in order to declare policies for server-side
|
|
applications that only cover a subset of supported methods, e.g., POST or
|
|
GET. Under such circumstances, it is acceptable that the application in question
|
|
only supports the methods given in the policy reference file (i.e.,
|
|
<CODE>HEAD</CODE> requests need not be supported). User agents SHOULD NOT
|
|
attempt to issue a <CODE>HEAD</CODE> request to an action URI if the relevant
|
|
methods specified in the form's <CODE>method</CODE> attribute have been properly
|
|
predeclared in the page's policy reference file.
|
|
<P>
|
|
In some cases, <EM>different</EM> data is collected at the <EM>same</EM>
|
|
action URI depending on some selection in the form. For example, a search
|
|
service might offer to both search for people (by name and/or email) and
|
|
(arbitrary) images. Using a set of radio buttons on the form, a single
|
|
server-side application located at one and the same action URI handles both
|
|
cases and collects the required information necessary for the search. If
|
|
a service wants to predeclare the data collection practices of the server-side
|
|
application it MAY declare <EM>all</EM> of the data collection practices
|
|
in a <EM>single</EM> policy file (using a <CODE><INCLUDE></CODE>
|
|
declaration matching the action URI). In this case, user agents MUST assume
|
|
that all data elements are collected under every circumstance. This solution
|
|
offers the convenience of a single policy but might not properly reflect
|
|
the fact that only parts of the listed data elements are collected at a time.
|
|
Services SHOULD make sure that a simple HEAD request to the action URI (i.e.,
|
|
without any arguments, especially without the value of the selected radio
|
|
button) will return a policy that covers all cases.
|
|
<P>
|
|
Note that if a form is handled through use of the GET method, then the action
|
|
URI reflects the choice of form elements selected by the user. In some cases,
|
|
it will be possible to make use of the wildcard syntax allowed in policy
|
|
reference files to specify different policies for different uses of the same
|
|
form action-handler URI. Therefore, user agents MUST include the query-string
|
|
portion of URIs when making comparisons with <CODE>INCLUDE</CODE> and
|
|
<CODE>EXCLUDE</CODE> elements in policy reference files.
|
|
<H2>
|
|
<A name="additional_requirements">2.4 Additional Requirements</A>
|
|
</H2>
|
|
<H3>
|
|
<A name="non-ambiguity">2.4.1 Non-ambiguity</A>
|
|
</H3>
|
|
<P>
|
|
A very important rule of policy references is that of non-ambiguity: For
|
|
each resource at a Web site there MUST be <EM>at most one</EM> policy active
|
|
at any given time. Thus two non-expired policy reference files on a given
|
|
site MUST NOT declare two or more different policy URIs for the same resource.
|
|
<P>
|
|
If a policy reference file at the <A href="#Well_Known_Location">well-known
|
|
location</A> declares a non-expired policy for a given URI, <EM>this policy
|
|
applies</EM>, regardless of any conflicting policy reference files referenced
|
|
through HTTP headers or HTML <CODE>link</CODE> tags.
|
|
<H3>
|
|
<A name="multiple">2.4.2 Multiple Languages</A>
|
|
</H3>
|
|
<P>
|
|
Multiple language versions (translations) of the same policy can be offered
|
|
by the server using the HTTP "<CODE>Content-Language</CODE>" header to properly
|
|
indicate that a particular language has been used for the policy. This is
|
|
useful so that human-readable fields such as entity and consequence can be
|
|
presented in multiple languages. The same mechanism can also be used to offer
|
|
multiple language versions for data schemas.
|
|
<P>
|
|
Whenever <CODE>Content-Language</CODE> is used to distinguish policies at
|
|
the same URI that are offered in multiple languages, the policies MUST have
|
|
the same meaning in each language. Two policies (or two data schemas) are
|
|
taken to be identical if
|
|
<UL>
|
|
<LI>
|
|
All formal (not natural language) protocol elements are semantically identical
|
|
(i.e., attribute order does not matter, the presence or absence of a default
|
|
value does not matter, but attribute values matter)
|
|
<LI>
|
|
All natural language protocol elements correspond one-to-one, and for each
|
|
correspondence, one is a careful translation of the other.
|
|
</UL>
|
|
<P>
|
|
Due to the use of the <CODE>Accept-Language</CODE> mechanism, implementors
|
|
should take note that user agents may see different language versions of
|
|
a policy or policy reference file despite sending the same
|
|
<CODE>Accept-Language</CODE> request header if a new language version of
|
|
a policy or data schema has been added.
|
|
<H3>
|
|
<A name="safezone">2.4.3 The "Safe Zone"</A>
|
|
</H3>
|
|
<P>
|
|
Every P3P-enabled user agent and service SHOULD ensure that all the relevant
|
|
communications that take place as part of fetching a P3P policy are part
|
|
of a special "safe zone" in which minimal data collection takes place and
|
|
any data that is collected is used only in non-identifiable ways. In particular,
|
|
requests to the <A href="#Well_Known_Location">well-known location</A> for
|
|
policy reference files SHOULD be covered by these "safe zone" practices.
|
|
<P>
|
|
To support this safe zone, P3P user agents SHOULD suppress the transmission
|
|
of data unnecessary for the purpose of finding a site's policy until the
|
|
policy has been fetched. Thus user agents SHOULD NOT send the HTTP
|
|
<CODE>Referer</CODE> header or accept cookies while requesting a P3P policy.
|
|
User agents MAY also wish to refrain from sending user agent information
|
|
or cookies accepted in a previous session while requesting a P3P policy.
|
|
User agent implementors need to be aware that there is a privacy trade-off
|
|
with using the <CODE>Accept-Language</CODE> HTTP header when requesting a
|
|
P3P policy. Sending the correct <CODE>Accept-Language</CODE> header will
|
|
allow fetching the P3P policy in the user's preferred natural language (if
|
|
available), but does expose a certain amount of information about the identity
|
|
of the user. User agents MAY wish to allow users to decide when these headers
|
|
should be sent.
|
|
<P>
|
|
Servers SHOULD NOT require the receipt of an HTTP <CODE>Referer</CODE> header,
|
|
cookies, user agent information, or other information unnecessary for responding
|
|
to the request in order to serve a policy file or policy reference file.
|
|
In addition, servers SHOULD NOT use in an identifiable way any information
|
|
collected while serving a policy file/policy reference file or responding
|
|
to a <CODE>HEAD</CODE> request.
|
|
<P>
|
|
Servers MAY return a <CODE>P3P</CODE> header in the response headers when
|
|
a P3P policy is requested. However, it is important to note that the
|
|
<CODE>P3P</CODE> header MUST be ignored, and that the "safe zone" requirements
|
|
described in this section apply instead. Returning a <CODE>P3P</CODE> header
|
|
in such cases is permitted in consideration of the fact that administrators
|
|
may find it easier to apply a P3P policy to all documents on a server, and
|
|
that requiring policies to be served without a <CODE>P3P</CODE> header may
|
|
result in extra work for site administrators.
|
|
<P>
|
|
Note that the safe zone requirements do not say that sites cannot keep
|
|
identifiable information -- only that they SHOULD NOT use in an identifiable
|
|
way any information collected while serving a policy file. Tracking down
|
|
the source of a denial of service attack, for example, would be a legitimate
|
|
reason to use this information and ignore this recommendation.
|
|
<H3>
|
|
<A name="discrimination">2.4.4 Non-Discrimination of Policies</A>
|
|
</H3>
|
|
<P>
|
|
Servers SHOULD make every effort to help user agents find P3P policies. In
|
|
particular, servers SHOULD place a policy reference file at the
|
|
<A href="#Well_Known_Location">well-known location</A> whenever possible.
|
|
When the <CODE>P3P</CODE> HTTP header is used as an alternative, servers
|
|
SHOULD:
|
|
<DL>
|
|
<DT>
|
|
<STRONG>Reference a policy in response to any request</STRONG>:
|
|
<DD>
|
|
P3P-compliant sites SHOULD include a link to a policy reference file for
|
|
a Webresource whenever possible.
|
|
<DT>
|
|
<STRONG>Support HTTP
|
|
</STRONG><STRONG><CODE>HEAD</CODE></STRONG><STRONG> requests</STRONG>
|
|
<DD>
|
|
P3P-compliant servers SHOULD support <CODE>HEAD</CODE> requests for any documents
|
|
that can be retrieved with <CODE>GET</CODE> requests. Whenever technically
|
|
feasible, servers should give a valid response to a <CODE>HEAD</CODE> request
|
|
for documents that are normally accessed by other HTTP methods as well (such
|
|
as <CODE>POST</CODE>).
|
|
</DL>
|
|
<H3>
|
|
<A name="security">2.4.5 Security of Policy Transport</A>
|
|
</H3>
|
|
<P>
|
|
P3P policies and references to P3P policies SHOULD NOT, in themselves, contain
|
|
any sensitive information. This means that there are no additional security
|
|
requirements for transporting a reference to a P3P policy beyond the requirements
|
|
of the document it is associated with; so, if an HTML document would normally
|
|
be served over a non-encrypted session, then the P3P protocol would
|
|
<STRONG>not</STRONG> require nor recommend that the document be served over
|
|
an encrypted session when a reference to a P3P policy is included with that
|
|
document.
|
|
<H3>
|
|
<A name="policy_updates">2.4.6 Policy Updates</A>
|
|
</H3>
|
|
<P>
|
|
Note that when a Web site changes its P3P policy, the old policy applies
|
|
to data collected when it was in effect. It is the responsibility of the
|
|
site to keep records of past P3P policies and policy reference files along
|
|
with the dates when they were in effect, and to apply these policies
|
|
appropriately.
|
|
<P>
|
|
If a site wishes to apply a new P3P policy to previously collected data,
|
|
it MUST provide appropriate notice and opportunities for users to accept
|
|
the new policy that are consistent with applicable laws, industry guidelines,
|
|
or other privacy-related agreements the site has made.
|
|
<H2>
|
|
<A name="example_scenarios">2.5 Example Scenarios</A>
|
|
</H2>
|
|
<P>
|
|
As an aid to sites deploying P3P, several example scenarios are presented,
|
|
along with descriptions of how P3P is used on those sites.
|
|
<P>
|
|
<STRONG>Scenario 1</STRONG>: Web site basic.example.com uses a variety of
|
|
images, all of which it hosts. It also includes some forms, which are all
|
|
submitted directly to the site. This site can declare a single P3P policy
|
|
for the entire site (or if different privacy policies apply to different
|
|
parts of the site, it can declare multiple P3P policies). As long as all
|
|
of the images and form action URIs are in directories covered by the site's
|
|
P3P policy, user agents will automatically recognize the images and forms
|
|
as covered by the site's policy.
|
|
<P>
|
|
<STRONG>Scenario 2</STRONG>: Web site busy.example.com uses a content
|
|
distribution network called cdn.example.com to host its images so as to reduce
|
|
the load on its servers. Thus, all of the images on the site have URIs at
|
|
cdn.example.com. CDN acts as an agent to Busy in this situation, and collects
|
|
no data other than log data. This log data is used only for Web site and
|
|
system administration in support of providing the services that Busy contracted
|
|
for. Busy's privacy policy applies to the images hosted by CDN, so Busy uses
|
|
the <CODE>EMBEDDED-INCLUDE</CODE> element in its policy reference file to
|
|
indicate that its P3P policy applies to embedded content served by
|
|
cdn.example.com. Optionally, cdn.example.com might also have a policy reference
|
|
file that declares that the busy.example.com privacy policy applies to these
|
|
images.
|
|
<P>
|
|
<STRONG>Scenario 3</STRONG>: Web site busy.example.com also has a contract
|
|
with an advertising company called clickads.example.com to provide banner
|
|
ads on its site. The contract allows Clickads to set cookies so as to make
|
|
sure each user doesn't see a given ad more than three times. Clickads collects
|
|
statistics on how many users view each ad and reports them to the companies
|
|
whose products are being advertised. But these reports do not reveal information
|
|
about any individual users. As was the case in Scenario 2, Busy's privacy
|
|
policies applies to these ads hosted by Clickads, so Busy uses the
|
|
<CODE>EMBEDDED-INCLUDE</CODE> element in its policy reference file to indicate
|
|
that its P3P policy applies to embedded content served by clickads.example.com.
|
|
Optionally, clickads.example.com might also have a policy reference file
|
|
that declares that the busy.example.com privacy policy applies to these ads.
|
|
The companies whose products are being advertised need not be mentioned in
|
|
the Busy privacy policy because the only data they are receiving is aggregate
|
|
data.
|
|
<P>
|
|
<STRONG>Scenario 4</STRONG>: Web site busy.example.com also has a contract
|
|
with funchat.example.com to host a chat room for its users. When users enter
|
|
the chat room they are actually leaving the Busy site. However, the chat
|
|
room has the Busy logo and is actually covered by the Busy privacy policy.
|
|
In this instance Funchat is acting as an agent for Busy, but -- unlike the
|
|
previous examples -- their content is not embedded in the Busy site. In this
|
|
case, there is no way for Busy to include Funchat in its policy reference
|
|
file. However, Busy should direct Funchat to place a policy reference file
|
|
on its site that points to the Busy P3P policy.
|
|
<P>
|
|
<STRONG>Scenario 5</STRONG>: Web site bigsearch.example.com has a form that
|
|
allows users to type in a search query and have it performed on their choice
|
|
of search engines located on other sites. When a user clicks the "submit"
|
|
button, the search query is actually submitted directly to these search engines
|
|
-- the action URI is not on bigsearch.example.com but rather on the search
|
|
engine selected by the user. Bigsearch cannot declare the privacy policies
|
|
for these search engines because form actions are not embedded content. So
|
|
when a user clicks the "submit" button, their user agent should go to the
|
|
appropriate search engine and check its privacy policy before posting any
|
|
data. In order to make this search choice mechanism work, Bigsearch might
|
|
actually have a form with an action URI on its own site, which redirects
|
|
to the appropriate search engine. In this case, the user agent should check
|
|
the search engine privacy policy upon receiving the redirect response.
|
|
<P>
|
|
<STRONG>Scenario 6</STRONG>: Web site bigsearch.example.com also has a form
|
|
that allows users to type in a search query and have it simultaneously performed
|
|
on ten different search engines. Bigsearch submits the queries, gets back
|
|
the results from each search engine, removes the duplicates, and presents
|
|
the results to the user. In this case, the user interacts only with Bigsearch.
|
|
Thus, the only P3P policy involved is the one that covers the Bigsearch Web
|
|
site. However, Bigsearch must disclose that it shares the users' search queries
|
|
with third parties (the search Web sites), unless Bigsearch has a contract
|
|
with these search engines and they act as agents to Bigsearch.
|
|
<P>
|
|
<STRONG>Scenario 7</STRONG>: Web site bigsearch.example.com also has banner
|
|
advertisements provided by a company called adnetwork.example.com. Adnetwork
|
|
uses cookies to develop profiles of users across many different Web sites
|
|
so that it can provide them with ads better suited to their interests. Because
|
|
the data about the sites that users are visiting is being used for purposes
|
|
other than just serving ads on the Bigsearch Web site, Adnetwork cannot be
|
|
considered an agent in this context. Adnetwork must create its own P3P policy
|
|
and use its own policy reference file to indicate what content it applies
|
|
to. In addition, Bigsearch may optionally use the
|
|
<CODE>EMBEDDED-INCLUDE</CODE> element in its policy reference file to indicate
|
|
that the Adnetwork P3P policy applies to these advertisements. Bigsearch
|
|
should only do this if Adnetwork has told it what P3P policy applies to these
|
|
advertisements and has agreed to notify Bigsearch if the policy reference
|
|
needs to be changed.
|
|
<P>
|
|
<STRONG>Scenario 8:</STRONG> Web site busy.example.com uses cookies throughout
|
|
its web site. It discloses a cookie policy, separate from its regular P3P
|
|
policy to cover these cookies. It uses the <CODE>COOKIE-INCLUDE</CODE> element
|
|
in its policy reference file to declare the appropriate policy for these
|
|
cookies. As a performance optimization, it also makes available a compact
|
|
policy by sending a P3P header that includes this compact policy whenever
|
|
it sets a cookie.
|
|
<P>
|
|
<STRONG>Scenario 9:</STRONG> Web site config.example.com provides a service
|
|
in which they optimize various kinds of web content based on each user's
|
|
computer and Internet configuration. Users go to the Config web site and
|
|
answer questions about their computer, monitor, and Internet connection.
|
|
Config encodes the responses and stores them in a cookie. Later, when the
|
|
user is visiting Busy -- a web site that has contracted with Config
|
|
-- whenever the browser requests content that can be optimized (certain images,
|
|
audio files, etc.), Busy will redirect the user to Config, which will read
|
|
the user's cookie, and deliver the appropriate content. In this case, Config
|
|
should declare a privacy policy that describes the kinds of data collected
|
|
and stored in its cookies, and how that data is used. It should use a
|
|
<CODE>COOKIE-INCLUDE</CODE> element in its policy reference file to
|
|
declare the policy for the cookies. It will probably reference Busy's P3P
|
|
policy for the actual images or audio files delivered, as it is acting much
|
|
like CDN acts in scenario 2. Busy will probably also use
|
|
<CODE>EMBEDDED-INCLUDE</CODE> elements in its policy reference file to reference
|
|
the policy for the Config-delivered content.
|
|
<H1>
|
|
<A name="P3P_markup">3. Policy Syntax and Semantics</A>
|
|
</H1>
|
|
<P>
|
|
P3P policies are encoded in XML. They may also be represented using the RDF
|
|
data model ([<A href="#RDF">RDF</A>]); however, an RDF representation is
|
|
not included in this specification. (Such a representation is planned to
|
|
be made available as a W3C Note prior to submitting P3P as a Proposed
|
|
Recommendation, together with a suitable RDF encoding of the policy reference
|
|
file).
|
|
<P>
|
|
Section 3.1 begins with an example of an English language privacy policy
|
|
and a corresponding P3P policy. P3P policies include general assertions that
|
|
apply to the entire policy as well as specific assertions -- called
|
|
<EM>statements</EM> -- that apply only to the handling of particular types
|
|
of data referred to by <EM>data references</EM>. Section 3.2 describes the
|
|
<CODE>POLICY</CODE> element and policy-level assertions. Section 3.3 describes
|
|
statements and data references.
|
|
<H2>
|
|
<A name="Example_policy">3.1 Example policies</A>
|
|
</H2>
|
|
<H3>
|
|
<A name="English">3.1.1 English language policies</A>
|
|
</H3>
|
|
<P>
|
|
The following are two examples of English-language privacy policy to be encoded
|
|
as a P3P policy. Both policies are for one example company, CatalogExample,
|
|
which has different policies for those browsing their site and those actually
|
|
purchasing products. Example 3.1. is provided in both English and as a more
|
|
formal description using P3P element and attribute names.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG>Example 3.1: CatalogExample's Privacy Policy for Browsers</STRONG>
|
|
<DD>
|
|
At CatalogExample, we care about your privacy. When you come to our site
|
|
to look for an item, we will only use this information to improve our site
|
|
and will not store it in an identifiable way.<BR>
|
|
<BR>
|
|
CatalogExample, Inc. is a licensee of the PrivacySealExample Program. The
|
|
PrivacySealExample Program ensures your privacy by holding Web site licensees
|
|
to high privacy standards and confirming with independent auditors that these
|
|
information practices are being followed.<BR>
|
|
<BR>
|
|
Questions regarding this statement should be directed to:<BR>
|
|
<CODE>CatalogExample<BR>
|
|
4000 Lincoln Ave.<BR>
|
|
Birmingham, MI 48009 USA<BR>
|
|
email: catalog@example.com<BR>
|
|
Telephone 248-EXAMPLE (248-392-6753)</CODE><BR>
|
|
<BR>
|
|
If we have not responded to your inquiry or your inquiry has not been
|
|
satisfactorily addressed, you can contact PrivacySealExample at
|
|
http://www.privacyseal.example.org. CatalogExample will correct all errors
|
|
or wrongful actions arising in connection with the privacy policy.<BR>
|
|
<BR>
|
|
<EM>What We Collect and Why:</EM><BR>
|
|
When you browse through our site we collect:
|
|
<UL>
|
|
<LI>
|
|
the basic information about your computer and connection to make sure that
|
|
we can get you the proper information and for security purposes.
|
|
<LI>
|
|
aggregate information on what pages consumers access or visit to improve
|
|
our site.
|
|
</UL>
|
|
<P>
|
|
<BR>
|
|
<EM>Data retention:</EM><BR>
|
|
We purge every two weeks the browsing information that we collect.
|
|
</DL>
|
|
<P>
|
|
Here is Example 3.1 in a more formal description, using the P3P element and
|
|
attribute names [with the section of the spec that was used cited in brackets
|
|
for easy reference]:
|
|
<UL>
|
|
<LI>
|
|
Disclosure URI: http://www.catalog.example.com/PrivacyPracticeBrowsing.html<BR>
|
|
[<A href="#POLICY">3.2.2 Policy</A>]
|
|
<LI>
|
|
Entity: CatalogExample<BR>
|
|
4000 Lincoln Ave. <BR>
|
|
Birmingham, MI 48009 <BR>
|
|
USA<BR>
|
|
catalog@example.com <BR>
|
|
+1 (248) 392-6753<BR>
|
|
[<A href="#ENTITY">3.2.4 Entity</A>]
|
|
<LI>
|
|
Access to Identifiable Information: None<BR>
|
|
[<A href="#ACCESS">3.2.5 Access</A>]
|
|
<LI>
|
|
Disputes:<BR>
|
|
resolution type: independent<BR>
|
|
service: http://www.privacyseal.example.org<BR>
|
|
description: PrivacySealExample<BR>
|
|
[<A href="#DISPUTES">3.2.6 Disputes</A>]
|
|
<LI>
|
|
Remedies: we'll correct any harm done wrong<BR>
|
|
[<A href="#REMEDIES">3.2.7 Remedies</A>]
|
|
<LI>
|
|
We collect:<BR>
|
|
dynamic.clickstream<BR>
|
|
dynamic.http<BR>
|
|
[<A href="#Base_Data_Schema">4.5 Base Data Schema</A>]
|
|
<LI>
|
|
For purpose: Web site and system administration, research and development<BR>
|
|
[<A href="#PURPOSE">3.3.4 Purpose</A>]
|
|
<LI>
|
|
Recipients: Only ourselves and our agents<BR>
|
|
[<A href="#RECPNT">3.3.5 Recipients</A>]
|
|
<LI>
|
|
Retention: As long as appropriate for the stated purposes <BR>
|
|
[<A href="#RETENTION">3.3.6 Retention</A>]<BR>
|
|
(Note also that the site's human-readable privacy policy MUST mention that
|
|
data is purged every two weeks, or provide a link to this information.)
|
|
</UL>
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG>Example 3.2: CatalogExample's Privacy Policy for Shoppers</STRONG>
|
|
<DD>
|
|
At CatalogExample, we care about your privacy. We will never share your credit
|
|
card number or any other financial information with any third party. With
|
|
your permission only, we will share information with carefully selected marketing
|
|
partners that meet either the preferences that you've specifically provided
|
|
or your past purchasing habits. The more we and know about your likes and
|
|
dislikes, the better we can tailor offerings to your needs.<BR>
|
|
<BR>
|
|
CatalogExample is a licensee of the PrivacySealExample Program. The
|
|
PrivacySealExample Program ensures your privacy by holding Web site licensees
|
|
to high privacy standards and confirming with independent auditors that these
|
|
information practices are being followed.<BR>
|
|
<BR>
|
|
Questions regarding this statement should be directed to:<BR>
|
|
<CODE>CatalogExample<BR>
|
|
4000 Lincoln Ave.<BR>
|
|
Birmingham, MI 48009 USA<BR>
|
|
email: catalog@example.com<BR>
|
|
Telephone +1 248-EXAMPLE (+1 248-392-6753)</CODE><BR>
|
|
<BR>
|
|
If we have not responded to your inquiry or your inquiry has not been
|
|
satisfactorily addressed, you can contact PrivacySealExample -
|
|
http://privacyseal.example.org/privacyseal. CatalogExample will correct all
|
|
errors or wrongful actions arising in connection with the privacy policy.<BR>
|
|
<BR>
|
|
When you browse through our site we collect:
|
|
<UL>
|
|
<LI>
|
|
the basic information about your computer and connection to make sure that
|
|
we can get you the proper information and for security purposes; and
|
|
<LI>
|
|
aggregate information on what pages consumers access or visit to improve
|
|
our site
|
|
</UL>
|
|
<P>
|
|
<BR>
|
|
If you choose to purchase an item we will ask you for more information including:
|
|
<UL>
|
|
<LI>
|
|
your name and address so that we can have your purchase delivered to you
|
|
and so we can contact you in the future;
|
|
<LI>
|
|
your email address and telephone number so we can contact you;
|
|
<LI>
|
|
a login and password to use to update your information at any time in the
|
|
future; and
|
|
<LI>
|
|
financial information to complete your purchase (you may choose to store
|
|
this for future use)
|
|
<LI>
|
|
optionally, you can enter other demographic information so that we can tailor
|
|
services to you in the future.
|
|
</UL>
|
|
<P>
|
|
<BR>
|
|
Also on this page we will give you the option to choose if you would like
|
|
to receive email, telephone calls or written service from CatalogExample
|
|
or from our carefully selected marketing partners who maintain similar privacy
|
|
practices. If you would like to receive these solicitations simply check
|
|
the appropriate boxes. You can choose to stop participating at any time simply
|
|
by changing your preferences.<BR>
|
|
<BR>
|
|
<EM>Changing and Updating personal information</EM><BR>
|
|
Consumers can change all of their personal account information by going to
|
|
the preferences section of CatalogExample at
|
|
http://catalog.example.com/preferences.html. You can change your address,
|
|
telephone number, email address, password as well as your privacy settings.<BR>
|
|
<BR>
|
|
<EM>Cookies</EM><BR>
|
|
CatalogExample uses cookies only to see if you have been an CatalogExample
|
|
customer in the past and, if so, customize services based on your past browsing
|
|
habits and purchases. We do not store any personal data in the cookie nor
|
|
do we share or sell the any of the information with other parties or
|
|
affiliates.<BR>
|
|
<BR>
|
|
<EM><A name="retention_secondexample">Data retention</A></EM><BR>
|
|
We will keep the information about you and your purchases for as long as
|
|
you remain our customer. If you do not place an order from us for one year
|
|
we will remove your information from our databases.
|
|
<DT>
|
|
</DL>
|
|
<H3>
|
|
3.1.2 <A href="#XML" name="encoding">XML</A> encoding of policies
|
|
</H3>
|
|
<P>
|
|
The following pieces of [<A href="#XML">XML</A>] capture the information
|
|
as expressed in the above two examples. P3P policies are statements that
|
|
are properly expressed as well-formed <A href="#XML">XML</A>. The policy
|
|
syntax will be explained in more detail in the sections that follow.
|
|
<P>
|
|
<STRONG>XML Encoding of Example 3.1</STRONG>:
|
|
<PRE><POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
|
|
discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
|
|
<ENTITY>
|
|
<DATA-GROUP>
|
|
<DATA ref="#business.name">CatalogExample</DATA>
|
|
<DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
|
|
<DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
|
|
<DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
|
|
<DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
|
|
<DATA ref="#business.contact-info.postal.country">USA</DATA>
|
|
<DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
|
|
</DATA-GROUP>
|
|
</ENTITY>
|
|
<ACCESS><nonident/></ACCESS>
|
|
<DISPUTES-GROUP>
|
|
<DISPUTES resolution-type="independent"
|
|
service="http://www.PrivacySeal.example.org"
|
|
short-description="PrivacySeal.example.org">
|
|
<IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
|
|
<REMEDIES><correct/></REMEDIES>
|
|
</DISPUTES>
|
|
</DISPUTES-GROUP>
|
|
<STATEMENT>
|
|
<PURPOSE><admin/><develop/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION> <!-- Note also that the site's human-readable
|
|
privacy policy MUST mention that data
|
|
is purged every two weeks, or provide a
|
|
link to this information. -->
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.clickstream"/>
|
|
<DATA ref="#dynamic.http"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</PRE>
|
|
<P>
|
|
<STRONG>XML Encoding of Example 3.2:</STRONG>
|
|
<PRE><POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
|
|
discuri="http://www.catalog.example.com/Privacy/PrivacyPracticeShopping.html"
|
|
opturi="http://catalog.example.com/preferences.html">
|
|
<ENTITY>
|
|
<DATA-GROUP>
|
|
<DATA ref="#business.name">CatalogExample</DATA>
|
|
<DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
|
|
<DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
|
|
<DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
|
|
<DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
|
|
<DATA ref="#business.contact-info.postal.country">USA</DATA>
|
|
<DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
|
|
<DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
|
|
</DATA-GROUP>
|
|
</ENTITY>
|
|
<ACCESS><contact-and-other/></ACCESS>
|
|
<DISPUTES-GROUP>
|
|
<DISPUTES resolution-type="independent"
|
|
service="http://www.PrivacySeal.example.org"
|
|
short-description="PrivacySeal.example.org">
|
|
<IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
|
|
<REMEDIES><correct/></REMEDIES>
|
|
</DISPUTES>
|
|
</DISPUTES-GROUP>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
We record some information in order to serve your request
|
|
and to secure and improve our Web site.
|
|
</CONSEQUENCE>
|
|
<PURPOSE><admin/><develop/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.clickstream.server"/>
|
|
<DATA ref="#dynamic.http.useragent"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
We use this information when you make a purchase.
|
|
</CONSEQUENCE>
|
|
<PURPOSE><current/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#user.name"/>
|
|
<DATA ref="#user.home-info.postal"/>
|
|
<DATA ref="#user.home-info.telecom.telephone"/>
|
|
<DATA ref="#user.business-info.postal"/>
|
|
<DATA ref="#user.business-info.telecom.telephone"/>
|
|
<DATA ref="#user.home-info.online.email"/>
|
|
<DATA ref="#dynamic.miscdata">
|
|
<CATEGORIES><purchase/></CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
At your request, we will send you carefully selected marketing
|
|
solicitations that we think you will be interested in.
|
|
</CONSEQUENCE>
|
|
<PURPOSE>
|
|
<contact required="opt-in"/>
|
|
<customization required="opt-in"/>
|
|
<tailoring required="opt-in"/>
|
|
</PURPOSE>
|
|
<RECIPIENT required="opt-in"><ours/><same/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#user.name" optional="yes"/>
|
|
<DATA ref="#user.home-info.postal" optional="yes"/>
|
|
<DATA ref="#user.home-info.telecom.telephone" optional="yes"/>
|
|
<DATA ref="#user.business-info.postal" optional="yes"/>
|
|
<DATA ref="#user.business-info.telecom.telephone" optional="yes"/>
|
|
<DATA ref="#user.home-info.online.email" optional="yes"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
We allow you to set a password so that you
|
|
can access your own information.
|
|
</CONSEQUENCE>
|
|
<PURPOSE><customization required="opt-in"/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.miscdata">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
At your request, we will tailor our site and
|
|
highlight products related to your interests.
|
|
</CONSEQUENCE>
|
|
<PURPOSE>
|
|
<customization required="opt-in"/>
|
|
<tailoring required="opt-in"/>
|
|
</PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#user.bdate.ymd.year" optional="yes"/>
|
|
<DATA ref="#user.gender" optional="yes"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>
|
|
We tailor our site based on your past visits.
|
|
</CONSEQUENCE>
|
|
<PURPOSE><tailoring/><develop/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.cookies">
|
|
<CATEGORIES><state/></CATEGORIES>
|
|
</DATA>
|
|
<DATA ref="#dynamic.miscdata">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</PRE>
|
|
<H2>
|
|
<A name="Policies">3.2 Policies</A>
|
|
</H2>
|
|
<P>
|
|
This section defines the syntax and semantics of P3P policies. All policies
|
|
MUST be encoded using [<A href="#UTF-8">UTF-8</A>]. P3P servers MUST encode
|
|
their policies using this encoding. P3P user agents MUST be able to parse
|
|
this syntax.
|
|
<P>
|
|
Policies can be placed stand-alone in a single file (using the
|
|
<CODE>POLICY</CODE> element), or gathered together using the
|
|
<CODE>POLICIES</CODE> element.
|
|
<H3>
|
|
3.2.1 <A name="POLICIES">The <CODE><STRONG>POLICIES</STRONG></CODE> element</A>
|
|
</H3>
|
|
<P>
|
|
The <CODE>POLICIES</CODE> element is used to gather several P3P policies
|
|
together in a single file. This is provided as a performance optimization:
|
|
many policies can be collected with a single request, improving network traffic
|
|
and caching. Even, the <CODE>POLICIES</CODE> element can be placed in the
|
|
well-known location, inside the <CODE>META</CODE> element: in this case,
|
|
user agents need only fetch a single file, containing both the policy reference
|
|
file and the policies.
|
|
<P>
|
|
Each policy included in a <CODE>POLICIES</CODE> element MUST have a
|
|
<CODE>name</CODE> attribute which is unique in the file. This allows policy
|
|
references (in <CODE>POLICY-REF</CODE> elements) to link to that policy.
|
|
<P>
|
|
<STRONG>Example 3.3:</STRONG>
|
|
<P>
|
|
The file in <CODE>http://www.example.com/Shop/policies.xml</CODE> could have
|
|
the following content:
|
|
<PRE><POLICIES xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY discuri="http://www.example.com/disc1" name="policy1"> .... </POLICY>
|
|
<POLICY discuri="http://www.example.com/disc2" name="policy2"> .... </POLICY>
|
|
<POLICY discuri="http://www.example.com/disc3" name="policy3"> .... </POLICY>
|
|
</POLICIES>
|
|
</PRE>
|
|
<P>
|
|
The files in <CODE>http://www.example.com/Shop/CDs/*</CODE> could then be
|
|
associated to the second policy ("<CODE>policy2</CODE>") using the following
|
|
policy reference file in <CODE>http://www.example.com/w3c/p3p.xml</CODE>
|
|
:
|
|
<PRE><META xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<POLICY-REFERENCES>
|
|
<POLICY-REF about="/Shop/policies#policy2">
|
|
<INCLUDE>/Shops/CDs/*</INCLUDE>
|
|
</POLICY-REF>
|
|
</POLICY-REFERENCES>
|
|
</META>
|
|
</PRE>
|
|
<P>
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top">[19]</TD>
|
|
<TD valign="top"><PRE>policies
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top"><PRE>`<POLICIES xmlns="http://www.w3.org/2000/12/P3Pv1">`
|
|
*policy
|
|
"</POLICIES>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
</H3>
|
|
<H3>
|
|
<A name="POLICY">3.2.2 The <STRONG><CODE>POLICY</CODE></STRONG>
|
|
element</A>
|
|
</H3>
|
|
<P>
|
|
The <CODE>POLICY</CODE> element contains a complete P3P policy. Each P3P
|
|
policy MUST contain exactly one <CODE>POLICY</CODE> element. The policy element
|
|
MUST contain an <CODE>ENTITY</CODE> element that identifies the legal entity
|
|
making the representation of the privacy practices contained in the policy.
|
|
In addition, the policy element MUST contain an <CODE>ACCESS</CODE> element,
|
|
and optionally <CODE>STATEMENT</CODE> elements, a <CODE>DISPUTES-GROUP</CODE>
|
|
element, an <CODE><A href="#the_expiry_element">EXPIRY</A></CODE> element
|
|
(indicating the expiration of the policy), a <A href="#Data_Schemas">P3P
|
|
data schema</A>, and one or more extensions.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><POLICY></CODE></STRONG>
|
|
<DD>
|
|
includes one or more statements. Each statement includes a set of disclosures
|
|
as applied to a set of data elements.
|
|
<DT>
|
|
<STRONG><CODE><A name="disc_URI">discuri</A> </CODE>(<EM>mandatory
|
|
attribute</EM>)</STRONG>
|
|
<DD>
|
|
URI of the natural language privacy statement
|
|
<DT>
|
|
<CODE><A name="opturi"><STRONG>opturi</STRONG></A></CODE>
|
|
<DD>
|
|
URI of instructions that users can follow to request or decline to have their
|
|
data used for a particular purpose (opt-in or opt-out). This attribute is
|
|
<EM><STRONG>mandatory</STRONG></EM> for policies that contain a
|
|
<CODE><A href="#PURPOSE">purpose</A></CODE> with required attribute set to
|
|
<CODE>opt-in</CODE> or <CODE>opt-out</CODE>.
|
|
<DT>
|
|
<CODE><STRONG>name</STRONG></CODE>
|
|
<DD>
|
|
name of the policy, used as a fragment identifier to be able to reference
|
|
the policy. This attribute is <EM><STRONG>mandatory</STRONG></EM> if the
|
|
<CODE>POLICY</CODE> is included in a <CODE>POLICIES</CODE> element.
|
|
</DL>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top" width="3%">[20]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>policy
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>`<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
|
|
discuri=` quoted-URI
|
|
[` opturi=` quoted-URI]
|
|
[` name=` quotedstring] `>`
|
|
*extension
|
|
[test]
|
|
[expiry]
|
|
[dataschema]
|
|
entity
|
|
access
|
|
[disputes-group]
|
|
*statement-block
|
|
*extension
|
|
`</POLICY>`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top" width="3%">[21]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>quoted-URI
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>`"` URI `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" colspan="4" valign="top">Here, URI is defined as per
|
|
<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</A>
|
|
[<A href="#URI">URI</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A NAME="test">3.2.3 The <STRONG><CODE>TEST</CODE></STRONG> element</A>
|
|
</H3>
|
|
<P>
|
|
The TEST element is use for testing purposes: the presence of
|
|
<CODE>TEST</CODE> in a policy indicates that the policy is just an example,
|
|
and as such, it MUST be ignored, and not be considered as a valid P3P policy.
|
|
<P>
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top">[22]</TD>
|
|
<TD valign="top"><PRE>test
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top"><PRE>"<TEST/>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A name="ENTITY">3.2.4 The <CODE><STRONG>ENTITY</STRONG></CODE> element</A>
|
|
</H3>
|
|
<P>
|
|
The <CODE>ENTITY</CODE> element gives a precise description of the legal
|
|
entity making the representation of the privacy practices.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><ENTITY></CODE></STRONG>
|
|
<DD>
|
|
identifies the legal entity making the representation of the privacy practices
|
|
contained in the policy
|
|
</DL>
|
|
<P>
|
|
The ENTITY element contains a description of the legal entity consisting
|
|
of <A href="#DATA">DATA elements</A> referencing (all or some of) the fields
|
|
of the <A href="#Business-Data">business dataset</A>: it MUST contain both
|
|
the legal entity's name as well as contact information such as postal address,
|
|
telephone number, email address, or other information that individuals may
|
|
use to contact the entity about their privacy policy. Note that some laws
|
|
and codes of conduct require entities to include a postal address or other
|
|
specific information in their contact information.
|
|
<TABLE BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="100%" BGCOLOR="#f5dcb3">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top" width="3%">[21]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE> entity
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>"<ENTITY>"
|
|
*extension
|
|
entitydescription
|
|
*extension
|
|
"</ENTITY>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top" width="3%">[22]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE> entitydescription
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>"<DATA-GROUP>"
|
|
`<DATA ref="#business.name"/>` PCDATA "</DATA>"
|
|
*(`<DATA ref="#business.` string `"/>` PCDATA "</DATA>")
|
|
"</DATA-GROUP>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" colspan="4" valign="top">Here, string is defined as
|
|
a sequence of characters (with " and & escaped) among the values that
|
|
are allowed by the <A href="#Business-Data">business dataset</A>.
|
|
<CODE>PCDATA</CODE> is defined as in [<A href="#XML">XML</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A name="ACCESS">3.2.5 The <STRONG><CODE>ACCESS</CODE></STRONG> element</A>
|
|
</H3>
|
|
<P>
|
|
The <CODE>ACCESS</CODE> element indicates whether the site provides access
|
|
to various kinds of information.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><ACCESS></CODE></STRONG>
|
|
<DD>
|
|
the ability of the individual to view identifiable information and address
|
|
questions or concerns to the service provider. Service providers MUST disclose
|
|
one value for the access attribute. The method of access is not specified.
|
|
Any disclosure (other than <CODE><all/></CODE>) is not meant to imply
|
|
that access to all data is possible, but that some of the data may be accessible
|
|
and that the user should communicate further with the service provider to
|
|
determine what capabilities they have.
|
|
<P>
|
|
Note that service providers may also wish to provide capabilities to access
|
|
information collected through means other than the Web at the
|
|
<STRONG><A href="#disc_URI">discuri</A>. </STRONG>However, the scope of P3P
|
|
statements are limited to data collected through HTTP or other Web transport
|
|
protocols. Also, if access is provided through the Web, use of strong
|
|
authentication and security mechanisms for such access is recommended; however,
|
|
security issues are outside the scope of this document.
|
|
</DL>
|
|
<P>
|
|
The <CODE>ACCESS</CODE> element must contain one of the following elements:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><nonident/></CODE></STRONG>
|
|
<DD>
|
|
Identifiable Data is Not Used
|
|
<DT>
|
|
<STRONG><CODE><all/></CODE></STRONG>
|
|
<DD>
|
|
All Identifiable Information: access is given to all identifiable information.
|
|
<DT>
|
|
<STRONG><CODE><contact-and-other/></CODE></STRONG>
|
|
<DD>
|
|
Identifiable Contact Information and Other Identifiable Information: access
|
|
is given to identifiable online and physical contact information as well
|
|
as to other information linked to an identifiable person.
|
|
<DT>
|
|
<STRONG><CODE><ident-contact/></CODE></STRONG>
|
|
<DD>
|
|
Identifiable Contact Information: access is given to identifiable online
|
|
and physical contact information (e.g., users can access things such as a
|
|
postal address).
|
|
<DT>
|
|
<STRONG><CODE><other-ident/></CODE></STRONG>
|
|
<DD>
|
|
Other Identifiable Information: access is given to certain other information
|
|
linked to an identifiable person (e.g., users can access things such as their
|
|
online account charges).
|
|
<DT>
|
|
<STRONG><CODE><none/></CODE></STRONG>
|
|
<DD>
|
|
None: no access to identifiable information is given.
|
|
</DL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[23]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>access
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<ACCESS>"
|
|
access_disclosure
|
|
*extension
|
|
"</ACCESS>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[24]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>access_disclosure
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<nonident/>" | ; Identifiable Data is Not Used
|
|
"<ident-contact/>" | ; Identifiable Contact Information
|
|
"<other-ident/>" | ; Other Identifiable Information
|
|
"<contact-and-other/>" | ; Identifiable and
|
|
Other Contact Information
|
|
"<all/>" | ; All Identifiable Information
|
|
"<none/>" ; None
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A name="DISPUTES">3.2.6 The <STRONG><CODE>DISPUTES</CODE></STRONG>
|
|
element</A>
|
|
</H3>
|
|
<P>
|
|
A policy SHOULD contain a <CODE>DISPUTES-GROUP</CODE> element, which contains
|
|
one or more <CODE>DISPUTES</CODE> elements. These elements describe dispute
|
|
resolution procedures that may be followed for disputes about a services'
|
|
privacy practices. Each <CODE>DISPUTES</CODE> element can optionally contain
|
|
a <CODE>LONG-DESCRIPTION</CODE> element, an <CODE>IMG</CODE> element, and
|
|
a <CODE>REMEDIES</CODE> element. Service providers with multiple dispute
|
|
resolution procedures should use a separate <CODE>DISPUTES</CODE> element
|
|
for each. Since different dispute procedures have separate remedy processes,
|
|
each <CODE>DISPUTES</CODE> element would need a separate
|
|
<CODE>LONG-DESCRIPTION</CODE>, <CODE>IMG</CODE> tag and <CODE>REMEDIES</CODE>
|
|
element, if they are being used.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><DISPUTES></CODE></STRONG>
|
|
<DD>
|
|
Describes dispute resolution procedures that may be followed for disputes
|
|
about a services' privacy practices, or in case of protocol violation.
|
|
<DT>
|
|
<STRONG><CODE>resolution-type</CODE></STRONG> <STRONG>(<EM>mandatory
|
|
attribute</EM>)</STRONG>
|
|
<DD>
|
|
takes one of the following four values:
|
|
<DL>
|
|
<DT>
|
|
<STRONG>Customer service </STRONG><CODE>[service] </CODE>
|
|
<DD>
|
|
Individual may complain to the Web site's customer service representative
|
|
for resolution of disputes regarding the use of collected data. The description
|
|
MUST include information about how to contact customer service.
|
|
<DT>
|
|
<STRONG>Independent organization </STRONG><CODE>[independent]</CODE>
|
|
<DD>
|
|
Individual may complain to an independent organization for resolution of
|
|
disputes regarding the use of collected data. The description MUST include
|
|
information about how to contact the third party organization.
|
|
<DT>
|
|
<STRONG>Court </STRONG><CODE>[court]</CODE>
|
|
<DD>
|
|
Individual may file a legal complaint against the Web site.
|
|
<DT>
|
|
<STRONG>Applicable law </STRONG><CODE>[law]</CODE>
|
|
<DD>
|
|
Disputes arising in connection with the privacy statement will be resolved
|
|
in accordance with the law referenced in the description.
|
|
</DL>
|
|
<DT>
|
|
<STRONG><CODE>service</CODE></STRONG> <STRONG>(<EM>mandatory
|
|
attribute</EM>)</STRONG>
|
|
<DD>
|
|
URI of the customer service Webpage or independent organization, or URI for
|
|
information about the relevant court or applicable law
|
|
<DT>
|
|
<STRONG><CODE>verification</CODE></STRONG>
|
|
<DD>
|
|
URI or certificate that can be used for verification purposes. It is anticipated
|
|
that seal providers will provide a mechanism for verifying a site's claim
|
|
that they have a seal.
|
|
<DT>
|
|
<STRONG><CODE>short-description</CODE></STRONG>
|
|
<DD>
|
|
A short human readable description of the name of the appropriate legal forum,
|
|
applicable law, or third party organization; or contact information for customer
|
|
service if not already provided at the service URI. No more than 255
|
|
<A href="#character">characters</A>.
|
|
</DL>
|
|
<P>
|
|
The <CODE>DISPUTES</CODE> element can contain a <CODE>LONG-DESCRIPTION</CODE>
|
|
element, where a human readable description is present: this should contain
|
|
the name of the appropriate legal forum, applicable law, or third party
|
|
organization; or contact information for customer service if not already
|
|
provided at the service URI.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><A name="LONG-DESCRIPTION"><LONG-DESCRIPTION></A></CODE></STRONG>
|
|
<DD>
|
|
This element contains a (possibly long) human readable description.
|
|
</DL>
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><IMG></CODE></STRONG>
|
|
<DD>
|
|
An image logo (for example, of the independent organization or relevant court)
|
|
<DT>
|
|
<STRONG><CODE>src</CODE></STRONG> <STRONG>(<EM>mandatory
|
|
attribute</EM>)</STRONG>
|
|
<DD>
|
|
URI of the image logo
|
|
<DT>
|
|
<STRONG><CODE>width</CODE></STRONG>
|
|
<DD>
|
|
width in pixels of the image logo
|
|
<DT>
|
|
<STRONG><CODE>height</CODE></STRONG>
|
|
<DD>
|
|
height in pixels of the image logo
|
|
<DT>
|
|
<STRONG><CODE>alt</CODE> (<EM>mandatory attribute</EM>)</STRONG>
|
|
<DD>
|
|
very short textual alternative for the image logo
|
|
</DL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[25]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>disputes-group
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DISPUTES-GROUP>"
|
|
1*dispute
|
|
*extension
|
|
"</DISPUTES-GROUP>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[26]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>dispute
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DISPUTES"
|
|
" resolution-type=" '"'("service"|"independent"|"court"|"law")'"'
|
|
" service=" quoted-URI
|
|
[" verification=" quotedstring]
|
|
[" short-description=" quotedstring]
|
|
">"
|
|
*extension
|
|
[longdescription]
|
|
[image]
|
|
[remedies]
|
|
*extension
|
|
"</DISPUTES>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[27]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>longdescription
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE><LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[28]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>image
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>"<IMG src=" quoted-URI
|
|
[" width=" `"` number `"`]
|
|
[" height=" `"` number `"`]
|
|
" alt=" quotedstring
|
|
"/>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[29]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>quotedstring
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>`"` string `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" colspan="4" valign="top">Here, <CODE>string</CODE>
|
|
is defined as a sequence of characters (with " and & escaped), and
|
|
<CODE>PCDATA</CODE> is defined as in [<A href="#XML">XML</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Note that there can be multiple assurance services, specified via multiple
|
|
occurrences of <CODE>DISPUTES</CODE> within the <CODE>DISPUTES-GROUP</CODE>
|
|
element. These fields are expected to be used in a number of ways, including
|
|
representing that one's privacy practices are self assured, audited by a
|
|
third party, or under the jurisdiction of a regulatory authority.
|
|
<H3>
|
|
<A name="REMEDIES">3.2.7 The <CODE>REMEDIES</CODE> element</A>
|
|
</H3>
|
|
<P>
|
|
Each <CODE>DISPUTES</CODE> element SHOULD contain a <CODE>REMEDIES</CODE>
|
|
element that specifies the possible remedies in case a policy breach
|
|
occurs.<BR>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><REMEDIES></CODE></STRONG>
|
|
<DD>
|
|
Remedies in case a policy breach occurs.
|
|
</DL>
|
|
<P>
|
|
The <CODE>REMEDIES</CODE> element must contain one or more of the following:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><correct/></CODE> </STRONG>
|
|
<DD>
|
|
Errors or wrongful actions arising in connection with the privacy policy
|
|
will be remedied by the service.
|
|
<DT>
|
|
<STRONG><CODE><money/></CODE> </STRONG>
|
|
<DD>
|
|
If the service provider violates its privacy policy it will pay the individual
|
|
an amount specified in the human readable privacy policy or the amount of
|
|
damages.
|
|
<DT>
|
|
<STRONG><CODE><law/></CODE></STRONG>
|
|
<DD>
|
|
Remedies for breaches of the policy statement will be determined based on
|
|
the law referenced in the human readable description.
|
|
<DT>
|
|
</DL>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[30]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>remedies
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<REMEDIES>"
|
|
1*remedy
|
|
*extension
|
|
"</REMEDIES>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[31]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>remedy
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<correct/>" |
|
|
"<money/>" |
|
|
"<law/>"
|
|
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H2>
|
|
<A name="Statements">3.3 Statements</A>
|
|
</H2>
|
|
<P>
|
|
Statements describe data practices that are applied to particular types of
|
|
data.
|
|
<H3>
|
|
3.3.1 <A name="STATEMENT">The
|
|
<STRONG><CODE>STATEMENT</CODE></STRONG> element</A>
|
|
</H3>
|
|
<P>
|
|
The <CODE>STATEMENT</CODE> element is a container that groups together a
|
|
<CODE>PURPOSE</CODE> element, a <CODE>RECIPIENT</CODE> element, a
|
|
<CODE>RETENTION</CODE> element, a <CODE>DATA-GROUP</CODE> element, and optionally
|
|
a <CODE>CONSEQUENCE</CODE> element and one or more extensions. All of the
|
|
data referenced by the <CODE>DATA-GROUP</CODE> is handled according to the
|
|
disclosures made in the other elements contained by the statement. Thus,
|
|
sites may group elements that are handled the same way and create a statement
|
|
for each group. Sites that would prefer to disclose separate purposes and
|
|
other information for each kind of data they collect can do so by creating
|
|
a separate statement for each data element.
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><STATEMENT></CODE></STRONG>
|
|
<DD>
|
|
data practices as applied to data elements.
|
|
</DL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[32]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>statement-block
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<STATEMENT>"
|
|
*extension
|
|
[consequence]
|
|
[non-identifiable]
|
|
purpose
|
|
recipient
|
|
retention
|
|
1*data-group
|
|
*extension
|
|
"</STATEMENT>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
To simplify practice declaration, service providers may aggregate any of
|
|
the disclosures (purposes, recipients, and retention) within a statement
|
|
over data elements. Service providers MUST make such aggregations as an additive
|
|
operation. For instance, a site that distributes your age to
|
|
<CODE>ours</CODE> (ourselves and our agents), but distributes your postal
|
|
code to <CODE>unrelated</CODE> (unrelated third parties), MAY say they distribute
|
|
your name and postal code to <CODE>ours</CODE> and <CODE>unrelated</CODE>.
|
|
Such a statement appears to distribute more data than actually happens. It
|
|
is up to the service provider to determine if their disclosure deserves
|
|
specificity or brevity.
|
|
<P>
|
|
Also, one must always disclose all options that apply. Consider a site with
|
|
the sole purpose of collecting information for the purposes of
|
|
<CODE>contact</CODE> (Contacting Visitors for Marketing of Services or Products).
|
|
Even though this is considered to be for the <CODE>current</CODE> (Completion
|
|
and Support of Current Activity) purpose, the site must state both
|
|
<CODE>contact</CODE> and <CODE>current</CODE> purposes. Consider a site which
|
|
distributes information to <CODE>ours</CODE> in order to redistribute it
|
|
to <CODE>public</CODE>: the site must state both <CODE>ours</CODE> and
|
|
<CODE>public</CODE> recipients.
|
|
<P>
|
|
Service providers often aggregate data they collect. Sometimes this aggregate
|
|
data may be used for different purposes than the original data, shared more
|
|
widely than the original data, or retained longer than the original data.
|
|
For example many sites publish or disclose to their advertisers statistics
|
|
such as number of visitors to their Web site, percentage of visitors
|
|
who fit into various demographic groups, etc. When aggregate
|
|
statistics are used or shared such that it would not be possible to derive
|
|
data for individual people or households based on these statistics,
|
|
no disclosures about these statistics are necessary in a P3P policy.
|
|
However, services MUST disclose the fact that the original data is collected
|
|
and declare any use that is made of the data before it is aggregated.
|
|
<H3>
|
|
3.3.2 <A name="CONSEQUENCE">The
|
|
<STRONG><CODE>CONSEQUENCE</CODE></STRONG> element</A>
|
|
</H3>
|
|
<P>
|
|
<CODE>STATEMENT</CODE> elements may optionally contain a
|
|
<CODE>CONSEQUENCE</CODE> element that can be shown to a human user to provide
|
|
further explanation about a site's practices.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><CONSEQUENCE></CODE></STRONG>
|
|
<DD>
|
|
Consequences that can be shown to a human user to explain why the suggested
|
|
practice may be valuable in a particular instance even if the user would
|
|
not normally allow the practice.
|
|
</DL>
|
|
<P>
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#f5dcb3">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[33]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>consequence
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<CONSEQUENCE>"
|
|
PCDATA
|
|
"</CONSEQUENCE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A NAME="NON-IDENTIFIABLE">3.3.3 The
|
|
<CODE><STRONG>NON-IDENTIFIABLE</STRONG></CODE> element</A>
|
|
</H3>
|
|
<P>
|
|
<CODE>STATEMENT</CODE> elements may optionally contain a
|
|
<CODE>NON-IDENTIFIABLE</CODE> element, only when the requirements specified
|
|
below are fulfilled.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><NON-IDENTIFIABLE/></CODE></STRONG>
|
|
<DD>
|
|
This is an element that can only be present in the statement, if there
|
|
is no data or no identifiable data collected. Data is seen as
|
|
non-identifiable in the sense of the present specification, if there
|
|
is no reasonable way for the entity or a third party to attach the collected
|
|
data to the identity of natural person.
|
|
</DL>
|
|
<P>
|
|
If the <CODE><NON-IDENTIFIABLE/></CODE> element is present, a human
|
|
readable explanation of how this is achieved MUST be included at the
|
|
<STRONG><A href="#disc_URI">discuri</A></STRONG> .
|
|
<P>
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%" bgcolor="#f5dcb3">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[34]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>non-identifiable
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<NON-IDENTIFIABLE/>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
3.3.4 <A name="PURPOSE">The <STRONG><CODE>PURPOSE</CODE></STRONG>
|
|
element</A>
|
|
</H3>
|
|
<P>
|
|
Each <CODE>STATEMENT</CODE> element MUST contain a <CODE>PURPOSE</CODE> element
|
|
that contains one or more purposes of data collection or uses of data. Sites
|
|
MUST classify their data practices into one or more of the purposes specified
|
|
below.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><PURPOSE></CODE></STRONG>
|
|
<DD>
|
|
purposes for data processing relevant to the Web.
|
|
</DL>
|
|
<P>
|
|
The <CODE>PURPOSE</CODE> element MUST contain one or more of the following:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><current/></CODE> </STRONG>
|
|
<DD>
|
|
<STRONG>Completion and Support of Current Activity:</STRONG> Information
|
|
may be used by the service provider to complete the activity for which it
|
|
was provided, such as the provision of information, communications, or
|
|
interactive services -- for example to return the results from a Web search,
|
|
to forward email, or place an order.
|
|
<DT>
|
|
<STRONG><CODE><admin/></CODE> </STRONG>
|
|
<DD>
|
|
<STRONG>Web Site and System Administration:</STRONG> Information may be used
|
|
for the technical support of the Web site and its computer system. This would
|
|
include processing computer account information, information used in the
|
|
course of securing and maintaining the site, and verification of Web site
|
|
activity by the site or its agents.
|
|
<DT>
|
|
<STRONG><CODE><develop/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Research and Development</STRONG>: Information may be used to enhance,
|
|
evaluate, or otherwise review the site, service, product, or market. This
|
|
does not include personal information used to tailor or modify the content
|
|
to the specific individual nor information used to evaluate, target, profile
|
|
or contact the individual.
|
|
<DT>
|
|
<STRONG><CODE><customization/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Affirmative Customization</STRONG>: Information may be used to tailor
|
|
or modify the content or design of the site only to specifications affirmatively
|
|
selected by the particular individual during a single visit or multiple visits
|
|
to the site. For example, a financial site that lets users select several
|
|
stocks whose current prices are displayed whenever the user visits.
|
|
<DT>
|
|
<STRONG><CODE><tailoring/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>One-time Tailoring</STRONG>: Information may be used to tailor or
|
|
modify content or design of the site not affirmatively selected by the particular
|
|
individual where the information is used only for a single visit to the site
|
|
and not used for any kind of future customization. For example, an online
|
|
store that suggests other items a visitor may wish to purchase based on the
|
|
items he has already placed in his shopping basket.
|
|
<DT>
|
|
<CODE><STRONG><pseudo-analysis/> </STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Pseudonymous Analysis</STRONG>: Information may be used to create
|
|
or build a record of a particular individual or computer that is tied to
|
|
a pseudonymous identifier, without tying personally-identifiable information
|
|
(such as name, address, phone number, email address, or IP address) to the
|
|
record. This profile will be used to determine the habits, interests, or
|
|
other characteristics of individuals <EM>for purpose of research, analysis
|
|
and reporting</EM>, but it will not be used to attempt to identify specific
|
|
individuals. For example, a marketer may wish to understand the interests
|
|
of visitors to different portions of a Web site.
|
|
<DT>
|
|
<CODE><STRONG><pseudo-decision/></STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Pseudonymous Decision</STRONG>: Information may be used to create
|
|
or build a record of a particular individual or computer that is tied to
|
|
a pseudonymous identifier, without tying personally-identifiable information
|
|
(such as name, address, phone number, email address, or IP address) to the
|
|
record. This profile will be used to determine the habits, interests, or
|
|
other characteristics of individuals <EM>to make a decision that directly
|
|
affects that individual</EM>, but it will not be used to attempt to identify
|
|
specific individuals. For example, a marketer may tailor or modify content
|
|
displayed to the browser based on pages viewed during previous visits.
|
|
<DT>
|
|
<CODE><STRONG><individual-analysis/></STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Individual Analysis</STRONG>: Information may be used to determine
|
|
the habits, interests, or other characteristics of individuals and combine
|
|
it with personally identifiable information <EM>for the purpose of research,
|
|
analysis and reporting</EM>. For example, an online Web site for a physical
|
|
store may wish to analyze how online shoppers make offline purchases.
|
|
<DT>
|
|
<CODE><STRONG><individual-decision/> </STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Individual Decision</STRONG>: Information may be used to determine
|
|
the habits, interests, or other characteristics of individuals and combine
|
|
it with personally identifiable information <EM>to make a decision that directly
|
|
affects that individual</EM>. For example, an online store suggests
|
|
items a visitor may wish to purchase based on items he has purchased during
|
|
previous visits to the Web site.
|
|
<DT>
|
|
<STRONG><CODE><contact/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Contacting Visitors for Marketing of Services or Products</STRONG>:
|
|
Information may be used to contact the individual, through a communications
|
|
channel other than voice telephone, for the promotion of a product or service.
|
|
This includes notifying visitors about updates to the Web site. This does
|
|
not include a direct reply to a question or comment or customer service for
|
|
a single transaction -- in those cases, <STRONG><CODE><current/>
|
|
</CODE></STRONG>would be used. In addition, this does not include marketing
|
|
via customized Webcontent or banner advertisements embedded in sites the
|
|
user is visiting -- these cases would be covered by the
|
|
<CODE><STRONG><tailoring/></STRONG></CODE>,
|
|
<CODE><STRONG><pseudo-analysis/></STRONG></CODE> and
|
|
<CODE><STRONG><pseudo-decision/></STRONG></CODE>, or
|
|
<CODE><STRONG><individual-analysis/></STRONG></CODE> and
|
|
<CODE><STRONG><individual-decision/></STRONG></CODE> purposes.
|
|
<DT>
|
|
<STRONG><CODE><historical/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Historical Preservation</STRONG>: Information may be archived or
|
|
stored for the purpose of preserving social history as governed by an existing
|
|
law or policy. This law or policy MUST be referenced in the
|
|
<CODE><DISPUTES></CODE> element and MUST include a specific definition
|
|
of the type of qualified researcher who can access the information, where
|
|
this information will be stored and specifically how this collection advances
|
|
the preseservation of history.
|
|
<DT>
|
|
<CODE><STRONG><telemarketing/></STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Contacting Visitors for Marketing of Services or Products Via
|
|
Telephone</STRONG>: Information may be used to contact the individual via
|
|
a voice telephone call for promotion of a product or service. This does not
|
|
include a direct reply to a question or comment or customer service for a
|
|
single transaction -- in those cases,
|
|
<CODE><STRONG><current/></STRONG></CODE> would be used.
|
|
<DT>
|
|
<STRONG><CODE><other-purpose></CODE> <EM>string</EM>
|
|
<CODE></other-purpose></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Other Uses</STRONG>: Information may be used in other ways not captured
|
|
by the above definitions. (A human readable explanation should be provided
|
|
in these instances).
|
|
</DL>
|
|
<P>
|
|
Each type of purpose can have the following optional attribute:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><A NAME="required">required</A></CODE></STRONG>
|
|
<DD>
|
|
Whether the purpose is a required practice for the site. The attribute can
|
|
take the following values:
|
|
<UL>
|
|
<LI>
|
|
<STRONG><CODE>always</CODE></STRONG> : The purpose is always required; users
|
|
cannot opt-in or opt-out of this use of their data. This is the default when
|
|
no <CODE>required</CODE> attribute is present.
|
|
<LI>
|
|
<STRONG><CODE>opt-in</CODE></STRONG> : Data may be used for this purpose
|
|
only when the user affirmatively requests this use -- for example, when a
|
|
user asks to be added to a mailing list. An affirmative request requires
|
|
users to take some action specifically to make the request. For example,
|
|
when users fill out a survey, checking an additional box to request to be
|
|
added to a mailing list would be considered an affirmative request. However,
|
|
submitting a survey form that contains a pre-checked mailing list request
|
|
box would not be considered an affirmative request. In addition, for any
|
|
purpose that users may affirmatively request, there must also be a way for
|
|
them to change their minds later and decline -- this MUST be specified at
|
|
the <CODE><A href="#opturi">opturi</A></CODE>.
|
|
<LI>
|
|
<STRONG><CODE>opt-out</CODE></STRONG> : Data may be used for this purpose
|
|
unless the user requests that it not be used in this way. When this value
|
|
is selected, the service MUST provide clear instructions to users on how
|
|
to opt-out of this purpose at the
|
|
<CODE><A href="#opturi">opturi</A></CODE>. Services SHOULD also provide these
|
|
instructions or a pointer to these instructions at the point of data collection.
|
|
</UL>
|
|
</DL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[35]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE> purpose
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<PURPOSE>"
|
|
1*purposevalue
|
|
*extension
|
|
"</PURPOSE>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[36]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE> purposevalue
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<current" [required] "/>" | ; Completion and Support of Current Activity
|
|
"<admin" [required] "/>" | ; Web Site and System Administration
|
|
"<develop" [required] "/>" | ; Research and Development
|
|
"<customization" [required] "/>" | ; Affirmative Customization
|
|
"<tailoring" [required] "/>" | ; One-time Tailoring
|
|
"<pseudo-analysis" [required] "/>" | ; Pseudonymous Analysis
|
|
"<pseudo-decision" [required] "/>" | ; Pseudonymous Decision
|
|
"<individual-analysis" [required] "/>" | ; Individual Analysis
|
|
"<individual-decision" [required] "/>" | ; Individual Decision
|
|
"<contact" [required] "/>" | ; Contacting Visitors for Marketing of Services or Products
|
|
"<historical" [required] "/>" | ; Historical Preservation
|
|
"<telemarketing" [required] "/>" | ; Telephone Marketing
|
|
"<other-purpose" [required] ">" PCDATA "</other-purpose>"; Other Uses
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[37]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE> required
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>" required=" `"` ("always"|"opt-in"|"opt-out") `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Service providers MUST use the above elements to explain the purpose of data
|
|
collection. Service providers MUST disclose <EM>all that apply</EM>. If a
|
|
service provider does not disclose that a data element will be used for a
|
|
given purpose, that is a representation that data will not be used for that
|
|
purpose. Service providers that disclose that they use data for
|
|
"<CODE>other</CODE>" purposes MUST provide human readable explanations of
|
|
those purposes.
|
|
<P>
|
|
Service providers MUST disclose <EM>all the recipients that apply</EM>. P3P
|
|
makes no distinctions about how that data is released to the recipient; it
|
|
simply requires that if data is released, then that sharing must be disclosed
|
|
in the P3P policy. Examples of disclosing data which MUST be covered by a
|
|
P3P statement include:
|
|
<UL>
|
|
<LI>
|
|
Transmitting customer data as part of an order-fulfillment or billing process
|
|
<LI>
|
|
Leasing or selling mailing lists
|
|
<LI>
|
|
Placing personal information in URIs when redirecting requests to a third
|
|
party
|
|
<LI>
|
|
Placing personal information in URIs which link to a third party
|
|
</UL>
|
|
<P>
|
|
Note that in some cases the above set of recipients may not completely describe
|
|
all the recipients of data. For example, the issue of transaction facilitators,
|
|
such as shipping or payment processors, who are necessary for the completion
|
|
and support of the activity but may follow different practices was problematic.
|
|
Currently, only delivery services can be explicitly represented in a policy.
|
|
Other such transaction facilitators should be represented in whichever category
|
|
most accurately reflects their practices with respect to the original service
|
|
provider. A special element for delivery services is included, but not one
|
|
for payment processors (such as banks or credit card companies) for the following
|
|
reasons: Financial institutions will typically have separate agreements with
|
|
their customers regarding the use of their financial data, while delivery
|
|
recipients typically do not have an opportunity to review a delivery service's
|
|
privacy policy.
|
|
<H3>
|
|
3.3.5 <A name="RECPNT">The <STRONG><CODE>RECIPIENT</CODE></STRONG>
|
|
element</A>
|
|
</H3>
|
|
<P>
|
|
Each <CODE>STATEMENT</CODE> element MUST contain a <CODE>RECIPIENT</CODE>
|
|
element that contains one or more recipients of the collected data. Sites
|
|
MUST classify their recipients into one or more of the six recipients specified.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><RECIPIENT></CODE></STRONG>
|
|
<DD>
|
|
the legal entity, or domain, beyond the service provider and its agents where
|
|
data may be distributed.
|
|
</DL>
|
|
<P>
|
|
The <CODE>RECIPIENT</CODE> element MUST contain one or more of the following:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><ours></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Ourselves and/or our entities acting as our agents or entities for
|
|
whom we are acting as an agent</STRONG>: An agent in this instance is defined
|
|
as a third party that processes data only on behalf of the service provider
|
|
for the completion of the stated purposes. (e.g., the service provider and
|
|
its printing bureau which prints address labels and does nothing further
|
|
with the information.)
|
|
<DT>
|
|
<STRONG><CODE><delivery></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Delivery services possibly following different practices</STRONG>:
|
|
Legal entities <EM>performing delivery services</EM> that may use data for
|
|
purposes other than completion of the stated purpose. This should also be
|
|
used for delivery services whose data practices are unknown.
|
|
<DT>
|
|
<STRONG><CODE><same></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Legal entities following our practices</STRONG>: Legal entities who
|
|
use the data on their own behalf under equable practices. (e.g., consider
|
|
a service provider that grants the user access to collected personal information,
|
|
and also provides it to a partner who uses it once but discards it. Since
|
|
the recipient, who has otherwise similar practices, cannot grant the user
|
|
access to information that it discarded, they are considered to have equable
|
|
practices.)
|
|
<DT>
|
|
<STRONG><CODE><other-recipient></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Legal entities following different practices</STRONG>: Legal entities
|
|
that are constrained by and accountable to the original service provider,
|
|
but may use the data in a way not specified in the service provider's practices
|
|
(e.g., the service provider collects data that is shared with a partner who
|
|
may use it for other purposes. However, it is in the service provider's interest
|
|
to ensure that the data is not used in a way that would be considered abusive
|
|
to the users' and its own interests.)
|
|
<DT>
|
|
<STRONG><CODE><unrelated></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Unrelated third parties</STRONG>: Legal entities whose data usage
|
|
practices are not known by the original service provider.
|
|
<DT>
|
|
<STRONG><CODE><public></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Public fora</STRONG>: Public fora such as bulletin boards, public
|
|
directories, or commercial CD-ROM directories.
|
|
</DL>
|
|
<P>
|
|
Each of the above tags can optionally contain:
|
|
<UL>
|
|
<LI>
|
|
one or more <CODE>recipient-description</CODE> tags, containing a description
|
|
of the recipient;
|
|
<LI>
|
|
with the exception of <CODE><ours></CODE>, a
|
|
<CODE><A HREF="#required">required</A></CODE> attribute: this attribute is
|
|
defined exactly as the analogous attribute in the <CODE>PURPOSE</CODE>
|
|
tag, indicating whether opt-in/opt-out of sharing is available (and, its
|
|
default value is <CODE>always</CODE>).
|
|
</UL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[38]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>recipient
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<RECIPIENT>"
|
|
1*recipientvalue
|
|
*extension
|
|
"</RECIPIENT>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[39]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>recipientvalue
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<ours>" *recdescr
|
|
"</ours> | ; only ourselves and our agents
|
|
"<same" [required] ">" *recdescr
|
|
"</same>" | ; legal entities following our practices
|
|
"<other-recipient" [required] ">" *recdescr
|
|
"</other-recipient>" | ; legal entities following different practices
|
|
"<delivery" [required] ">" *recdescr
|
|
"</delivery>" | ; delivery services following different practices
|
|
"<public" [required] ">" *recdescr
|
|
"</public>" | ; public fora
|
|
"<unrelated" [required] ">" *recdescr
|
|
"</unrelated>" ; unrelated third parties
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[40]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>recdescr
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<recipient-description>"
|
|
PCDATA ; description of the recipient
|
|
"</recipient-description>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Service providers MUST disclose <EM>all the recipients that apply</EM>. P3P
|
|
makes no distinctions about how that data is released to the recipient; it
|
|
simply requires that if data is released, then that sharing must be disclosed
|
|
in the P3P policy. Examples of disclosing data which MUST be covered by a
|
|
P3P statement include:
|
|
<UL>
|
|
<LI>
|
|
Transmitting customer data as part of an order-fulfillment or billing process
|
|
<LI>
|
|
Leasing or selling mailing lists
|
|
<LI>
|
|
Placing personal information in URIs when redirecting requests to a third
|
|
party
|
|
<LI>
|
|
Placing personal information in URIs which link to a third party
|
|
</UL>
|
|
<P>
|
|
Note that in some cases the above set of recipients may not completely describe
|
|
all the recipients of data. For example, the issue of transaction facilitators,
|
|
such as shipping or payment processors, who are necessary for the completion
|
|
and support of the activity but may follow different practices was problematic.
|
|
Currently, only delivery services can be explicitly represented in a policy.
|
|
Other such transaction facilitators should be represented in whichever category
|
|
most accurately reflects their practices with respect to the original service
|
|
provider.
|
|
<P>
|
|
A special element for delivery services is included, but not one for payment
|
|
processors (such as banks or credit card companies) for the following reasons:
|
|
Financial institutions will typically have separate agreements with their
|
|
customers regarding the use of their financial data, while delivery recipients
|
|
typically do not have an opportunity to review a delivery service's privacy
|
|
policy.
|
|
<P>
|
|
Note that the <CODE><delivery/></CODE> element SHOULD NOT be used for
|
|
delivery services that agree to use data only on behalf of the service provider
|
|
for completion of the delivery.
|
|
<H3>
|
|
3.3.6 <A name="RETENTION">The
|
|
<STRONG><CODE>RETENTION</CODE></STRONG> element</A>
|
|
</H3>
|
|
<P>
|
|
Each <CODE>STATEMENT</CODE> element MUST contain a <CODE>RETENTION</CODE>
|
|
element that indicates the kind of retention policy that applies to the data
|
|
referenced in that statement.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><RETENTION></CODE></STRONG>
|
|
<DD>
|
|
the type of retention policy in effect
|
|
</DL>
|
|
<P>
|
|
The <CODE>RETENTION</CODE> element MUST contain one of the following:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><no-retention/></CODE></STRONG>
|
|
<DD>
|
|
Information is not retained for more than a brief period of time necessary
|
|
to make use of it during the course of a single online interaction. Information
|
|
MUST be destroyed following this interaction and MUST not be logged, archived,
|
|
or otherwise stored. This type of retention policy would apply, for example,
|
|
to services that keep no Web server logs, set cookies only for use during
|
|
a single session, or collect information to perform a search but do not keep
|
|
logs of searches performed.
|
|
<DT>
|
|
<STRONG><CODE><stated-purpose/></CODE></STRONG>
|
|
<DD>
|
|
For the stated purpose: Information is retained to meet the stated purpose.
|
|
This requires information to be discarded at the earliest time possible.
|
|
Sites MUST have a retention policy that establishes a destruction time table.
|
|
The retention policy MUST be included in or linked from the site's human-readable
|
|
privacy policy.
|
|
<DT>
|
|
<STRONG><CODE><legal-requirement/></CODE></STRONG>
|
|
<DD>
|
|
As required by law or liability under applicable law: Information is retained
|
|
to meet a stated purpose, but the retention period is longer because of a
|
|
legal requirement or liability. For example, a law may allow consumers to
|
|
dispute transactions for a certain time period; therefore a business may
|
|
for liability reasons decide to maintain records of transactions, or a law
|
|
may affirmatively require a certain business to maintain records for auditing
|
|
or other soundness purposes. Sites MUST have a retention policy that establishes
|
|
a destruction time table. The retention policy MUST be included in or linked
|
|
from the site's human-readable privacy policy.
|
|
<DT>
|
|
<STRONG><CODE><business-practices/></CODE></STRONG>
|
|
<DD>
|
|
Determined by service provider's business practice: Information is retained
|
|
under a service provider's stated business practices. Sites MUST have a retention
|
|
policy that establishes a destruction time table. The retention policy MUST
|
|
be included in or linked from the site's human-readable privacy policy.
|
|
<DT>
|
|
<STRONG><CODE><indefinitely/></CODE></STRONG>
|
|
<DD>
|
|
Indefinitely: Information is retained for an indeterminate period of time.
|
|
The absence of a retention policy would be reflected under this option. Where
|
|
the recipient is a public fora, this is the appropriate retention policy.
|
|
<STRONG><CODE></CODE></STRONG>
|
|
</DL>
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[41]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>retention
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<RETENTION>"
|
|
retentionvalue
|
|
*extension
|
|
"</RETENTION>"
|
|
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[42]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>retentionvalue
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<no-retention/>" | ; not retained
|
|
"<stated-purpose/>" | ; for the stated purpose
|
|
"<legal-requirement/>" | ; stated purpose by law
|
|
"<indefinitely/>" | ; indeterminated period of time
|
|
"<business-practices/>" ; by business practices
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A name="DATA">3.3.7 The <STRONG><CODE>DATA-GROUP</CODE></STRONG> and
|
|
<STRONG><CODE>DATA</CODE></STRONG> elements</A>
|
|
</H3>
|
|
<P>
|
|
Each <CODE>STATEMENT</CODE> element MUST contain at least one
|
|
<CODE>DATA-GROUP</CODE> element that contains one or more <CODE>DATA</CODE>
|
|
elements. <CODE>DATA</CODE> elements are used to describe the type of data
|
|
that a site collects.
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><DATA-GROUP></CODE></STRONG>
|
|
<DD>
|
|
describes the data to be transferred or inferred
|
|
<DT>
|
|
<STRONG><CODE><A name="base_attribute">base</A></CODE></STRONG>
|
|
<DD>
|
|
<EM>base URI</EM> ([<A href="#URI">URI</A>]) for URI references present in
|
|
<CODE>ref</CODE> attributes. When this attribute is omitted, the default
|
|
value is the URI of the P3P base data schema
|
|
(<A href="http://www.w3.org/TR/P3P/base">http://www.w3.org/TR/P3P/base</A>).
|
|
When the attribute appears as an empty string (""), the base is the local
|
|
document.
|
|
</DL>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><DATA></CODE></STRONG>
|
|
<DD>
|
|
describes the data to be transferred or inferred
|
|
<DT>
|
|
<STRONG><CODE>ref </CODE>(<EM>mandatory attribute)</EM></STRONG>
|
|
<DD>
|
|
<EM>URI reference</EM> ([<A href="#URI">URI</A>]), where the fragment identifier
|
|
part denotes the <EM>name of a data element/set</EM>, and the URI part denotes
|
|
the corresponding <EM>data schema</EM>. In case the URI part is not present,
|
|
if the <CODE>DATA</CODE> element is contained within a
|
|
<CODE>DATA-GROUP</CODE> element, then the default base URI is assumed to
|
|
be the URI of the <CODE>base</CODE> attribute. In the other cases, as usual,
|
|
the default base URI is a same-document reference
|
|
([<A href="#URI">URI</A>]).<BR>
|
|
Remember that <EM><STRONG>names of data elements and sets are
|
|
case-sensitive</STRONG></EM> (so, for example, <CODE>user.home</CODE> is
|
|
different from <CODE>USER.HOME</CODE> or <CODE>User.Home</CODE>).
|
|
<DT>
|
|
<STRONG><CODE>optional</CODE></STRONG>
|
|
<DD>
|
|
indicates whether or not the site requires visitors to submit this data element;
|
|
"no" indicates that the data element is required, while "yes" indicates that
|
|
the data element is not required. <EM>The default is "no".</EM> The
|
|
<CODE>optional</CODE> attribute is used only in policies (not in data schema
|
|
definitions).
|
|
</DL>
|
|
<P>
|
|
Note that user agents should be cautious about using the
|
|
<CODE>optional</CODE> attribute in automated decision-making. If the
|
|
<CODE>optional</CODE> attribute is associated with a data element directly
|
|
controlled by the user agent (such as the HTTP <CODE>Referer</CODE> header
|
|
or cookies), the user agent should make sure that this data is not transmitted
|
|
to Web sites at which a data element is optional if the site's policy would
|
|
not match a user's preferences if the data element was required. Likewise,
|
|
for data elements that users typically type into forms, user agents
|
|
should alert users when a site's practices about optional data do not match
|
|
their preferences.
|
|
<P>
|
|
<CODE>DATA</CODE> elements can contain the actual data (as already seen in
|
|
the case of the <CODE>ENTITY</CODE> element), and can contain related
|
|
<A href="#Categories">category</A> information.
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[43] </TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>data-group
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DATA-GROUP"
|
|
[" base=" quoted-URI]
|
|
">"
|
|
1*dataref
|
|
*extension
|
|
"</DATA-GROUP>"
|
|
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[44]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>dataref
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>`<DATA" ref="` URI-reference `"`
|
|
[" optional=" `"` ("yes"|"no") `"`] ">"
|
|
[categories] ; the <A href="#Categories">categories </A>of the data element.
|
|
[PCDATA] ; the eventual value of the data element
|
|
"</DATA>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4" bgcolor="#f5dcb3" valign="top">Here,
|
|
<CODE>URI-reference</CODE> is defined as in [<A href="#URI">URI</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
For example, to reference the user's home address city, all the elements
|
|
of the data set <CODE>user.business-info</CODE> and (optionally) all the
|
|
elements of the data set <CODE>user.home-info.telecom</CODE>, the service
|
|
would send the following references inside a P3P policy:
|
|
<PRE><DATA-GROUP>
|
|
<DATA ref="#user.home-info.city"/>
|
|
<DATA ref="#user.home-info.telecom" optional="yes"/>
|
|
<DATA ref="#user.business-info"/>
|
|
</DATA-GROUP>
|
|
</PRE>
|
|
<P>
|
|
When the actual value of the data is known, it can be expressed inside the
|
|
<CODE>DATA</CODE> element. For example, as seen in the
|
|
<A href="#encoding">example policies</A>:
|
|
<PRE> <ENTITY>
|
|
<DATA-GROUP>
|
|
<DATA ref="#business.name">CatalogExample</DATA>
|
|
<DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
|
|
...
|
|
</PRE>
|
|
<H2>
|
|
<A name="Categories">3.4 Categories</A>
|
|
</H2>
|
|
<P>
|
|
Categories are elements inside data elements that provide hints to users
|
|
and user agents as to the intended uses of the data. Categories are vital
|
|
to making P3P user agents easier to implement and use. Note that <EM>categories
|
|
are not data elements</EM>: they just allow users to express more generalized
|
|
preferences and rules over the exchange of their data.
|
|
<P>
|
|
The following elements are used to denote data categories:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[45]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>categories
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<CATEGORIES>" 1*category "</CATEGORIES>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[46]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>category
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<physical/>" | ; Physical Contact Information
|
|
"<online/>" | ; Online Contact Information
|
|
"<uniqueid/>" | ; Unique Identifiers
|
|
"<purchase/>" | ; Purchase Information
|
|
"<financial/>" | ; Financial Information
|
|
"<computer/>" | ; Computer Information
|
|
"<navigation/>" | ; Navigation and Click-stream Data
|
|
"<interactive/>" | ; Interactive Data
|
|
"<demographic/>" | ; Demographic and Socioeconomic Data
|
|
"<content/>" | ; Content
|
|
"<state/>" | ; State Management Mechanisms
|
|
"<political/>" | ; Political Information
|
|
"<health/>" | ; Health Information
|
|
"<preference/>" | ; Preference Data
|
|
"<government/> | ; Government-issued Identifiers
|
|
"<other-category>" PCDATA "</other-category>" ; Other
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><physical/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Physical Contact Information</STRONG>: Information that allows an
|
|
individual to be contacted or located in the physical world -- such as telephone
|
|
number or address.
|
|
<DT>
|
|
<STRONG><CODE><online/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Online Contact Information</STRONG>: Information that allows an
|
|
individual to be contacted or located on the Internet -- such as email. Often,
|
|
this information is independent of the specific computer used to access the
|
|
network. (See the category "Computer Information")
|
|
<DT>
|
|
<STRONG><CODE><uniqueid/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Unique Identifiers</STRONG>: Non-financial identifiers, excluding
|
|
government-issued identifiers, issued for purposes of consistently identifying
|
|
the individual. These include identifiers issued by a Web site or service.
|
|
<DT>
|
|
<STRONG><CODE><purchase/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Purchase Information</STRONG>: Information actively generated by
|
|
the purchase of a product or service, including information about the method
|
|
of payment.
|
|
<DT>
|
|
<STRONG><CODE><financial/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Financial Information</STRONG>: Information about an individual's
|
|
finances including account status and activity information such as account
|
|
balance, payment or overdraft history, and information about an individual's
|
|
purchase or use of financial instruments including credit or debit card
|
|
information. Information about a discrete purchase by an individual, as described
|
|
in "Purchase Information," alone does not come under the definition of "Financial
|
|
Information."
|
|
<DT>
|
|
<STRONG><CODE><computer/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Computer Information</STRONG>: Information about the computer system
|
|
that the individual is using to access the network -- such as the IP number,
|
|
domain name, browser type or operating system.
|
|
<DT>
|
|
<STRONG><CODE><navigation/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Navigation and Click-stream Data</STRONG>: Data <EM>passively</EM>
|
|
generated by <EM>browsing</EM> the Web site -- such as which pages are visited,
|
|
and how long users stay on each page.
|
|
<DT>
|
|
<STRONG><CODE><interactive/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Interactive Data</STRONG>: Data <EM>actively</EM> generated from
|
|
or reflecting <EM>explicit interactions</EM> with a service provider through
|
|
its site -- such as queries to a search engine, or logs of account activity.
|
|
<DT>
|
|
<STRONG><CODE><demographic/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Demographic and Socioeconomic Data</STRONG>: Data about an individual's
|
|
characteristics -- such as gender, age, and income.
|
|
<DT>
|
|
<STRONG><CODE><content/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Content</STRONG> : The words and expressions contained in the body
|
|
of a communication -- such as the text of email, bulletin board postings,
|
|
or chat room communications.
|
|
<DT>
|
|
<STRONG><CODE><state/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>State Management Mechanisms</STRONG>: Mechanisms for maintaining
|
|
a stateful session with a user or automatically identifying users who have
|
|
visited a particular site or accessed particular content previously -- such
|
|
as HTTP cookies.
|
|
<DT>
|
|
<STRONG><CODE><political/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Political Information</STRONG>: Membership in or affiliation with
|
|
groups such as religious organizations, trade unions, professional associations,
|
|
political parties, etc.
|
|
<DT>
|
|
<STRONG><CODE><health/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Health Information</STRONG>: information about an individual's physical
|
|
or mental health, sexual orientation, use or inquiry into health care services
|
|
or products, and purchase of health care services or products.
|
|
<DT>
|
|
<STRONG><CODE><preference/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Preference Data</STRONG>: Data about an individual's likes and dislikes
|
|
-- such as favorite color or musical tastes.
|
|
<DT>
|
|
<STRONG><CODE><location/></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Location Data</STRONG>: Information that can be used to identify
|
|
an individual's current physical location and track them as their location
|
|
changes -- such as GPS position data.
|
|
<DT>
|
|
<CODE><STRONG><government/></STRONG></CODE>
|
|
<DD>
|
|
<STRONG>Government-issued Identifiers</STRONG>: Identifiers issued by a
|
|
government for purposes of consistently identifying the individual.
|
|
<DT>
|
|
<STRONG><CODE><other-category> </CODE><EM>string</EM>
|
|
<CODE></other-category></CODE></STRONG>
|
|
<DD>
|
|
<STRONG>Other</STRONG>: Other types of data not captured by the above
|
|
definitions. (A human readable explanation should be provided in these instances,
|
|
between the <CODE><other-category></CODE> and the
|
|
<CODE></other-category></CODE> tags.)
|
|
</DL>
|
|
<P>
|
|
The <STRONG>Computer</STRONG>, <STRONG>Navigation</STRONG>,
|
|
<STRONG>Interactive</STRONG> and <STRONG>Content</STRONG> categories can
|
|
be distinguished as follows. The Computer category includes information about
|
|
the user's computer including IP address and software configuration. Navigation
|
|
data describes actual user behavior related to browsing. When an IP address
|
|
is stored in a log file with information related to browsing activity, both
|
|
the Computer category and the Navigation category should be used. Interactive
|
|
Data is data actively solicited to provide some useful service at a site
|
|
beyond browsing. Content is information exchanged on a site for the purposes
|
|
of communication.
|
|
<P>
|
|
The <STRONG>Other</STRONG> category should be used only when data is requested
|
|
that does not fit into any other category.
|
|
<P>
|
|
P3P uses categories to give users and user agents additional hints as to
|
|
what type of information is requested from a service. While most data in
|
|
the Base Data Schema is in a known category (or a set of known categories),
|
|
some data elements can be in a number of different categories, depending
|
|
on the situation. The former are called <EM>fixed-category data elements</EM>
|
|
(or "fixed data elements" for short), the latter <EM>variable-category data
|
|
elements</EM> ("variable data elements"). Both types of elements are briefly
|
|
described in the two sections below.
|
|
<H2>
|
|
<A name="extension">3.5 Extension Mechanism</A>
|
|
</H2>
|
|
<P>
|
|
P3P provides a flexible and powerful mechanism to extend its syntax and semantics
|
|
using one element: <CODE>EXTENSION</CODE>. This element is used to indicate
|
|
portions of the policy which belong to an extension. The meaning of the data
|
|
within the <CODE>EXTENSION</CODE> element is defined by the extension itself.
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE><EXTENSION></CODE></STRONG>
|
|
<DD>
|
|
describes an extension to the syntax
|
|
<DT>
|
|
<STRONG><CODE>optional</CODE></STRONG>
|
|
<DD>
|
|
This attribute determines if the extension is <EM>mandatory</EM> or
|
|
<EM>optional</EM>. A <EM>mandatory</EM> extension is indicated by giving
|
|
the <CODE>optional</CODE> attribute a value of <CODE>no</CODE>. A
|
|
<EM>mandatory</EM> extension to the P3P syntax means that applications that
|
|
do not understand this extension cannot understand the meaning of the whole
|
|
policy (or data schema). An <EM>optional</EM> extension, indicated by giving
|
|
the optional attribute a value of <CODE>yes</CODE>, means that applications
|
|
that do not understand this extension can safely ignore the contents of the
|
|
<CODE>EXTENSION</CODE> element, and proceed to process the whole policy (or
|
|
data schema) as usual. The <CODE>optional</CODE> attribute is not required;
|
|
its default value is <CODE>yes</CODE>.
|
|
</DL>
|
|
<TABLE border="0" cellspacing="0" cellpadding="0" width="100%">
|
|
<TR>
|
|
<TD valign="top" bgcolor="#F5DCB3">[47]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>extension
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#F5DCB3"><PRE>"<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
For example, if www.catalog.example.com would like to add to P3P a feature
|
|
to indicate that a certain set of data elements were only to be collected
|
|
from users living in the United States, Canada, or Mexico, it could add a
|
|
mandatory extension like this:
|
|
<PRE><DATA-GROUP>
|
|
...
|
|
<EXTENSION>
|
|
<COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalog.example.com/P3P/region">
|
|
<USA/><Canada/><Mexico/>
|
|
</COLLECTION-GEOGRAPHY>
|
|
</EXTENSION>
|
|
</DATA-GROUP>
|
|
</PRE>
|
|
<P>
|
|
On the other hand, if www.catalog.example.com would like to add an extension
|
|
stating what country the server is in, an optional extension might be more
|
|
appropriate, such as the following:
|
|
<PRE><POLICY>
|
|
<EXTENSION optional="yes">
|
|
<ORIGIN xmlns="http://www.catalog.example.com/P3P/origin" country="USA"/>
|
|
</EXTENSION>
|
|
...
|
|
</POLICY>
|
|
</PRE>
|
|
<P>
|
|
The <CODE>xmlns</CODE> attribute is significant since it specifies the namespace
|
|
for interpreting the names of elements and attributes used in the extension.
|
|
Note that, as specified in [<A href="#XML-Name">XML-Name</A>], the namespace
|
|
URI is just intended to be a unique identifier for the XML entities used
|
|
by the extension. Nevertheless, service providers MAY provide a page with
|
|
a description of the extension at the corresponding URI.
|
|
<H2>
|
|
<A NAME="PREFERENCES">3.6 Import and Export of User Preferences</A>
|
|
</H2>
|
|
<P>
|
|
User agents MUST document a method by which preferences can be imported and
|
|
processed, and SHOULD document a method by which preferences can be exported.
|
|
<H1>
|
|
<A NAME="compact_policies">4. Compact Policies</A>
|
|
</H1>
|
|
<P>
|
|
Compact policies are summarized P3P policies that provide hints to user agents
|
|
to enable the user agent to make quick, synchronous decisions about applying
|
|
policy. Compact policies are a performance optimization that is
|
|
<STRONG>OPTIONAL</STRONG> for either user agents or servers. User agents
|
|
that are unable to obtain enough information from a compact policy to make
|
|
a decision according to a user's preferences SHOULD fetch the full policy.
|
|
<P>
|
|
In P3Pv1, compact policies contain policy information related to cookies
|
|
only. The web server is responsible for building a P3P compact policy to
|
|
represent the cookies referenced in a full policy. The policy specified in
|
|
a P3P compact policy applies to data stored within the cookie and also to
|
|
data the cookie references at a web site.
|
|
<H2>
|
|
<A NAME="referencing_compact_policies">4.1 Referencing compact policies</A>
|
|
</H2>
|
|
<P>
|
|
Any document transferred by HTTP MAY include a P3P compact policy through
|
|
the P3P: header. If a site is using P3P headers, it MAY include this on responses
|
|
for all appropriate request methods, including <CODE>HEAD</CODE> and
|
|
<CODE>OPTION</CODE> requests.
|
|
<P>
|
|
To specify a compact policy within the P3P header, a site specifies the compact
|
|
policy in the P3P header (cf. <A HREF="#syntax_ext">Section 2.2.2</A>). The
|
|
P3P compact policy header has a quoted string that may contain one or more
|
|
delimited tokens (the "compact policy"). Spaces are the only valid delimiters.
|
|
The syntax for this header is as follows:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[48]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-policy-field
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>`CP="` compact-policy `"`
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[49]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-policy
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>compact-access
|
|
[" " compact-disputes]
|
|
[*(" " compact-remedies)]
|
|
[" " compact-non-identifiable]
|
|
[1*(" " compact-purpose)]
|
|
[1*(" "compact-recipient)]
|
|
1*(" " compact-retention)
|
|
[*(" " compact-category)]<BR>[compact-test]
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
In keeping with the rules for HTTP headers, the P3P portion of this header
|
|
may be written in any case.
|
|
<P>
|
|
User agents MAY process the P3P-compact-policy-field.
|
|
<H2>
|
|
<A NAME="compact_policy_vocabulary">4.2 Compact Policy Vocabulary</A>
|
|
</H2>
|
|
<P>
|
|
P3P compact policies support the following elements from the P3P vocabulary:
|
|
<CODE>ACCESS</CODE>, <CODE>CATEGORIES</CODE>, <CODE>DISPUTES</CODE>,
|
|
<CODE>NON-INDENTIFIABLE</CODE>, <CODE>PURPOSE</CODE>, <CODE>RECIPIENT</CODE>,
|
|
<CODE>REMEDIES</CODE>, <CODE>RETENTION</CODE>, <CODE>TEST</CODE>.
|
|
<P>
|
|
The P3P compact policy vocabulary is expressed using a developer-readable
|
|
language to reduce the number of bytes transferred over the wire within a
|
|
HTTP response header. The syntax of the tokens follows:
|
|
<H3>
|
|
<A NAME="compact_purposes">4.2.1 Compact <CODE>PURPOSE</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Purposes are expressed in P3P compact policy format using a three letter
|
|
code plus an optional one letter attribute. Such optional attribute encodes
|
|
the value of the "<CODE>required</CODE>" attribute in full P3P policies:
|
|
its value can be "<CODE>a</CODE>", "<CODE>i</CODE>" and "<CODE>o</CODE>",
|
|
which mean that the "<CODE>required</CODE>" attribute in the corresponding
|
|
P3P policy must be set to "<CODE>always</CODE>", "<CODE>opt-in</CODE>" and
|
|
"<CODE>opt-out</CODE>" respectively.
|
|
<P>
|
|
If a P3P compact policy needs to specify one or more other-purposes in its
|
|
full P3P policy, a single <CODE>OTP</CODE> flag is used to signal the user-agent
|
|
that other-purposes exist in the full P3P policy.
|
|
<P>
|
|
The corresponding associations among P3P purposes and compact policy codes
|
|
follow:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[50]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-purpose
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"CUR" [creq] | ; for <current/>
|
|
"ADM" [creq] | ; for <admin/>
|
|
"DEV" [creq] | ; for <develop/>
|
|
"CUS" [creq] | ; for <customization/>
|
|
"TAI" [creq] | ; for <tailoring/>
|
|
"PSA" [creq] | ; for <presudo-analysis/>
|
|
"PSD" [creq] | ; for <preudo-decision/>
|
|
"IVA" [creq] | ; for <individual-analysis/>
|
|
"IVD" [creq] | ; for <indovidual-decision/>
|
|
"CON" [creq] | ; for <contact/>
|
|
"HIS" [creq] | ; for <historical/>
|
|
"TEL" [creq] | ; for <telemarketing/>
|
|
"OPT" [creq] ; for <other-purpose/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[51]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>creq
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"a"| ;"always"
|
|
"i"| ;"opt-in"
|
|
"o" ;"opt-out"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_recipients">4.2.2 Compact <CODE>RECIPIENT</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Recipients are expressed in P3P compact policy format using a three letter
|
|
code plus an optional one letter attribute. Such optional attribute encodes
|
|
the value of the "<CODE>required</CODE>" attribute in full P3P policies:
|
|
its value can be "<CODE>a</CODE>", "<CODE>i</CODE>" and "<CODE>o</CODE>",
|
|
which mean that the "<CODE>required</CODE>" attribute in the corresponding
|
|
P3P policy must be set to "<CODE>always</CODE>", "<CODE>opt-in</CODE>" and
|
|
"<CODE>opt-out</CODE>" respectively.
|
|
<P>
|
|
The corresponding associations among P3P recipients and compact policy codes
|
|
follow:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[52]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-recipient
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"OUR" | ; for <ours/>
|
|
"DEL" [creq] | ; for <delivery/>
|
|
"SAM" [creq] | ; for <same/>
|
|
"UNR" [creq] | ; for <unrelated/>
|
|
"PUB" [creq] | ; for <public/>
|
|
"OTR" [creq] ; for <other-recipient/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_retention">4.2.3 Compact <CODE>RETENTION</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Information in the <CODE>RETENTION</CODE> element is represented in compact
|
|
policies as follows:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[53]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-retention
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"NOR" | ; for <no-retention/>
|
|
"STP" | ; for <stated-purpose/>
|
|
"LEG" | ; for <legal-requirement/>
|
|
"BUS" | ; for <business-practices/>
|
|
"IND" ; for <indefinitely/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_categories">4.2.4 Compact <CODE>CATEGORIES</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Categories are represented in compact policies as follows:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[54]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-category
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"PHY" | ; for <physical/>
|
|
"ONL" | ; for <online/>
|
|
"UNI" | ; for <uniqueID/>
|
|
"PUR" | ; for <purchase/>
|
|
"FIN" | ; for <financial/>
|
|
"COM" | ; for <computer/>
|
|
"NAV" | ; for <navigation/>
|
|
"INT" | ; for <interactive/>
|
|
"DEM" | ; for <demographic/>
|
|
"CNT" | ; for <content/>
|
|
"STA" | ; for <state/>
|
|
"POL" | ; for <political/>
|
|
"HEA" | ; for <health/>
|
|
"PRE" | ; for <preference/>
|
|
"GOV" | ; for <government/>
|
|
"OTC" ; for <other-category/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Note that if a P3P policy specifies one or more <CODE>other-category</CODE>
|
|
in its full P3P policy, a <STRONG>single</STRONG> <CODE>OTC</CODE> token
|
|
is used to signal the user-agent that <CODE>other-category</CODE>'s exist
|
|
in the full P3P policy.
|
|
<H3>
|
|
<A NAME="compact_non_identifiable">4.2.5 Compact
|
|
<CODE>NON-IDENTIFIABLE</CODE></A>
|
|
</H3>
|
|
<P>
|
|
The presence of the <CODE>NON-IDENTIFIABLE</CODE> element is signaled by
|
|
the <CODE>NID</CODE> token:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[55]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-non-identifiable
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"NID" ; for <NON-IDENTIFIABLE/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_disputes">4.2.6 Compact <CODE>DISPUTES</CODE></A>
|
|
</H3>
|
|
<P>
|
|
If a full P3P policy contains a <CODE>DISPUTES-GROUP</CODE> element that
|
|
contains one or more <CODE>DISPUTES</CODE> elements, then the server should
|
|
signal the user agent by providing a <STRONG>single</STRONG>
|
|
"<CODE>DSP</CODE>" token in the P3P-compact policy field:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[56]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-disputes
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"DSP" ; there is some DISPUTES
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_access">4.2.7 Compact <CODE>ACCESS</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Information in the <CODE>ACCESS</CODE> element is represented in compact
|
|
policies as follows:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[57]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-access
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"NOI" | ; for <nonident/>
|
|
"ALL" | ; for <all/>
|
|
"CAO" | ; for <contact-and-other/>
|
|
"IDC" | ; for <ident-contact/>
|
|
"OTI" | ; for <other-ident/>
|
|
"NON" ; for <none/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H3>
|
|
<A NAME="compact_remedies">4.2.8 Compact <CODE>REMEDIES</CODE></A>
|
|
</H3>
|
|
<P>
|
|
Information in the <CODE>REMEDIES</CODE> element is represented in compact
|
|
policies as follows:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[58]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-remedies
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"COR" | ; for <correct/>
|
|
"MON" | ; for <money/>
|
|
"LAW" ; for <law/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
<A NAME="compact_test">4.2.9 Compact <CODE>TEST</CODE></A>
|
|
</H3>
|
|
<P>
|
|
The presence of the <CODE>TEST</CODE> element is signaled by the
|
|
<CODE>TST</CODE> token:
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%" bgcolor="#F5DCB3">
|
|
<TR>
|
|
<TD valign="top" width="3%" bgcolor="#F5DCB3">[59]</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3" width="211"><PRE>compact-test
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD valign="top" bgcolor="#F5DCB3"><PRE>"TST" ; for <TEST/>
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
<H2>
|
|
<A NAME="compact_policy_scope">4.3 Compact Policy Scope</A>
|
|
</H2>
|
|
<P>
|
|
When a P3P compact policy is included in a HTTP response header, it applies
|
|
to cookies set by the current response. This includes cookies set through
|
|
the use of a HTTP <CODE>SET-COOKIE</CODE> header or a cookies set by script.
|
|
<P>
|
|
Since compact policies can only apply policy to cookies set in the current
|
|
response, compact policies cannot apply policy to cookies from a different
|
|
namespace. The <CODE>COOKIE-INCLUDE </CODE>element has this capability
|
|
<H2>
|
|
<A NAME="compact_policy_lifetime">4.4 Compact Policy Lifetime</A>
|
|
</H2>
|
|
<P>
|
|
To use compact policies, the validity of the full P3P policy must span the
|
|
lifetime of the cookie. There is no method to indicate that policy is valid
|
|
beyond the life of the cookie because the value of user-agent caching is
|
|
marginal, since sites would not know when to optimize by not sending the
|
|
compact policy. When a server sends a compact policy, it is asserting that
|
|
the compact policy and corresponding full P3P policy will be in effect for
|
|
at least the lifetime of the cookie to which it applies.
|
|
<H2>
|
|
<A NAME="full_into_compact">4.5 Transforming a P3P Policy to a Compact
|
|
Policy</A>
|
|
</H2>
|
|
<P>
|
|
When using P3P compact policies, the web site is responsible for building
|
|
a compact policy by summarizing the policy referenced by the
|
|
<CODE>COOKIE-INCLUDE</CODE> elements of a P3P policy. The transformation
|
|
of a P3P policy to a P3P compact policy may result in a loss of descriptive
|
|
policy information – the compact policy may not contain all of the policy
|
|
information specified in the full P3P policy. Full policies that include
|
|
mandatory extensions MUST not be represented as compact policies.
|
|
<P>
|
|
If a site’s policy uses <CODE>COOKIE-EXCLUDE</CODE> elements then the
|
|
site will need to manage sending the correct P3P compact policies to the
|
|
user agent given the cookies set in a specific response.
|
|
<P>
|
|
In addition to the <CODE>COOKIE-EXCLUDE</CODE> elements, other information
|
|
from the full policy is discarded when building a compact policy. This includes
|
|
expiry, data group/data-schema elements, entity elements, consequences elements,
|
|
and disputes elements are reduced.
|
|
<P>
|
|
All of the purposes, recipients, and categories that appear in multiple
|
|
statements in a full policy MUST be aggregated in a compact policy, as described
|
|
in section 3.3.1. When performing the aggregation, a web site MUST disclose
|
|
all relevant tokens (for instance, observe the following example, where multiple
|
|
retention policies are specified.)
|
|
<P>
|
|
<STRONG>Example 4.1:</STRONG>
|
|
<P>
|
|
Consider the following P3P policy:
|
|
<PRE><POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
|
|
discuri="http://www.example.com/cookiepolicy.html"
|
|
opturi="http://www.example.com/opt.html">
|
|
<ENTITY>
|
|
<DATA-GROUP>
|
|
<DATA ref="#business.name">Example, Corp.</DATA>
|
|
<DATA ref="#business.contact-info.online.email">privacy@example.com</DATA>
|
|
</DATA-GROUP>
|
|
</ENTITY>
|
|
<ACCESS><none/></ACCESS>
|
|
<DISPUTES-GROUP>
|
|
<DISPUTES resolution-type="service"
|
|
service="http://www.example.com/privacy.html"
|
|
short-description="Please contact our customer service desk with
|
|
privacy concerns by emailing privacy@example.com"/>
|
|
</DISPUTES-GROUP>
|
|
<STATEMENT>
|
|
<PURPOSE><admin/><develop/><pseudo-decision/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><indefinitely/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.cookies">
|
|
<CATEGORIES><preference/><navigation/></CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<PURPOSE><customization required="opt_out"/></PURPOSE>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<RETENTION><stated-purpose/></RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.cookies">
|
|
<CATEGORIES><preference/><uniqueid/></CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</PRE>
|
|
<P>
|
|
The corresponding compact policy is:
|
|
<PRE>"NON DSP ADM DEV PSD CUSo OUR IND STP PRE NAV UNI"
|
|
</PRE>
|
|
<H2>
|
|
<A NAME="compact_into_full">4.6 Transforming a Compact Policy to a P3P
|
|
Policy</A>
|
|
</H2>
|
|
<P>
|
|
Some user agents may attempt to generate a full P3P policy from a compact
|
|
policy, for use in evaluating user preferences. They will not be able to
|
|
provide values for the <CODE>ENTITY</CODE> and <CODE>DISPUTES</CODE> elements
|
|
as well as a number of the attributes. However:
|
|
<DL>
|
|
<DT>
|
|
In case there <EM>are not</EM> multiple different values of compact retention,
|
|
<DD>
|
|
they should be able to generate a policy with an appropriate
|
|
<CODE>ACCESS</CODE> element, and: a single <CODE>STATEMENT</CODE> element
|
|
that contains the appropriate <CODE>RECIPIENT</CODE>, <CODE>RETENTION</CODE>,
|
|
and <CODE>PURPOSE</CODE> elements, as well as a
|
|
<CODE><A HREF="#Dynamic_Data">dynamic.miscdata</A></CODE> element with the
|
|
appropriate <CODE>CATEGORIES</CODE>.
|
|
<DT>
|
|
In case there <EM>are</EM> multiple different values of compact retention,
|
|
<DD>
|
|
they should be able to generate a policy with an appropriate
|
|
<CODE>ACCESS</CODE> element, and: multiple <CODE>STATEMENT</CODE> elements
|
|
(as many as the different values of the compact retention) that contain a
|
|
different corresponding value for the <CODE>RETENTION</CODE> element, the
|
|
appropriate <CODE>RECIPIENT</CODE>, and <CODE>PURPOSE</CODE> elements, as
|
|
well as a <CODE><A HREF="#Dynamic_Data">dynamic.miscdata</A></CODE> element
|
|
with the appropriate <CODE>CATEGORIES</CODE>.
|
|
</DL>
|
|
<H1>
|
|
<A name="Data_Schemas">5. Data Schemas</A>
|
|
</H1>
|
|
<P>
|
|
P3P has the ability to define <EM>data schemas</EM> to provide a common way
|
|
for services and user agents to refer to data elements. A data schema describes
|
|
specific data elements, which may be grouped into hierarchical data sets.
|
|
<P>
|
|
In order to provide <EM>multilingual support</EM> for data schema files,
|
|
a server can supply the right alternative based on the HTTP
|
|
<CODE>Accept-Language</CODE> header.
|
|
<P>
|
|
Services may declare and use data elements by creating a data schema and
|
|
referencing it in a policy using the <CODE>DATA</CODE> element. P3P comes
|
|
with a standard data schema, the
|
|
<EM><STRONG><A href="#Base_Data_Schema">P3P Base Data
|
|
Schema</A></STRONG></EM>, that defines a wide variety of commonly used data
|
|
elements.
|
|
<P>
|
|
Data elements often come in groups with certain common elements: thus, P3P
|
|
also allows <EM>structures</EM> to be defined. A <EM>structure</EM> is
|
|
a collection of specified data elements. New structures can be defined, and
|
|
P3P also provides built-in <STRONG><EM><A href="#Data_Types">basic data
|
|
structures</A></EM></STRONG>, which can be conveniently reused by other new
|
|
schemas.
|
|
<P>
|
|
The <CODE><DATASCHEMA></CODE> element contains references to the new
|
|
data elements.
|
|
<P>
|
|
<TABLE bgcolor="#f5dcb3" border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[60]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>dataschema
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DATASCHEMA" [` xmlns="http://www.w3.org/2000/12/P3Pv1"`] ">"
|
|
*(datadef|datastruct|extension)
|
|
"</DATASCHEMA>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Data schemas can be <EM>embedded</EM> in a policy, or expressed as a
|
|
<EM>stand-alone XML file</EM>. In the second case, the appropriate XML namespace
|
|
attribute <CODE>xmlns</CODE> MUST be used to indicate this is a P3P data
|
|
schema file:
|
|
<PRE><DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<DATA-STRUCT ... />
|
|
...
|
|
<DATA-DEF ... />
|
|
</DATASCHEMA>
|
|
</PRE>
|
|
<H2>
|
|
<A name="DATA-DEF-TYPE">5.1 The <CODE><STRONG>DATA-DEF</STRONG></CODE> and
|
|
<STRONG><CODE>DATA-STRUCT</CODE></STRONG> elements</A>
|
|
</H2>
|
|
<DL>
|
|
<DT>
|
|
<CODE><STRONG><DATA-DEF></STRONG></CODE> and
|
|
<STRONG><CODE><DATA-STRUCT></CODE></STRONG>
|
|
<DD>
|
|
Define a data element or a data structure, respectively.
|
|
</DL>
|
|
<P>
|
|
The following attributes are common to these two elements:
|
|
<DL>
|
|
<DT>
|
|
<STRONG><CODE>name </CODE>(<EM>mandatory attribute)</EM></STRONG>
|
|
<DD>
|
|
Indicates the name of the data element or data structure. Remember that names
|
|
of data element and data structures are <STRONG>case-sensitive</STRONG>,
|
|
so, for example, <CODE>user.home</CODE> is different from
|
|
<CODE>USER.HOME</CODE> or <CODE>User.Home</CODE>. Furthermore, in names of
|
|
data elements and structures no number character can appear immediately following
|
|
a dot.
|
|
<DT>
|
|
<STRONG><CODE>structref</CODE></STRONG>
|
|
<DD>
|
|
<EM>URI reference</EM> ([<A href="#URI">URI</A>]), where the fragment identifier
|
|
part denotes the <EM>structure</EM>, and the URI part denotes the corresponding
|
|
<EM>data schema</EM> where it is defined. The default base URI is a same-document
|
|
reference ([<A href="#URI">URI</A>]). Data elements or data structures without
|
|
a <CODE>structref</CODE> attribute (and, so, without an associated structure)
|
|
are called <EM>unstructured</EM>.
|
|
<DT>
|
|
<STRONG><CODE>short-description</CODE></STRONG>
|
|
<DD>
|
|
a string denoting the short display name of the data element or structure,
|
|
no more than 255 <A href="#character">characters</A>.
|
|
</DL>
|
|
<P>
|
|
The <CODE>DATA-DEF</CODE> and <CODE>DATA-STRUCT</CODE> elements can also
|
|
contain a long description of the data element or structure, using the
|
|
<CODE><A href="#LONG-DESCRIPTION">LONG-DESCRIPTION</A></CODE> element.
|
|
<P>
|
|
<TABLE border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[61]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>datadef
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DATA-DEF name=" quotedstring
|
|
[` structref="` URI-reference `"`]
|
|
[" short-description=" quotedstring]
|
|
">"
|
|
[categories] ; the <A href="#Categories">categories </A>of the data element.
|
|
[longdescription] ; the long description of the data element
|
|
"</DATA-DEF>"
|
|
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD bgcolor="#f5dcb3" valign="top">[62]</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>datastruct
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3" valign="top"><PRE>=
|
|
</PRE>
|
|
</TD>
|
|
<TD bgcolor="#f5dcb3"><PRE>"<DATA-STRUCT name=" quotedstring
|
|
[` structref="` URI-reference `"`]
|
|
[" short-description=" quotedstring]
|
|
">"
|
|
[categories] ; the <A href="#Categories">categories </A>of the Data Structure.
|
|
[longdescription] ; the long description of the Data Structure
|
|
"</DATA-STRUCT>"
|
|
</PRE>
|
|
</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD colspan="4" bgcolor="#f5dcb3" valign="top">Here,
|
|
<CODE>URI-reference</CODE> is defined as in [<A href="#URI">URI</A>].</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
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 <CODE>name</CODE> attribute
|
|
using a full stop ("<CODE>.</CODE>") character as separator.
|
|
<P>
|
|
For example, the company HyperSpeedExample might want to describe the features
|
|
of a vehicle, using a structure called <CODE>vehicle</CODE> that includes
|
|
features like a vehicle's model (<CODE>vehicle.model</CODE>), color
|
|
(<CODE>vehicle.color</CODE>), year of manufacture
|
|
(<CODE>vehicle.built.year</CODE>), price (<CODE>vehicle.price</CODE> ).
|
|
<P>
|
|
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: <EM>structures
|
|
can be composed</EM>. In this case, the
|
|
<EM><STRONG><A href="#Base_Data_Schema">P3P Base Data
|
|
Schema</A></STRONG></EM> (which provides built-in definitions of widely used
|
|
structures and data elements) already provides a structure
|
|
<CODE>postal</CODE>, describing all the postal information of a location.
|
|
So, the final definition of the structure vehicle is
|
|
<P>
|
|
<CODE>vehicle.model</CODE> (unstructured)<BR>
|
|
<CODE>vehicle.color</CODE> (unstructured)<BR>
|
|
<CODE>vehicle.built.year</CODE> (unstructured)<BR>
|
|
<CODE>vehicle.price</CODE> (unstructured)<BR>
|
|
<CODE>vehicle.built.where</CODE> (with basic structure <CODE>postal</CODE>)
|
|
<P>
|
|
The basic structure postal has descriptions of the form
|
|
<CODE>postal.street</CODE>, <CODE>postal.city</CODE>, and so on. Since we
|
|
have applied the structure postal to <CODE>vehicle.built.where</CODE>, it
|
|
means that we can access the street and city of a vehicle using the descriptions
|
|
<CODE>vehicle.built.where.street</CODE> and
|
|
<CODE>vehicle.built.where.city</CODE> respectively. So, applying a structure
|
|
(in this case, <CODE>postal</CODE>) means we can build very complex descriptions
|
|
in a modular way.
|
|
<P>
|
|
As said, structures do not contain data elements, they are just abstract
|
|
descriptions: 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
|
|
<CODE>car</CODE> and <CODE>motorcycle</CODE>, both with the above structure
|
|
<CODE>vehicle</CODE>.
|
|
<P>
|
|
This description of the data elements (actual data elements plus, if the
|
|
case, the structures needed to describe them) is encoded in XML using a data
|
|
schema. In the HyperSpeedExample case, it would be something like:
|
|
<PRE><DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<DATA-STRUCT name="vehicle.model"
|
|
short-description="Model">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.color"
|
|
short-description="Color">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.built.year"
|
|
short-description="Construction Year">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.built.where"
|
|
structref="http://www.w3.org/TR/P3P/base#postal"
|
|
short-description="Construction Place">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-DEF name="car" structref="#vehicle"/>
|
|
<DATA-DEF name="motorcycle" structref="#vehicle"/>
|
|
</DATASCHEMA>
|
|
</PRE>
|
|
<P>
|
|
Continuing with the example, in order to reference a car model and construction
|
|
year, Hyperspeed <EM>or any other service</EM> could send the following
|
|
references inside a P3P policy:
|
|
<PRE><DATA-GROUP>
|
|
<!-- First, the "car.model" data element, whose definition is in the data schema
|
|
at http://www.HyperSpeed.example.com/models-schema
|
|
-->
|
|
<DATA ref="http://www.HyperSpeed.example.com/models-schema#car.model"/>
|
|
|
|
<!-- And second, the "car.built.year" data element, whose definition is the data schema
|
|
at http://www.HyperSpeed.example.com/models-schema
|
|
-->
|
|
<DATA ref="http://www.HyperSpeed.example.com/models-schema#car.built.year"/>
|
|
</DATA-GROUP>
|
|
</PRE>
|
|
<P>
|
|
As structures can also carry category information, in the above references
|
|
both of the data elements are of category
|
|
<CODE><preference/></CODE>, since this is the category specified in
|
|
the <CODE>vehicle</CODE> structures for the attributes <CODE>model</CODE>
|
|
and <CODE>vehicle</CODE>.
|
|
<P>
|
|
Using the <CODE><A href="#base_attribute">base</A></CODE> attribute, the
|
|
above references can be written in an even more compact way:
|
|
<PRE><DATA-GROUP base="http://www.HyperSpeed.example.com/models-schema">
|
|
<DATA ref="#car.model"/>
|
|
<DATA ref="#car.built.year"/>
|
|
</DATA-GROUP>
|
|
</PRE>
|
|
<P>
|
|
Alternatively, the data schema could be <EM>embedded</EM> directly into a
|
|
policy file. In this case, the policy file could look like:
|
|
<PRE><CODE><POLICY xmlns="http://www.w3.org/2000/12/P3Pv1" ... ></CODE>
|
|
<!-- Here the embedded data schema begins -->
|
|
<DATASCHEMA>
|
|
<DATA-STRUCT name="vehicle.model"
|
|
short-description="Model">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.color"
|
|
short-description="Color">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.built.year"
|
|
short-description="Construction Year"">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-STRUCT name="vehicle.built.where"
|
|
structref="http://www.w3.org/TR/P3P/base#postal"
|
|
short-description="Construction Place">
|
|
<CATEGORIES><preference/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
<DATA-DEF name="car" structref="#vehicle"/>
|
|
<DATA-DEF name="motorcycle" structref="#vehicle"/>
|
|
</DATASCHEMA>
|
|
<!-- Now the policy begins -->
|
|
...
|
|
<DATA-GROUP base="">
|
|
<DATA ref="#car.model"/>
|
|
<DATA ref="#car.built.year"/>
|
|
</DATA-GROUP>
|
|
...
|
|
</POLICY>
|
|
</PRE>
|
|
<P>
|
|
Note that in any case there MUST NOT be more than one data schema per file
|
|
(so, care should be taken when embedding a data schema in a
|
|
<CODE>POLICY</CODE> contained in a <CODE>POLICIES</CODE> element).
|
|
<P>
|
|
Data elements and structures can be classified according to whether or not
|
|
they are in some fixed category (using the <CODE>category</CODE> element).
|
|
Schema designers can use this attribute within their schema definitions to
|
|
define an almost-invariable category for each element. Once defined, this
|
|
value <EM>cannot</EM> be changed when referencing such elements from within
|
|
user preferences and P3P policies, but it <EM>can</EM> be changed in other
|
|
schema definitions (in the vehicle example above we redefine as
|
|
<CODE>preference</CODE> the category for the <CODE>vehicle.built.where</CODE>
|
|
structure, while the <CODE>postal</CODE> structure, defined in the
|
|
<A href="#Base_Data_Schema">Base Data Schema</A>, has the
|
|
<CODE>physical</CODE> and <CODE>demographic</CODE> categories).
|
|
<P>
|
|
If the <CODE>CATEGORIES</CODE> element is not present (so, leaving the category
|
|
undefined), it MUST be explicitly listed in each P3P policy referencing such
|
|
elements. Users can have different preferences depending on different category
|
|
values for the same element. And in the case of undefined categories within
|
|
data <EM>structures</EM>, other schema definitions can explicitly set categories
|
|
in derived elements (otherwise the original definition overrides any value
|
|
in the derived schema).
|
|
<P>
|
|
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.
|
|
<H2>
|
|
<A name="dataschemas_immutability">5.2 Persistence of Data Schemas</A>
|
|
</H2>
|
|
<P>
|
|
An essential requirement on data schemas is the <EM><STRONG>persistence of
|
|
data schemas</STRONG></EM>: data schemas that can be fetched at a certain
|
|
URI can only be changed by extending the data schema in a
|
|
<EM>backward-compatible</EM> 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
|
|
<EM>must therefore use a new different URI</EM>.
|
|
<P>
|
|
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 "<CODE>Content-Language</CODE>" response header field to properly
|
|
indicate that a particular language has been used for the data schema.
|
|
<H2>
|
|
5.3 <A name="Data_Types">Basic Data Structures</A>
|
|
</H2>
|
|
<P>
|
|
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.
|
|
<H3>
|
|
5.3.1 <A name="Dates">Dates</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG>date</STRONG> structure specifies a date. Since date information
|
|
can be used in different ways, depending on the context, all
|
|
<STRONG>date</STRONG> information is tagged as being of "variable" category.
|
|
Schema definitions have to explicitly set the corresponding category in the
|
|
element referencing this data structure. For example, soliciting the birthday
|
|
of a user might be "Demographic and Socioeconomic Data", while the expiration
|
|
date of a credit card belongs to the "Purchase Information" category.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>date</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>ymd.year</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Year</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>ymd.month</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Month</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>ymd.day</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Day</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>hms.hour</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Hour</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>hms.minute</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Minute</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>hms.second</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Second</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>fractionsecond</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Fraction of Second</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>timezone</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Time Zone</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The "time zone" information is for example described in the time standard
|
|
[<A href="#ISO8601">ISO8601</A>]. Note that "date.ymd" and "date.hms" can
|
|
be used to fast reference the year/month/day and hour/minutes/seconds blocks
|
|
respectively.
|
|
<H3>
|
|
5.3.2 <A name="Names">Names</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG>personname</STRONG> structure specifies information about the
|
|
naming of a person.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>personname</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>prefix</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Name Prefix</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>given</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Given Name (First Name)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>family</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Family Name (Last Name)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>middle</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Middle Name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>suffix</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Name Suffix</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>nickname</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Nickname</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
5.3.3 <A name="Certificates">Certificates</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG>certificate</STRONG> structure is used to specify identity
|
|
certificates (like, for example, X.509).
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>certificate</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>key</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Certificate Key</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>format</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Certificate Format</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
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.
|
|
<H3>
|
|
5.3.4 <A name="Telephones">Telephones</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG>telephonenum</STRONG> structure specifies the characteristics
|
|
of a telephone number.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>telephonenum</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>intcode</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>International Telephone code</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>loccode</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Local Telephone Area code</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>number</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Telephone Number</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>ext</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Telephone Extension</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>comment</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Telephone Optional Comments</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
5.3.5 <A name="Contact_Information">Contact Information</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG>contact</STRONG> structure is used to specify contact information.
|
|
Services can specify precisely which set of data they need, postal,
|
|
telecommunication, or online address information.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>contact</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>postal</TD>
|
|
<TD>Physical Contact Information, Demographic and Socioeconomic Data</TD>
|
|
<TD>postal</TD>
|
|
<TD>Postal Address Information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>telecom</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD>telecom</TD>
|
|
<TD>Telecommunications Information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>online</TD>
|
|
<TD>Online Contact Information</TD>
|
|
<TD>online</TD>
|
|
<TD>Online Address Information</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H4>
|
|
5.3.5.1 <A name="Postal">Postal</A>
|
|
</H4>
|
|
<P>
|
|
The <STRONG>postal</STRONG> structure specifies a postal mailing address.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>postal</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>name</TD>
|
|
<TD>Physical Contact Information, Demographic and Socioeconomic Data</TD>
|
|
<TD>personname</TD>
|
|
<TD>Name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>street</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Street Address</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>city</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>City</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>stateprov</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>State or Province</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>postalcode</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Postal code</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>country</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Country Name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>organization</TD>
|
|
<TD>Physical Contact Information, Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Organization Name</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The "country" field represents the information of the name of the country
|
|
(for example, one among the countries listed
|
|
in [<A href="#iso3166">ISO3166</A>]).
|
|
<H4>
|
|
5.3.5.2 <A name="Telecommunication">Telecommunication</A>
|
|
</H4>
|
|
<P>
|
|
The <STRONG>telecom</STRONG> structure specifies telecommunication information
|
|
about a person.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>telecom</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>telephone</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD>telephonenum</TD>
|
|
<TD>Telephone number</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>fax</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD>telephonenum</TD>
|
|
<TD>Fax number</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>mobile</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD>telephonenum</TD>
|
|
<TD>Mobile Telephone number</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>pager</TD>
|
|
<TD>Physical Contact Information</TD>
|
|
<TD>telephonenum</TD>
|
|
<TD>Pager number</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H4>
|
|
5.3.5.3 <A name="Online">Online</A>
|
|
</H4>
|
|
<P>
|
|
The <STRONG>online</STRONG> structure specifies online information about
|
|
a person.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>online</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>email</TD>
|
|
<TD>Online Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Email Address</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>uri</TD>
|
|
<TD>Online Contact Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Home Page Address</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
5.3.6 <A name="Internet_Addresses">Access Logs and Internet Addresses</A>
|
|
</H3>
|
|
<P>
|
|
Two structures used for representing forms of Internet addresses are provided.
|
|
The <CODE>uri</CODE> structure covers Universal Resource Identifiers (URI),
|
|
which are defined in more detail in [<A href="#URI">URI</A>]. The
|
|
<CODE>ipaddr</CODE> structure represents IP addresses and Domain Name System
|
|
(DNS) hostnames.
|
|
<H4>
|
|
5.3.6.1 <A name="URI_data_structure">URI</A>
|
|
</H4>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>uri</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>authority</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>URI authority</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>stem</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>URI stem</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>querystring</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Query-string portion of URI</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The authority of a URI is defined as the <CODE>authority</CODE> component
|
|
in [<A href="#URI">URI</A>]. The stem of a URI is defined as the
|
|
information contained in the portion of the URI 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.
|
|
<P>
|
|
Since URI information can be used in different ways, depending on the context,
|
|
all the fields in the <CODE>uri</CODE> structure are tagged as being of
|
|
"variable" category. Schema definitions MUST explicitly set the corresponding
|
|
category in the element referencing this data structure.
|
|
<H4>
|
|
5.3.6.2 <A name="IPaddress_data_structure">ipaddr</A>
|
|
</H4>
|
|
<P>
|
|
The <CODE>ipaddr</CODE> structure represents the hostname and IP address
|
|
of a system.
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>ipaddr</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>hostname</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Complete host and domain name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>partialhostname</TD>
|
|
<TD>Demographic</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Partial hostname</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>fullip</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Full IP address</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>partialip</TD>
|
|
<TD>Demographic</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Partial IP address</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The <CODE>hostname</CODE> element is used to represent collection of either
|
|
the simple hostname of a system, or the full hostname including domain name.
|
|
The <CODE>partialhostname</CODE> element represents the information of a
|
|
fully-qualified hostname which has had <EM>at least</EM> 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".
|
|
<P>
|
|
The <CODE>fullip</CODE> element represents the information of a full IP version
|
|
4 or IP version 6 address. The <CODE>partialip</CODE> element represents
|
|
an IP version 4 address (only - not a version 6 address) which has had <EM>at
|
|
least</EM> 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).
|
|
<P>
|
|
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.
|
|
<H4>
|
|
<A name="access_log">5.3.6.3 Access Log Information</A>
|
|
</H4>
|
|
<P>
|
|
The <CODE>loginfo</CODE> structure is used to represent information typically
|
|
stored in Web-server access logs.
|
|
<P>
|
|
<TABLE width="100%" border="1" cellpadding="2">
|
|
<TR>
|
|
<TD><STRONG><CODE>loginfo</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>uri</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD>uri</TD>
|
|
<TD>URI of requested resource</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>timestamp</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD>date</TD>
|
|
<TD>Request timestamp</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>clientip</TD>
|
|
<TD>Computer Information</TD>
|
|
<TD>ipaddr</TD>
|
|
<TD>Client's IP address or hostname</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>other.httpmethod</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>HTTP request method</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>other.bytes</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Data bytes in response</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>other.statuscode</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Response status code</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The resource in the HTTP request is captured by the <CODE>uri</CODE> field.
|
|
The time at which the server processes the request is represented by the
|
|
<CODE>timestamp</CODE> 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
|
|
<CODE>clientip</CODE> field.
|
|
<P>
|
|
The <CODE>other</CODE> data fields represent other information commonly stored
|
|
in Web server access logs. <CODE>other.httpmethod</CODE> is the HTTP method
|
|
(such as <CODE>GET</CODE>, <CODE>POST</CODE>, etc) in the client's request.
|
|
<CODE>other.bytes</CODE> indicates the number of bytes in the response-body
|
|
sent by the server. <CODE>other.statuscode</CODE> is the HTTP status code
|
|
on the request, such as 200, 302, or 404 (see section 6.1.1 of
|
|
[<A href="#HTTP1_1_ref">HTTP1.1</A>] for details).
|
|
<H4>
|
|
5.3.6.4 <A name="other_http_info">Other HTTP Protocol Information</A>
|
|
</H4>
|
|
<P>
|
|
The <CODE>httpinfo</CODE> structure represents information carried by the
|
|
HTTP protocol which is not covered by the <CODE>loginfo</CODE> structure.
|
|
<TABLE width="100%" border="1" cellpadding="2">
|
|
<TR>
|
|
<TD><STRONG><CODE>httpinfo</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>referer</TD>
|
|
<TD>Navigation and click-stream data</TD>
|
|
<TD>uri</TD>
|
|
<TD>Last URI requested by the user</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>useragent</TD>
|
|
<TD>Computer Information</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>User agent information</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
The <CODE>useragent</CODE> field represents the information in the HTTP
|
|
<CODE>User-Agent</CODE> header (which gives information about the type and
|
|
version of the user's Web browser), and/or the HTTP <CODE>accept</CODE>*
|
|
headers.
|
|
<P>
|
|
The <CODE>referer</CODE> field represents the information in the HTTP
|
|
<CODE>Referer</CODE> 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.
|
|
<H2>
|
|
5.4 <A name="Base_Data_Schema">The Base Data Schema</A>
|
|
</H2>
|
|
<P>
|
|
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:
|
|
<STRONG><CODE>user</CODE></STRONG>,
|
|
<STRONG><CODE>thirdparty</CODE></STRONG>,
|
|
<STRONG><CODE>business</CODE></STRONG> and
|
|
<STRONG><CODE>dynamic</CODE></STRONG>. The <CODE>user</CODE>,
|
|
<CODE>thirdparty</CODE> and <CODE>business</CODE> sets include elements that
|
|
users and/or businesses might provide values for, while the
|
|
<CODE>dynamic</CODE> 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
|
|
<CODE>user</CODE> 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.
|
|
<P>
|
|
The formal XML definition of the P3P Base Data Schema is given in
|
|
<A href="#basedataxml">Appendix 3</A>. In the following sections, the base
|
|
data elements and sets are explained one by one. In the future there will
|
|
be in all likelihood <EM>demand for the creation of other data sets
|
|
and elements.</EM> Obvious applications include catalogue, payment, and
|
|
agent/system attribute schemas (an extensive set of system elements is provided
|
|
for example in
|
|
<A href="http://www.w3.org/TR/NOTE-agent-attributes">http://www.w3.org/TR/NOTE-agent-attributes</A>.)
|
|
<P>
|
|
Each table below specifies a <STRONG>set</STRONG>, 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.
|
|
<H3>
|
|
5.4.1 <A name="User_Data">User Data</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG><CODE>user</CODE></STRONG> data set includes general information
|
|
about the user.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>user</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>name</TD>
|
|
<TD>Physical Contact Information, Demographic and Socioeconomic Data</TD>
|
|
<TD>personname</TD>
|
|
<TD>User's Name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>bdate</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD>date</TD>
|
|
<TD>User's Birth Date</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>cert</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD>certificate</TD>
|
|
<TD>User's Identity Certificate</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>gender</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>User's Gender (male or female)</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>employer</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>User's Employer</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>department</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Department or division of organization where user is employed</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>jobtitle</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>User's Job Title</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>home-info</TD>
|
|
<TD>Physical Contact Information, Online Contact Information, Demographic
|
|
and Socioeconomic Data</TD>
|
|
<TD>contact</TD>
|
|
<TD>User's Home Contact Information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>business-info</TD>
|
|
<TD>Physical Contact Information, Online Contact Information, Demographic
|
|
and Socioeconomic Data</TD>
|
|
<TD>contact</TD>
|
|
<TD>User's Business Contact Information</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
Note, that this data set includes elements that are actually sets of data
|
|
themselves. These sets are defined in the <A href="#Data_Types">Data
|
|
Structures</A> 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
|
|
<CODE>user.home.postal.postalcode</CODE> 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.
|
|
<H3>
|
|
5.4.2 <A name="Third-Party-Data">Third Party Data</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG><CODE>thirdparty</CODE></STRONG> 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 <CODE>user</CODE> data set.
|
|
User agents may offer to store multiple such <CODE>thirdparty</CODE> data
|
|
sets and allow users to select the appropriate values from a list when necessary.
|
|
<P>
|
|
The <CODE>thirdparty</CODE> data set is identical with the <CODE>user</CODE>
|
|
data set. See section <A href="#User_Data">5.4.1 User Data</A> for details.
|
|
<H3>
|
|
5.4.3 <A name="Business-Data">Business Data</A>
|
|
</H3>
|
|
<P>
|
|
The <STRONG><CODE>business</CODE></STRONG> data set features a subset of
|
|
<CODE>user</CODE> data relevant for organizations. In P3P1.0, this data set
|
|
is primarily used for declaring the policy entity, though it should also
|
|
be applicable to business-to-business interactions.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>business</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>name</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Organization Name</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>department</TD>
|
|
<TD>Demographic and Socioeconomic Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Department or division of organization</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>cert</TD>
|
|
<TD>Unique Identifiers</TD>
|
|
<TD>certificate</TD>
|
|
<TD>Organization Identity Certificate</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>contact-info</TD>
|
|
<TD>Physical Contact Information, Online Contact Information, Demographic
|
|
and Socioeconomic Data</TD>
|
|
<TD>contact</TD>
|
|
<TD>Contact Information for the organization</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<H3>
|
|
5.4.4 <A name="Dynamic_Data">Dynamic Data</A>
|
|
</H3>
|
|
<P>
|
|
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
|
|
<CODE>dynamic</CODE> 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.
|
|
<P>
|
|
<TABLE border="1" cellpadding="2" width="100%">
|
|
<TR>
|
|
<TD><STRONG><CODE>dynamic</CODE></STRONG></TD>
|
|
<TD><STRONG>Category</STRONG></TD>
|
|
<TD><STRONG>Structure</STRONG></TD>
|
|
<TD><STRONG>Short display name</STRONG></TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>clickstream</TD>
|
|
<TD>Navigation and Click-stream Data, Computer Information</TD>
|
|
<TD>loginfo</TD>
|
|
<TD>Click-stream information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>http</TD>
|
|
<TD>Navigation and Click-stream Data, Computer Information</TD>
|
|
<TD>httpinfo</TD>
|
|
<TD>HTTP protocol information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>clientevents</TD>
|
|
<TD>Navigation and Click-stream Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>User's interaction with a resource</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>cookies</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Use of HTTP cookies</TD>
|
|
</TR>
|
|
<TR class="variable">
|
|
<TD>miscdata</TD>
|
|
<TD><EM>(<A href="#variable">variable-category</A>)</EM></TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Miscellaneous non-base data schema information</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>searchtext</TD>
|
|
<TD>Interactive Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Search terms</TD>
|
|
</TR>
|
|
<TR>
|
|
<TD>interactionrecord</TD>
|
|
<TD>Interactive Data</TD>
|
|
<TD><EM>unstructured</EM></TD>
|
|
<TD>Server stores the transaction history</TD>
|
|
</TR>
|
|
</TABLE>
|
|
<P>
|
|
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.
|
|
<DL>
|
|
<DT>
|
|
<CODE><STRONG>clickstream</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>clickstream</CODE> 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
|
|
can use this data element to describe how that data will be used, as well
|
|
as this element sites which do URI path analysis. Web sites that collect
|
|
only some of the data elements listed for the <CODE>clickstream</CODE> element
|
|
MAY choose to list those specific elements rather than the entire
|
|
<CODE>dynamic.clickstream</CODE> element. This allows sites with more limited
|
|
data-collection practices to accurately present those practices to their
|
|
visitors.
|
|
<DT>
|
|
<CODE><STRONG>http</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>http</CODE> element contains additional information contained in
|
|
the HTTP protocol. See the definition of the <CODE>httpinfo</CODE> structure
|
|
for descriptions of specific elements. Sites MAY use the
|
|
<CODE>dynamic.http</CODE> field as a shorthand to cover all the elements
|
|
in the <CODE>httpinfo</CODE> structure if they wish, or they MAY reference
|
|
the specific elements in the <CODE>httpinfo</CODE> structure.
|
|
<DT>
|
|
<CODE><STRONG>clientevents</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>clientevents</CODE> 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 [<A HREF="#ref_DOM2-Events">DOM2-Events</A>]. The
|
|
<CODE>clientevents</CODE> 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; <CODE>clickstream</CODE> covers that event. However, the
|
|
DOM event <CODE>DOMFocusIn</CODE> (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 occurrance 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.
|
|
<DT>
|
|
<CODE><STRONG>cookies</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>cookies</CODE> element should be used whenever HTTP cookies are
|
|
set or retrieved by a site. Please note that <CODE>cookies</CODE> is a
|
|
<EM>variable data element</EM> and requires the explicit declaration of usage
|
|
categories in a policy.
|
|
<DT>
|
|
<CODE><STRONG>miscdata</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>miscdata</CODE> 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 <CODE>miscdata</CODE> element in their policies for each category
|
|
of miscellaneous data they collect.
|
|
<DT>
|
|
<CODE><STRONG>searchtext</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>searchtext</CODE> 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.
|
|
<DT>
|
|
<CODE><STRONG>interactionrecord</STRONG></CODE>
|
|
<DD>
|
|
The <CODE>interactionrecord</CODE> 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).
|
|
</DL>
|
|
<H2>
|
|
<A name="categories_and_data">5.5 Categories and Data Elements/Structures</A>
|
|
</H2>
|
|
<H3>
|
|
5.5.1 <A name="fixed">Fixed-Category Data Elements/Structures</A>
|
|
</H3>
|
|
<P>
|
|
Most of the elements in the base data schema are so called <EM>"fixed"</EM>
|
|
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
|
|
[<A href="#APPEL">APPEL</A>], 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.
|
|
<P>
|
|
When creating data schemas for fixed data elements, schema creators have
|
|
to explicitly enumerate the categories that these element belong to. For
|
|
example:
|
|
<BLOCKQUOTE>
|
|
<CODE><DATA-STRUCT
|
|
name="<STRONG><FONT color="#3366ff">postal.street</FONT></STRONG>"
|
|
structref="#<FONT color="#cc33cc">text</FONT>"</CODE> <BR>
|
|
<CODE>
|
|
short-description="<FONT color="#3366ff">Street
|
|
Address</FONT>"></CODE><BR>
|
|
<CODE><CATEGORIES><physical/></CATEGORIES></CODE><BR>
|
|
<CODE></DATA-STRUCT></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
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":
|
|
<BLOCKQUOTE>
|
|
<CODE><DATA-STRUCT
|
|
name="<STRONG><FONT color="#3366ff">user.name</FONT></STRONG>"
|
|
structref="#<FONT color="#cc33cc">personname</FONT>"</CODE> <BR>
|
|
<CODE>
|
|
short-description="<FONT color="#3366ff">User's
|
|
Name</FONT>"></CODE><BR>
|
|
<CODE><CATEGORIES><physical/><demographic/></CATEGORIES></CODE><BR>
|
|
<CODE></DATA-STRUCT></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
Please note that the category classes of fixed data elements/structures can
|
|
<STRONG>not</STRONG> 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.
|
|
<H3>
|
|
5.5.2 <A name="variable">Variable-Category Data Elements/Structures</A>
|
|
</H3>
|
|
<P>
|
|
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 <EM>variable-category data elements/structures</EM> (or "variable
|
|
data element/structure" for short). Although most variable data elements
|
|
in the P3P Base Data Schema are combined in the <STRONG>dynamic</STRONG>
|
|
element set, they can appear in any data set, even mixed with
|
|
<EM>fixed-category data elements</EM>.
|
|
<P>
|
|
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 <EM>fixed</EM>. For example when specifying the
|
|
"Year" <EM>Data Structure</EM>, 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:
|
|
<BLOCKQUOTE>
|
|
<CODE><DATA-STRUCT
|
|
name="<STRONG><FONT color="#3366ff">date.ymd.year</FONT></STRONG>"</CODE><BR>
|
|
<CODE>
|
|
short-description="<FONT color="#3366ff">Year</FONT>"/>
|
|
<FONT color="#993300"><!-- Variable Data Structure--></FONT></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
This allows new schema extensions that reference such variable-category
|
|
<EM>Data Structures</EM> 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:
|
|
<BLOCKQUOTE>
|
|
<CODE><DATA-STRUCT
|
|
name="<STRONG><FONT color="#3366ff">Card.ExpDate</FONT></STRONG>"
|
|
|
|
structref="#<FONT color="#cc33cc">date.ymd</FONT>"</CODE> <BR>
|
|
<CODE>
|
|
short-description="<FONT color="#3366ff">Card Expiration
|
|
Date</FONT>"></CODE><BR>
|
|
<CODE><CATEGORIES><purchase/></CATEGORIES><BR>
|
|
</DATA-STRUCT></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
Under these conditions, the variable Data Structure <STRONG>date</STRONG>
|
|
is assigned a fixed category <A href="#Categories">"Purchase Information</A>"
|
|
when being used for specifying a credit card expiration date.
|
|
<P>
|
|
Note that while user preferences can list such variable data elements without
|
|
any additional category information (effectively expressing preferences over
|
|
<EM>any</EM> 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 <CODE>DATA</CODE> element listed in the policy, for example
|
|
as in:
|
|
<BLOCKQUOTE>
|
|
<CODE><POLICY ... ></CODE><BR>
|
|
<CODE> ...</CODE><BR>
|
|
<CODE> <DATA
|
|
ref="#dynamic.cookies"><CATEGORIES><uniqueid/></CATEGORIES></DATA></CODE><BR>
|
|
<CODE> ...</CODE><BR>
|
|
<CODE></POLICY></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
where a service declares that cookies are used for identifying the user at
|
|
this site (i.e. category <A href="#Categories">Unique Identifiers</A>).
|
|
<P>
|
|
If a service wants to declare a data element that is in multiple categories,
|
|
it simply declares the corresponding categories (as shown in the
|
|
<A href="#fixed">above section</A>):
|
|
<BLOCKQUOTE>
|
|
<CODE><POLICY ... ></CODE><BR>
|
|
<CODE> ...</CODE><BR>
|
|
<CODE> <DATA
|
|
ref="#dynamic.cookies"><CATEGORIES><uniqueid/><preference/></CATEGORIES></DATA></CODE><BR>
|
|
<CODE> ...</CODE><BR>
|
|
<CODE></POLICY></CODE>
|
|
</BLOCKQUOTE>
|
|
<P>
|
|
With the above declaration a service announces that it uses cookies both
|
|
for identifying the user at this site <EM>and</EM> 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.
|
|
<P>
|
|
Finally, note that categories can be inherited as well: <EM>Categories inherit
|
|
downward when a field is structured, but only into fields which have no
|
|
predefined category.</EM> 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.
|
|
<H2>
|
|
5.6 <A name="using_data_elements">Using Data Elements</A>
|
|
</H2>
|
|
<P>
|
|
P3P offers Web sites a great deal of flexibility in how they describe the
|
|
types of data they collect.
|
|
<UL>
|
|
<LI>
|
|
Sites may describe data generally using the <STRONG>dynamic.miscdata</STRONG>
|
|
element and the appropriate categories.
|
|
<LI>
|
|
Sites may describe data specifically using the data elements defined in the
|
|
base data schema.
|
|
<LI>
|
|
Sites may describe data specifically using data elements defined in new data
|
|
schemas.
|
|
</UL>
|
|
<P>
|
|
Any of these three methods may be combined within a single policy.
|
|
<P>
|
|
By using the <CODE><STRONG>dynamic.miscdata</STRONG></CODE> 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
|
|
<CODE><STRONG>dynamic.miscdata</STRONG></CODE> 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
|
|
<CODE><STRONG>user.business-info.contact.postal</STRONG></CODE>. 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.
|
|
<P>
|
|
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.
|
|
<P>
|
|
Regardless of whether a site wishes to make general or specific data disclosures,
|
|
there are additional advantages to disclosing specific elements from the
|
|
<CODE><STRONG>dynamic</STRONG></CODE> data set. For example, by disclosing
|
|
<CODE><STRONG>dynamic.cookies</STRONG></CODE> 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
|
|
<CODE><STRONG>dynamic.http.referer</STRONG></CODE> element in P3P policies
|
|
and send the header if it will be used for a purpose the user finds acceptable.
|
|
<P>
|
|
<HR>
|
|
<H1>
|
|
6. <A name="Appendices">Appendices</A>
|
|
</H1>
|
|
<H2>
|
|
Appendix 1: <A name="References_normative">References</A> (Normative)
|
|
</H2>
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
[<A name="CHARMODEL"><STRONG>CHARMODEL</STRONG></A>]
|
|
<DD>
|
|
M. Dürst, F. Yergeau (Eds.),
|
|
"<A href="http://www.w3.org/TR/1999/WD-charmod-19991129/">Character Model
|
|
for the World Wide Web </A>," <A href="http://www.w3.org">World Wide Web
|
|
Consortium</A> Working Draft. 29 November 1999.
|
|
<DT>
|
|
[<STRONG><A NAME="ref_DOM2-Events">DOM2-Events</A></STRONG>]
|
|
<DD>
|
|
T. Pixley (Ed.),
|
|
"<A HREF="http://www.w3.org/TR/2000/PR-DOM-Level-2-Events-20000927/">Document
|
|
Object Model (DOM) Level 2 Events Specification</A>,"
|
|
<A href="http://www.w3.org">World Wide Web Consortium</A>, Proposed
|
|
Recommendation. 27 September 2000.
|
|
<DT>
|
|
[<A name="HTTP1_0_ref"><STRONG>HTTP1.0</STRONG></A>]
|
|
<DD>
|
|
T. Berners-Lee, R. Fielding, H. Frystyk,
|
|
"<A href="http://www.ietf.org/rfc/rfc1945.txt">RFC1945 -- Hypertext Transfer
|
|
Protocol -- HTTP/1.0</A>," May 1996.
|
|
<DT>
|
|
[<A name="HTTP1_1_ref"><STRONG>HTTP1.1</STRONG></A>]
|
|
<DD>
|
|
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
|
|
Berners-Lee, "<A href="http://www.ietf.org/rfc/rfc2616.txt">RFC2616 -- Hypertext
|
|
Transfer Protocol -- HTTP/1.1</A>," June 1999. [Updates
|
|
<A href="http://www.ietf.org/rfc/rfc2068.txt">RFC2068</A>]
|
|
<DT>
|
|
[<A name="KEY"><STRONG>KEY</STRONG></A>]
|
|
<DD>
|
|
S. Bradner. "<A href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119-- Key
|
|
words for use in RFCs to Indicate Requirement Levels</A>." March 1997.
|
|
<DT>
|
|
[<A name="P3P-HEADER"><STRONG>P3P-HEADER</STRONG></A>]
|
|
<DD>
|
|
R. Lotenberg, M. Marchiori, M. Nottingham (Eds.),
|
|
"<A HREF="http://www.w3.org/2000/draft-w3c-p3p-header.txt"> W3C Platform
|
|
for Privacy Preferences 1.0 (P3P1.0) HTTP Header</A>" (also available in
|
|
<A HREF="http://www.w3.org/2000/draft-w3c-p3p-header.html">HTML</A> and
|
|
<A HREF="http://www.w3.org/2000/draft-w3c-p3p-header.xml">XML</A> formats),
|
|
to be submitted to the <A href="http://www.ietf.org">IETF</A> as Internet
|
|
Draft.
|
|
<DT>
|
|
[<A NAME="ref_STATE"><STRONG>STATE</STRONG></A>]
|
|
<DD>
|
|
Kristol, D., Montulli, L.,
|
|
"<A HREF="http://www.ietf.org/rfc/rfc2965.txt">RFC2965 -- HTTP State Management
|
|
Mechanism</A>." October, 2000 [Obsoletes
|
|
<A HREF="http://www.ietf.org/rfc/rfc2109.txt">RFC2109</A>]
|
|
<DT>
|
|
[<A name="URI"><STRONG>URI</STRONG></A>]
|
|
<DD>
|
|
T. Berners-Lee, R. Fielding, and L. Masinter.
|
|
"<A href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396 -- Uniform Resource
|
|
Identifiers (URI): Generic Syntax and Semantics</A>." August 1998. [Updates
|
|
<A href="http://www.ietf.org/rfc/rfc1738.txt">RFC1738</A>]
|
|
<DT>
|
|
[<A name="UTF-8"><STRONG>UTF-8</STRONG></A>]
|
|
<DD>
|
|
F. Yergeau. "<A href="http://www.ietf.org/rfc/rfc2279.txt">RFC2279 -- UTF-8,
|
|
a transformation format of ISO 10646</A>." January 1998.
|
|
<DT>
|
|
[<A name="XML"><STRONG>XML</STRONG></A>]
|
|
<DD>
|
|
T. Bray, J. Paoli, C. M. Sperberg-McQueen (Eds.).
|
|
"<A href="http://www.w3.org/TR/REC-xml">Extensible Markup Language (XML)
|
|
1.0 Specification</A>." <A href="http://www.w3.org/">World Wide Web
|
|
Consortium</A>, Recommendation. 10 February 1998.
|
|
<DT>
|
|
[<A name="XML-Name"><STRONG>XML-Name</STRONG></A>]
|
|
<DD>
|
|
T. Bray, D. Hollander, A. Layman (Eds.).
|
|
"<A href="http://www.w3.org/TR/REC-xml-names/">Namespaces in XML.</A>"
|
|
<A href="http://www.w3.org/">World Wide Web Consortium</A>, Recommendation.
|
|
14 January 1999.
|
|
<DT>
|
|
[<A name="XML-Schema1"><STRONG>XML-Schema1</STRONG></A>]
|
|
<DD>
|
|
H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Eds.).
|
|
"<A HREF="http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/">XML Schema
|
|
Part 1: Structures</A>" <A href="http://www.w3.org">World Wide Web
|
|
Consortium</A> Working Draft. 22 September 2000.
|
|
<DT>
|
|
[<A name="XML-Schema2"><STRONG>XML-Schema2</STRONG></A>]
|
|
<DD>
|
|
P. Biron, A. Malhotra (Eds.).
|
|
"<A HREF="http://www.w3.org/TR/2000/WD-xmlschema-2-20000922/">XML Schema
|
|
Part 2: datatypes</A>" <A href="http://www.w3.org">World Wide Web
|
|
Consortium</A> Working Draft. 22 September 2000.
|
|
</DL>
|
|
<H2>
|
|
Appendix 2: <A name="References_nonnormative">References</A> (Non-Normative)
|
|
</H2>
|
|
<P>
|
|
<DL>
|
|
<DT>
|
|
[<A name="ABNF"><STRONG>ABNF</STRONG></A>]
|
|
<DD>
|
|
D. Crocker, P. Overel.
|
|
"<A href="http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt">RFC2234
|
|
-- Augmented BNF for Syntax Specifications: ABNF</A>," Internet Mail Consortium,
|
|
Demon Internet Ltd., November 1997.
|
|
<DT>
|
|
[<STRONG><A name="APPEL">APPEL</A></STRONG>]
|
|
<DD>
|
|
M. Langheinrich (Ed.). "<A href="http://www.w3.org/TR/P3P-preferences">A
|
|
P3P Preference Exchange Language (APPEL)</A>"
|
|
<A href="http://www.w3.org/">World Wide Web Consortium</A> Working Draft.
|
|
<DT>
|
|
[<A NAME="ref_COOKIES"><STRONG>COOKIES</STRONG></A>]
|
|
<DD>
|
|
"<A HREF="http://www.netscape.com/newsref/std/cookie_spec.html">Persistent
|
|
Client State -- HTTP Cookies</A>," Preliminary Specification, Netscape, 1999.
|
|
<DT>
|
|
[<STRONG><A name="HTML">HTML</A></STRONG>]
|
|
<DD>
|
|
D. Raggett, A. Le Hors, and I. Jacobs (Eds.).
|
|
"<A href="http://www.w3.org/TR/html401/">HTML 4.01 Specification</A>"
|
|
<A href="http://www.w3.org/">World Wide Web Consortium</A>
|
|
<DT>
|
|
[<A name="iso3166"><STRONG>ISO3166</STRONG></A>]
|
|
<DD>
|
|
"ISO3166: Codes for The Representation of Names of Countries." International
|
|
Organization for Standardization.
|
|
<DT>
|
|
[<A name="ISO8601"><STRONG>ISO8601</STRONG></A>]
|
|
<DD>
|
|
"ISO8601: Data elements and interchange formats -- Information interchange
|
|
-- Representation of dates and times." International Organization for
|
|
Standardization.
|
|
<DT>
|
|
[<A name="RDF"><STRONG>RDF</STRONG></A>]
|
|
<DD>
|
|
O. Lassila and R. Swick (Eds.).
|
|
"<A href="http://www.w3.org/TR/REC-rdf-syntax/">Resource Description Framework
|
|
(RDF) Model and Syntax Specification.</A>" <A href="http://www.w3.org/">World
|
|
Wide Web Consortium</A>, Recommendation. 22 February 1999.
|
|
<DT>
|
|
[<A name="UNICODE"><STRONG>UNICODE</STRONG></A>]
|
|
<DD>
|
|
Unicode Consortium.
|
|
"<A href="http://www.unicode.org/unicode/standard/standard.html">The Unicode
|
|
Standard</A>"
|
|
</DL>
|
|
<H2>
|
|
<A name="basedataxml">Appendix 3: The P3P Base Data Schema Definition
|
|
(Normative)</A>
|
|
</H2>
|
|
<P>
|
|
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
|
|
<A href="http://www.w3.org/TR/P3P/base">http://www.w3.org/TR/P3P/base</A>
|
|
.
|
|
<PRE><DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
|
|
<!-- ********** Base Data Structures ********** -->
|
|
|
|
<!-- "date" Data Structure -->
|
|
<DATA-STRUCT name="date.ymd.year"
|
|
short-description="Year"/>
|
|
|
|
<DATA-STRUCT name="date.ymd.month"
|
|
short-description="Month"/>
|
|
|
|
<DATA-STRUCT name="date.ymd.day"
|
|
short-description="Day"/>
|
|
|
|
<DATA-STRUCT name="date.hms.hour"
|
|
short-description="Hour"/>
|
|
|
|
<DATA-STRUCT name="date.hms.minute"
|
|
short-description="Minutes"/>
|
|
|
|
<DATA-STRUCT name="date.hms.second"
|
|
short-description="Second"/>
|
|
|
|
<DATA-STRUCT name="date.fractionsecond"
|
|
short-description="Fraction of Second"/>
|
|
|
|
<DATA-STRUCT name="date.timezone"
|
|
short-description="Time Zone"/>
|
|
|
|
<!-- "personname" Data Structure -->
|
|
<DATA-STRUCT name="personname.prefix"
|
|
short-description="Name Prefix">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="personname.given"
|
|
short-description="Given Name (First Name)">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="personname.middle"
|
|
short-description="Middle Name">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="personname.family"
|
|
short-description="Family Name (Last Name)">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="personname.suffix"
|
|
short-description="Name Suffix">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="personname.nickname"
|
|
short-description="Nickname">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "certificate" Data Structure -->
|
|
<DATA-STRUCT name="certificate.key"
|
|
short-description="Certificate key">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="certificate.format"
|
|
short-description="Certificate format">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "telephonenum" Data Structure -->
|
|
<DATA-STRUCT name="telephonenum.intcode"
|
|
short-description="International Telephone Code">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telephonenum.loccode"
|
|
short-description="Local Telephone Area Code">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telephonenum.number"
|
|
short-description="Telephone Number">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telephonenum.ext"
|
|
short-description="Telephone Extension">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telephonenum.comment"
|
|
short-description="Telephone Optional Comments">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "postal" Data Structure -->
|
|
<DATA-STRUCT name="postal.name" struct-ref="#personname">
|
|
<CATEGORIES><physical/><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.street"
|
|
short-description="Street Address">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.city"
|
|
short-description="City">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.stateprov"
|
|
short-description="State or Province">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.postalcode"
|
|
short-description="Postal Code">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.organization"
|
|
short-description="Organization Name">
|
|
<CATEGORIES><physical/><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="postal.country"
|
|
short-description="Country Name">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "telecom" Data Structure -->
|
|
<DATA-STRUCT name="telecom.telephone"
|
|
short-description="Telephone Number"
|
|
structref="#telephonenum">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telecom.fax"
|
|
short-description="Fax Number"
|
|
structref="#telephonenum">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telecom.mobile"
|
|
short-description="Mobile Telephone Number"
|
|
structref="#telephonenum">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="telecom.pager"
|
|
short-description="Pager Number"
|
|
structref="#telephonenum">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "online" Data Structure -->
|
|
<DATA-STRUCT name="online.email"
|
|
short-description="Email Address">
|
|
<CATEGORIES><online/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="online.uri"
|
|
short-description="Home Page Address">
|
|
<CATEGORIES><online/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "contact" Data Structure -->
|
|
<DATA-STRUCT name="contact.postal"
|
|
short-description="Postal Address Information"
|
|
structref="#postal">
|
|
<CATEGORIES><physical/><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="contact.telecom"
|
|
short-description="Telecommunications Information"
|
|
structref="#telecom">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="contact.online"
|
|
short-description="Online Address Information"
|
|
structref="#online">
|
|
<CATEGORIES><online/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "uri" Data Structure -->
|
|
<DATA-STRUCT name="uri.authority"
|
|
short-description="URI authority"/>
|
|
|
|
<DATA-STRUCT name="uri.stem"
|
|
short-description="URI stem"/>
|
|
|
|
<DATA-STRUCT name="uri.querystring"
|
|
short-description="Query-string portion of URI"/>
|
|
|
|
<!-- "ipaddr" Data Structure -->
|
|
<DATA-STRUCT name="ipaddr.hostname"
|
|
short-description="Complete host and domain name">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="ipaddr.partialhostname"
|
|
short-description="Partial hostname">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="ipaddr.fullip"
|
|
short-description="Full IP address">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="ipaddr.partialip"
|
|
short-description="Partial IP address">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "loginfo" Data Structure -->
|
|
<DATA-STRUCT name="loginfo.uri"
|
|
short-description="URI of requested resource"
|
|
structref="#uri">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="loginfo.timestamp"
|
|
short-description="Request timestamp"
|
|
structref="#date">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="loginfo.clientip"
|
|
short-description="Client's IP address or hostname"
|
|
structref="#ipaddr">
|
|
<CATEGORIES><computer/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="loginfo.other.httpmethod"
|
|
short-description="HTTP request method">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="loginfo.other.bytes"
|
|
short-description="Data bytes in response">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="loginfo.other.statuscode"
|
|
short-description="Response status code">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- "httpinfo" Data Structure -->
|
|
<DATA-STRUCT name="httpinfo.referer"
|
|
short-description="Last URI requested by the user"
|
|
structref="#uri">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<DATA-STRUCT name="httpinfo.useragent"
|
|
short-description="User agent information">
|
|
<CATEGORIES><computer/></CATEGORIES>
|
|
</DATA-STRUCT>
|
|
|
|
<!-- ********** Base Data Schemas ********** -->
|
|
|
|
<!-- "dynamic" Data Schema -->
|
|
<DATA-DEF name="dynamic.clickstream"
|
|
short-description="Click-stream information"
|
|
structref="#loginfo">
|
|
<CATEGORIES><navigation/><computer/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="dynamic.http"
|
|
short-description="HTTP protocol information"
|
|
structref="#httpinfo">
|
|
<CATEGORIES><navigation/><computer/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="dynamic.clientevents"
|
|
short-description="User's interaction with a resource">
|
|
<CATEGORIES><navigation/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="dynamic.cookies"
|
|
short-description="Use of HTTP cookies"/>
|
|
|
|
<DATA-DEF name="dynamic.miscdata"
|
|
short-description="Miscellaneous non-base data schema information"/>
|
|
|
|
<DATA-DEF name="dynamic.searchtext"
|
|
short-description="Search terms">
|
|
<CATEGORIES><interactive/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="dynamic.interactionrecord"
|
|
short-description="Server stores the transaction history">
|
|
<CATEGORIES><interactive/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<!-- "user" Data Schema -->
|
|
<DATA-DEF name="user.name"
|
|
short-description="User's Name"
|
|
structref="#personname">
|
|
<CATEGORIES><physical/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.bdate"
|
|
short-description="User's Birth Date"
|
|
structref="#date">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.cert"
|
|
short-description="User's Identity certificate"
|
|
structref="#certificate">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.gender"
|
|
short-description="User's Gender">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.jobtitle"
|
|
short-description="User's Job Title">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.home-info"
|
|
short-description="User's Home Contact Information"
|
|
structref="#contact">
|
|
<CATEGORIES><physical/><online/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.business-info"
|
|
short-description="User's Business Contact Information"
|
|
structref="#contact">
|
|
<CATEGORIES><physical/><online/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.employer"
|
|
short-description="Name of User's Employer">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="user.department"
|
|
short-description="Department or division of organization where user is employed">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<!-- "thirdparty" Data Schema -->
|
|
<DATA-DEF name="thirdparty.name"
|
|
short-description="Third Party's Name"
|
|
structref="#personname">
|
|
<CATEGORIES><physical/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.bdate"
|
|
short-description="Third Party's Birth Date"
|
|
structref="#date">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.cert"
|
|
short-description="Third Party's Identity certificate"
|
|
structref="#certificate">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.gender"
|
|
short-description="Third Party's Gender">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.jobtitle"
|
|
short-description="Third Party's Job Title">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.home-info"
|
|
short-description="Third Party's Home Contact Information"
|
|
structref="#contact">
|
|
<CATEGORIES><physical/><online/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.business-info"
|
|
short-description="Third Party's Business Contact Information"
|
|
structref="#contact">
|
|
<CATEGORIES><physical/><online/><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.employer"
|
|
short-description="Name of Third Party's Employer">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="thirdparty.department"
|
|
short-description="Department or division of organization where third party is employed">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<!-- "business" Data Schema -->
|
|
<DATA-DEF name="business.name"
|
|
short-description="Organization Name">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="business.department"
|
|
short-description="Department or division of organization">
|
|
<CATEGORIES><demographic/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="business.cert"
|
|
short-description="Organization Identity certificate"
|
|
structref="#certificate">
|
|
<CATEGORIES><uniqueid/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
<DATA-DEF name="business.contact-info"
|
|
short-description="Contact Information for the Organization"
|
|
structref="#contact">
|
|
<CATEGORIES><physical/></CATEGORIES>
|
|
</DATA-DEF>
|
|
|
|
</DATASCHEMA>
|
|
</PRE>
|
|
<H2>
|
|
<A name="Appendix_schema">Appendix 4: XML Schema Definition (Normative)</A>
|
|
</H2>
|
|
<P>
|
|
This appendix contains the XML schema, both for P3P policy reference files,
|
|
for P3P policy documents, and for P3P data schema documents. An XML schema
|
|
may be used to validate the structure and datastruct values used in an instance
|
|
of the schema given as an XML document. P3P policy and data schema documents
|
|
are XML documents that MUST conform to this schema. Note that this schema
|
|
is based on the XML schema working drafts
|
|
[<A href="#XML-Schema1">XML-Schema1</A>][<A href="#XML-Schema2">XML-Schema2</A>],
|
|
which are subject to change. The schema is also present as a separate file
|
|
at the URI
|
|
<A HREF="http://www.w3.org/2000/12/P3Pv1.xsd">http://www.w3.org/2000/12/P3Pv1.xsd</A>
|
|
.
|
|
<PRE><!DOCTYPE schema
|
|
PUBLIC '-//W3C//DTD XMLSCHEMA 200010//EN'
|
|
'http://www.w3.org/2000/10/XMLSchema.dtd' [
|
|
<!ATTLIST schema
|
|
xmlns:p3p CDATA #FIXED 'http://www.w3.org/2000/12/P3Pv1'>
|
|
]>
|
|
|
|
<schema
|
|
xmlns='http://www.w3.org/2000/10/XMLSchema'
|
|
xmlns:p3p='http://www.w3.org/2000/12/P3Pv1'
|
|
targetNamespace='http://www.w3.org/2000/12/P3Pv1'
|
|
elementFormDefault='qualified'>
|
|
|
|
<!-- Basic P3P Data Type -->
|
|
<simpleType name='yes_no'>
|
|
<restriction base='string'>
|
|
<enumeration value='yes'/>
|
|
<enumeration value='no'/>
|
|
</restriction>
|
|
</simpleType>
|
|
|
|
|
|
<!-- *********** Policy Reference *********** -->
|
|
<!-- ************** META ************** -->
|
|
<element name='META'>
|
|
<complexType mixed='true'>
|
|
<sequence minOccurs='0' maxOccurs='unbounded'>
|
|
<element ref='p3p:POLICY-REFERENCES'/>
|
|
<element ref='p3p:POLICIES' minOccurs='0'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ******* POLICY-REFERENCES ******** -->
|
|
<element name='POLICY-REFERENCES'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:EXPIRY' minOccurs='0'/>
|
|
<element ref='p3p:POLICY-REF' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<element name='POLICY-REF'>
|
|
<complexType>
|
|
<sequence>
|
|
<element name='INCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
|
|
<element name='EXCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
|
|
<element name='COOKIE-INCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='string'/>
|
|
<element name='COOKIE-EXCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='string'/>
|
|
<element name='EMBEDDED-INCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
|
|
<element name='EMBEDDED-EXCLUDE'
|
|
minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
|
|
<element name='METHOD'
|
|
minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
|
|
</sequence>
|
|
<attribute name='about' type='uriReference' use='required'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ************* EXPIRY ************* -->
|
|
<element name='EXPIRY'>
|
|
<complexType>
|
|
<attribute name='max-age' type='nonNegativeInteger' use='optional'/>
|
|
<attribute name='date' type='string' use='optional'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ************ POLICIES ************ -->
|
|
<element name='POLICIES'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
|
|
<!-- **************** Policy **************** -->
|
|
<!-- ************* POLICY ************* -->
|
|
<element name='POLICY'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
<element ref='p3p:TEST'/>
|
|
<element ref='p3p:EXPIRY' minOccurs='0'/>
|
|
<element ref='p3p:DATASCHEMA' minOccurs='0'/>
|
|
<element ref='p3p:ENTITY'/>
|
|
<element ref='p3p:ACCESS'/>
|
|
<element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
|
|
<element ref='p3p:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
<attribute name='discuri' type='uriReference' use='required'/>
|
|
<attribute name='opturi' type='uriReference' use='optional'/>
|
|
<attribute name='name' type='ID' use='optional'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ************* TEST ************* -->
|
|
<element name='TEST' minOccurs='0'>
|
|
|
|
<!-- ************* ENTITY ************* -->
|
|
<element name='ENTITY'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
<element ref='p3p:DATA-GROUP'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ************* ACCESS ************* -->
|
|
<element name='ACCESS'>
|
|
<complexType>
|
|
<sequence>
|
|
<choice>
|
|
<element name='nonident' type='p3p:access-value'/>
|
|
<element name='ident-contact' type='p3p:access-value'/>
|
|
<element name='other-ident' type='p3p:access-value'/>
|
|
<element name='contact-and-other' type='p3p:access-value'/>
|
|
<element name='all' type='p3p:access-value'/>
|
|
<element name='none' type='p3p:access-value'/>
|
|
</choice>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='access-value'/>
|
|
|
|
<!-- ************ DISPUTES ************ -->
|
|
<element name='DISPUTES-GROUP'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:DISPUTES' maxOccurs='unbounded'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<element name='DISPUTES'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
<choice minOccurs='0'>
|
|
<sequence>
|
|
<element ref='p3p:LONG-DESCRIPTION'/>
|
|
<element ref='p3p:IMG' minOccurs='0'/>
|
|
<element ref='p3p:REMEDIES' minOccurs='0'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
<sequence>
|
|
<element ref='p3p:IMG'/>
|
|
<element ref='p3p:REMEDIES' minOccurs='0'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
<sequence>
|
|
<element ref='p3p:REMEDIES'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</choice>
|
|
</sequence>
|
|
<attribute name='resolution-type' use='required'>
|
|
<simpleType>
|
|
<restriction base='string'>
|
|
<enumeration value='service'/>
|
|
<enumeration value='independent'/>
|
|
<enumeration value='court'/>
|
|
<enumeration value='law'/>
|
|
</restriction>
|
|
</simpleType>
|
|
</attribute>
|
|
<attribute name='service' type='uriReference' use='required'/>
|
|
<attribute name='verification' type='string' use='optional'/>
|
|
<attribute name='short-description' type='string' use='optional'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ******** LONG-DESCRIPTION ******** -->
|
|
<element name='LONG-DESCRIPTION'>
|
|
<simpleType>
|
|
<restriction base='string'/>
|
|
</simpleType>
|
|
</element>
|
|
|
|
<!-- ************** IMG *************** -->
|
|
<element name='IMG'>
|
|
<complexType>
|
|
<attribute name='src' type='uriReference' use='required'/>
|
|
<attribute name='width' type='nonNegativeInteger' use='optional'/>
|
|
<attribute name='height' type='nonNegativeInteger' use='optional'/>
|
|
<attribute name='alt' type='string' use='required'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<!-- ************ REMEDIES ************ -->
|
|
<element name='REMEDIES'>
|
|
<complexType>
|
|
<sequence>
|
|
<choice maxOccurs='unbounded'>
|
|
<element name='correct' type='p3p:remedies-value'/>
|
|
<element name='money' type='p3p:remedies-value'/>
|
|
<element name='law' type='p3p:remedies-value'/>
|
|
</choice>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='remedies-value'/>
|
|
|
|
<!-- *********** STATEMENT ************ -->
|
|
<element name='STATEMENT'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
<element name='CONSEQUENCE' minOccurs='0' type='string'/>
|
|
<element name='NON-IDENTIFIABLE' minOccurs='0'>
|
|
<complexType/>
|
|
</element>
|
|
<element ref='p3p:PURPOSE'/>
|
|
<element ref='p3p:RECIPIENT'/>
|
|
<element ref='p3p:RETENTION'/>
|
|
<element ref='p3p:DATA-GROUP' maxOccurs='unbounded'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='non-identifiable'/>
|
|
|
|
<!-- ************ PURPOSE ************* -->
|
|
<element name='PURPOSE'>
|
|
<complexType>
|
|
<sequence>
|
|
<choice maxOccurs='unbounded'>
|
|
<element name='current' type='p3p:purpose-value'/>
|
|
<element name='admin' type='p3p:purpose-value'/>
|
|
<element name='develop' type='p3p:purpose-value'/>
|
|
<element name='customization' type='p3p:purpose-value'/>
|
|
<element name='tailoring' type='p3p:purpose-value'/>
|
|
<element name='pseudo-analysis' type='p3p:purpose-value'/>
|
|
<element name='pseudo-decision' type='p3p:purpose-value'/>
|
|
<element name='individual-analysis' type='p3p:purpose-value'/>
|
|
<element name='individual-decision' type='p3p:purpose-value'/>
|
|
<element name='contact' type='p3p:purpose-value'/>
|
|
<element name='historical' type='p3p:purpose-value'/>
|
|
<element name='telemarketing' type='p3p:purpose-value'/>
|
|
<element name='other-purpose'>
|
|
<complexType mixed='true'>
|
|
<attribute name='required' use='optional' type='p3p:required-value'/>
|
|
</complexType>
|
|
</element>
|
|
</choice>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<simpleType name='required-value'>
|
|
<restriction base='string'>
|
|
<enumeration value='always'/>
|
|
<enumeration value='opt-in'/>
|
|
<enumeration value='opt-out'/>
|
|
</restriction>
|
|
</simpleType>
|
|
|
|
<complexType name='purpose-value'>
|
|
<attribute name='required' use='optional' type='p3p:required-value'/>
|
|
</complexType>
|
|
|
|
<!-- *********** RECIPIENT ************ -->
|
|
<element name='RECIPIENT'>
|
|
<complexType>
|
|
<sequence>
|
|
<choice maxOccurs='unbounded'>
|
|
<element name='ours'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
<element name='same' type='p3p:recipient-value'/>
|
|
<element name='other-recipient' type='p3p:recipient-value'/>
|
|
<element name='delivery' type='p3p:recipient-value'/>
|
|
<element name='public' type='p3p:recipient-value'/>
|
|
<element name='unrelated' type='p3p:recipient-value'/>
|
|
</choice>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='recipient-value'>
|
|
<sequence>
|
|
<element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
<attribute name='required' use='optional' type='p3p:required-value'/>
|
|
</complexType>
|
|
|
|
<element name='recipient-description'>
|
|
<complexType mixed='true'/>
|
|
</element>
|
|
|
|
<!-- *********** RETENTION ************ -->
|
|
<element name='RETENTION'>
|
|
<complexType>
|
|
<sequence>
|
|
<choice>
|
|
<element name='no-retention' type='p3p:retention-value'/>
|
|
<element name='stated-purpose' type='p3p:retention-value'/>
|
|
<element name='legal-requirement' type='p3p:retention-value'/>
|
|
<element name='indefinitely' type='p3p:retention-value'/>
|
|
<element name='business-practices' type='p3p:retention-value'/>
|
|
</choice>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='retention-value'/>
|
|
|
|
<!-- ************** DATA ************** -->
|
|
<element name='DATA-GROUP'>
|
|
<complexType>
|
|
<sequence>
|
|
<element ref='p3p:DATA' maxOccurs='unbounded'/>
|
|
<element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
|
|
</sequence>
|
|
<attribute name='base' type='uriReference'
|
|
use='default' value='http://www.w3.org/TR/P3P/base'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
<element name='DATA'>
|
|
<complexType mixed='true'>
|
|
<sequence minOccurs='0' maxOccurs='unbounded'>
|
|
<element ref='p3p:CATEGORIES'/>
|
|
</sequence>
|
|
<attribute name='ref' type='uriReference' use='required'/>
|
|
<attribute name='optional' use='default' value='no' type='p3p:yes_no'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
|
|
<!-- ************** Data Schema ************* -->
|
|
<!-- *********** DATASCHEMA *********** -->
|
|
<element name='DATASCHEMA'>
|
|
<complexType>
|
|
<choice minOccurs='0' maxOccurs='unbounded'>
|
|
<element ref='p3p:DATA-DEF'/>
|
|
<element ref='p3p:DATA-STRUCT'/>
|
|
<element ref='p3p:EXTENSION'/>
|
|
</choice>
|
|
</complexType>
|
|
</element>
|
|
|
|
<element name='DATA-DEF' type='p3p:data-def'/>
|
|
<element name='DATA-STRUCT' type='p3p:data-def'/>
|
|
|
|
<complexType name='data-def'>
|
|
<sequence>
|
|
<element ref='p3p:CATEGORIES' minOccurs='0'/>
|
|
<element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/>
|
|
</sequence>
|
|
<attribute name='name' type='ID' use='required'/>
|
|
<attribute name='structref' type='uriReference' use='optional'/>
|
|
<attribute name='short-description' type='string' use='optional'/>
|
|
</complexType>
|
|
|
|
<!-- *********** CATEGORIES *********** -->
|
|
<element name='CATEGORIES'>
|
|
<complexType>
|
|
<choice maxOccurs='unbounded'>
|
|
<element name='physical' type='p3p:categories-value'/>
|
|
<element name='online' type='p3p:categories-value'/>
|
|
<element name='uniqueid' type='p3p:categories-value'/>
|
|
<element name='purchase' type='p3p:categories-value'/>
|
|
<element name='financial' type='p3p:categories-value'/>
|
|
<element name='computer' type='p3p:categories-value'/>
|
|
<element name='navigation' type='p3p:categories-value'/>
|
|
<element name='interactive' type='p3p:categories-value'/>
|
|
<element name='demographic' type='p3p:categories-value'/>
|
|
<element name='content' type='p3p:categories-value'/>
|
|
<element name='state' type='p3p:categories-value'/>
|
|
<element name='political' type='p3p:categories-value'/>
|
|
<element name='health' type='p3p:categories-value'/>
|
|
<element name='preference' type='p3p:categories-value'/>
|
|
<element name='government' type='p3p:categories-value'/>
|
|
<element name='other-category' type='string'/>
|
|
</choice>
|
|
</complexType>
|
|
</element>
|
|
|
|
<complexType name='categories-value'/>
|
|
|
|
<!-- *********** EXTENSION ************ -->
|
|
<element name='EXTENSION'>
|
|
<complexType mixed='true'>
|
|
<choice minOccurs='0' maxOccurs='unbounded'>
|
|
<any minOccurs='0' maxOccurs='unbounded' processContents='skip'/>
|
|
</choice>
|
|
<attribute name='optional' use='default' value='yes' type='p3p:yes_no'/>
|
|
</complexType>
|
|
</element>
|
|
|
|
</schema>
|
|
</PRE>
|
|
<H2>
|
|
<A name="DTD">Appendix 5: XML DTD Definition (Normative)</A>
|
|
</H2>
|
|
<P>
|
|
This appendix contains the DTD for policy documents and for data schemas.
|
|
The DTD is also present as a separate file at the URI
|
|
<A HREF="http://www.w3.org/2000/12/P3Pv1.dtd">http://www.w3.org/2000/12/P3Pv1.dtd</A>
|
|
.
|
|
<PRE><!-- *************** Entities *************** -->
|
|
<!ENTITY % URI "CDATA">
|
|
<!ENTITY % NUMBER "CDATA">
|
|
|
|
<!-- *********** Policy Refernece *********** -->
|
|
|
|
<!-- ************** META ************** -->
|
|
<!ELEMENT META (#PCDATA | POLICY-REFERENCES | POLICIES)*>
|
|
|
|
<!-- ******* POLICY-REFERENCES ******** -->
|
|
<!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*)>
|
|
<!ELEMENT POLICY-REF (INCLUDE*,
|
|
EXCLUDE*,
|
|
EMBEDDED-INCLUDE*,
|
|
EMBEDDED-EXCLUDE*,
|
|
METHOD*)>
|
|
<!ATTLIST POLICY-REF
|
|
about %URI; #REQUIRED >
|
|
|
|
<!-- ************* EXPIRY ************* -->
|
|
<!ELEMENT EXPIRY EMPTY>
|
|
<!ATTLIST EXPIRY
|
|
max-age %NUMBER; #IMPLIED
|
|
date CDATA #IMPLIED >
|
|
|
|
<!-- ************ POLICIES ************ -->
|
|
<!ELEMENT POLICIES (POLICY*)>
|
|
|
|
<!-- ***** INCLUDE/EXCLUDE/METHOD ***** -->
|
|
<!ELEMENT INCLUDE (#PCDATA)>
|
|
<!ELEMENT EXCLUDE (#PCDATA)>
|
|
<!ELEMENT COOKIE-INCLUDE (#PCDATA)>
|
|
<!ELEMENT COOKIE-EXCLUDE (#PCDATA)>
|
|
<!ELEMENT EMBEDDED-INCLUDE (#PCDATA)>
|
|
<!ELEMENT EMBEDDED-EXCLUDE (#PCDATA)>
|
|
<!ELEMENT METHOD (#PCDATA)>
|
|
|
|
<!-- **************** Policy **************** -->
|
|
|
|
<!-- ************* POLICY ************* -->
|
|
<!ELEMENT POLICY (EXTENSION*,
|
|
TEST,
|
|
EXPIRY?,
|
|
DATASCHEMA?,
|
|
ENTITY,
|
|
ACCESS,
|
|
DISPUTES-GROUP?,
|
|
STATEMENT*,
|
|
EXTENSION*)>
|
|
<!ATTLIST POLICY
|
|
discuri %URI; #REQUIRED
|
|
opturi %URI; #IMPLIED
|
|
name ID #IMPLIED >
|
|
|
|
<!-- ******** TEST ******** -->
|
|
<!ELEMENT TEST (EMPTY)>
|
|
|
|
<!-- ************* ENTITY ************* -->
|
|
<!ELEMENT ENTITY (EXTENSION*, DATA-GROUP, EXTENSION*)>
|
|
|
|
<!-- ************* ACCESS ************* -->
|
|
<!ELEMENT ACCESS ((nonident
|
|
| all
|
|
| contact-and-other
|
|
| ident-contact
|
|
| other-ident
|
|
| none),
|
|
EXTENSION*)>
|
|
<!ELEMENT nonident EMPTY>
|
|
<!ELEMENT all EMPTY>
|
|
<!ELEMENT contact-and-other EMPTY>
|
|
<!ELEMENT ident-contact EMPTY>
|
|
<!ELEMENT other-ident EMPTY>
|
|
<!ELEMENT none EMPTY>
|
|
|
|
<!-- ************ DISPUTES ************ -->
|
|
<!ELEMENT DISPUTES-GROUP (DISPUTES+, EXTENSION*)>
|
|
<!ELEMENT DISPUTES (EXTENSION*,
|
|
( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*)
|
|
| (IMG, REMEDIES?, EXTENSION*)
|
|
| (REMEDIES, EXTENSION*) )?)>
|
|
<!ATTLIST DISPUTES
|
|
resolution-type (service | independent | court | law) #REQUIRED
|
|
service %URI; #REQUIRED
|
|
verification CDATA #IMPLIED
|
|
short-description CDATA #IMPLIED >
|
|
|
|
<!-- ******** LONG-DESCRIPTION ******** -->
|
|
<!ELEMENT LONG-DESCRIPTION (#PCDATA)>
|
|
|
|
<!-- ************** IMG *************** -->
|
|
<!ELEMENT IMG EMPTY>
|
|
<!ATTLIST IMG
|
|
src %URI; #REQUIRED
|
|
width %NUMBER; #IMPLIED
|
|
height %NUMBER; #IMPLIED
|
|
alt CDATA #REQUIRED >
|
|
|
|
<!-- ************ REMEDIES ************ -->
|
|
<!ELEMENT REMEDIES ((correct | money | law)+, EXTENSION*)>
|
|
<!ELEMENT correct EMPTY>
|
|
<!ELEMENT money EMPTY>
|
|
<!ELEMENT law EMPTY>
|
|
|
|
<!-- *********** STATEMENT ************ -->
|
|
<!ELEMENT STATEMENT (EXTENSION*,
|
|
NON-IDENTIFIABLE?,
|
|
CONSEQUENCE?,
|
|
PURPOSE,
|
|
RECIPIENT,
|
|
RETENTION,
|
|
DATA-GROUP+,
|
|
EXTENSION*)>
|
|
|
|
<!-- ********** CONSEQUENCE *********** -->
|
|
<!ELEMENT CONSEQUENCE (#PCDATA)>
|
|
|
|
<!-- ******** NON-IDENTIFIABLE ******** -->
|
|
<!ELEMENT NON-IDENTIFIABLE (EMPTY)>
|
|
|
|
<!-- ************ PURPOSE ************* -->
|
|
<!ELEMENT PURPOSE ((current
|
|
| admin
|
|
| develop
|
|
| customization
|
|
| tailoring
|
|
| pseudo-analysis
|
|
| pseudo-decision
|
|
| individual-analysis
|
|
| individual-decision
|
|
| contact
|
|
| historical
|
|
| telemarketing
|
|
| other-purpose)+,
|
|
EXTENSION*)>
|
|
|
|
<!ENTITY % pur_att
|
|
"required (always | opt-in | opt-out) #IMPLIED">
|
|
<!ELEMENT current EMPTY>
|
|
<!ATTLIST current %pur_att;>
|
|
<!ELEMENT admin EMPTY>
|
|
<!ATTLIST admin %pur_att;>
|
|
<!ELEMENT develop EMPTY>
|
|
<!ATTLIST develop %pur_att;>
|
|
<!ELEMENT customization EMPTY>
|
|
<!ATTLIST customization %pur_att;>
|
|
<!ELEMENT tailoring EMPTY>
|
|
<!ATTLIST tailoring %pur_att;>
|
|
<!ELEMENT pseudo-analysis EMPTY>
|
|
<!ATTLIST pseudo-analysis %pur_att;>
|
|
<!ELEMENT pseudo-decision EMPTY>
|
|
<!ATTLIST pseudo-decition %pur_att;>
|
|
<!ELEMENT individual-analysis EMPTY>
|
|
<!ATTLIST individual-analysis %pur_att;>
|
|
<!ELEMENT individual-decision EMPTY>
|
|
<!ATTLIST individual-decision %pur_att;>
|
|
<!ELEMENT contact EMPTY>
|
|
<!ATTLIST contact %pur_att;>
|
|
<!ELEMENT profiling EMPTY>
|
|
<!ATTLIST profiling %pur_att;>
|
|
<!ELEMENT historical EMPTY>
|
|
<!ATTLIST historical %pur_att;>
|
|
<!ELEMENT telemarketing EMPTY>
|
|
<!ATTLIST telemarketing %pur_att;>
|
|
<!ELEMENT other-purpose (#PCDATA)>
|
|
<!ATTLIST other-purpose %pur_att;>
|
|
|
|
<!-- *********** RECIPIENT ************ -->
|
|
<!ELEMENT RECIPIENT ((ours
|
|
| same
|
|
| other-recipient
|
|
| delivery
|
|
| public
|
|
| unrelated)+,
|
|
EXTENSION*)>
|
|
<!ELEMENT ours (recipient-description*)>
|
|
<!ELEMENT same (recipient-description*)>
|
|
<!ATTLIST same %pur_att;>
|
|
<!ELEMENT other-recipient (recipient-description*)>
|
|
<!ATTLIST other-recipient %pur_att;>
|
|
<!ELEMENT delivery (recipient-description*)>
|
|
<!ATTLIST delivery %pur_att;>
|
|
<!ELEMENT public (recipient-description*)>
|
|
<!ATTLIST public %pur_att;>
|
|
<!ELEMENT unrelated (recipient-description*)>
|
|
<!ATTLIST unrelated %pur_att;>
|
|
<!ELEMENT recipient-description (#PCDATA)>
|
|
|
|
<!-- *********** RETENTION ************ -->
|
|
<!ELEMENT RETENTION ((no-retention
|
|
| stated-purpose
|
|
| legal-requirement
|
|
| indefinitely
|
|
| business-practices),
|
|
EXTENSION*)>
|
|
<!ELEMENT no-retention EMPTY>
|
|
<!ELEMENT stated-purpose EMPTY>
|
|
<!ELEMENT legal-requirement EMPTY>
|
|
<!ELEMENT indefinitely EMPTY>
|
|
<!ELEMENT business-practices EMPTY>
|
|
|
|
<!-- ************** DATA ************** -->
|
|
<!ELEMENT DATA-GROUP (DATA+, EXTENSION*)>
|
|
<!ATTLIST DATA-GROUP
|
|
base %URI; "http://www.w3.org/TR/P3P/base" >
|
|
<!ELEMENT DATA (#PCDATA | CATEGORIES)*>
|
|
<!ATTLIST DATA
|
|
ref %URI; #REQUIRED
|
|
optional (yes | no) "no" >
|
|
|
|
|
|
<!-- *********** DATA SCHEMA *********** -->
|
|
<!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*>
|
|
|
|
<!ELEMENT DATA-DEF (CATEGORIES?, LONG-DESCRIPTION?)>
|
|
<!ATTLIST DATA-DEF
|
|
name ID #REQUIRED
|
|
structref %URI; #IMPLIED
|
|
short-description CDATA #IMPLIED >
|
|
|
|
<!ELEMENT DATA-STRUCT (CATEGORIES?, LONG-DESCRIPTION?)>
|
|
<!ATTLIST DATA-STRUCT
|
|
name ID #REQUIRED
|
|
structref %URI; #IMPLIED
|
|
short-description CDATA #IMPLIED >
|
|
|
|
<!-- *********** CATEGORIES *********** -->
|
|
<!ELEMENT CATEGORIES (physical
|
|
| online
|
|
| uniqueid
|
|
| purchase
|
|
| financial
|
|
| computer
|
|
| navigation
|
|
| interactive
|
|
| demographic
|
|
| content
|
|
| state
|
|
| political
|
|
| health
|
|
| preference
|
|
| government
|
|
| other-category)+>
|
|
<!ELEMENT physical EMPTY>
|
|
<!ELEMENT online EMPTY>
|
|
<!ELEMENT uniqueid EMPTY>
|
|
<!ELEMENT purchase EMPTY>
|
|
<!ELEMENT financial EMPTY>
|
|
<!ELEMENT computer EMPTY>
|
|
<!ELEMENT navigation EMPTY>
|
|
<!ELEMENT interactive EMPTY>
|
|
<!ELEMENT demographic EMPTY>
|
|
<!ELEMENT content EMPTY>
|
|
<!ELEMENT state EMPTY>
|
|
<!ELEMENT political EMPTY>
|
|
<!ELEMENT health EMPTY>
|
|
<!ELEMENT preference EMPTY>
|
|
<!ELEMENT government EMPTY>
|
|
<!ELEMENT other EMPTY>
|
|
|
|
<!-- *********** EXTENSION ************ -->
|
|
<!ELEMENT EXTENSION (#PCDATA)>
|
|
<!ATTLIST EXTENSION
|
|
optional (yes | no) "yes" >
|
|
</PRE>
|
|
<H2>
|
|
<A name="Appendix_Notation">Appendix 6: ABNF Notation</A> (Non-normative)
|
|
</H2>
|
|
<P>
|
|
The formal grammar of P3P is given in this specification using a slight
|
|
modification of [<A href="#ABNF">ABNF</A>]. The following is a simple description
|
|
of the ABNF.
|
|
<DL>
|
|
<DT>
|
|
<CODE><STRONG>name = (elements) </STRONG></CODE>
|
|
<DD>
|
|
where <name> is the name of the rule, <elements> is one or more
|
|
rule names or terminals combined through the operands provided below. Rule
|
|
names are case-insensitive.
|
|
<DT>
|
|
<CODE>(</CODE><CODE><STRONG>element1 element2)</STRONG></CODE>
|
|
<DD>
|
|
elements enclosed in parentheses are treated as a single element, whose contents
|
|
are strictly ordered.
|
|
<DT>
|
|
<CODE><STRONG><a>*<b>element</STRONG></CODE>
|
|
<DD>
|
|
at least <a> and at most <b> occurrences of the element.
|
|
<DD>
|
|
<EM>(1*4<element> means one to four elements.)</EM>
|
|
<DT>
|
|
<CODE><STRONG><a>element</STRONG></CODE>
|
|
<DD>
|
|
exactly <a> occurrences of the element.
|
|
<DD>
|
|
<EM>(4<element> means exactly 4 elements.)</EM>
|
|
<DT>
|
|
<CODE><STRONG><a>*element</STRONG></CODE>
|
|
<DD>
|
|
<a> or more elements
|
|
<DD>
|
|
<EM>(4*<element> means 4 or more elements.)</EM>
|
|
<DT>
|
|
<CODE><STRONG>*<b>element</STRONG></CODE>
|
|
<DD>
|
|
0 to <b> elements.
|
|
<DD>
|
|
<EM>(*5<element> means 0 to 5 elements.)</EM>
|
|
<DT>
|
|
<CODE><STRONG>*element</STRONG></CODE>
|
|
<DD>
|
|
0 or more elements.
|
|
<DD>
|
|
<EM>(*<element> means 0 to infinite elements.)</EM>
|
|
<DT>
|
|
<CODE><STRONG>[element]</STRONG></CODE>
|
|
<DD>
|
|
optional element, equivalent to *1(element).
|
|
<DD>
|
|
<EM>([element] means 0 or 1 element.)</EM>
|
|
<DT>
|
|
<CODE><STRONG>"string"</STRONG></CODE> or
|
|
<CODE><STRONG>'string'</STRONG></CODE>
|
|
<DD>
|
|
matches the literal string given inside double quotes.
|
|
</DL>
|
|
<P>
|
|
Other notations used in the productions are:
|
|
<DL>
|
|
<DT>
|
|
; or <STRONG><CODE>/* ... */</CODE></STRONG>
|
|
<DD>
|
|
comment.
|
|
</DL>
|
|
<H2>
|
|
<A name="guiding_principles">Appendix 7: P3P Guiding Principles</A>
|
|
(Non-normative)
|
|
</H2>
|
|
<P>
|
|
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 "<A href="http://www.w3.org/TR/NOTE-P3P10-principles">P3P
|
|
Guiding Principles</A>".
|
|
<P>
|
|
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
|
|
<EM>should</EM> 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.
|
|
<H3>
|
|
Information Privacy
|
|
</H3>
|
|
<P>
|
|
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.
|
|
<P>
|
|
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:
|
|
<UL>
|
|
<LI>
|
|
<A href="http://www.cdma.org/privacy/ethics.html">CDMA Code of Ethics &
|
|
Standards of Practice: Protection of Personal Privacy</A>
|
|
<LI>
|
|
<A href="http://www.privacy.org/pi/intl_orgs/coe/dp_convention_108.txt">1981
|
|
Council of Europe Convention For the Protection of Individuals with Regard
|
|
to Automatic Processing of Personal Data</A>
|
|
<LI>
|
|
<A href="http://www.csa.ca/">CSA</A>--Q830-96 Model Code for the Protection
|
|
of Personal Information
|
|
<LI>
|
|
<A href="http://europa.eu.int/eur-lex/en/lif/dat/1995/en_395L0046.html">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</A>
|
|
<LI>
|
|
<A href="http://www.the-dma.org/library/guidelines/onlineguidelines.shtml">The
|
|
DMA's Marketing Online Privacy Principles and Guidance</A> and
|
|
<A href="http://www.the-dma.org/library/guidelines/ethicalguidelines.shtml">The
|
|
DMA Guidelines for Ethical Business Practice</A>
|
|
<LI>
|
|
<A href="http://www.oecd.org/dsti/sti/it/secur/prod/PRIV-EN.HTM">OECD Guidelines
|
|
on the Protection of Privacy and Transborder Flows of Personal Data</A>
|
|
<LI>
|
|
<A href="http://www.privacyalliance.org/resources/ppguidelines.shtml">Online
|
|
Privacy Alliance Guidelines for Online Privacy Policies</A>
|
|
</UL>
|
|
<P>
|
|
In addition, service providers and P3P implementers should recognize and
|
|
address the special concerns surrounding children's privacy.
|
|
<H3>
|
|
Notice and Communication
|
|
</H3>
|
|
<P>
|
|
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.
|
|
<P>
|
|
Service providers should:
|
|
<UL>
|
|
<LI>
|
|
Communicate explicitly about data collection and use, identifying the purpose
|
|
for which personal information is collected and the extent to which it may
|
|
be shared.
|
|
<LI>
|
|
Use P3P privacy policies to communicate about all information they propose
|
|
to collect through a Web interaction.
|
|
<LI>
|
|
Prominently post clear, human-readable privacy policies.
|
|
</UL>
|
|
<P>
|
|
User agents should:
|
|
<UL>
|
|
<LI>
|
|
Provide mechanisms for displaying a service's information practices to users.
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
Not be configured by default to transfer personal information to a service
|
|
provider without the user's consent.
|
|
<LI>
|
|
Inform users about the privacy-related options offered by the user agent.
|
|
</UL>
|
|
<H3>
|
|
Choice and Control
|
|
</H3>
|
|
<P>
|
|
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.
|
|
<P>
|
|
Service providers should:
|
|
<UL>
|
|
<LI>
|
|
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.
|
|
<LI>
|
|
Obtain informed consent prior to the collection and use of personal information.
|
|
<LI>
|
|
Provide information about the ability to review and if appropriate correct
|
|
personal information.
|
|
</UL>
|
|
<P>
|
|
User agents should:
|
|
<UL>
|
|
<LI>
|
|
Include configuration tools that allow users to customize their preferences.
|
|
<LI>
|
|
Allow users to import and customize P3P preferences from trusted parties.
|
|
<LI>
|
|
Present configuration options to users in a way that is neutral or biased
|
|
towards privacy.
|
|
<LI>
|
|
Be usable without requiring the user to store user personal information as
|
|
part of the installation or configuration process.
|
|
</UL>
|
|
<H3>
|
|
Fairness and Integrity
|
|
</H3>
|
|
<P>
|
|
Service providers should treat users and their personal information with
|
|
fairness and integrity. This is essential for protecting privacy and promoting
|
|
trust.
|
|
<P>
|
|
Service providers should:
|
|
<UL>
|
|
<LI>
|
|
Accurately represent their information practices in a clear and unambiguous
|
|
manner -- never with the intention of misleading users.
|
|
<LI>
|
|
Use information only for the stated purpose and retain it only as long as
|
|
necessary.
|
|
<LI>
|
|
Ensure that information is accurate, complete, and up-to-date.
|
|
<LI>
|
|
Disclose accountability and means for recourse.
|
|
<LI>
|
|
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.
|
|
</UL>
|
|
<P>
|
|
User agents should:
|
|
<UL>
|
|
<LI>
|
|
Act only on behalf of the user according to the preferences specified by
|
|
the user.
|
|
<LI>
|
|
Accurately represent the practices of the service provider.
|
|
</UL>
|
|
<H3>
|
|
Security
|
|
</H3>
|
|
<P>
|
|
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.
|
|
<P>
|
|
Service providers should:
|
|
<UL>
|
|
<LI>
|
|
Provide mechanisms for protecting any personal information they collect.
|
|
<LI>
|
|
Use appropriate trusted protocols for the secure transmission of data.
|
|
</UL>
|
|
<P>
|
|
User agents should:
|
|
<UL>
|
|
<LI>
|
|
Provide mechanisms for protecting the personal information that users store
|
|
in any data repositories maintained by the agent.
|
|
<LI>
|
|
Use appropriate trusted protocols for the secure transmission of data.
|
|
<LI>
|
|
Warn users when an insecure transport mechanism is being used.
|
|
</UL>
|
|
<H2>
|
|
<A name="Appendix_Working">Appendix 8: Working Group Contributors</A>
|
|
(Non-normative)
|
|
</H2>
|
|
<P>
|
|
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), Rajeev Dujari (Microsoft), Matthias Enzmann (GMD), Patrick Feng
|
|
(RPI), 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.), Mark
|
|
Uhrmacher (Doubleclick), Danny Weitzner (W3C), Michael Wallent (Microsoft),
|
|
Rigo Wenning (W3C), Betty Whitaker (NCR), Kevin Yen (Netscape), Sam Yen
|
|
(Citigroup), Alan Zausner (American Express).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
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).
|
|
<P>
|
|
Finally, <A href="#guiding_principles">Appendix 7</A> is drawn from the W3C
|
|
Note "<A href="http://www.w3.org/TR/NOTE-P3P10-principles">P3P Guiding
|
|
Principles</A>", 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.).
|
|
<P>
|
|
<HR>
|
|
<P>
|
|
<EM><SMALL><A name="changelog">Change log</A> from the
|
|
<A HREF="http://www.w3.org/TR/2000/WD-P3P-20001018/">18 October Last Call
|
|
Specification</A>:</SMALL></EM>
|
|
<UL>
|
|
<LI>
|
|
Stylistic improvements, added clarifications, many typos fixed.
|
|
<LI>
|
|
Dropped mandatory APPEL support, substituted by generic
|
|
<A HREF="#PREFERENCES">requirement on import/export of user preferences</A>
|
|
<LI>
|
|
The <CODE>other</CODE> category is now <CODE>other-category</CODE>
|
|
<LI>
|
|
Support of <CODE>EMBEDDED-INCLUDE</CODE>, <CODE>EMBEDDED-EXCLUDE</CODE>,
|
|
<CODE>COOKIE-INCLUDE</CODE> and <CODE>COOKIE-EXCLUDE</CODE> is now required
|
|
(MUST) and not just recommended (SHOULD)
|
|
<LI>
|
|
<CODE>contact_and_other</CODE>, <CODE>ident_contact</CODE>,
|
|
<CODE>other_ident</CODE>, <CODE>opt_in</CODE>, <CODE>opt_out</CODE> are now
|
|
<CODE>contact-and-other</CODE>, <CODE>ident-contact</CODE>,
|
|
<CODE>other-ident</CODE>, <CODE>opt-in</CODE>, <CODE>opt-out</CODE>
|
|
<LI>
|
|
New Scenarios added to <A HREF="#example_scenarios">Section 2.5</A>
|
|
<LI>
|
|
New <A HREF="#compact_policies">Section 4</A> on <EM><STRONG>compact
|
|
policies</STRONG></EM>
|
|
<LI>
|
|
Added new <A HREF="#test"><CODE>TEST</CODE> element</A>
|
|
</UL>
|
|
</BODY></HTML>
|