This is a subspecification of the P3P1.0 specification for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and will eventually be advanced toward W3C Recommendation status. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." The underlying concepts of the draft are fairly stable and we encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document.
This draft document will be considered by W3C and its members according to W3C process. This document is made public for the purpose of receiving comments that inform the W3C membership and staff on issues likely to affect the implementation, acceptance, and adoption of P3P.
Send comments to www-p3p-public-comments@w3.org (archived at http://lists.w3.org/Archives/Public/www-p3p-public-comments).
The P3P Specification [P3P] specifies an [XML] / [RDF] application that defines the structure, or grammar, of a P3P proposal. This document, the harmonized vocabulary, describes the terms that fit into the P3P grammar; this process is technically called the "semantic definition of a XML/RDF schema or vocabulary." For example, the P3P specification states that P3P statements must declare the purposes for which data are collected, this document specifies a list of six such purposes and their meaning.
P3P can support multiple schemas. However, P3P is likely to be most effective when a single base vocabulary is widely used since information practice statements are most useful when they can be readily understood by users and their computer agents. Complementary vocabularies may develop to cater to jurisdiction-specific concerns not addressed by the base vocabulary. This can be easily accomplished through the XML-namespace [XML-names] facility, which allows tags from different XML schemas to be intermixed. However, the semantics of this specification always dominate those of an external namespace. For instance, someone can not place an attribute within a proposal that says "and this proposal is void on Tuesdays" and argue this excuses them from the semantics defined in the P3P specification.
Therefore, this document includes a base set of vocabulary elements useful for expressing privacy policies reflective of a diversity of privacy laws, self-regulatory norms, and cultural notions about privacy. This vocabulary can be used to express policies as diverse as anonymous browsing to the provision of personalized Web content and services. However, P3P implementations need not restrict themselves solely to vocabularies defined within this document.
Note, in addition to the terms specified in the harmonized vocabulary, P3P requires services to specify in their proposals the service provider's identity, an experience space to which their practices apply (e.g., realm: http://www.w3.org), the location at which users can find a human-readable explanation of the service's privacy policies (discURI) and an optional human-readable description of the result (e.g., consequence: "to offer customized sports updates").
Security issues and protocols are not addressed by this document. Information about the characteristics and strength of those protocols is critical to a user's decision regarding the transmission of information. However, an assumption of P3P is that communication and storage security is achieved through means other than P3P itself (such as SSL).
Legal issues regarding law enforcement demands for information are not addressed by this document. It is possible that a service provider that otherwise abides by its proposal of not redistributing data to others may be required to do so by force of law.
| Comment: Much of the work done on this schema was conducted under significant time pressure. Accordingly, there is interest from members of the working group to have some of these issues revisited in the future by the W3C or other entities as appropriate. |
This specification is a representation of a rough, inclusive consensus from the Harmonization WG -- meaning that which is specified is recommended as a minimal set of terms. The recommendation and requirements are offset in a colored table. Requirements are expressed over variables which the WG thinks values must be defined for in order to be a valid P3P proposal. Products must support the ability to parse and act upon all the variables defined, though we do not specify the way such values need to be acted upon or presented in a graphical user interface; these are left to implementations and user configuration -- which is addressed in the P3P Implementation Guide.
To simplify practice declaration, service providers may aggregate any of the disclosures (purposes, recipients, and identifiable use) within a statement over data elements. Service providers MUST make such aggregations as an additive operation. For instance, a site that distributes your age to (0: ourselves), but distributes your zip code to (3: the public), MAY say they distribute your {name and zip code} to {0, 3: ourselves and the public}. Such a statement appears to distribute more data than actually happens. It is up to the service provider to determine if their disclosure deserves specificity or brevity.
Also, one must always disclose all options that apply. Consider a site with the sole purpose of collecting information for the purposes of {4: Contacting Visitors for Marketing of Services or Products}. Even though this is considered to be for the {0: Completion and Support of Current Activity}, the site must state {0,4}. Consider a site which distributes information to {0: Ourselves and our agents}in order to redistribute it to {3: Unrelated third parties or public fora}, the site must state {0,3}.
A data category is a quality of a data element or class that may be used by the user's agent to determine what type of element is under discussion.
| Status Optional: Service providers MAY use data categories to describe data elements or data sets. If a service provider requires a representation of data that is not otherwise referenceable in an easily understood way, we recommend the following terms be used according to their corresponding definitions. |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4* | |
| 5* |
|
| 6* |
|
| 7 |
|
| 8 |
|
| 9* |
|
* Note: 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 following specifies and defines a set of six purposes for data processing relevant to the Web.
| Status Required: Service providers MUST use the following terms 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. |
| 0 |
|
| 1 |
|
| 2 |
|
| 3 |
|
| 4 |
|
| 5 |
|
Qualifiers are appended to a purpose to provide additional information on how the purpose is realized with respect to a data element or set of data elements.
| Status Required: Services MUST disclose one of the values of the Identifiable qualifier. |
| Status Required: Services must disclose all the
Recipients that apply.
Comment: Creating a set of values which are simple, informative to the user, and accurate for service provider representations is very challenging and the WG is not completely satisfied with the results. For instance, 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. As it stands, such organizations should be represented in whichever category most accurately reflects their practices with respect to the original service provider. |
| 0 |
|
|
| 1 |
|
|
| 2 |
|
|
| 3 |
|
The following are general disclosures about the policies of the service provider. Further information on the policies would be found at the discURI.
| Status Required: Service providers must disclose all
Access capabilities that apply. The methods of access is
not specified. This disclosure applies to the identifiable use disclosure.
Any disclosure is not meant to imply that access to all data is possible,
but that some of the data may be accessible and that the user should communicate
further with the service provider to determine what capabilities they have.
Comment: Service providers may also wish to provide capabilities to access to information collected through means other than the Web at the discURI. However, the scope of P3P statements are limited to data collected through HTTP or other Web transport protocols. Also, if access is provided through the Web we recommend the use of strong authentication and security mechanisms for such access, however security issues are outside the scope of this document. |
- 0 Identifiable Data is Not Used
- [this should be consistent with the use of the identifiable qualifier].
- 1 Identifiable Contact Information
- access is given to identifiable online and physical contact information (e.g., users can access things such as a postal address).
- 2 Other Identifiable Information
- access is given to other information linked to an identifiable person. (e.g., users can access things such as a their online account charges).
- 3 None
- no access to identifiable information is given.
| Status Required (but specified elsewhere): A required version
of this disclosure is implemented through the assurance field, defined in
the P3P1.0 specification.
Comment: We expect this field can be used in a number of ways, from representing that one's privacy practices are self assured, audited by a third party, or under the jurisdiction of a regulatory authority. |
| Status Optional: If a site wishes to signify in a proposal that
it makes a disclosure about change_agreement, or retention, it may do so
with the following. No disclosure means that the service provider makes no
representation of a policy on that topic.
Comment: Some members of the working group felt that 1) disclosures could be made about other topics such as security (see the purpose section), 2) more specific values should be provided, and 3) that such disclosures should be required. However, a strong consensus for this could not be reached in the available time. |
_________
Copyright © 1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.