is the name of the statement.
<STATEMENT-GROUP>
STATEMENT
element
that identifies the statement group to which that statement belongsid
STATEMENT-GROUP-DEF
element.name
STATEMENT
element.| [38] | sg-extension |
= |
`<EXTENSION optional="yes">` `<STATEMENT-GROUP` `id="` quotedstring `"` `name="` quotedstring `"` [short-description] `xmlns = "http://www.w3.org/2006/01/P3Pv11" />` `</EXTENSION>` |
<STATEMENT> <EXTENSION optional="yes"> <STATEMENT-GROUP id="browsing" name="browsing of static pages" xmlns="http://www.w3.org/2006/01/P3Pv11" /> </EXTENSION> … </STATEMENT>
CONSEQUENCE
elementSTATEMENT
elements may optionally contain a
CONSEQUENCE
element that can be shown to a human user to provide
further explanation about a site's practices.
The definition of CONSEQUENCE
given here is somewhat
different from the definition given in the P3P 1.0 specification, which stated that
the element should be used for 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."
The P3P 1.1 definition has been broadened to reflect how the
CONSEQUENCE
element is being used by web sites in practice. As
the P3P 1.1 definition subsumes the P3P 1.0 definition, it is not necessary
for web sites that have developed their policies using the P3P 1.0 definition
to change their policies unless they want to take advantage of the additional
flexibility offered by the P3P 1.1 definition. See also Completeness of Human-Readable Translations .
<CONSEQUENCE>
STATEMENT
that can be shown to a human user. This field is
not intended to replace or duplicate the detailed information that may
be provided in a site's full human-readable privacy policy. Note that
user agents that display this field MAY truncate lengthy
CONSEQUENCE
strings or display this information only if a
user follows a hyperlink.| [39] | consequence |
= |
"<CONSEQUENCE>" PCDATA "</CONSEQUENCE>" |
NON-IDENTIFIABLE
elementA STATEMENT
element may optionally contain the
NON-IDENTIFIABLE
element, signifying either that there is no
data collected under this STATEMENT
, or that all of the data
referenced by that STATEMENT
will be anonymized upon
collection.
<NON-IDENTIFIABLE/>
STATEMENT
. In order
to consider the data "anonymized", there must be no reasonable way for
the entity or a third party to attach the collected data to the
identity of a natural person. Some types of data are inherently
anonymous, such as randomly-generated session IDs. Data which might
identify natural people in some circumstances, such as IP addresses,
names, or addresses, must have a non-reversible transformation applied
in order be considered "anonymized".If the NON-IDENTIFIABLE
element is present in any
STATEMENT
elements in a policy, then a human readable
explanation of how the data is anonymized MUST be included or linked to at
the discuri .
Also, if the NON-IDENTIFIABLE
element is present in a
STATEMENT
then the other elements in that STATEMENT
are optional.
| [40] | non-identifiable |
= |
"<NON-IDENTIFIABLE/>" |
PURPOSE
elementEach STATEMENT
element that does not include a
NON-IDENTIFIABLE
element MUST contain a PURPOSE
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.
<PURPOSE>
The PURPOSE
element MUST contain one or more of the
following:
<current/>
<admin/>
<develop/>
<tailoring/>
<pseudo-analysis/>
<pseudo-decision/>
<individual-analysis/>
<individual-decision/>
<contact/>
<current/>
would be
used. In addition, this does not include marketing via customized Web
content or banner advertisements embedded in sites the user is visiting
-- these cases would be covered by the
<tailoring/>
,
<pseudo-analysis/>
and
<pseudo-decision/>
, or
<individual-analysis/>
and
<individual-decision/>
purposes.<historical/>
<DISPUTES>
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 preservation of history.<telemarketing/>
<current/>
would be used.<other-purpose>
string
</other-purpose>
Each type of purpose (with the exception of current
) can have
the following optional attribute:
required
always
: The purpose is always
required; users cannot opt-in or opt-out of this use of their data.
This is the default when no required
attribute is
present.opt-in
: 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 opturi
.opt-out
: 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
opturi
. Services SHOULD also
provide these instructions or a pointer to these instructions at
the point of data collection.| [41] | purpose |
= |
"<PURPOSE>" *extension 1*purposevalue *extension "</PURPOSE>" |
| [42] | purposevalue |
= |
"<current/>" | ; Completion and Support of Activity For Which Data Was Provided "<admin" [required] "/>" | ; Web Site and System Administration "<develop" [required] "/>" | ; Research and Development "<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 |
| [43] | required |
= |
" required=" `"` ("always"|"opt-in"|"opt-out") `"` |
Service providers MUST use the above elements to explain the purpose of
data collection. Service providers MUST disclose all that apply. 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
"other
" purposes MUST provide human readable explanations of
those purposes.
PPURPOSE
element (EXTENSION)The primary purpose extension element allows user agents to determine the primary reason why the data recipient is collecting data. Multiple primary purposes may be used.
The PPURPOSE
is placed after the opening tag of the
PURPOSE
element. It is intended to expand upon the
<current/>
tag, providing a more detailed description of
data usage.
| [44] | primary-purpose = |
"<extension>" "<ppurpose>" *primary-purpose-value "</ppurpose>" "</extension>" |
| [45] | primary-purpose-value = |
"<account/>" | ; Account and/or Subscription Management "<arts/>" | ; Arts and Entertainment "<browsing/>" | ; Web Browsing "<charity/>" | ; Charitable Donations "<communicate/>" | ; Communications Services "<custom/>" | ; Customization "<delivery/>" | ; Delivery "<downloads/>" | ; Software Downloads "<education/>" | ; Education "<feedback/>" | ; Responding to User "<finmgt/>" | ; Banking and Financial Management "<gambling/>" | ; Online Gambling "<gaming/>" | ; Online Gaming "<government/>" | ; Government Services "<health/>" | ; Healthcare Services "<login/>" | ; Authentication and Authorization "<marketing/>" | ; Advertising, Marketing, and/or Promotion "<news/>" | ; News and Information "<payment/>" | ; Payment and Transaction Facilitation "<sales/>" | ; Sales of Products or Services "<search/>" | ; Search Engines "<state/>" | ; State and Session Management "<surveys/>" ; Surveys and Questionnaires |
<PPURPOSE>
The PPURPOSE
element MUST contain one or more of the
following:
<account/>
<arts/>
<browsing/>
<charity/>
<communicate/>
<custom/>
tailoring
, pseudo-decision
, or
individual-decision
. This element might be used, for
example, at a site that allows the user to change the language in which
content is presented.<delivery/>
<downloads/>
<education/>
<feedback/>
<finmgt/>
<gambling/>
<gaming/>
<government/>
<health/>
<login/>
<marketing/>
<news/>
<payment/>
<sales/>
<search/>
<state/>
<surveys/>
In the following sample, information is primarily being provided to authenticate a user as well as provide web content.
<PURPOSE> <EXTENSION optional="yes"> <PPURPOSE xmlns="http://www.w3.org/2006/01/P3Pv11"> <browsing/> <login/> </PPURPOSE> </EXTENSION> <current/> </PURPOSE>
RECIPIENT
elementEach STATEMENT
element that does not include a
NON-IDENTIFIABLE
element MUST contain a RECIPIENT
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.
<RECIPIENT>
The RECIPIENT
element MUST contain one or more of the
following:
<ours>
<delivery>
<same>
<other-recipient>
<unrelated>
<public>
Each of the above tags can optionally contain:
recipient-description
tags, containing a
description of the recipient;<ours>
, a required
attribute: this attribute is defined
exactly as the analogous attribute in the PURPOSE
tag,
indicating whether opt-in/opt-out of sharing is available (and, its
default value is always
).| [46] | recipient |
= |
"<RECIPIENT>" *extension 1*recipientvalue *extension "</RECIPIENT>" |
| [47] | recipientvalue |
= |
"<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 |
| [48] | recdescr |
= |
"<recipient-description>" PCDATA ; description of the recipient "</recipient-description>" |
Service providers MUST disclose all the recipients that apply. 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:
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.
Note that the <delivery/>
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.
JURISDICTION
element
(EXTENSION)The jurisdiction extension element allows user agents to make judgments about the trustworthiness of a data recipient based on the regulatory environment they are placed in. Jurisdictions of recipients can be rendered machine readable by inserting a known URI into the service field (e.g. the URI of a body of legislation which applies). For example organizations within the European Union can be assumed to comply to European data protection law and could therefore insert the URI of the 95/46 directive as in the example above. Some jurisdictions prohibit transfer of data to certain other jurisdictions without the explicit consent of the data subject. It should be noted therefore declaring the data transfer activity of a recipient using the P3P jurisdiction extension is not sufficient to guarantee its legality.
| [49] | recipientvalue = |
<extension> "<jurisdiction [required] | ; legal entities in the jurisdiction "service=" quoted-URI | ; indicated in the service URI xmlns="http://www.w3.org/2006/01/P3Pv11" > *recdescr "</jurisdiction> </extension> |
Example:
<RECIPIENT> <EXTENSION> <JURISDICTION service="http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:EN:HTML" short-description="31995L0046 Official Journal L 281, 23/11/1995 P. 0031 - 0050"> 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 </JURISDICTION> </EXTENSION> </RECIPIENT>
RETENTION
elementEach STATEMENT
element that does not include a
NON-IDENTIFIABLE
element MUST contain a RETENTION
element that indicates the kind of retention policy that applies to the data
referenced in that statement.
<RETENTION>
The RETENTION
element MUST contain one of the following:
<no-retention/>
<stated-purpose/>
<legal-requirement/>
<business-practices/>
<indefinitely/>
| [50] | retention |
= |
"<RETENTION>" *extension retentionvalue *extension "</RETENTION>" |
| [51] | retentionvalue |
= |
"<no-retention/>" | ; not retained "<stated-purpose/>" | ; for the stated purpose "<legal-requirement/>" | ; stated purpose by law "<indefinitely/>" | ; indeterminate period of time "<business-practices/>" ; by business practices |
DATA-GROUP
and
datatype extension
elementsEach STATEMENT
element that does not include a
NON-IDENTIFIABLE
element MUST contain at least one
DATA-GROUP
element that contains one or more
datatype
extension elements. datatype
extension
elements are used to describe the type of data that a site collects.
A set of datatype
extension Elements that every
user-agent MUST be aware of is defined in
Structure of Base Data Schema
<DATA-GROUP>
<datatype>
optional
optional
attribute is used only in policies
(not in data schema definitions).Note that user agents should be cautious about using the
optional
attribute in automated decision-making. If the
optional
attribute is associated with a data element directly
controlled by the user agent (such as the HTTP Referer
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.
datatype
elements can contain the actual data (as already seen in
the case of the ENTITY
element), and can contain related category information.
| [52] | data-group |
= |
"<DATA-GROUP" [" base=" quoted-URI] ">" *extension 1*dataref *extension "</DATA-GROUP>" |
| [53] | dataref |
= |
`<DATA" ref="` URI-reference `"` [" optional=" `"` ("yes"|"no") `"`] ">" [categories] ; the categories of the data element. [PCDATA] ; the eventual value of the data element "</DATA>" |
Here, URI-reference is
defined as in [URI]. |
For example, to reference the user's home address city, all the elements
of the data set <user><business-info/></user>
and (optionally) all the elements of the data set <user><home-info>
<telecom/></home-info></user>
, the service
would send the following references inside a P3P policy:
<DATA-GROUP> <datatype optional="yes"> <user> <home-info> <telecom/> </home-info> </user> </datatype> <datatype optional="yes"> <user> <business-info/> </user> </datatype> </DATA-GROUP>
When the actual value of the data is known, it can be expressed inside the
DATA
element. For example, as seen in the example policies:
<ENTITY> <DATA-GROUP> <EXTENSION> <datatype> <business> <orgname> CatalogExample </orgname> <contact-info> <postal> <street> 4000 Lincoln Ave. </street> <city> Birmingham </city> <state> MI </state> <postalcode> 48009 </postalcode> <country> USA </country> </postal> …
CATEGORIES
elementCategories 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. Categories allow users to
express more generalized preferences and rules over the exchange of their data
whereas data elements are intended to describe more specific types and even
instances of data. Categories SHOULD NOT be used within the DATA
elements of an ENTITY
element.
The following elements are used to denote data categories:
| [54] | categories |
= |
"<CATEGORIES>" 1*category "</CATEGORIES>" |
| [55] | category |
= |
"<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 "<location/>" | ; Location Data "<government/> | ; Government-issued Identifiers "<other-category>" PCDATA "</other-category>" ; Other |
<physical/>
<online/>
<uniqueid/>
<purchase/>
<financial/>
<computer/>
<navigation/>
<interactive/>
<demographic/>
<content/>
<state/>
<political/>
<health/>
<preference/>
<location/>
<government/>
<other-category>
string
</other-category>
<other-category>
and the
</other-category>
tags.)The Computer, Navigation, Interactive and Content 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.
The Other category SHOULD be used only when data is requested that does not fit into any other category.
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 fixed-category data elements (or "fixed data elements" for short), the latter variable-category data elements ("variable data elements"). Both types of elements are described in Section 5.2.2.
EXTENSION
elementP3P provides a flexible and powerful mechanism to extend its syntax and
semantics using one element: EXTENSION
. This element is used to
indicate portions of the policy/policy reference file/data schema which
belong to an extension. The meaning of the data within the
EXTENSION
element is defined by the extension itself.
<EXTENSION>
optional
optional
attribute a value of no
.
A mandatory extension to the P3P syntax means that
applications that do not understand this extension cannot understand
the meaning of the whole policy (or policy reference file, or data
schema) containing it. An optional extension, indicated by
giving the optional attribute a value of yes
, means that
applications that do not understand this extension can safely ignore
the contents of the EXTENSION
element, and proceed to
process the whole policy (or policy reference file, or data schema) as
usual. The optional
attribute is not required; its default
value is yes
.| [56] | extension |
= |
"<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>" |
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:
<DATA-GROUP> ... <EXTENSION optional="no"> <COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalog.example.com/P3P/region"> <USA/><Canada/><Mexico/> </COLLECTION-GEOGRAPHY> </EXTENSION> </DATA-GROUP>
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:
<POLICY> <EXTENSION optional="yes"> <ORIGIN xmlns="http://www.catalog.example.com/P3P/origin" country="USA"/> </EXTENSION> ... </POLICY>
The xmlns
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 [XML-Name], 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.
The EXTENSION
element can appear in various places within P3P
syntax: such positions are normatively specified by the
P3P 1.0 XML Schema
(and, informally specified by the ABNF syntax..
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.
P3P user agents MUST act according to the preference settings selected by the user. This requires that they be able to process policy and policy reference files as appropriate to evaluate each policy with respect to a user's preferences or other criteria specified by the settings. Depending on these settings, this may require, for example, that the user agent verify that required parts of the P3P policy are present, or check that the syntax of the entire policy is valid.
Compact policies are a performance optimization that is OPTIONAL for both user agents and servers. They represent only a summary of a site's full P3P policy for a cookie; the full P3P policy is the authoritative statement of policy. However, if a site makes compact policy statements, it MUST make these statements in good faith. 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.
User agents that use compact policies as part of their decision making MUST include a mechanism that allows users to determine that a particular decision was made based on a compact policy and to view that compact policy. However, user agents that provide general information about a site's P3P policies to users MUST use the full P3P policy and MUST NOT use the compact policy for this purpose.
In P3P, compact policies contain policy information related to cookies (cf. [COOKIES] and [STATE]) 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 all cookies set in the same HTTP response as the compact policy, all cookies set by scripts associated with that HTTP response, and also to data linked to the cookies.
Any HTTP resource MAY include a P3P compact policy through the P3P
response header (cf. Section 2.2.2). If a site is
using P3P headers, it SHOULD include this on responses for all appropriate
request methods, including HEAD
and OPTION
requests.
The P3P compact policy header has a quoted string that may contain one or more delimited tokens (the "compact policy"). Tokens can appear in any order, and the space character (" ") is the only valid delimiter. The syntax for this header is as follows:
| [57] | compact-policy-field |
= |
`CP="` compact-policy `"` |
| [58] | compact-policy |
= |
compact-token *(" " compact-token) |
| [59] | compact-token |
= |
compact-access | compact-disputes | compact-remedies | compact-non-identifiable | compact-purpose | compact-recipient | compact-retention | compact-categories | compact-test |
As for all HTTP headers, the name of the P3P header field is case-insensitive. The field-value (i.e., the content of the header) is instead case sensitive.
If an HTTP response includes more than one compact policy, P3P user agents MUST ignore all compact policies after the first one.
P3P compact policies use tokens representing the following elements from
the P3P vocabulary: ACCESS
, CATEGORIES
,
DISPUTES
, NON-INDENTIFIABLE
, PURPOSE
,
RECIPIENT
, REMEDIES
, RETENTION
,
TEST
.
If a token appears more than once in a single compact policy, the compact policy has the same semantics as if that token appeared only once. If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.
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:
ACCESS
Information in the ACCESS
element is represented in compact
policies using tokens composed by a three letter code:
| [60] | compact-access |
= |
"NOI" | ; for <nonident/> "ALL" | ; for <all/> "CAO" | ; for <contact-and-other/> "IDC" | ; for <ident-contact/> "OTI" | ; for <other-ident/> "NON" ; for <none/> |
DISPUTES
If a full P3P policy contains a DISPUTES-GROUP
element that
contains one or more DISPUTES
elements, then the server should
signal the user agent by providing a single
"DSP
" token in the P3P-compact policy field:
| [61] | compact-disputes |
= |
"DSP" ; there are some DISPUTES |
REMEDIES
Information in the REMEDIES
element is represented in compact
policies as follows:
| [62] | compact-remedies |
= |
"COR" | ; for <correct/> "MON" | ; for <money/> "LAW" ; for <law/> |
NON-IDENTIFIABLE
The presence of the NON-IDENTIFIABLE
element in every
statement of the policy is signaled by the NID
token (note that
the NID
token MUST NOT be used unless the
NON-IDENTIFIABLE
element is present in every statement within
the policy):
| [63] | compact-non-identifiable |
= |
"NID" ; for <NON-IDENTIFIABLE/> |
PURPOSE
Purposes are expressed in P3P compact policy format using tokens composed
by a three letter code plus an optional one letter attribute. Such an
optional attribute encodes the value of the "required
" attribute
in full P3P policies: its value can be "a
", "i
" and
"o
", which mean that the "required
" attribute in
the corresponding P3P policy must be set to "always
",
"opt-in
" and "opt-out
" respectively.
If a P3P compact policy needs to specify one or more other-purposes in its
full P3P policy, a single OTP
flag is used to signal the user
agent that other-purposes exist in the full P3P policy.
The corresponding associations among P3P purposes and compact policy codes follow:
| [64] | compact-purpose |
= |
"CUR" | ; for <current/> "ADM" [creq] | ; for <admin/> "DEV" [creq] | ; for <develop/> "TAI" [creq] | ; for <tailoring/> "PSA" [creq] | ; for <pseudo-analysis/> "PSD" [creq] | ; for <pseudo-decision/> "IVA" [creq] | ; for <individual-analysis/> "IVD" [creq] | ; for <individual-decision/> "CON" [creq] | ; for <contact/> "HIS" [creq] | ; for <historical/> "TEL" [creq] | ; for <telemarketing/> "OTP" [creq] ; for <other-purpose/> |
| [65] | creq |
= |
"a"| ;"always" "i"| ;"opt-in" "o" ;"opt-out" |
RECIPIENT
Recipients are expressed in P3P compact policy format using a three letter
code plus an optional one letter attribute. Such an optional attribute
encodes the value of the "required
" attribute in full P3P
policies: its value can be "a
", "i
" and
"o
", which mean that the "required
" attribute in
the corresponding P3P policy must be set to "always
",
"opt-in
" and "opt-out
" respectively.
The corresponding associations among P3P recipients and compact policy codes follow:
| [66] | compact-recipient |
= |
"OUR" | ; for <ours/> "DEL" [creq] | ; for <delivery/> "SAM" [creq] | ; for <same/> "UNR" [creq] | ; for <unrelated/> "PUB" [creq] | ; for <public/> "OTR" [creq] ; for <other-recipient/> |
RETENTION
Information in the RETENTION
element is represented in
compact policies as follows:
| [67] | compact-retention |
= |
"NOR" | ; for <no-retention/> "STP" | ; for <stated-purpose/> "LEG" | ; for <legal-requirement/> "BUS" | ; for <business-practices/> "IND" ; for <indefinitely/> |
CATEGORIES
Categories are represented in compact policies as follows:
| [68] | compact-categories |
= |
"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/> "LOC" | ; for <location/> "GOV" | ; for <government/> "OTC" ; for <other-category/> |
Note that if a P3P policy specifies one or more
other-category
in its full P3P policy, a single
OTC
token is used to signal the user agent that
other-category
's exist in the full P3P policy.
TEST
The presence of the TEST
element is signaled by the
TST
token:
| [69] | compact-test |
= |
"TST" ; for <TEST/> |
STATEMENT
The STATEMENT element is represented in compact policies using the curly brace { } symbols. The { represents the opening STATEMENT tag and the } represents the closing statement tag.
The syntax of the compact statement corresponds to the syntax of the full statement. Unless it surrounds a compact NON-IDENTIFIABLE element, each pair of braces MUST surround one compact RETENTION element and at least one of each of the following compact elements: PURPOSE, RECIPIENT, and CATEGORIES. Alternatively, a pair of braces may surround a compact NON-IDENTIFIABLE element; optionally any of the PURPOSE, RECIPIENT, and CATEGORIES elements; and optionally a RETENTION element.
A compact policy that has an improperly matching pair of curly braces or is missing one of the required statement elements MUST be treated as if no curly braces are present.
A compact policy may contain one or more statements. A compact policy with no {} elements is considered to have a single implied statement element.
It is reminded here that the <our-host>
compact token
can be used here. The OHO
token is specified in
the section on Domain Relationships.
| [70] | compact-statement |
= |
"{" ; for <STATEMENT> ((compact-retention compact-purpose compact-recipient 1*compact-categories) | (compact-non-identifiable [compact-purpose] [compact-recipient] [compact-retention] *[compact-categories])) "}" ; for </STATEMENT> |
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 SET-COOKIE
header or cookies set by
script.
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.
When using P3P compact policies, the Web site is responsible for building
a compact policy by summarizing the policy referenced by the
COOKIE-INCLUDE
elements of a P3P policy reference file. If a
site's policy reference file uses COOKIE-EXCLUDE
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.
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. The information from the full policy that is discarded when building a compact policy includes expiry, data group/data-schema elements, entity elements, consequences elements, and disputes elements are reduced.
Full policies that include mandatory extensions MUST NOT be represented as compact policies.
The P3P 1.0 specification required that all purposes, recipients, and
categories that appear in multiple statements in a full policy be aggregated
in a compact policy, as described in section 3.3.1. With the addition of the
compact STATEMENT
element in P3P 1.1, this is no longer
necessary, although it is still permitted. When performing the aggregation, a
Web site MUST disclose all relevant tokens (for instance, observe Example
4.1, where multiple retention policies are specified.)
In addition, for each fixed category data element appearing in a statement the associated category as defined in the associated schema MUST be included in the compact policy.
Example 4.1:
Consider the following P3P policy:
<POLICY name="sample" 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<EMAIL_ADDRESS></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<EMAIL_ADDRESS></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> <individual-decision required="opt-out"/> </PURPOSE> <RECIPIENT> <ours/> </RECIPIENT> <RETENTION> <stated-purpose/> </RETENTION> <DATA-GROUP> <DATA ref="#user.name.given"/> <DATA ref="#dynamic.cookies"> <CATEGORIES> <preference/> <uniqueid/> </CATEGORIES> </DATA> </DATA-GROUP> </STATEMENT> </POLICY>
The corresponding compact aggregated policy is:
"NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"
The corresponding compact policy using the new compact
grouping mechanism called compact-statement
:
"NON DSP { ADM DEV PSD OUR IND PRE NAV } { IVDo OUR STP PHY PRE UNI }"
Each STATEMENT
element in a P3P Policy must
define the data type to which it applies using a
DATA-GROUP
element. A data schema is a
description of the set of data types which may be used within
policy DATA-GROUP
elements. A data schema is a hierarchical
set of data types of increasing granularity, which
allow P3P DATA-GROUP
elements to describe the specific classes
of data a service is actually or potentially collecting collect. Policies may
use either the Base Data Schema provided by this specification, or may create
custom data schemas according to the rules set out in section 5.3
STATEMENT
data types may be specified to different levels
of granularity. For example, STATEMENTS
may declare that they
collect data which are:
user(<user/>) or
user, homeinfo AND online:
<user> <homeinfo> <online/> </homeinfo> </user>:i.e. data such as a person's email address which is both user data, home info data and online data. This is obviously a more granular description than just "User". In set theory terms, we mean the intersection of these 3 classes
For a given STATEMENT
data type declared, it must be
assumed that all levels of detail below the lowest type in the
hierarchy are also collected. So in the above example if
the STATEMENT
only specifies collection of User data (case 1.)
then for evaluation purposes, it should be assumed that the
service also collects data such as a user's work address,
navigation data etc…. In the second case however, it should
be assumed that the service collects only a user's home online
data - i.e. home email and uri. The more general the type you
choose (the higher in the hierarchy), the more data types you
are making statements about.
Note that for the purposes of evaluating
a STATEMENT
, user agents MUST interpret MAY
collect as conservatively as possible and assume that any
data types mentioned, WILL be collected.
However for the purposes of data collection, STATEMENT
elements
MUST NOT be understood as a request for data for all the data types
declared.
The structure of the default hierarchy of types is described in the base data structure section. P3P 1.1. provides a new format for expressing P3P data schemas in a simpler way than P3P 1.0. The hierarchy of the P3P 1.1 data schema is based on the hierarchy of the P3P 1.0 data schema but is expressed using standard XML syntax. A description of the P3P 1.0 data schema can be referenced in the P3P 1.0 Specification The new format uses Structures and the more general Datatypes which can be validated against an XML schema.
The P3P 1.1 Data Schema is an XML schema which describes elements organized in a hierarchy of increasing specificity. The elments in higher places include all allowed subtypes. An element high up in the hierarchy thus contains all the meaning of the allowed subtypes, unless the collected subtypes are declared by inserting a child element.
For example
<datatype> <user/> </datatype>
means: "the service may collect any of the allowed subtypes of user data" (name,birthdate,login, cert etc....) Furthermore this property is carried through to all the subtypes of these elements. So collecting user data also means collecting login-id and login-password etc …
If instead the following is specified:
<datatype> <user> <cert> <key/> </cert> </user> </datatype>
this means that the service may only collect the user's certificate key and nothing else.
P3P defines a default data schema called the P3P base data schema that includes a large number of data elements commonly used by services. The elements of the base data schema, their names and meanings were properly internationalized. Note that the data element names specified in the base data schema or in custom 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. Note however that automatic form filling tools cannot deal with abstract data types (i.e. types must specify how they are instantiated. For example <user/> is abstract but <user><name><prefix/></name></user> can be instantiated.)
The following is an example instance of a P3P1.1 compliant datatype element. Full details of the data schema hierarchy are given in section 5.5.. Details on backward compatibility are given in section 5.7
<DATA-GROUP> <EXTENSION> <datatype optional="yes"> <dynamic> <cookies> <categories> <preference/> </categories> </cookies> <clickstream/> </dynamic> </datatype> </EXTENSION> <DATA ref="#dynamic.clickstream"> <categories>preference</categories> </DATA> </DATA-GROUP>
This example shows the following aspects of how to use data elements in P3P 1.1:
datatype
element.datatype
element indicates
whether or not the site requires visitors to submit
this type of data in order to access a resource or complete a transaction;
"no" indicates that the data element is not optional (it is required),
while "yes" indicates that the data element is optional. The default is
"no.".STATEMENT
is about. The hierarchy of these elements is described in
detail in section 5.5 Structure of Base
Data Schema.dynamic
, but only the
subclass of dynamic data
which is also clickstream
data
.<user> <name/> <bdate/> </user>
Is equivalent to:
<user> <name/> </user> <user> <bdate/> </user>
<annotation> <documentation> HTTP Protocol Information </documentation> <appinfo> <categories> <navigation/> <computer/> </categories> </appinfo> </annotation>
categories
for fixed category elements (such as
dynamic
, clickstream
in the above example) has no
effect and is not recommended. All "fixed category" data elements have
categories assigned to them when they are defined in a data schema. This only
serves as extra semantics for the benefit of rule systems.
Categories are a way of giving a meaning to types of data which may be too general to be contained in specific data types. For example cookie data may contain any kind of information and it is therefore useful to be able to describe whether the cookie data is demographic, navigation etc… Another example is clickstream data, which may be delimited as navigation, computer or demographic type clickstream data.
Categories are used in different ways in writing and evaluating P3P policies.
Variable-category
data elements are elements which do not
fit into any specific category because they may contain any
kind of information and therefore require the policy writer to
specify the category of information which is actually
collected. In P3P policies, the CATEGORIES
element is used to
specify the type of such variable-category data elements.
Services MUST specify at least one category for each
variable-category element in a P3P policy, using a CATEGORIES
element. Extra categories are appended as siblings below a
single CATEGORIES
element.
In the base data schema, there are only 2 so-called
variable-category elements,
<dynamic><cookies/></dynamic>
and
<dynamic><miscdata/></dynamic>
. Cookies are
defined as variable-category because they contain any kind of
personally identifiable data and applications evaluating a
policy need more information about what kind of data is stored
in a cookie. The miscdata element acts as a catchall data type
which can in effect be used to specify miscellaneous data in a
number of the P3P categories.
An element in a custom schema is defined as "variable-category" if it satisfies the following conditions
In this capacity as broad types for variable-category data
elements such as cookies, categories
can only be assigned as a
leaf child of the hierarchy.
For example the following is correct syntax:
<p3p11:data-group> <p3p11:datatype> <p3p11:dynamic> <p3p11:cookies> <p3p:CATEGORIES> <p3p:navigation/> <p3p:preference/> </p3p:CATEGORIES> </p3p11:cookies> </p3p11:dynamic> </p3p11:datatype> </p3p11:data-group>
Whereas the following is not:
<p3p11:data-group> <p3p11:datatype> <p3p11:dynamic> <p3p11:cookies/> <p3p:categories> <p3p:navigation/> <p3p:preference/> </p3p:categories> </p3p11:dynamic> </p3p11:datatype> </p3p11:data-group>
And nor is the following (no categories specified for a variable-category element):
<p3p11:data-group> <p3p11:datatype> <p3p11:dynamic> <p3p11:cookies/> <p3p11:/dynamic> <p3p11:/datatype> </p3p11:data-group>
Categories are intended for use in rule systems such as APPEL
to allow preference sets to match a broad range of data elements
without listing each one individually. Most of the elements in
the base data schema are so called fixed data elements
:
they belong to one or more category classes. By assigning a
category invariably to elements or structures in the base data
schema, user agent rule systems are able to refer to entire
groups of elements simply by referencing the corresponding
category. For example, using [APPEL], the privacy
preferences exchange language, users can write rules that warn
them when they visit a site that collects any data element in the
navigation category.
Categories are assigned to all elements in the XSD schema
except variable category elements. Categories for fixed elements
are defined using the XSD annotation, appinfo element. These
category assignments are never used in policies but add
semantics to data types for the purposes of matching. These
semantics can then be used by rule systems within user-agents to
match ranges of data types according to categories rather than
specifying each individual data type. Rule evaluation engines
should extract categories assigned from the appinfo
element in
data schemas. Multiple categories may be assigned for example
the following element in the base data schema defines the contact
data type
<xsd:element minOccurs="0" name="home-info" type="contactComplexType"> <xsd:annotation> <xsd:appinfo> <CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <physical /> <online /> <demographic /> </CATEGORIES> </xsd:appinfo> <xsd:documentation> User's Home Contact Information </xsd:documentation> </xsd:annotation> </xsd:element>
Please note that user agents MUST ignore any categories assigned to fixed-category elements in policies and use the original category (or set of categories) listed in the schema definition for the purposes of rule-matching.
Data elements or custom schemas may reference elements in other schemas simply by referring to another namespace.
Example data element referencing a custom data element:
<datatype xmlns="http://www.example.com/creditcardDataSchema"> <creditCard> <date/> </creditCard> </datatype>
For more information, please have a look at 5.3. Defining New Schemas
Example schema referencing another schema:
Natural language descriptions of the meaning of data
elements may be found within <annotation>
children of the element definition in any P3P1.1 XSD data
schema. These may be of 2 kinds:
<description>A short description for display in
data capture summaries.</description>
<appinfo> <long-description>A long
description for documentation purposes</long-description>
</appinfo>
These descriptions are intended to be used by user-agents in creating human-readable translations of policies. They SHOULD NOT however be included in machine readable policies.
Services publishing custom data schemas MAY wish to translate these fields into multiple languages. The annotation element's contents MAY be translated, but the element name MUST NOT be translated - this field needs to stay constant across translations of a data schema. If a service is going to provide a data schema in multiple natural languages, then it SHOULD examine the Accept-Language HTTP request-header on requests for that data schema to pick the best available alternative.
Services may declare new data elements by creating and publishing their own data schemas expressed using [XML-Schema1] or [XML-Schema2]. These schemas MUST also comply with the following rules over and above the rules of correct XML Schema syntax.
Custom schemas:
datatype
with an
optional
attribute with allowed values yes/no
:
See the examples below.There are some additional requirements relating to the use of categories
Custom Schemas:
xsd:complexType
to reference P3P1.0 categories
(this can also be copied from the base data schema - see the examples
below)variable-category
elements by referencing
the categories type defined in 1 above. (i.e. they must be required
to define at least one category from the P3P schema) For example:
<xsd:element minOccurs="0" name="miscdata" type="categoriesComplexType"> <xsd:annotation> <xsd:documentation> Miscellaneous non-base data schema information </xsd:documentation> </xsd:annotation> </xsd:element>
variable-category
element, categories
MUST also be assigned for all elements defined in custom data schemas,
according to the scheme of categories defined in the P3P 1.0 schema
(see Section 3.4 for the complete
list of allowed categories).Custom schemas MUST NOT create
new categories. If custom schema authors need to create broad
types of data which do not fall within the 17 category elements
defined by P3P1.1, these may instead be defined within the standard
hierarchy of the data schema as top level data types.
Categories are assigned using the xsd:appinfo
element as in
the following example:
<xsd:element minOccurs="0" name="CreditCard" type="CC"> <xsd:annotation> <xsd:appinfo> <categories xmlns="http://www.w3.org/2002/01/P3Pv1"> <financial /> <purchase /> <location /> </categories> </xsd:appinfo> <xsd:documentation> Credit Card Data </xsd:documentation> </xsd:annotation> </xsd:element>
In addition, it is helpful for schema readability (but not
required) to organize the structure in terms of named and reuseable
xsd:complexType
elements. For example the base data schema
repeatedly reuses the dateComplexType. This also provides additional semantics
about the structure of the schema (e.g. the information that a
certain set of types are all dates). The syntax used in the P3P
base data schema should act as a guide to authors of custom data
schemas. The following commented snippet from the base data schema
shows good syntax for creating custom schemas and includes all the
requirements stated above:
Sample of typical syntax for a P3P1.1 schema (commented snippet of base data schema)
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:p3p="http://www.w3.org/2002/01/P3Pv1" xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11" xmlns:p3p11bds="http://www.w3.org/2006/01/P3Pv11BDS" xmlns:example="http://example.org/2006/01/custom" targetNamespace="http://example.org/2006/01/custom" elementFormDefault="qualified" > <!-- ***************************************************************************** The following section can be cut and pasted into all custom schemas - Start here. All types in the custom schema are descendents of the datatype element. ******************************************************************************* --> <import namespace="http://www.w3.org/2002/01/P3Pv1" schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd" /> <import namespace="http://www.w3.org/2006/01/P3Pv11" schemaLocation="http://www.w3.org/2006/01/P3Pv11" /> <import namespace="http://www.w3.org/2006/01/P3Pv11BDS" schemaLocation="http://www.w3.org/2006/01/P3Pv11BDS" /> <complexType name="categoriesComplexType"> <all> <element ref="p3p:categories" minOccurs="1" /> </all> </complexType> <!-- ***************************************************************************** Root type and optional(yes/no) attribute ******************************************************************************* --> <element name="datatype" type="datadefComplexType" /> <!-- ***************************************************************************** First child of root ******************************************************************************* --> <complexType name="datadefComplexType"> <all> <!-- ***************************************************************************** The preceding section can be cut and pasted into all custom schemas - Finish here ******************************************************************************* --> <element minOccurs="0" name="dynamic" type="dynamicComplexType" /> <element minOccurs="0" name="user" type="userComplexType" /> <element minOccurs="0" name="thirdparty" type="thirdpartyComplexType" /> <element minOccurs="0" name="business" type="businessComplexType" /> </all> <!--**************************************************************************** Also add this attribute definition - optional attribute of datatype element ***********************************************************************************--> <attribute type="p3p:yes_no" default="no" use="optional" name="optional" /> <!--*************************************************************************** Also add this attribute definition (above) - optional attribute of datatype element *****************************************************************************--> </complexType> <!--*************************************************************************** The user data complex type *****************************************************************************--> <complexType name="userComplexType"> <all> <element minOccurs="0" name="name" type="personnameComplexType"> <annotation> <appinfo> <p3p:CATEGORIES xmlns="http://www.w3.org/2002/01/P3Pv1"> <physical /> <demographic /> </p3p:CATEGORIES> </appinfo> <documentation> User's Name </documentation> </annotation> </element> <element minOccurs="0" name="bdate" type="dateComplexType"> <annotation> <appinfo> <!--*************************************************************************** Categories defined here *****************************************************************************--> <categories xmlns="http://www.w3.org/2002/01/P3Pv1"> <demographic /> </categories> </appinfo> <documentation> User's Birth Date </documentation> </annotation> </element> …etc… </all> </complexType> <!--*************************************************************************** The dynamic data complex type *****************************************************************************--> <complexType name="dynamicComplexType"> <all> <element minOccurs="0" name="clickstream" type="loginfoComplexType"> <annotation> <appinfo> <p3p:CATEGORIES> <p3p:navigation /> <p3p:computer /> </p3p:CATEGORIES> </appinfo> <documentation> Click-stream information </documentation> </annotation> </element> <element minOccurs="0" name="http" type="httpinfoComplexType"> <annotation> <appinfo> <p3p:CATEGORIES> <p3p:navigation /> <p3p:computer /> </p3p:CATEGORIES> </appinfo> <documentation> HTTP protocol information </documentation> </annotation> </element> …etc… <!--*************************************************************************** A variable-category element *****************************************************************************--> <element minOccurs="0" name="cookies" type="categoriesComplexType"> <annotation> <documentation> Use of HTTP cookies </documentation> </annotation> </element> </all> </complexType> …etc… </schema>
This section defines exactly what is meant by a hierarchy of increasing specicifity.
More formally speaking, for an element
<B>
to be defined as an allowed child of
element <A>
means if the policy states that
it may collect data of type <A>
, then it
can also be taken to state that it may also collect data of
type <B>
. The inverse relation however
does not hold. Transitivity also holds for this relation. That
is, if a policy states that it collects data of type
<A>
and if <B>
is an
allowed subelement of <A>
and
<C>
is an allowed subelement of
<B>
, then it can be assumed that the
controller of the policy may also collect data of type
<C>
. The hierarchy is mirrored by the
hierarchy of XML elements used to express them. It should be
noted that the use of a particular data element is NOT
a request for that particular type of data, or a statement that
the data is collected, rather a hypothetical
statement that it may be collected.
For example if <classicalmusicpreference>
is defined as an allowed subelement of
<musicalpreference>
, this means that if a
policy statement has the data type
<datatype> <musicalpreference/> </datatype>
then it can be assumed that the STATEMENT
is also describing
the collection of data of classical music preference data.
The relationships are also transitive, so
<baroquemusicpreference>
is understood to be
a subclass of <musicalpreference>
because it
is a subelement of
<classicalmusicpreference>
which is a
subelement of <musicalpreference>
This could be expressed in the following XML Schema:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:p3p="http://www.w3.org/2002/01/P3Pv1" xmlns:sample="http://example.org/sample" targetNamespace="http://example.org/sample" elementFormDefault="qualified" > <!-- ***************************************************************************** The following section can be cut and pasted into all custom schemas - Start here. All types in the custom schema are descendents of the datatype element. ******************************************************************************* --> <xsd:import schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd" namespace="http://www.w3.org/2002/01/P3Pv1" /> <xsd:complexType name="categoriesComplexType"> <xsd:all> <xsd:element ref="p3p:categories" minOccurs="1" /> </xsd:all> </xsd:complexType> <!-- ***************************************************************************** root type and optional(yes/no) attribute ******************************************************************************* --> <xsd:element name="datatype" type="datadefComplexType" /> <!-- ***************************************************************************** first child of root ******************************************************************************* --> <xsd:complexType name="datadefComplexType"> <xsd:all> <!-- ***************************************************************************** The preceding section can be cut and pasted into all custom schemas - Finish here ******************************************************************************* --> <xsd:element minOccurs="0" name="musical-preference" type="musical-preferenceComplexType"> <xsd:annotation> <xsd:documentation> Musical Preferences </xsd:documentation> <xsd:appinfo> <categories xmlns="http://www.w3.org/2002/01/P3Pv1"> <preference/> </categories> </xsd:appinfo> </xsd:annotation> </xsd:element> </xsd:all> <!--**************************************************************************** Optional attribute of datatype element Always add this attribute definition - optional attribute of datatype element ***********************************************************************************--> <xsd:attribute type="p3p:yes_no" default="no" use="optional" name="optional" /> </xsd:complexType> <xsd:complexType name="musical-preferenceComplexType"> <xsd:all> <xsd:element minOccurs="0" name="classicalmusic-preference" type="classicalmusic-preferenceComplexType"> <xsd:annotation> <xsd:documentation> Classical Music Preferences </xsd:documentation> <xsd:appinfo> <categories xmlns="http://www.w3.org/2002/01/P3Pv1"> <preference/> </categories> </xsd:appinfo> </xsd:annotation> </xsd:element> </xsd:all> </xsd:complexType> <xsd:complexType name="classicalmusic-preferenceComplexType"> <xsd:all> <xsd:element minOccurs="0" name="baroquemusic-preference"> <xsd:annotation> <xsd:documentation> Baroque Music Preferences </xsd:documentation> <xsd:appinfo> <categories xmlns="http://www.w3.org/2002/01/P3Pv1"> <preference/> </categories> </xsd:appinfo> </xsd:annotation> </xsd:element> </xsd:all> </xsd:complexType> </xsd:schema>
An essential requirement on data schemas is the persistence of data schemas: data schemas that can be fetched at a certain URI can only be changed by extending the data schema in a backward-compatible way (that is to say, changing the data schema does not change the meaning of any policy using that schema). This way, the URI of a policy acts in a sense like a unique identifier for the data elements and structures contained therein: any data schema that is not backward-compatible must therefore use a new different URI.
Note that a useful application of the persistence of data schemas is given for example in the case of multi-lingual sites: multiple language versions (translations) of the same data schema can be offered by the server, using the HTTP "Content-Language" response header field to properly indicate that a particular language has been used for the data schema.
The XML schema is not designed to be human readable, but in writing policies, and choosing data elements to make statements about, it can be useful to have a picture of the hierarchy of categories available. Section 5.5.1. gives a visual overview of the data schema hierarchy which is intended to be used as a quick reference. Section 5.5.2. lists elements with their exact definitions and their allowed children. It does not show the allowed categories, which are described in section 5.5.2.
 Although it is a flat list, it does define the hierarchy by defining the allowed subtypes of each class. The following tables are mainly for referencing the exact description of the meaning of each data type and the allowed categories. 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. To choose an element from the hierarchy, you should refer to the tables in section 5.5.1.
| Type | Allowed Categories | Allowed Descendents | Short Description | Notes |
|---|---|---|---|---|
| Dynamic | Variable | clickstream ,http, clientevents, cookies, searchtext, interactionrecord, miscdata | Dynamic Data | In some cases, there is a need to specify data elements that do not have fixed values that a user might type in or store in a repository. In the P3P base data schema, all such elements are grouped under the class of dynamic data. 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. |
| User | Physical Contact Information, Demographic and Socioeconomic Data, Unique Identifiers,Online Contact Information | name, bdate, login, cert, gender, jobtitle, home-info, business-info | General information about the user | |
| Third-party | Physical Contact Information, Demographic and Socioeconomic Data, Unique Identifiers,Online Contact Information | name, bdate, login, cert, gender, jobtitle, home-info, business-info | The thirdparty data set allows users and businesses to provide values for a related third party. This can be useful whenever third party information needs to be exchanged, for example when ordering a present online that should be sent to another person, or when providing information about one's spouse or business partner. Such information could be stored in a user repository alongside the user data set. User agents may offer to store multiple such thirdparty data sets and allow users to select the appropriate values from a list when necessary. The allowed subtypes of thirdparty data element are identical to those of the user data set. | |
| Business | orgname, department, cert, contact-info | The business data type features a subset of user data relevant for describing legal entities. In P3P1.1, this data element is primarily used for describing the policy entity, although it should also be applicable to business-to-business interactions. | ||
orgname |
Physical Contact Information, Demographic and Socioeconomic Data |
Organization Name |
||
name |
Physical Contact Information, Demographic and Socioeconomic Data |
prefix, given, family, middle, suffix, nickname |
User's Name |
|
bdate |
Demographic and Socioeconomic Data |
ymd.year, ymd.month, ymd.day, hms.hour, hms.minute, hms.second, fractionsecond, timezone |
User's Birth Date |
|
login |
Unique Identifiers |
id,password |
User's Login Information |
The login element and its children refer to information (IDs and passwords) for computer systems and Web sites which require authentication. Note that this data element should not be used for computer systems or Web sites which use digital certificates for authentication: in those cases, the cert element should be used. |
cert |
Unique Identifiers |
key, format |
User's Identity Certificate |
The cert element and its children refer to identity certificates (like, for example, X.509). |
gender |
Demographic and Socioeconomic Data |
- |
User's Gender (Male or Female) |
|
employer |
Demographic and Socioeconomic Data |
- |
User's Employer |
|
department |
Demographic and Socioeconomic Data |
- |
Department or Division of Organization where User is Employed |
|
jobtitle |
Demographic and Socioeconomic Data |
- |
User's Job Title |
|
home-info |
Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data |
postal, telecom, online |
User's Home Contact Information |
|
contact-info |
Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data |
postal, telecom, online |
Contact Information for the Organization |
|
business-info |
Physical Contact Information, Online Contact Information, Demographic and Socioeconomic Data |
postal, telecom, online, employer, department |
User's Business Contact Information |
|
clickstream |
Navigation and Click-stream Data, Computer Information |
uri, timestamp, clientip, other.httpmethod, other.bytes, other.statuscode |
Click-stream Information | The clickstream element and its children refer to information typically stored in Web-server access logs. The clickstream element is expected to apply to practically all Web sites. It represents the combination of information typically found in Web server access logs: the IP address or hostname of the user's computer, the URI of the resource requested, the time the request was made, the HTTP method used in the request, the size of the response, and the HTTP status code in the response. Web sites that collect standard server access logs as well as sites which do URI path analysis can use this data element to describe how that data will be used. Web sites that collect only some of the data elements listed as allowed children of the clickstream element MAY choose to list those specific elements rather than the entire dynamic-clickstream element. This allows sites with more limited data-collection practices to accurately present those practices to their visitors. The resource in the HTTP request is captured by the uri field. The IP address of the client system making the request is given by the clientip field. |
http |
Navigation and Click-stream Data, Computer Information |
referer, useragent |
HTTP Protocol Information | The http element contains additional information contained in the HTTP protocol. The http element and its children refer to information carried by the HTTP protocol which is not covered by the clickstream element and its children. |
clientevents |
Navigation and Click-stream Data |
- |
User's Interaction with a Resource | The clientevents element represents data about how the user interacts with their Web browser while interacting with a resource. For example, an application may wish to collect information about whether the user moved their mouse over a certain image on a page, or whether the user ever brought up the help window in a Java applet. This kind of information is represented by the clientevents data element. Much of this interaction record is represented by the events and data defined by the Document Object Model (DOM) Level 2 Events [DOM2-Events]. The clientevents data element also covers any other data regarding the user's interaction with their browser while the browser is displaying a resource. The exception is events which are covered by other elements in the base data schema. For example, requesting a page by clicking on a link is part of the user's interaction with their browser while viewing a page, but merely collecting the URL the user has clicked on does not require declaring this data element; clickstream covers that event. However, the DOM event DOMFocusIn (representing the user moving their mouse over an object on a page) is not covered by any other existing element, so if a site is collecting the occurrence of this event, then it needs to state that it collects the dynamic.clientevents element. Items covered by this data element are typically collected by client-side scripting languages, such as JavaScript, or by client-side applets, such as ActiveX or Java applets. Note that while the previous discussion has been in terms of a user viewing a resource, this data element also applies to Web applications which do not display resources visually - for example, audio-based Web browsers. |
cookies |
- |
Use of HTTP Cookies | The cookies element should be used whenever HTTP cookies are set or retrieved by a site. Please note that cookies is a variable category data element and requires the explicit declaration of usage categories in a policy. | |
miscdata |
- |
Miscellaneous Non-base Data Schema Information | The miscdata element references information collected by the service that the service does not reference using a specific data element. Categories have to be used to better describe these data: sites MUST reference a separate miscdata element in their policies for each category of miscellaneous data they collect. | |
searchtext |
Interactive Data |
- |
Search Terms | The searchtext element references a specific type of solicitation used for searching and indexing sites. For example, if the only fields on a search engine page are search fields, the site only needs to disclose that data element. |
interactionrecord |
Interactive Data |
- |
Server Stores the Transaction History | The interactionrecord element should be used if the server is keeping track of the interaction it has with the user (i.e. information other than clickstream data, for example account transactions, etc). |
ymd.year |
- |
Year |
The following elements refer to data connected with
dates. Since date information can be used in different ways,
depending on the context, all such information is tagged as being of
variable category. For example, schema definitions can
explicitly set the corresponding category in the element referencing
these elements, where soliciting the birthday of a user might be
"Demographic and Socioeconomic Data", while the expiration date of a
credit card might belong to the Purchase Information
category. |
|
ymd.month |
- |
Month |
||
ymd.day |
- |
Day |
||
hms.hour |
- |
Hour |
||
hms.minute |
- |
Minute |
||
hms.second |
- |
Second |
||
fractionsecond |
- |
Fraction of Second |
||
timezone |
- |
Time Zone |
||
prefix |
Demographic and Socioeconomic Data |
- |
Name Prefix |
|
given |
Physical Contact Information |
- |
Given Name (First Name) |
|
family |
Physical Contact Information |
- |
Family Name (Last Name) |
|
middle |
Physical Contact Information |
- |
Middle Name |
|
suffix |
Demographic and Socioeconomic Data |
- |
Name Suffix |
|
nickname |
Demographic and Socioeconomic Data |
- |
Nickname |
|
id |
Unique Identifiers |
- |
Login ID |
The "id" element represents the ID portion of the login information for a computer system. Often, user IDs are made public, while passwords are kept secret. IDs do not include any type of biometric authentication mechanisms.
|
password |
Unique Identifiers |
- |
Login Password |
The "password" element represents the password portion of the login information for a computer system. This is a secret data value, usually a character string, that is used in authenticating a user. Passwords are typically kept secret, and are generally considered to be sensitive information |
key |
Unique Identifiers |
- |
Certificate Key |
|
format |
Unique Identifiers |
- |
Certificate Format |
The "format" element 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. |
postal |
Physical Contact Information, Demographic and Socioeconomic Data |
name, street, city, stateprov, postalcode, organization, country |
Postal Address Information |
The following 3 elements and their children refer to contact information. Services can specify precisely which set of data they need, postal, telecommunication, or online address information. The postal element and its children refer to a postal mailing address. |
telecom |
Physical Contact Information |
telephone, fax, mobile, pager |
Telecommunications Information |
The telecom element and its children refer to the characteristics of telephone, fax, mobile and pager numbers. |
online |
Online Contact Information |
email,uri |
Online Address Information |
The online element and its children refer to online information about a person or legal entity. |
intcode |
Physical Contact Information |
- |
International Telephone Code |
|
loccode |
Physical Contact Information |
- |
Local Telephone Area Code |
|
number |
Physical Contact Information |
- |
Telephone Number |
|
ext |
Physical Contact Information |
- |
Telephone Extension |
|
comment |
Physical Contact Information |
- |
Telephone Optional Comments |
|
street |
Physical Contact Information |
- |
Street Address |
|
city |
Demographic and Socioeconomic Data |
- |
City |
|
stateprov |
Demographic and Socioeconomic Data |
- |
State or Province |
|
postalcode |
Demographic and Socioeconomic Data |
- |
Postal Code |
|
country |
Demographic and Socioeconomic Data |
- |
Country Name |
The "country" element represents the information of the name of the country (for example, one among the countries listed in [ISO3166]). |
organization |
Demographic and Socioeconomic Data |
- |
Organization Name |
|
telephone |
Physical Contact Information |
intcode, loccode, number, ext, comment |
Telephone Number |
|
fax |
Physical Contact Information |
intcode, loccode, number, ext, comment |
Fax Number |
|
mobile |
Physical Contact Information |
intcode, loccode, number, ext, comment |
Mobile Telephone Number |
|
pager |
Physical Contact Information |
intcode, loccode, number, ext, comment |
Pager Number |
|
Online Contact Information |
- |
Email Address |
||
uri |
Online Contact Information |
- |
Home Page Address |
The uri element and its children refer to Universal Resource Identifiers (URI), which are defined in [URI]. Since URI information can be used in different ways, depending on the context, all the child elements of the uri element are tagged as being of variable category. Schema definitions MUST explicitly set the corresponding category in the element referencing this data structure. |
authority |
- |
URI Authority |
||
stem |
- |
URI Stem |
||
querystring |
- |
Query-string Portion of URI |
||
authority |
- |
URI Authority |
The authority of a URI is defined as the authority component in [URI]. The stem of a URI is defined as the information contained in the portion of the URI after the authority and up to (and including) the first '?' character in the URI, and the querystring is the information contained in the portion of the URI after the first '?' character. For URIs which do not contain a '?' character, the stem is the entire URI, and the querystring is empty. |
|
stem |
- |
URI Stem |
||
querystring |
- |
Query-string Portion of URI |
||
hostname |
Computer Information |
- |
Complete Host and Domain Name |
The hostname element is used to represent
collection of either the simple hostname of a system, or the full
hostname including domain name. The partialhostname
element represents the information of a fully-qualified hostname
which has had at least the host portion removed from the
hostname. In other words, everything up to the first '.' in the
fully-qualified hostname MUST be removed for an address to quality as
a "partial hostname". |
partialhostname |
Demographic |
- |
Partial Hostname |
|
fullip |
Computer Information |
- |
Full IP Address |
The 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. |
partialip |
Demographic |
- |
Partial IP Address |
|
uri |
Navigation and click-stream data |
authority, stem, querystring |
URI of Requested Resource |
|
timestamp |
Navigation and click-stream data |
ymd.year, ymd.month, ymd.day, hms.hour, hms.minute, hms.second, fractionsecond, timezone |
Request Timestamp |
The time at which the server processes the request is represented by the timestamp field. Server implementations are free to define this field as the time the request was received, the time that the server began sending the response, the time that sending the response was complete, or some other convenient representation of the time the request was processed. |
clientip |
Computer Information, Demographic and Socioeconomic Data |
hostname, partialhostname, fullip, partialip |
Client's IP Address or Hostname |
The clientip element and its children refer to IP addresses and Domain Name System (DNS) hostnames. |
other.httpmethod |
Navigation and click-stream data |
- |
HTTP Request Method |
The HTTP method (such as GET, POST, etc)
in the client's request |
other.bytes |
Navigation and click-stream data |
- |
Number of Data Bytes in Response |
The number of bytes in the response-body sent by the server |
other.statuscode |
Navigation and click-stream data |
- |
Response Status Code |
The HTTP status code on the request, such as 200,
302, or 404 (see section 6.1.1 of [HTTP1.1 ] for details). |
referer |
Navigation and click-stream data |
authority, stem, querystring |
Last URI Requested by the User |
The referer element represents the information in the HTTP Referer header, which gives information about the previous page visited by the user. Note that this field is misspelled in exactly the same way as the corresponding HTTP header |
useragent |
Computer Information |
- |
User Agent Information |
The useragent field represents the information in the HTTP User-Agent header (which gives information about the type and version of the user's Web browser), and/or the HTTP accept* headers. |
P3P offers Web sites a lot of flexibility in how they describe the types of data they collect.
<dynamic><miscdata/></dynamic>
element and the appropriate categories.Any of these three methods may be combined within a single policy.
By using the
<dynamic><miscdata/></dynamic>
element, sites can specify the types of data they collect without
having to enumerate every individual data element. This may be
convenient for sites that collect a lot of data or sites belonging
to large organizations that want to offer a single P3P policy
covering the entire organization. However, the disadvantage of this
approach is that user agents will have to assume that the site might
collect any data element belonging to the categories referenced by
the site. So, for example, if a site's policy states that it
collects
<dynamic><miscdata/></dynamic>
of the
physical contact information category, but the only physical contact
information it collects is business address, user agents will
nonetheless assume that the site might also collect telephone
numbers. If the site wishes to be clear that it does not collect
telephone numbers or any other physical contact information other
than business address, than it should disclose that it collects
<user><business-info><contact><postal/>
</contact></business-info></user>
.
Furthermore, as user agents are developed with automatic
form-filling capabilities, it is likely that sites that enumerate
the data they collect will be able to better integrate with these
tools.
By defining new data schemas, sites can precisely specify the data they collect beyond the base data set. However, if user agents are unfamiliar with the elements defined in these schemas, they will be able to provide only minimal information to the user about these new elements. The information they provide will be based on the category and display names specified for each element.
Regardless of whether a site wishes to make general or
specific data disclosures, there are additional advantages to
disclosing specific elements from the
<dynamic/>
data set. For example, by
disclosing
<dynamic><cookies/></dynamic>
a
site can indicate that it uses cookies and explain the purpose
of this use. User agent implementations that offer users cookie
control interfaces based on this information are encouraged.
Likewise, user agents that by default do not send the
HTTP_REFERER header, might look for the
<dynamic><http><referrer/></http></dynamic>
element in P3P policies and send the header if it will be used
for a purpose the user finds acceptable.
Backward compatibility with P3P 1.0 is addressed as follows:
P3P 1.1 policies must include data elements in both P3P 1.0 and P3P1.1 (extension) data element syntax. It is anticipated that most policy authors will use a P3P1.1 policy editor which will output the correct formats automatically, however in the case that the policy is being written without a GUI, this can be easily achieved by writing policies using P3P1.1 data elements and publishing the P3P1.1 Data Element backward compatibility transform of the policy. The corresponding XSLT-Sheets are reproduced in the Annex 4
For Example, write the DATA-GROUP element as:
<DATA-GROUP base="http://www.w3.org/2005/09/p3p-converter.html?uri=http:%2F%2Fwww.example.com%2Fcustomdataschema.xsd"> <EXTENSION> <datatype xmlns="http://www.example.com/customdataschema.xsd"> <dynamic> <clickstream> <CATEGORY>preference</CATEGORY> </clickstream> </dynamic> </datatype> </EXTENSION> </DATA-GROUP>
and transform it to compliant format using the P3P1.1 Data Element backward compatibility transform to the following:
<DATA-GROUP base="http://www.w3.org/2005/09/p3p-converter.html?uri=http:%2F%2Fwww.example.com%2Fcustomdataschema.xsd"> <EXTENSION> <datatype xmlns="http://www.example.com/customdataschema.xsd"> <dynamic> <clickstream> <categories>preference</categories> </clickstream> </dynamic> </datatype> </EXTENSION> <DATA ref="#dynamic.clickstream"> <categories> <preference/> </categories> </DATA> </DATA-GROUP>
Web sites using custom data schemas MUST publish these schemas in P3P1.1 format only.
User agents are only required to validate P3P1.1 policy data elements elements according to a P3P1.1 data schema. User agents may optionally continue to parse and perform validation according to P3P 1.0 format custom data schemas This can also be acheived in an implementation independent way using a set of xslt transforms provided to transform both policy elements and custom schemas to the P3P1.1 format.
Web sites using custom data schemas MUST publish these schemas in P3P1.1 format only.
User agents are only required to validate P3P1.1 policy data elements according to a P3P1.1 data schema. User agents may optionally continue to parse and perform validation according to P3P 1.0 format custom data schemas
This can also be acheived in an implementation independent way using policytransformP3PDataElements.xsl and removeDuplicatePolicyDataElements.xsl xslt transforms provided to transform both policy elements and custom schemas to the P3P1.1 format.
A typical process of producing a policy with custom data elements may be summarized as follows (note that usually this would be taken care of by a policy editor).
For custom schemas:
<DATA-GROUP> <EXTENSION> <datatype xmlns="http://www.example.com/customdataschema.xsd"> <classicalmusicpreference> <baroquemusicpreference/> </classicalmusicpreference> </datatype> </EXTENSION> </DATA-GROUP>
Publish Backward compatibility transform of policy referencing P3P1.1 custom data schema. E.g.
<DATA-GROUP> <EXTENSION> <datatype xmlns="http://www.example.com/customdataschema.xsd"> <classicalmusicpreference> <baroquemusicpreference/> </classicalmusicpreference> </datatype> </EXTENSION> <DATA ref="#classicalmusicpreference.baroquemusicpreference"> <CATEGORIES> <preference/> </CATEGORIES> </DATA> </DATA-GROUP>
Data elements can also be written in P3P1.0 format and transformed to the P3P1.1 format using P3P1.1 Data Element forward transform
XML does not define a formal semantics except when used within RDF. The use of XSD to define classes of data types however necessarily implies a correspondence between XML elements and real-world classes of data, which is therefore a form of semantics. We have chosen not to use a language with formal semantics because of the sparse support for such languages as RDF and OWL in commercial browser implementations.
This section specifies guidelines for P3P 1.1 user agents. Some of these guidelines serve to reinforce requirements that appear elsewhere in this specification, providing specific guidance for user agent implementers. Other guidelines introduce new requirements for full compliance with this specifcation or provide suggestions for implementers. All of these guidelines are designed to promote consistency among user agent implementations and to assist implementers in designing user agents that will be both usable and useful. By using consistent language to describe web site privacy practices, user agent implementers can help ensure that their implementations represent web site privacy practices accurately. In addition, consistent implementations serve to reduce the uncertainty web site operators have about how their policies will be displayed by P3P user agents.
P3P user agents may display human-readable translations of P3P policies. Because of the large number of fields in a P3P policy, in some case, user agent implementers may wish to develop human-readable translations that do not include all P3P policy elements. The following guidelines are designed to reduce the chance that abridged translations may mislead users.
Section 3 includes normative definitions for all P3P vocabulary elements. However, many of these definitions are rather verbose and use language that is unsuitable for display to end users. Therefore, the P3P 1.1 Working Group has developed a set of "plain language" translations for most of the P3P vocabulary elements. These translations are designed to convey the essence of each element in relatively simple language, without conflicting with the normative definition. A "plain English" version is presented here, translations to other languages will be posted on the W3C Web-site when they become available. P3P user agents SHOULD display P3P policy information to users using the plain English wording shown here or an equivalent translation.
| P3P Element | Attribute | Plain Language Translation |
|---|---|---|
| POLICY | discuri (attribute of POLICY element) | Read our full privacy policy at [with link to discuri] |
| POLICY | opturi (attribute of POLICY element) | Find out how to opt-in or opt-out at [with link to opturi] |
| ENTITY | This policy is issued by: [display all entity information provided by site] | |
| ACCESS | Your access to information about you: | |
| ACCESS | nonident | We do not keep any information identified with you |
| ACCESS | all | We give you access to all of our information identified with you |
| ACCESS | contact-and-other | We give you access to your contact information and some of our other information identified with you |
| ACCESS | ident-contact | We give you access to only your contact information in our records |
| ACCESS | other-ident | We allow you to access some of our information identified with you, but not your contact information |
| ACCESS | none | We do not give you access to our information about you |
| DISPUTES | Ways to resolve privacy-related disputes with us include: | |
| DISPUTES | service | [display long description and short description, if provided, with hyperlink to service URI, otherwise display "customer service" with hyperlink to service URI] |
| DISPUTES | independent | [display long description and short description, if provided, with hyperlink to service URI, otherwise display "independent organization" with hyperlink to service URI] |
| DISPUTES | court | We believe that the following authority offers recourse for disputes: [display long description and short description, if provided, with hyperlink to service URI, otherwise display "possible legal complaint" with hyperlink to service URI] |
| DISPUTES | law | We believe that the following laws or regulations provide recourse: [display long description and short description, if provided, with hyperlink to service URI, otherwise display "law" with hyperlink to service URI] |
| REMEDIES | [no heading - display this following corresponding disputes element] | |
| DISPUTES | correct | We will correct any errors we make related to the commitments in our privacy policy |
| DISPUTES | money | We will compensate individuals if it is determined that we have violated our privacy policy |
| DISPUTES | law | Our privacy policy references a law that may determine remedies for breaches of our policy |
| NON-IDENTIFIABLE | We do not keep any information that could be used to identify you personally | |
| PURPOSE | The ways your information may be used: | |
| PURPOSE | current | To provide the service you requested |
| PURPOSE | admin | To perform web site and system administration |
| PURPOSE | develop | For research and development, but without connecting any information to you |
| PURPOSE | tailoring | To customize the site for your current visit only |
| PURPOSE | pseudo-analysis | To do research and analysis in which your information may be linked to an ID code but not to your personal identity |
| PURPOSE | pseudo-decision | To make decisions that directly affect you without identifying you, for example to display content or ads based on links you clicked on previously |
| PURPOSE | individual-analysis | To do research and analysis that uses information about you |
| PURPOSE | individual-decision | To make decisions that directly affect you using information about you, for example to recommend products or services based on your previous purchases |
| PURPOSE | contact | To contact you through means other than telephone (for example, email or postal mail) to market services or products |
| PURPOSE | historical | To aid in historical preservation as governed by a law or policy described in this privacy policy |
| PURPOSE | telemarketing | To contact you by telephone to market services or products |
| PURPOSE | other-purpose | For other uses: [include site's human, readable explanation; if site omits human-readable explanation say "not described here"] |
| PURPOSE | required (attribute of purpose and recipients elements) | (attribute, see below) |
| PURPOSE | required always | (no remark) |
| PURPOSE | required opt-in | [append to purpose/recipient] -- only if you request this |
| PURPOSE | required opt-out | [append to purpose/recipient] -- unless you opt-out |
| RECIPIENT | With whom we may share your information | |
| RECIPIENT | ours | Companies that help us fulfill your requests (for example, shipping a product to you), but these companies must not use your information for any other purpose |
| RECIPIENT | delivery | Delivery companies that help us fulfill your requests and who may also use your information in other ways |
| RECIPIENT | same | Companies that have privacy policies similar to ours |
| RECIPIENT | other-recipient | Companies that are accountable to us, though their privacy policies may be different from ours |
| RECIPIENT | unrelated | Other companies whose privacy policies are unknown to us |
| RECIPIENT | public | People who may access your information from a public area, such as a bulletin board, chat room, or directory |
| RECIPIENT | required (attribute of purpose and recipients elements) | (attribute, see below) |
| RECIPIENT | required always | (no remark) |
| RECIPIENT | required opt-in | [append to purpose/recipient] -- only if you request this |
| RECIPIENT | required opt-out | [append to purpose/recipient] -- unless you opt-out |
| RETENTION | How long we may keep your information | |
| RETENTION | no-retention | We do not keep your information beyond your current online session |
| RETENTION | stated-purpose | We keep your information only long enough to perform the activity for which we collected it |
| RETENTION | legal-requirement | We keep your information only as long as we need to for legal purposes |
| RETENTION | business-practices | Our full privacy policy explains how long we keep your information |
| RETENTION | indefinitely | We may keep your information indefinitely |
| CATEGORIES | We may collect the following types of information about you | |
| CATEGORIES | physical | Name, address, phone number, or other physical contact information |
| CATEGORIES | online | Email address or other online contact information |
| CATEGORIES | uniqueid | Website login IDs and other identifiers (excluding government IDs and financial account numbers) |
| CATEGORIES | purchase | Information about your purchases, including payment methods |
| CATEGORIES | financial | Financial information such as accounts, balances, and transaction history |
| CATEGORIES | computer | Information about the computer you are using, such as its hardware, software, or Internet address |
| CATEGORIES | navigation | Which pages you visited on this web site and how long you stayed at each page |
| CATEGORIES | interactive | Activities you engaged in at this web site, such as your searches and transactions |
| CATEGORIES | demographic | Information about social and economic categories that might apply to you, such as your gender, age, income, or where you are from |
| CATEGORIES | content | Messages you send to us or post on this site, such as email, bulletin board postings, or chat room conversations |
| CATEGORIES | state | Cookies and mechanisms that perform similar functions |
| CATEGORIES | political | Which groups you might be a member of such as religious organizations, trade unions, and political parties |
| CATEGORIES | health | Health information such as information about your medical condition or your interest in health-related topics, services, or products |
| CATEGORIES | preference | Information about your tastes or interests |
| CATEGORIES | location | Information about an exact geographic location, such as data transmitted by your GPS-enabled device |
| CATEGORIES | government | Government-issued identifiers such as social security numbers |
| CATEGORIES | other-category | Other types of data: [include site's human, readable explanation; if site omits human-readable explanation say "not described here"] |
| CATEGORIES | optional (attribute of data elements) |
|
P3P user agents SHOULD include mechanisms that allow users to store P3P policies and their corresponding translations easily to make them available for later viewing or printing.
P3P user agents MUST NOT rely on P3P compact policies that do not comply with the P3P 1.0 or P3P 1.1 specifications or are obviously erroneous. Such compact policies SHOULD be deemed invalid and the corresponding cookies should be treated as if they had no compact policies. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid compact policy.
Although the P3P 1.1. specification does not hold user agents responsible for verifying that web site P3P policies are accurate, it is a good idea for user agents to do some sanity checking to flag P3P policies that are obviously erroneous. Such policies should be deemed invalid. The following guidelines are designed to reduce the chance that a P3P user agent will accept an invalid policy. (See also section 2.4.4 Policy and Policy Reference File Processing by User Agents.)
STATEMENT
that includes the
individual-analysis element and does not include at least one data
element from one of the following data categories: physical, online,
financial, purchase, government. (RATIONALE: This purpose requires
"identified data". While it is possible to have other categories
associated with an identified subject, the actual identification is
impossible without a data element associated with one or more of the
above categories.)STATEMENT
that includes the
individual-decision element and does not include at least one data
element from one of the following data categories: physical, online,
financial, purchase, government. (RATIONAEL: This purpose requires
"identified data". While it is possible to have other categories
associated with an identified subject, the actual identification is
impossible without a data element associated with one or more of the
above categories.)STATEMENT
that includes the
contact element and does not include at least one data element from one
of the following data categories: physical, online. (RATIONALE: Logic
dictates that to contact an individual the initiator of the contact would
possess a data element identifying the individual in a place where he or
she would be contacted - either the online or offline worlds. This would
presuppose elements contained by one of the above categories.)STATEMENT
that includes the
telemarketing element and does not include at least one data element from
the physical category. (Rationale: Again logic dictates that if
you are going to contact someone via telephone, you at least have a data
element that contains phone numbers. These data elements should all be
within the Physical category.)As a best practice, users should receive notice about a site's privacy practices prior to their user agent transmitting any personal data. Personal data means anything which might reasonably be linked to the user (see section 1.3 Identity Definitions) and as such can even include IP addresses and locale data transmitted in http headers before a page has even loaded. In order to present such notice, a user agent would need to fetch a P3P policy prior to loading a page following the guidelines specified in section 2.4.3 The Safe Zone. However, implementers will need to consider the performance, usability, and privacy tradeoffs associated with displaying privacy information prior to loading a page. One way that privacy and usability might be simultaneously maximized is to treat all requests made prior to display of policy information as safe zone requests.
At sites that include form fields, user agents SHOULD provide notice about the corresponding privacy practices prior to form submittal. Besides being best practice, this may be needed in order to comply with regulations in some jurisdictions (such as the European Union) that require a notice about the purpose of data collection to be presented to the user before any personal information is captured. User interface designs should recognize that the privacy policy for the form's action [URI] may be different than the privacy policy for the HTML page in which the form is embedded. In order to allow users to view privacy policy information associated with action URIs prior to form submittal, user agents might include a privacy tab that loads policy information for action URIs as a page loads, a button or menu item that causes policy information for action URIs to be displayed, or a pop-up that appears when a user begins entering information into a form field.
Persistent Client State -- HTTP Cookies, RFC2965, IETF, October 2000
Agents and P3PP3P Position Paper: W3C Workshop on the Future of P3P November 12-13, 2002
Web Privacy with P3Pby Lorrie Faith Cranor, O'Reilly & Associates, 2002
The data schema corresponding to the P3P 1.1 base data schema follows for easy reference. The schema below is using XML Schema to express the P3P Base Data Schema. It includes syntax and semantics of the old P3P 1.0 Base Data Schema. Using the Transforms for backwards compatibility below, it can be also used by P3P 1.0 user agents.  Backward Compatibility Requirements, the Policy transform serves to transform policies or custom schemata from either the new P3P 1.1 format or the old P3P 1.0 format into a backwards compatible format containing both versions. This can be done using the XSLT-Sheets below or just using the W3C P3P Transformation Service
This way, users can either use the well known P3P Editors or use widely available XML-tools to produce P3P Dataschemas. Once the P3P Data Schema (which is now pure XML Schema) is produced, it can be transformed using the transforms mentioned and annexed below.
This XSLT stylesheet transforms P3P 1.1 datatype
elements into a combined code of datatype
elements
and P3P 1.0 DATA
elements for backwards compatibility.
See 5.7. Backward Compatibility
Requirements for more information
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/2002/01/P3Pv1" exclude-result-prefixes="xsl"> <!-- **************************************************************************************************** Note that if the input policy contains a mixture of P3P1.0 and P3P1.1 elements or you have already run the transform once on your policy, then you should run the removeduplicates xslt (following in the specification). **************************************************************************************************** --> <!-- Simple identity function to output the rest of the policy--> <xsl:template match="@*|*|processing-instruction()|comment()" priority="-2"> <xsl:copy> <xsl:apply-templates select="*|@*|text()" /> </xsl:copy> </xsl:template> <!-- **************************************************************************************************** Transform new data elements to old data elements and add the transformations alongside Works by getting the leaves and then going back up to the top (as there can be multiple leaves now. **************************************************************************************************** --> <xsl:template match="//*[local-name()='EXTENSION'][count(child::*[local-name()='datatype'])!=0]"> <xsl:for-each select=".//*[count(child::*[local-name()!='CATEGORIES'])=0 and count(ancestor::*[local-name()='CATEGORIES'])=0]"> <xsl:element name="DATA"> <xsl:attribute name="ref"> <xsl:variable name="tempStr"> <xsl:call-template name="StrConcat"> <xsl:with-param name="dot"> . </xsl:with-param> </xsl:call-template> </xsl:variable> <xsl:value-of select="concat('#',substring-after($tempStr,'.'))"/> </xsl:attribute> <xsl:if test="count(.//*[local-name()='CATEGORIES'])!=0"> <xsl:copy-of select=".//*[local-name()='CATEGORIES']"/> </xsl:if> <xsl:value-of select="."/> </xsl:element> </xsl:for-each> <xsl:copy-of select="."/> </xsl:template> <!-- **************************************************************************************************** Transform old data elements and add the transformations alongside **************************************************************************************************** --> <xsl:template match="//*[local-name()='DATA']" > <xsl:element name="EXTENSION"> <xsl:element name="datatype"> <xsl:if test="@*[local-name()='optional']"> <xsl:copy-of select="@*[local-name()='optional']"/> </xsl:if> <xsl:variable name="refAttribute" select="@*[local-name()='ref']"/> <xsl:call-template name="StrSplit"> <xsl:with-param name="str" select="substring-after($refAttribute,'#')"/> </xsl:call-template> </xsl:element> </xsl:element> <xsl:copy-of select="."/> </xsl:template> <!-- ***************************************************************************************************************** reconsitute the ref attributes - for backward (P3P1.1 -> P3P1.0) transform **************************************************************************************************************** --> <xsl:template name="StrConcat"> <xsl:param name="dot" select="/.."/> <xsl:if test="local-name()!='datatype'"> <xsl:for-each select="parent::*"> <xsl:call-template name="StrConcat"> <xsl:with-param name="dot"> . </xsl:with-param> </xsl:call-template> </xsl:for-each> <xsl:value-of select="$dot"/> <!-- Change the business.name attribute if there is one --> <xsl:choose> <xsl:when test="local-name()='orgname'"> name </xsl:when> <xsl:otherwise> <xsl:value-of select="local-name()"/> </xsl:otherwise> </xsl:choose> </xsl:if> </xsl:template> <!-- **************************************************************************************************** String Split for forward (P3P1.0 -> P3P1.1) transform **************************************************************************************************** --> <xsl:template name="StrSplit"> <xsl:param name="str" select="/.."/> <xsl:param name="parent" select="/.."/> <xsl:choose> <xsl:when test="contains($str,'.') and substring-before($str,'.')!='ymd' and substring-before($str,'.')!='hms'"> <xsl:element name="{substring-before($str,'.')}"> <xsl:call-template name="StrSplit"> <xsl:with-param name="str" select="substring-after($str,'.')" /> <xsl:with-param name="parent" select="$str" /> </xsl:call-template> </xsl:element> </xsl:when> <!-- Change the business name to Orgname so it doesn't expect children like firstname, prefix etc... --> <xsl:when test="$parent='business.name'"> <xsl:element name="orgname"> <xsl:for-each select="./*[local-name()='CATEGORIES']"> <xsl:copy-of select="."/> </xsl:for-each> <xsl:copy-of select="./text()"/> </xsl:element> </xsl:when> <xsl:otherwise> <xsl:element name="{$str}"> <xsl:for-each select="./*[local-name()='CATEGORIES']"> <xsl:copy-of select="."/> </xsl:for-each> <xsl:copy-of select="./text()"/> </xsl:element> </xsl:otherwise> </xsl:choose> </xsl:template> </xsl:stylesheet>
This XSLT stylesheet removes duplicate elements that have been generated by applying the Policy-transform multiple times. See 5.7. Backward Compatibility Requirements for more information
<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" exclude-result-prefixes="xsl" > <xsl:output method="xml" media-type="application/xml" /> <!-- Simple identity function to output the rest of the policy--> <xsl:template match="@*|*|processing-instruction()|comment()" priority="-2" > <xsl:copy> <xsl:apply-templates select="*|@*|text()|processing-instruction()|comment()" /> </xsl:copy> </xsl:template> <!-- remove duplicate EXTENSION elements --> <xsl:template match="//*[local-name()='DATA-GROUP']/*[local-name()='EXTENSION']"> <xsl:variable name="duplicates"> <xsl:call-template name="detectDuplicateSiblings"> <xsl:with-param name="node" select="."/> </xsl:call-template> </xsl:variable> <xsl:if test="$duplicates!='true'"> <xsl:copy-of select="."/> </xsl:if> </xsl:template> <xsl:template name="detectDuplicateSiblings"> <xsl:param name="node" select="/.."/> <xsl:variable name="A" select="$node/descendant::*[(not(text()) or not(normalize-space(string(.))='')) and count(child::*)=0]"/> <xsl:variable name="extensionLeaves" select="following-sibling::*[local-name()='EXTENSION']/descendant::*[(not(text()) or not(normalize-space(string(.))='')) and count(child::*)=0]"/> <xsl:variable name="isTrue"> <xsl:call-template name="loopExtensions"> <xsl:with-param name="count" select="0"/> <xsl:with-param name="contextNodeToTest" select="$A"/> <xsl:with-param name="nodeList" select="$extensionLeaves"/> </xsl:call-template> </xsl:variable> <xsl:value-of select="$isTrue"/> </xsl:template> <xsl:template name="loopExtensions"> <xsl:param name="count" select="/.."/> <xsl:param name="nodeList" select="/.."/> <xsl:param name="contextNodeToTest" select="/.."/> <xsl:variable name="isEqualDeep"> <xsl:call-template name="recurseComparison"> <xsl:with-param name="A" select="$contextNodeToTest"/> <xsl:with-param name="B" select="$nodeList[$count]"/> <xsl:with-param name="level" select="0"/> </xsl:call-template> </xsl:variable> <xsl:choose> <xsl:when test="$isEqualDeep='true'"> true </xsl:when> <xsl:otherwise> <xsl:if test="$count<count($nodeList)"> <xsl:call-template name="loopExtensions"> <xsl:with-param name="count" select="$count + 1"/> <xsl:with-param name="nodeList" select="$nodeList"/> <xsl:with-param name="contextNodeToTest" select="$contextNodeToTest"/> </xsl:call-template> </xsl:if> </xsl:otherwise> </xsl:choose> </xsl:template> <xsl:template name="recurseComparison"> <xsl:param name="A" select="/.."/> <xsl:param name="B" select="/.."/> <xsl:param name="level" select="/.."/> <xsl:variable name="isEqual"> <xsl:if test="local-name($A)=local-name($B)"> true </xsl:if> </xsl:variable> <xsl:choose> <xsl:when test="$isEqual='true'"> <xsl:choose> <xsl:when test="local-name($A/parent::*)!='datatype' and local-name($B/parent::*)!='datatype' and count($A/parent::*)!=0 "> <xsl:call-template name="recurseComparison"> <xsl:with-param name="A" select="$A/parent::*"/> <xsl:with-param name="B" select="$B/parent::*"/> <xsl:with-param name="level" select="$level+1"/> </xsl:call-template> </xsl:when> <xsl:otherwise> true </xsl:otherwise> </xsl:choose> </xsl:when> <xsl:otherwise> false </xsl:otherwise> </xsl:choose> </xsl:template> <!-- remove duplicate DATA elements --> <xsl:template match="//*[local-name()='DATA']"> <xsl:variable name="ref" select="@*[local-name()='ref']"/> <xsl:if test="not($ref=following-sibling::*[local-name()='DATA']/@*[local-name()='ref'])"> <xsl:copy-of select="."/> </xsl:if> </xsl:template> </xsl:stylesheet>
This appendix contains the XML schema for P3P 1.1 policy reference files, for P3P 1.1 policy documents, and for P3P 1.1 data schema documents. P3P 1.1 policy reference files, P3P policy documents and P3P data schema documents are XML documents that MUST conform to this schema. Note that this schema is based on the XML Schema specification [XML-Schema1][XML-Schema2]. The schema is also present as a separate file at http://www.w3.org/2006/01/P3Pv11.xsd.
The P3P 1.1 XML Schema imports all elements from the P3P 1.0 Schema. The P3P 1.0 XML Schema is not presented here, but can be found in the P3P 1.0 Specification or under it's namespace URI, notably http://www.w3.org/2002/01/P3Pv1.xsd.
<?xml version="1.0" encoding="UTF-8"?> <schema elementFormDefault="qualified" targetNamespace="http://www.w3.org/2006/01/P3Pv11" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:p3p="http://www.w3.org/2002/01/P3Pv1" xmlns:p3p11="http://www.w3.org/2006/01/P3Pv11" xmlns:p3p11bds="http://www.w3.org/2006/01/P3Pv11BDS"> <!-- enabling xml:lang attribute --> <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/> <import namespace="http://www.w3.org/2002/01/P3Pv1" schemaLocation="http://www.w3.org/2002/01/P3Pv1"/> <import namespace="http://www.w3.org/2006/01/P3Pv11BDS" schemaLocation="http://www.w3.org/2006/01/P3Pv11BDS.xsd" /> <!-- *********** P3P 1.1 Elements ************ --> <!-- p3p attribute --> <attribute name="p3p" type="anyURI"> <annotation> <documentation> <div xmlns="http://www.w3.org/1999/xhtml"> <p>The P3P-generic attribute takes a URI as its value.</p> <p>The meaning is that a P3P document describing the privacy policy relevant to this element may be found at the URI given.</p> </div> </documentation> </annotation> </attribute> <simpleType name="consent_value"> <restriction base="string"> <enumeration value="opt-in"/> <enumeration value="opt-out"/> <enumeration value="always"/> <enumeration value="mixed"/> </restriction> </simpleType> <element name="STATEMENT-GROUP-DEF"> <complexType> <attribute name="id" type="ID" use="required"/> <attribute name="consent" type="p3p11:consent_value" use="optional"/> <attribute name="name" type="string" use="optional"/> <attribute name="short-description" type="string" use="optional"/> </complexType> </element> <element name="STATEMENT-GROUP"> <complexType> <attribute name="id" type="IDREF" use="required"/> </complexType> </element> <!--  ************ JURISDICTION ************ --> <element name="JURISDICTION"> <complexType> <simpleContent> <extension base="string"> <attribute name="service" type="anyURI" use="required"/> <attribute name="short-description" type="string" use="optional"/> </extension> </simpleContent> </complexType> </element> <!-- ********* P3P 1.1 Data-Group Element below Entity --> <!-- <element name="datatype" type="p3p11:datatypeComplexType" /> --> <complexType name="datatypeComplexType"> <all> <element minOccurs="0" name="dynamic" type="p3p11bds:dynamicComplexType" /> <element minOccurs="0" name="user" type="p3p11bds:userComplexType" /> <element minOccurs="0" name="thirdparty" type="p3p11bds:thirdpartyComplexType" /> <element minOccurs="0" name="business" type="p3p11bds:businessComplexType" /> </all> <attribute type="p3p:yes_no" default="no" use="optional" name="optional" /> </complexType> <element name='DATA-GROUP'> <complexType> <sequence> <any processContents="lax"/> <!-- ******* Definition of 1.1 datatype ************** --> <element minOccurs="0" name="datatype" type="p3p11:datatypeComplexType" /> </sequence> </complexType> </element> <element name="our-host" type="our-host-type" /> <complexType name="our-host-type"> <attribute name='name' type='string' use='optional'/> <attribute name="authority" type="string" use="optional" /> </complexType> </schema>
The formal grammar of P3P is given in this specification using a slight modification of [ABNF]. The following is a simple description of the ABNF.
name = (elements)
(
element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string"
or
'string'
Other notations used in the productions are:
/* ... */
This appendix describes the intent of P3P development and recommends guidelines regarding the responsible use of P3P technology. An earlier version was published in the W3C Note "P3P Guiding Principles" (http://www.w3.org/TR/NOTE-P3P10-principles).
The Platform for Privacy Preferences Project (P3P) has been designed to be flexible and support a diverse set of user preferences, public policies, service provider polices, and applications. This flexibility will provide opportunities for using P3P in a wide variety of innovative ways that its designers had not imagined. The P3P Guiding Principles were created in order to: express the intentions of the members of the P3P Working Groups when designing this technology and suggest how P3P can be used most effectively in order to maximize privacy and user confidence and trust on the Web. In keeping with our goal of flexibility, this document does not place requirements upon any party. Rather, it makes recommendations about 1) what should be done to be consistent with the intentions of the P3P designers and 2) how to maximize user confidence in P3P implementations and Web services. P3P was intended to help protect privacy on the Web. We encourage the organizations, individuals, policy-makers and companies who use P3P to embrace the guiding principles in order to reach this goal.
P3P has been designed to promote privacy and trust on the Web by enabling service providers to disclose their information practices, and enabling individuals to make informed decisions about the collection and use of their personal information. P3P user agents work on behalf of individuals to reach agreements with service providers about the collection and use of personal information. Trust is built upon the mutual understanding that each party will respect the agreement reached.
Service providers should preserve trust and protect privacy by applying relevant laws and principles of data protection and privacy to their information practices. The following is a list of privacy principles and guidelines that helped inform the development of P3P and may be useful to those who use P3P:
In addition, service providers and P3P implementers should recognize and address the special concerns surrounding children's privacy.
Service providers should provide timely and effective notices of their information practices, and user agents should provide effective tools for users to access these notices and make decisions based on them.
Service providers should:
User agents should:
Certain jurisdictions view the storage of cookies on a user's hard drive as an act of data processing. In such jurisdictions (e.g. the EU), policies should always be evaluated before a cookie is set and cookies should not be stored unless the cookie's policy is found to comply with the user's preferences.
Users should be given the ability to make meaningful choices about the collection, use, and disclosure of personal information. Users should retain control over their personal information and decide the conditions under which they will share it.
Service providers should:
User agents should:
Service providers should treat users and their personal information with fairness and integrity. This is essential for protecting privacy and promoting trust.
Service providers should:
User agents should:
While P3P itself does not include security mechanisms, it is intended to be used in conjunction with security tools. Users' personal information should always be protected with reasonable security safeguards in keeping with the sensitivity of the information.
Service providers should:
User agents should:
The P3P 1.1 Specification was produced by the P3P 1.1 Specification Working Group. The following individuals contributed: Lorrie Cranor (Chair), Diana Alonso-Blas (European Commission), Eric Brunner-Williams (Invited Expert), Brooks Dobbs (Doubleclick Inc), Bill Duserick (Fidelity), Jeff Edelen (American Express), Serge Egelman (CMU), Jeremy Epling (Microsoft), Giles Hogben (JRC), Jack Humphrey (Invited Expert), Patrick C. K. Hung (CSIRO), Marc Langheinrich (ETH Zürich), Helena Lind (Ericsson), Matthias Schunter (IBM Zürich), Ari Schwartz (CDT), David Stampley (Invited Expert), Rigo Wenning (W3C)
The P3P 1.0 specification was produced by the P3P Specification Working Group. The following individuals participated in the P3P Specification Working Group, chaired by Lorrie Cranor (AT&T): Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage), Joe Coco (Microsoft), Brooks Dobbs (DoubleClick), Rajeev Dujari (Microsoft), Matthias Enzmann (GMD), Patrick Feng (RPI), Aaron Goldfeder (Microsoft), Dan Jaye (Engage), Marit Hansen (Privacy Commission of Land Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zürich), Daniel Lim (PrivacyBank), Ran Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE), Christine McKenna (Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry (Microsoft), Jules Polonetsky (DoubleClick), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Noboru Shimizu (ENC), Rob Smibert (Jotter Technologies Inc.), Tri Tran (AvenueA), Mark Uhrmacher (DoubleClick), Danny Weitzner (W3C), Michael Wallent (Microsoft), Rigo Wenning (W3C), Betty Whitaker (NCR), Allen Wyke (Engage), Kevin Yen (Netscape), Sam Yen (Citigroup), Alan Zausner (American Express).
The P3P Specification Working Group inherited a large part of the specification from previous P3P Working Groups. The Working Group would like to acknowledge the contributions of the members of these previous groups (affiliations shown are the members' affiliations at the time of their participation in each Working Group).
The P3P Implementation and Deployment Working Group, chaired by Rolf Nelson (W3C) and Marc Langheinrich (NEC/ETH Zurich): Mark Ackerman (University of California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft), Lorrie Cranor (AT&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer (Citibank), Betty Whitaker (NCR).
The P3P Syntax Working Group, chaired by Steve Lucas (Matchlogic): Lorrie Cranor (AT&T), Melissa Dunn (Microsoft), Daniel Jaye (Engage Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM), Drummond Reed (Intermind), Joseph Reagle (W3C).
The P3P Vocabulary Harmonization Working Group, chaired by Joseph Reagle (W3C): Liz Blumenfeld (America Online), Ann Cavoukian (Information and Privacy Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor (AT&T), Jim Crowe (Direct Marketing Association), Josef Dietl (W3C), David Duncan (Information and Privacy Commission/Ontario), Melissa Dunn (Microsoft), Patricica Faley (Direct Marketing Association), Marit Köhntopp (Privacy Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong Privacy Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser (America Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for Democracy and Technology), Nick Platten (Data Protection Consultant, formerly of DG XV, European Commission), Ari Schwartz (Center for Democracy and Technology), Jonathan Stark (TRUSTe).
The P3P Protocols and Data Transport Working Group, chaired by Yves Leroux (Digital): Lorrie Cranor (AT&T), Philip DesAutels (Matchlogic), Melissa Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye (Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers (VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph Reagle (W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds).
The P3P Vocabulary Working Group, chaired by Lorrie Cranor (AT&T): Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly).
The P3P Architecture Working Group, chaired by Martin Presler-Marshall (IBM): Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).
Finally, Appendix 7 is drawn from the W3C Note "P3P Guiding Principles", whose signatories are: Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.).
<our-host>
element to the
XML SchemaP3P Guiding Principles
Linked Datafrom 1.3.2 as well as the associated Paragraph.
STATEMENT-GROUP-DEF
element
(EXTENSION). Statement attaching system and naming added as 3.3.2 The STATEMENT-GROUP
element
(EXTENSION). This also includes contents a solution to Bug 171STATEMENT-GROUP-DEF
and
STATEMENT-GROUP
into their respective sections as 3.2.3 and
3.3.2