Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
This document, part of the P3P specification, specifies the names of base P3P data elements, sets, and their data types.
This is a subspecification of the P3P 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/).
P3P uses a set of Base Data Elements to provide a common platform for services and user agents to request and exchange information. All P3P-compliant user agent implementations MUST be aware of these data elements. The P3P Base Data set includes two element sets, user. and dynamic.. The user. set includes elements that users might provide values for, while the dynamic. set includes elements that are dynamically generated in the course of a user's browsing session. User agents may support a variety of mechanisms that allow users to provide values for the elements in the user. set, including mechanisms that support multiple personae. Users may choose not to provide values for these data elements.
Data Elements can be classified along two axes: whether or not they are in a fixed category (using the category attribute), and whether or not they are part of the user's repository (using the source attribute.) Schema Designers can use these attributes within their schema definitions to define an invariable category and/or source value for each element. Once defined, these values cannot be changed when referencing such elements from within user preferences, P3P proposals, or other schema definitions.
However, if left undefined, those attributes MUST be explicitly listed in each P3P proposal referencing such elements. Users can have different preferences depending on different attribute-values for the same element. And in the case of undefined attributes within data types, other schema definition can explicitly set categories and/or source information in derived elements (otherwise the original definition overrides any value in the derived schema).
Please refer to the section Creating New Data Sets in the P3P Syntax Specification for more information on the usage of these two attributes.
Finally, remember that, as specified in the syntax spec, when soliciting data via an HTML form the form field names should instead use an underscore ("_") to separate the different levels of the attribute name (e.g. user.name.First must be referenced as User_Name_First). This allows interoperability with client-side javascript which also uses the dot notation to access form field names and values.
The following are the base data elements and sets. The members of this working group expect that in the future, there will be demand for the creation of other data sets and elements. Obvious applications include catalogue, payment, and agent/system attribute schemas. (An extensive set of system elements is provided in a white paper draft (W3C Members only) and are based on http://www.w3.org/TR/NOTE-agent-attributes.)
Each table below specifies a set, the elements within the set, the category associated with the element, its type, and the display name shown to users. More than one category may be associated with a fixed data element. However, we have tried to assign each base data element to only one category whenever possible. We recommend that data schema designers do the same.
Note that variable data elements list a wildcard "*" in the category field, indicating that services must explicitly choose one or more categories for this element should they include it in a proposal. They also feature a different background color.
The user. data set includes general information about the user.
user. | Category | Type | Short display name |
name. | Physical Contact Information, Demographic and SocioEconomic Data | personname. | User's Name |
bdate. | Demographic and SocioEconomic Data | date. | User's Birth Date |
cert. | Unique Identifiers | certificate | User's Identity certificate |
gender | Demographic and SocioEconomic Data | gender | User's gender |
employer | Demographic and SocioEconomic Data | text | User's Employer |
department | Demographic and SocioEconomic Data | text | Department or division of organization where user is employed |
jobtitle | Demographic and SocioEconomic Data | text | User's Job Title |
home. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
contact. | User's Home Contact Information |
business. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
contact. | User's Business Contact Information |
Note, that this data set includes elements that are actually sets of data themselves. These sets are defined in the data types subsection of this document. The short display name for an individual element contained within a data set is defined as the concatenation of the short display names that have been defined for the set and the element, separated by commas. For example, the short display name for user.home.postal.Postalcode would be "User's Home Contact Information, Postal Address Information, Postal code". User agent implementations may prefer to develop their own short display names rather than using the concatenated names when prompting users for information.
In some cases, there is a need to specify data elements that do not have associated data values in the user's repository (e.g., when a service wishes to declare it keeps HTTP logs): these are the so-called non-repository elements explained in the P3P Syntax Specification. In the P3P Base Data Set, all such non-repository elements are grouped under the dynamic. data set. While elements from other data sets (such as user.) might require the user agent to perform steps to retrieve such information from the user repository, elements from the dynamic. data set are never to be found in the repository but instead are collected outside the scope of P3P, for example through HTTP headers, HTML forms, or implicitly on the server side by collecting clickstream logs.
dynamic. | Category | Type | Short display name |
clickstream.client | Navigation and Click-stream Data | boolean | Click-stream collected on the client |
clickstream.server | Navigation and Click-stream Data | boolean | Click-stream collected on the server |
cookies | * | boolean | cookies are processed (read/write) |
http.useragent | Computer Information | text | User Agent information |
http.referrer | Navigation and Click-stream Data | uri | Last URI requested by the user |
miscdata | * | text | Miscellaneous non-base data set information |
searchtext | Interactive Data | text | Search terms |
interactionrecord | Interactive Data | boolean | server stores the transaction history |
These elements are often implicit in navigation or Web interactions. They should be used with categories to describe the type of information collected through these methods. A brief description of each element follows.
"clickstream.client" should be used when the server accesses off-line browsing information that has been collected by the user's client. Some versions (e.g. 5.0) of Microsoft's Internet Explorer are known to support such behavior.
"clickstream.server" will probably apply to almost all sites on the Web today. It must be used whenever page access data is kept on the server side. Almost all known Web server implementations today will by default create such an access log, often including origin of the request (IP address or DNS name), time, requested resource, HTTP answer code and transferred bytes. Any combination of resource name and originating address should be considered clickstream data (i.e. it allows the reconstruction of a visitors movements through the site) and should be declared.
Please note that the logging of referer or user agent information (included in the headers of the HTTP request by many browsers) should explicitly by declared using the http.useragent and http.referrer data elements.
"cookies" should be used whenever information is placed on a user's machine using the HTTP cookie mechanism in order to be "solicited" (i.e. automatically sent) later. Please note that "cookies" is a variable data element and requires the explicit declaration of usage categories in a proposal.
"http.useragent" indicates that the server stores additional information about the user agent in its logs, such as operating system, browser software and version.
"http.referrer" indicates that the server stores additional information about the page the user viewed previously, as indicated by the HTTP_REFERER header (the HTTP spec uses two "R" instead of three!).
The "miscdata" element references information collected by the service that is not described by any element in the currently available (base) data element sets. Sites MUST reference a separate miscdata element in their proposals for each category of miscdata they collect.
"searchtext" is 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.
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). This element is only meant to inform the user that such information will be retained, but does not indicate how long such data will be kept.
Proposals that contain one or more of the Variable Data Elements above explicitly declare the category (as defined by the Vocabulary) of the information they solicit, for example:
<P3P:PROP>
...
<DATA:REF name="dynamic.miscdata" VOC:category="1">
...
</P3P:PROP>
when asking (through a form) for a user's IRC name (which would be in category 1 Online Contact Information).
Please note that if a form asks for elements from a known schema set -- for
example the user's name or postal address -- these SHOULD be
explicitly listed in the proposal using the element's name and the
"source="service"
" attribute, instead of referencing them indirectly
through a "dynamic.miscdata" element.
The date. type is a structured type that specifies a date. Since date information can be used in different ways, depending on the context, all date. information is tagged as being of "variable" category. Schema definitions have to explicitly set the corresponding category in the element referencing this data type. For example, soliciting the birthday of a user might be "Demographic and SocioEconomic Data", while the expiration date of a credit card belongs to the "Financial Account Identifiers" category.
date. | Category | Type | Short display name |
year | * | number | Year |
month | * | number | Month |
day | * | number | Day |
hour | * | number | Hour |
minute | * | number | Minute |
second | * | number | Second |
fractionsecond | * | number | Fraction of Second |
timezone | * | text | Time Zone |
All the fields in the date. type correspond to those in the most informative profile of the time standard ISO8601.
The personname. type is a structured type that specifies information about the naming of a person.
personname. | Category | Type | Short display name |
prefix | Demographic and SocioEconomic Data | text | Name Prefix |
first | Physical Contact Information | text | First Name |
middle | Physical Contact Information | text | Middle Name |
last | Physical Contact Information | text | Last Name |
suffix | Demographic and SocioEconomic Data | text | Name Suffix |
formatted | Physical Contact Information, Demographic and SocioEconomic Data | text | formatted Name |
nickname | Demographic and SocioEconomic Data | text | Nickname |
The certificate. type is a structured type to specify identity certificates (like, for example, X.509).
certificate. | Category | Type | Short display name |
key | Unique Identifiers | binary | Certificate Key |
format | Unique Identifiers | text | Certificate Format |
The "format" field is an IANA registered public key or authentication certificate format, while the "key" field contains the corresponding certificate key.
The phonenum. type is a structured type that specifies the characteristics of a phone number.
phonenum. | Category | Type | Short display name |
intcode | Physical Contact Information | number | International Phone code |
loccode | Physical Contact Information | number | Local Phone Area code |
number | Physical Contact Information | number | Phone Number |
ext | Physical Contact Information | number | Phone Extension |
comment | Physical Contact Information | text | Phone Optional Comments |
The contact. type is a structured, redirected, type to other types. This is done so that services can specify precisely which set of data they need.
contact. | Category | Type | Short display name |
postal. | Physical Contact Information, Demographic and SocioEconomic Data | postal. | Postal Address Information |
telecom. | Physical Contact Information | telecom. | Telecommunications Information |
online. | Online Contact Information | online. | Online Address Information |
The postal. type is a structured type that specifies a postal mailing address.
postal. | Category | Type | Short display name |
name. | Physical Contact Information, Demographic and SocioEconomic Data | personname. | Name |
street.line1 | Physical Contact Information | text | Street Address 1 |
street.line2 | Physical Contact Information | text | Street Address 2 |
street.line3 | Physical Contact Information | text | Street Address 3 |
city | Physical Contact Information | text | City |
stateprov | Physical Contact Information | text | State or Province |
postalcode | Demographic and SocioEconomic Data | text | Postal code |
countrycode | Demographic and SocioEconomic Data | Country | Country code |
country | Demographic and SocioEconomic Data | text | Country Name |
organization | Physical Contact Information, Demographic and SocioEconomic Data | text | Organization Name |
formatted | Demographic and SocioEconomic Data | text | formatted Postal Address |
Using three distinct fields for the street information allows service providers and user agents to split long addresses into multiple lines during solicitation. However, since all fields share the common street. prefix, this shorthand form can be used in both preference files and proposals to reference all three fields at once.
The "formatted" field is used to specify the formatted text corresponding to the delivery address, as it could for example be printed on a label.
The telecom. type is a structured type that specifies telecommunication information about a person.
telecom. | Category | Type | Short display name |
phone. | Physical Contact Information | phonenum. | Phone number |
fax. | Physical Contact Information | phonenum. | Fax number |
mobile. | Physical Contact Information | phonenum. | Mobile Phone number |
pager. | Physical Contact Information | phonenum. | Pager number |
The online. type is a structured type that specifies online information about a person.
online. | Category | Type | Short display name |
Online Contact Information | text | Email Address | |
uri | Online Contact Information | uri | Home Page Address |
This specification uses the following primitive data element datatypes:
Primitive DataType | Definition |
text | [UTF-8] |
gender | "M" or "F". |
boolean | "0" or "1". |
binary | Base64 per RFC-1531. [MIME] |
number | text composed with the digits "0", "1", "2", "3", "4", "5", "6", "7", "8", "9". |
Country | [ISO3166] |
uri | [URI] |
The data schema corresponding to the P3P base data set follows. In order to improve legibility, we have indented and aligned the code along various attribute names.
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax/"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
<USES><STATEMENT>
<!-- ********** Base Data Types **********
-->
<!-- "date." Data Type -->
<DATA:REF name="date.year"
short="Year"
type="number" size="6"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.month"
short="Month"
type="number" size="2"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.day"
short="Day"
type="number" size="2"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.hour"
short="Hour"
type="number" size="2"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.minute"
;
short="Minutes"
type="number" size="2"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.second"
short="Second"
type="number" size="2"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.fractionsecond"
short="Fraction of Second"
type="number" size="6"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="date.timezone"
short="Time Zone"
type="text" size="10"
template="yes"/> <!-- Variable Data Element
-->
<!-- "personname." Data Type -->
<DATA:REF name="personname.Prefix"
short="Name Prefix"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="personname.first"
short="First Name"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="personname.middle"
short="Middle Name"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="personname.last"
short="Last Name"
type="text"
VOC:category="physical"
template="yes"/>
<DATA:REF name="personname.suffix"
short="Name Suffix"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="personname.formatted"
short="formatted Name"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="personname.formatted"
short="formatted Name"
type="text"
VOC:category="demograph" template="yes"/>
<DATA:REF name="personname.nickname"
short="Nickname"
type="text"
VOC:category="demograph"
template="yes"/>
<!-- "certificate." Data Type
-->
<DATA:REF name="certificate.key"
short="Certificate Key"
type="binary" size="0"
VOC:category="uniqueid" template="yes"/>
<DATA:REF name="certificate.format"
short="Certificate format"
type="number" size="128"
VOC:category="uniqueid" template="yes"/>
<!-- "phonenum." Data Type -->
<DATA:REF name="phonenum.intcode"
short="International Phone Code"
type="number" size="11"
VOC:category="physical" template="yes"/>
<DATA:REF name="phonenum.loccode"
short="Local Phone Area Code"
type="number" size="11"
VOC:category="physical" template="yes"/>
<DATA:REF name="phonenum.number"
short="Phone Number"
type="number" size="30"
VOC:category="physical" template="yes"/>
<DATA:REF name="phonenum.ext"
short="Phone Extension"
type="number" size="11"
VOC:category="physical" template="yes"/>
<DATA:REF name="phonenum.comment"
short="Phone Optional Comments"
type="text"
VOC:category="physical" template="yes"/>
<!-- "contact." Data Type" -->
<DATA:REF name="contact.postal."
short="Postal Address Information"
type="postal."
VOC:category="physical" template="yes"/>
<DATA:REF name="contact.postal."
short="Postal Address Information"
type="postal."
VOC:category="demograph"
template="yes"/>
<DATA:REF name="contact.telecom."
short="Telecommunications Information"
type="telecom."
VOC:category="physical" template="yes"/>
<DATA:REF name="contact.online."
short="Online Address Information"
type="online."
VOC:category="online" template="yes"/>
<!-- "postal." Data Type -->
<DATA:REF name="postal.name."
short="Name"
type="personname."
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.name."
short="Name"
type="personname."
VOC:category="demograph"
template="yes"/>
<DATA:REF name="postal.street.line1"
short="Street Address, Line 1"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.street.line2"
short="Street Address, Line 2"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.street.line3"
short="Street Address, Line 3"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.city"
short="City"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.stateprov"
short="State or Province"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.postalcode"
short="Postal Code"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="postal.organization"
short="Organization Name"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.organization"
short="Oranization Name"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="postal.formatted"
short="Formatted Postal Address"
type="text"
VOC:category="physical" template="yes"/>
<DATA:REF name="postal.formatted"
short="Formatted Postal Address"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="postal.country"
short="Country Name"
type="text"
VOC:category="demograph"
template="yes"/>
<DATA:REF name="postal.countrycode"
short="Country Code"
type="Country" size="2"
VOC:category="demograph"
template="yes"/>
<!-- "telecom." Data Type -->
<DATA:REF name="telecom.phone."
short="Phone Number"
type="phonenum."
VOC:category="physical" template="yes"/>
<DATA:REF name="telecom.fax."
short="Fax Number"
type="phonenum."
VOC:category="physical" template="yes"/>
<DATA:REF name="telecom.mobile."
short="Mobile Phone Number"
type="phonenum."
VOC:category="physical" template="yes"/>
<DATA:REF name="telecom.pager."
short="Pager Number"
type="phonenum."
VOC:category="physical" template="yes"/>
<!-- "online." Data Type -->
<DATA:REF name="online.email"
short="Email Address"
type="text"
VOC:category="online" template="yes"/>
<DATA:REF name="online.uri"
short="Home Page Address"
type="uri"
VOC:category="online" template="yes"/>
<!-- ********** Base Data Sets ********** -->
<!-- "dynamic." Data Set -->
<DATA:REF
name="dynamic.clickstream.client"
short="Click-stream collected on the client"
type="boolean" source="service"
VOC:category="navigation"/>
<DATA:REF
name="dynamic.clickstream.server"
short="Click-stream collected on the server"
type="boolean" source="service"
VOC:category="navigation"/>
<DATA:REF name="dynamic.cookies"
short="cookies are processed (read/write)"
type="boolean" source="service"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="dynamic.http.useragent"
short="User Agent information"
type="text" source="service"
VOC:category="navigation"/>
<DATA:REF name="dynamic.http.referrer"
short="Last URI requested by the user"
type="uri" source="service"
VOC:category="navigation"/>
<DATA:REF name="dynamic.miscdata"
short="Miscellaneous non base data set
information"
type="text" source="service"
template="yes"/> <!-- Variable Data Element
-->
<DATA:REF name="dynamic.searchtext"
short="Search terms"
type="text" source="service"
VOC:category="interactive"/>
<DATA:REF
name="dynamic.interactionrecord"
short="server stores the transaction history"
type="boolean" source="service"
VOC:category="interactive"/>
<!-- "user." Data Set -->
<DATA:REF name="user.name."
short="User's Name"
type="personname."
VOC:category="physical"/>
<DATA:REF name="user.name."
short="User's Name"
type="personname."
VOC:category="demograph"/>
<DATA:REF name="user.bdate."
short="User's Birth Date"
type="date."
VOC:category="demographic"/>
<DATA:REF name="user.cert."
short="User's Identity certificate"
type="certificate."
VOC:category="uniqueid"/>
<DATA:REF name="user.gender"
short="User's gender"
type="gender"
VOC:category="demograph"/>
<DATA:REF name="user.jobtitle"
short="User's Job Title"
type="text"
VOC:category="demograph"/>
<DATA:REF name="user.home."
short="User's Home Contact Information"
type="contact."
VOC:category="physical"/>
<DATA:REF name="user.business."
short="User's Business Contact Information"
type="contact."
VOC:category="physical"/>
<DATA:REF name="user.employer"
short="Name of User's Employer"
type="text"
VOC:category="demograph"/>
<DATA:REF name="user.department"
short="Department or division of organization where user
is employed"
type="text"
VOC:category="demograph"/>
</STATEMENT></USES>
</PROP>
[fill in later]