Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
This is the core and lengthiest document of the P3P specification; it documents the requirements, assumptions, and specifies the P3P protocols, transport methods, and the data structures' syntax and encoding.
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/).
___
Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices and enables users to exercise preferences over those practices. P3P compliant products will allow users to be informed of site practices (in both machine and human readable formats), to delegate decisions to their computer when appropriate, and to tailor their relationship to specific sites. Site practices that are compatible with a user's preferences can, at the user's option, be accessed "seamlessly". Otherwise users will be notified of a site's practices and have the opportunity to agree to those terms or other terms and continue browsing if they wish.
P3P gives users the ability to make informed decisions regarding their Web experience and the ability to control the use of their information. Sites can use P3P to increase the level of confidence users place in their services, as well as improve the quality of the services offered, customize content, and simplify site access.
P3P uses [XML] (using the [RDF] data model) for the exchange of structured data and assertions. P3P will support future digital certificate and digital signature capabilities. P3P can be incorporated into browsers, browser plug-ins, servers, or proxy servers that sit between a client and server.
The P3P specification provides mechanisms:
This document, its chapters, and its normative references, include all the specification necessary for the implementation of interoperable P3P applications. This specification was built upon the work of previous working groups and includes:
This document includes the main body of the P3P specification. The detailed -- natural language -- semantics of the privacy disclosure vocabulary can be found in:
The detailed syntax and datatypes of the base data set is found in:
Note that while use of the above vocabulary is required for P3P1.0 compliance, the facility of XML-namespaces [XML-name] allows additional or complementary vocabularies to be easily introduced.
We use the following typographical conventions for representing the status of text:
| Schema definition in ABNF notation. |
The ABNF notation used in this specification is specified in RFC2234 and summarized in Appendix 2.
When a user encounters a Web service, the Web service may declare its privacy practices and additionally solicit information from the user.
A P3P proposal consists of one or more statements, each of which expresses privacy practices for a set of data elements. The P3P proposal should cover all relevant data elements and practices: if a service wants to collect a data element, it must be mentioned in the proposal. Note that most declarations in P3P are positive, meaning you state what you do, rather than what you do not do.
A core concept to the P3P specification is that of a P3P agreement. A P3P agreement is a proposal agreed to by both the service and user agent. User agents compare the privacy practices specified in a proposal with the user's preferences to determine whether to enter into an agreement. An agreement applies to all data exchanged between the user agent and service within a specified realm -- a Web resource or "tree" of Web resources referenced by a single URI, or list of Web resources referenced by a list of URIs.
Once an agreement is reached, the enumerated data elements that are included in the agreed-to proposal should be interpreted by the user agent as data requests from the service. It is possible to have an agreement without referencing data elements. Such an agreement states that no information is collected.
More than one proposal may exist for a realm. Services also have the capability to offer alternative or optional proposals. Every proposal can have a set of 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. User agents should record the agreements reached, indexed by a fingerprint of the agreement, called the .
Rather than sending a new proposal to the user agent on every contact, a site may send the propID of an existing agreement. This is 1) asserting that the service and the user agent have already agreed to a proposal, 2) signaling which proposal and privacy practices they are operating under, and 3) requesting those data elements referenced in the agreement. The user agent may turn away, respond with the requested data, or request a full proposal -- if either it has no record of such an agreement or it desires a new one.
Proposals (or pointers to proposals) are sent in the transport mechanism (HTTP) or within the content/resource (HTML page). Multiple alternative proposals may exist for any given resource, for purposes of flexibility. Services may use the P3P-extension multiple times within HTTP, or use multiple links within HTML.
An agent should return the information according to the methods native to its transport and content model. We define how to accomplish information exchange using HTTP methods. We also specify an extensibility mechanism for returning information through other means.
There are two notable areas where we substantively provide extensibility mechanisms.
Our design is such that applications can be efficiently implemented independent of our assumptions or expectations regarding the latency of multi-round communications, the cacheability of proposals, the use of user agent or server side data repositories, and the size of the agreement repositories.
P3P makes several assumptions about the environment in which it works and the problem it is trying to solve.
This document specifies requirements over interoperability, feature sets, and policy related semantics. Interoperability requirements constrain implementations such that the protocols operate in accordance with a "shared" protocol state machine and that information is not arbitrarily lost or confounded. This document further specifies requirements over feature sets. This means that while not implementing a feature does not break the protocol, it is an abuse of the reciprocating party's -- or user's -- expectation of which features are supported. Furthermore, because of the important policy implications of this application, P3P includes natural language semantics for an XML/RDF schema. To provide an example, an interoperability requirement requires that all parties support the protocol primitives and their responses. Given this requirement, a compliant agent could always return a SORRY. However, it abuses the expectations of a service from being able to reach an agreement if all agents are implemented to merely return a sorry. To extend this example, services may not be willing to implement multiple policies or negotiated settlements if no agents exist to do so -- in either case, this lack of a support of a feature does not abuse protocol interoperability.
The breadth of these requirements is atypical but necessary given that P3P is more than a protocol, but an application of existing standards such as HTTP and XML. Furthermore, this document discusses expected features which are not yet implemented and need not be part of the specification itself, but are an important part of the P3P user experience.
The following key words are used throughout the document and should be read as interoperability requirements. This specification uses words as defined in RFC2119 [KEY] for defining the significance of each particular requirement. These words are:
The following table presents a summary of features and operations with respect to their requirements. The context of whether the requirements are placed on the client and/or service is left to the context found in the specification.
| Section | Feature/Operation | Key Word | Explanation (or Implication if not supported) |
Terminology |
propID | MUST | propID uniquely identifies any privacy proposal |
| the HTML LINK tag | MUST | agents and services must be able to locate a proposal in this location | |
| the HTTP extension mechanism | MUST | agents and services must be able to locate a proposal in this location | |
| postURI/CGI | MUST | data must be able to be sent back via HTTP post to some URI | |
| XML parsing | MUST | proposals and data syntax are readily processed or presented to the user. The RDF data model was used to structure the required grammar/syntax but applications need not support RDF if they do not want to take advantage of the RDF data model. | |
| Full XML and XML-namespace support | MUST | implementations must support full XML and namespaces, not just that used here. | |
| Data References | base data reference syntax | MUST | agents must be able to understand that syntax of solicited information |
| Abstract Elements | abstract elements | MUST | methods of references data exchanged through mechanisms other than P3P |
| Harmonized Vocab | harmonized vocabulary | MUST | see the harmonized vocubarly for requirements; they must be followed otherwise the implementation abuses consensus on adequate levels of privacy disclosure |
| Reason Codes | (OK, SRY-, ERR-, SRY, ERR) | MUST | Necessary for reaching agreement. If a reason code is not provided there is an implied semantic. Consequently the semantic is required, the presence of the code is optional. |
| Operational Description | propID repository | SHOULD | full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists. |
| service can write to the data repository | SHOULD | services can write information back to the user repository if the user permits | |
| data repository | MAY | frequently requested user profile information is stored and managed by the user. | |
| Data Definitions | new schema instantiation | MAY | schemas other than the base set can be instantiated and supported by the agent. |
| Source Attribute | source attribute | MAY | agents support multiple, extensible mechanisms by which information is solicited. |
A very simple P3P user agent might do little more than receive P3P proposals and present them to users. Whenever information is requested, such a user agent would prompt the user to make a decision. Thus such a user agent would not make any decisions on behalf of a user or transfer any user data automatically (with the exception of passively generated data such as click-stream data).
User agents that make decisions on behalf of a user or transfer user data automatically must include a user-configurable "trust engine." The trust engine must be able to take a P3P proposal and a set of user preferences -- recorded as a set of rules -- as input and determine what action (seamless accept, seamless reject, informational prompt, warning prompt, or other action) should be taken. User preferences can be encoded in [APPEL] or another language. The preference language should be well-documented or a user interface should be provided for creating rule sets in that language. The user agent must provide a way for users to import rule sets that they create themselves or obtain from others. It should also provide mechanisms for users to create or change rules.
User agents may be initially unconfigured (thus requiring users to configure them before they can be used) or configured with a default rule set. However user agents must not be configured by default to transfer personal information to a service provider without the user's active agreement (seamless accept).
The following scenarios are designed to illustrate several possible ways that P3P might be used. Each scenario highlights a different P3P feature. Scenario 1 shows how a basic P3P agreement is established. Scenarios 2 and 3 show what happens when a user returns to a site where an agreement has already been reached. Scenarios 4 and 5 highlight the use of the user data repository given existing agreements.
These scenarios illustrate interactions in which no negotiation occurs. However, any scenario could be expanded to one in which a site initially offers multiple alternative proposals. The expanded example scenario in Appendix 1 includes an example of negotiation.
The table below summarizes the features of each scenario. A "-" in the table
indicates a feature about which no assumptions (neutral) are made.
| Scenario | Existing Agreement | New Proposal | Data Requested | Data Written |
| 1 | No | Yes | - | - |
| 2 | Yes | No | - | - |
| 3 | Yes | Yes | - | - |
| 4 | - | - | Yes | No |
| 5 | - | - | Yes | Yes |
The protocol model is based on a single interaction. Since we follow the rule of thumb that compact data (usually, just a single line) should be placed in an HTTP header, often the response to a request will be a location at which the client must fetch the actual proposal -- just as an HTML client makes several requests to retrieve images in a page. This single interaction (which may involve multiple HTTP requests) can be extended to multiple interactions (or "negotiation") if needed. That is, multiple interactions can be built on top of a single interaction without affecting the simplicity of a single round interaction. It is important to note that the proposed protocol interactions strictly follow the HTTP request/response paradigm in order to properly interact with intermediate caches which may or may not know about P3P.
The basic protocol actions can be summarized as follows.
The client can perform any of the following actions at any point in time when issuing requests.
The server can perform the following actions:
In order to use the HTTP Extension Framework [HTTP-EXT], it is required to provide a globally unique URI identifying the extension (the extension declaration). The P3P extension declaration is the following URI:
http://www.w3.org/TR/WD-P3P/
The P3P extensions are the following:
A client requests a proposal from a server by issuing a request stating that it is P3P savvy. This request is performed via the HTTP Extension Framework, using the P3P extension declaration (http://www.w3.org/TR/WD-P3P/). It is up to the implementation whether to use the Optional or Mandatory extension.
For example, a client can verify, using the OPTIONS method, whether the server is P3P compliant or not:
OPTIONS some.resource HTTP/1.1 Host: some.host Opt: "http://www.w3.org/TR/WD-P3P/"
Or, for example, within a normal GET request:
GET some.resource HTTP/1.1 Host: some.host Opt: "http://www.w3.org/TR/WD-P3P/"
Of course, if the Mandatory extension is used in place of the Optional one, the methods M-OPTIONS and M-GET must be used ([HTTP-EXT]).
If the client already has an agreement for a specific resource or wants to agree to an offered proposal then it can require the server to use this proposal for the data included in the request. This is done using the Mandatory P3P extension declaration with the M-POST method, and setting the following P3P extensions for each proposal:
If the server does not want to comply with this policy it must disregard the data and return an error.
For example, if the client wants to agree to an offered proposal with propID 94df1293a3e5, it could send:
M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-data: <TXD 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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
...
[Content]
As another example, if the client wants to agree to an offered proposal with propID 94df1293a3e5 and to a proposal with propID AAbbAAbbAAbb, it could send:
M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Man: "http://www.w3.org/TR/WD-P3P/"; ns='22-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-data: <TXD 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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
22-status: OK
22-propID: "md5:AAbbAAbbAAbb"
22-data: <TXD 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">
22-data: <DATA:REF name="User.Business.Postal.City" value="Cambridge">
22-data: </TXD>
...
[Content]
The server can at any point in time indicate which policy will be used for one or more resources. In case more than one proposal is offered, they are considered as multiple alternative proposals. Alternative means that the client is supposed to choose (at most) one proposal among the possibly many offered. Suggesting proposals can be done in two ways: at HTTP level, using the HTTP Extension framework, or at HTML level, using the HTML LINK tag. These two ways are not exclusive: in case both are used at the same time, the interpretation is a set of multiple alternative proposals.
This is done using the Optional P3P extension declaration, and setting the following P3P extensions for each suggested proposal:
The default realm is the current Request-URI only.
For example:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-propID: "md5:94df1293a3e5"
14-proposal: "http://www.privacy.org/P3PProposal"
...
[Content]
Or, in case of multiple (three) alternative proposals:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='18-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='20-'
15-propID: "md5:94df1293a3e5"
15-proposal: "http://www.privacy.org/P3PProposal"
18-propID: "md5:23as53aw12w2"
18-proposal: "http://www.privacy.org/P3PProposal2"
20-propID: "md5:56ew89qwht14"
20-proposal: "http://www.privacy.org/P3PProposal3"
...
[Content]
This is accomplished by using the HTML LINK tag in the following way for each suggested alternative proposal:
<LINK rel="p3p:md5:hash" href="URI">
Here, URI points to the P3P proposal, and "p3p:md5:hash" is a relation name used to distinguish this special P3P link, and to encode the (md5) hash of the proposal. For example, if a proposal at http://www.privacy.org/P3PProposal has hash 94df1293a3e5, we would use <LINK rel="p3p:md5:94df1293a3e5" href="http://www.privacy.org/P3PProposal">.
Note: This may increase the latency of fetching a proposal since it must now be sought in the HTML content. However, such proposals can be cached. Regardless, this method should only be used for sites which 1) do not use P3P data methods and 2) have a few, simple, non-overlapping proposals for their site.
If the client requires a proposal using the M-POST method, the server must either accept it or fail: this is a property of the Mandatory request functionality [HTTP-EXT]. If the server accepts the proposal, no further reply is required. If the server does not accept the proposal then it must disregard all the data possibly received by the client with the M-POST message, and it must issue an error in which it may suggest a policy that it can accept (the client can then decide whether it wants to try again or not). This is done using the Optional P3P extension declaration, and setting the following P3P extensions:
Of course, the propID extension must be set if a new proposal is offered. Again, the default realm is the current Request-URI only.
For example, if the previous agreement has expired:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-status: SRY-AE
14-propID: "md5:94df1293c1p8"
14-proposal: "http://www.privacy.org/newP3PProposal"
...
[Content]
Reason codes are sent in the status extention headers and indicate the state of a proposal or data -- potentially -- in the context of a previous interaction. Every P3P extension must include a status header with a specified value or extension URI. Applications that do not understand the status extension must ignore the p3p-message.
| Reason Token | Explaination |
| OK | ok, receipt of the contents of the proposal or data extension completed successfully. |
| SRY-AU | because the agreement is unkown. (sent in response to the content of the data extension) |
| SRY-AE | because the agreement expired. (sent in response to the content of the data extension) |
| SRY-PR | because the proposal was rejected. (sent in response to the content of the proposal extension) |
| SRY-DU | because the data is unavailable. (sent in response to the content of the proposal extension) |
| SRY-DR | because the data could not be accepted or written to repository (sent in response to the content of the proposal extension) |
| SRY | sorry, receipt of the contents of the proposal or data extension failed. This code can be sent, in response to the content of the proposal extension, when all the other SRY- codes are not applicable |
| ERR-IF | invalid format, the P3P message that was received was syntactically invalid or semantic garbage. |
| ERR-TF | data transfer failed, the transfer request was received, and it was syntactically valid, and covered by a valid agreement, but the data could not be stored for some reason. |
| ERR | error, a request was not understood or received properly. This code can be sent when all the other ERR- codes are not applicable |
Note that if, for privacy reasons, the client does not want to divulge its reasons for refusing a proposal, the client can reply with the generic SRY code, rather than with a more specific SRY- code. The same holds for the error messages (ERR can be used rather than a specific ERR-), although it is advisable that ERR-IF and ERR-TF are used whenever possible.
1. The user goes to an order page and asks for a proposal:
GET store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Opt: "http://www.w3.org/TR/WD-P3P/"
2. Or perhaps the service returns location of alternative proposals, structured via RDF, in effect for the requested URI:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/P3P/"; ns='12-'
12-propID: "md5:aaaaaa"
12-proposal: "http://www.store1.com/P3PProposal1.RDF"
Opt: "http://www.w3.org/TR/P3P/"; ns='4253-'
4253-propID: "md5:ababab"
4253-proposal: "http://www.store1.com/P3PProposal2.RDF"
...
Content-Type: text/html
Content-Length: 110
<html><body>
<h1>Welcome to Cool Catalogue</h1>
<p>We'd love to have the following information to
customize our online catalogue to you.</p>
<form method="POST" action="http://www.CoolCatalog.com/cgi-bin">
<p><input type="submit" value="Submit" name="B1">
<input type="reset" value="Reset" name="B2">
First Name <input type="text" name="User.Name.First" size="20" value="Your First Name Here">
Second Name <input type="text" name="User.Name.Second" size="20" value="Your Second Name Here">
</form>
</body>
</html>
3. The user agrees by returning the relevant propIDs with the data that is returned. Agreement over abstract data elements (see [BASEDATA]) is assumed to follow from subsequent interactions with the service.
M-POST store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Man: "http://www.w3.org/TR/WD-P3P/" ns='23-'
23-propID: "md5:aaaaaa"
23-status: "OK"
23-data: <TXD 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">
23-data: </TXD>
Man: "http://www.w3.org/TR/WD-P3P/" ns='78-'
78-propID: "md5:ababab"
78-status: "OK"
78-data: <TXD 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">
78-data: <DATA:REF name="User.Name.First" value="Sheila">
78-data: <DATA:REF name="User.Name.Second" value="Doherty">
78-data:
...
[Content]
This section describes the syntax and semantics of P3P proposals as well as for blocks of user data transmitted between a user agent and a service. A more complete English language description of the terms used in a proposal may be found in [HARMV].
We begin with an example of an English language privacy policy and a corresponding P3P proposal in Section 4.1. P3P proposals include general assertions that apply to the entire proposal as well as specific assertions -- called statements -- that apply only to the handling of particular types of data referred to by data references. Section 4.2 describes the proposal element and proposal-level assertions. Section 4.3 describes the TXD element that is used to transfer data blocks. Section 4.4 describes statements and data references.
In the sections that follow we introduce a number of XML elements. Each element is given in <> brackets, followed by a list of valid attributes and an XML name space (xmlns). All listed attributes are optional, except when tagged as mandatory.
The following is an example of an English-language privacy policy that we would like to encode as a P3P proposal.
CoolCatalog makes the following statement for the Web pages at http://www.CoolCatalog.com/catalog/.We use cookies and collect your gender and (optionally) information about your preferences to customize our entry catalog pages for the type of clothing you are likely to be interested in and for our own research and product development. We do not use this information in identifiable form.
We also maintain server logs that include information about the what pages on our site are visited and the types of browsers our visitors use. We use this information in order to maintain and improve our web site. We do not use this information in an identifiable way.
We do not provide access capabilities to information we may have from you, but we do have retention and opt-out policies, which you can read more about at our privacy page http://www.CoolCatalog.com/PrivacyPractice.html. The third-party PrivacySeal.org provides assurance that we abide by this agreement.
The following is a more formal description, using the P3P element and attribute names, with their numeric values in parentheses:
Entity: http://www.CoolCatalog.com/
Realm: http://www.CoolCatalog.com/catalog/
Disclosure URI: http://www.CoolCatalog.com/PrivacyPractice.html
Access to Identifiable Information: none (3)
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention (0,1)We collect:
Cookies_
User.Gender
Form.Data_ (category=8, optional)
For purpose: Customization of the site to individuals, research and development (2.3)
Identifiable use: No (0)
Recipients: Only ourselves and our agents (0)
Consequence: A site with clothes you would appreciateWe collect:
ClickStream.Server_
HTTP.UserAgent_
For purpose: Web site and system administration, research and development (1,3)
Recipients: Only ourselves and our agents(0)
The following piece of [RDF] captures the information as expressed above. P3P proposals are statements that are properly expressed according to the syntax model of [RDF] as well as well-formed XML. However, there are two assumptions, used to make the proposal shorter, that slightly differentiate a P3P proposal from standard RDF. If the XML/RDF data is homogeneously P3P then the enclosing RDF tags may be optionally omitted. The proposal syntax will be explained in more detail in the sections that follow.
<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax"> <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" entity="http://www.CoolCatalog.com"> <ASSURANCE org="http://www.PrivacySeal.org" text="third party" image="http://www.PrivacySeal.org/Logo.gif"/> <REALM uri="http://www.CoolCatalog.com/catalog/"> <VOC:DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html" access="3" other="0,1"/> <USES> <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0" consq="a site with clothes you would appreciate"> <DATA:REF name="Cookies_" source="0"/> <DATA:REF name="Form.Data_" VOC:category="8" optional="1" source="0"/> <DATA:REF name="User.Gender" source="1"/> </STATEMENT> </USES> <USES> <STATEMENT VOC:purp="1,3" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="ClickStream.Server_" source="0"/> <DATA:REF name="HTTP.UserAgent_" source="0"/> </STATEMENT> </USES> </PROP> </RDF:RDF>
This section defines the key elements, attributes and processing heuristics for operating on a proposal. All proposals are encoded using [UTF-8].
| [1] | PROP-msg |
= |
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/REC-rdf-syntax/">` proposal "</RDF:RDF>")| proposal |
| [2] | proposal |
= |
`<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"` [" agrexp=" `"` datetime `"`] ;default is six months " entity=" quoted-URI [" postURI=" quoted-URI] ">" 1*statement-block disclosure [assurance] 1*realm `</PROP>` |
The entity attribute references a domain name and path that can be associated with the legal entity making the representation of the privacy practices contained in the proposal. In the absence of digital signatures, this is the only mechanism for tracking down the legal entity via the weak identification mechanisms provided by the domain name registry's and the records of the organization responsible for that domain name. In addition, the entity attribute is used as the "root" domain to which the URIs in the realm must domain-match [KRISTOL] when a certificate is not used as the realm attribute. In addition, the URI of the customer request must domain-match the entity attribute.
| [3] | realm |
= |
"<REALM" " uri=" quoted-URI "/>" |
Note that there can be multiple realms, specified via multiple occurrences of the REALM element.
The URIs specified by REALM define the scope of the agreement (the "realm"). This information is used by the user agent, for example, to determine whether there is an existing agreement with the service. Each of the Realm URIs should "domain-match" [KRISTOL] the domain of the server.
User agents should record the realms with which an agreement has been reached and the corresponding propIDs and store them for as long as the agreements remain valid (or as long as feasible). When returning to any part of a realm previously visited, the user agent should include the relevant propID in its requests to the service.
Schemes
P3P is designed around HTTP and related schemes (such as HTTPS). Specifically in the case of HTTP and HTTPS, agreements reached using HTTP implicitly cover URI requests that use the HTTPS scheme (but not vice versa). For example, if a user reaches an agreement with realm "http://www.romulus.com/", then https://www.romulus.com" is considered part of the realm. However, if the user reached an agreement with realm "https://www.romulus.com/", then "http://www.romulus.com" is not subject to the agreement. Agreements may be reached regarding realms that include other schemes such as FTP; however, the agreement must be reached by conducting the protocol over HTTP (or HTTPS) or through links embedded in HTML content. The protocol may be extended in the future to cover data exchange and negotiation using other schemes, such as FTP or NNTP.
| The values of [4-6] are provided for reference only. The normative specification is in the harmonized vocabulary document. | |||
| [4] | disclosure |
= |
"<VOC:DISCLOSURE"
" discURI=" quoted-URI
" access=" `"` access-disclosure `"`
[" other=" `"`
other-disclosure *("," other-disclosure) `"`]
"/>"
|
| [5] | access-disclosure |
= |
"0" | ; Identifiable Data is Not Used "1" | ; Identifiable Contact Information "2" | ; Other Identifiable Information "3" | ; None |
| [6] | other-disclosure |
= |
"0" | ; change agreement "1" ; retention |
| [7] | assurance |
= |
"<ASSURANCE" " service=" quoted-URI [" text=" quoted-string] [" image=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] [" alt=" quoted-string] ] "/>" |
Note that there can be multiple assurances services, specified via multiple occurrences of ASSURANCE.
The client sends data referencing a specific agreement to the service (see Section 3.3.2) by transmitting an XML/RDF message in the header. The service can also send similar messages to a user agent to request that values be stored in the user data repository.
| [8] | TXD-msg |
= |
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax">` txd-block `</RDF:RDF>`)| txd-block |
| [9] | txd-block |
= |
`<TXD 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" `>` *(data-reference) `</TXD>` |
When TXD messages are sent as HTTP header extensions, line breaks should be inserted after each closing angle bracket >. In addition, the appropriate prefix must be inserted on each line. For example:
42-data: <TXD 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">
42-data: <DATA:REF name="User.Name.First" value="Sheila"/>
42-data: <DATA:REF name="User.Name.Last" value="Doherty"/>
42-data: <DATA:REF name="User.Name.Title" value="Miss"/>
42-data: </TXD>
Statements describe data practices that are applied to particular types of data.
| [10] | statement-block |
= |
"<USES>"
"<STATEMENT"
[" action=" `"` action `"`]
" VOC:purp=" `"` purpose *("," purpose) `"`
" VOC:recpnt=" `"` recipients *("," recipients) `"`
" VOC:id=" yesno
[" consq=" quoted-string]
">"
*(data-reference)
"</STATEMENT>"
"</USES>"
|
| [11] | action |
= |
("r" | "rw") ; r=read, rw=read&write, default is read
|
| The values of [12-15] are provided for reference only. The normative specification is in the harmonized vocabulary document. | |||
| [12] | purpose |
= |
"0" | ; Completion and Support of Current Activity
"1" | ; Web Site and System Administration
"2" | ; Customization of the Site to Individuals
"3" | ; Research and Development
"4" | ; Contacting Visitors for Marketing of Services or Products
"5" [" (" string ")"] ; Other Uses
|
| [13] | recipient |
= |
"0" | ; only ourselves and our agents "1" | ; organizations following our practices "2" | ; organizations following different practices "3" ; unrelated third parties or public forum |
| [14] | id |
= |
yesno |
| [15] | yesno |
= |
"1" | "0" ; 1 stands for "Yes", 0 for "No" |
Note: Originally, very conservative default values were chosen ("0") to force services to counter those defaults to be honest about those practices. However, this could lead to semantic interpretability: a service believes an attribute is optional and a user gives them information based on the implied/default semantic. A better approach could be to set the default values very high (i.e., if the recipient attribute isn't included, it means the data is distributed to the public.) However, we are now erring on the side of not providing default values to ensure there is no confusion between optional attributes and required attributes with default semantics.
Services have the capacity to ask that information be written to the user repository. Consider a P3P agent receiving the following request as part of a proposal:
<STATEMENT action="r" VOC:purp="2" VOC:recpnt="0"
VOC:id="0"/>
<DATA:REF name="User.Name.First"
source="1"/>
</STATEMENT>
<STATEMENT ="rw" VOC:purp="2" VOC:recpnt="0" VOC:id="0">
<DATA:REF name="FineShoes.shoesize"
xmlns:DATA="http://www.FineShoes.com/Schema1.0"
source="1"/>
</STATEMENT>
The user could be prompted, asked if she agrees to this proposal, and then shown a form-like interface with the User.Name.First auto-filled (assuming she's entered that before) and a blank field for FineShoes.shoesize. The user would enter this information and transmit it using a TXD.
The user sends:
43-data: <TXD 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">
43-data: <DATA:REF name="User.Name.First" value="Sheila"/>
43-data: <DATA:REF name="User.Name.Second" value="Doherty"/>
43-data: <DATA:REF
name="FineShoes.Shoesize" xmlns:DATA="http://www.FineShoes.com/Schema1.0"
value="7"/>
</TXD>
Whenever the attribute "rw" is applied to a data element, and a new value is provided by the user, the user agent should attempt a write to the data repository. If that attempt fails, the agent should return the appropriate response code. This auto-write eliminates the need for the service to retransmit information back to the user agent. However, the service may send a TXD message at any time. For instance, even though the user provided their shoesize as 7, the service may wish to convert it into European shoe sizes and write that value instead.
xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/basedata"
| [16] | data-reference |
= |
"<DATA:REF" " name=" quoted-string " source=" `"` source `"` [" xmlns:DATA=" quoted-URI] [" optional=" yesno] [" value=" quoted-string] [" type="quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" VOC:category=" categories] [" short=" quoted-string] [" long=" quoted-string] [" size=" `"` number `"`] ; default is 0 (unlimited size) "/>" |
| [17] | source |
= |
"0" | ; service "1" | ; agent "2" | ; matched-form "3" ; extension |
| [18] | categories |
= |
`"` *(number ",") number `"` |
Example: To request the user's home address city, all the elements of the data set User.Business. and (optionally) all the elements of the data set User.Home.Telecom.Phone and collect them through a matched form, the service would send the following references inside a P3P proposal:
<DATA:REF name="User.Home.Postal.City" source="2"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1"
source="2"/>
<DATA:REF name="User.Business." source="2"/>
If the user agrees to returning the city and business information and only the international phone code and local area code of her home phone number, she returns the following inside the txd tag:
<DATA:REF name="User.Home.Postal.City" value="Cambridge"/>
<DATA:REF name="User.Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="User.Home.Telecom.Phone.LocCode"
value="617"/>
<DATA:REF name="User.Business.Postal.Street" value="254 Windsor
St."/>
<DATA:REF name="User.Business.Postal.City"
value="Cambridge"/>
... (the other values of User.Business.) ...
Categories are attributes of 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; they allow users to express more generalized preferences and rules over the exchange of their data. Categories are often included when defining a new element or when referring to data that the user is prompted to type in (as opposed to data stored in the user data repository).
Membership of data elements in categories is generally disjoint; most data elements should belong to just one category. However data elements may belong to more than one category when necessary. In addition, a data set belongs to all of the categories to which its elements belong. Base data elements have all been assigned a default category in the P3P specification. When a service proposes a new data element, the proposal should include the default category or categories for the element, however the user and/or user agent retains final control over the category assignment.
In the current version of P3P, the following numbers are used to denote data categories:
"0" ; Physical Contact Information "1" ; Online Contact Information "2" ; Unique Identifiers "3" ; Financial Account Identifiers "4" ; Computer Information "5" ; Navigation and Click-stream Data "6" ; Transaction Data "7" ; Preference Data "8" ; Demographic and SocioEconomic Data "9" ; Content
While we specify the category attribute for reference purposes, the normative definitions and values, as well as a more detailed explanation of each category, can be found in the P3P Harmonized Vocabulary Specification.
The source attribute specifies a mechanism for transferring data from the user agent to the service. We define three standard mechanisms, and an extensibility mechanism that allows new data transfer mechanisms to be defined in the future. The standard mechanisms are as follows:
A service may also wish to transfer data using another mechanism not defined here, such as an electronic commerce wallet. In that case, the service should specify source="3" to indicate that data will be collected using that mechanism.
DATA:REF elements should always include a source attribute with exactly one value, except when they occur in a data schema definition. In that case the attribute may be left out entirely, it may take one value, or it may take multiple values.
Services may use the optional attribute to indicate that a data request is optional. User agents may send or ignore optional attributes according to the user's preferences.
Note that P3P does not include a mechanism for specifying that certain data practices are optional. If services wish to give users a choice of data practices, for example, whether or not data is used for marketing, they may do so by providing multiple alternative proposals that users may choose from.
Services may declare and use new data elements by creating a data schema and referencing it in a proposal using the DATA namespace (xmlns:DATA). When data elements beyond those defined in the base data set [BASEDATA] are referenced in a proposal, the DATA:REF element must include values for the following attributes: name, category, type, typeschema, and short (typeschema may be omitted if it has the same value as the DATA namespace). If the data schema URI does not domain match the origin server URI, user agents MUST check the data schema to verify the consistency of the information. Otherwise the information in the main data schema MAY be checked in order to verify consistency of the information. In case of a mismatch, either an ERR-IF reason code (Invalid Format) or the generic ERR code must be returned. If for any other reason the user is unable to reconstruct the needed information, either a SRY-DU reason code (Data Unavailable) or a generic SRY code must be returned.
The format of a new data schema is a special proposal of the form
<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> .... </STATEMENT></USES></PROP>
A data block is enclosed within the <STATEMENT> tag and contains references to the new data elements. References can be made using the <DATA:REF> tag and the following attributes: name, type, typeschema, template, VOC:category, short, long, size, source.
For every data element, all of the information except long and source are mandatory. If source is present, it indicates that the element must only be collected using the specified data transport mechanism. If source is missing, there are no restrictions placed on how the element may be collected. If any attribute is missing, it is presumed to be present with an empty string. In the case of the typeschema, the empty string value has the special meaning that the type schema coincides with the value of the xmlns:DATA attribute.
For example, suppose the company HyperSpeed wants to build the following data schema:
car.model
car.color
car.built.year
car.built.where. (of basic type Postal.)
car.price
bike.model
bike.color
bike.built.year
bike.built.where. (of basic type Postal.)
bike.price
Then, it could place the following code at http://www.HyperSpeed.com/models-schema
<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 VOC:purp="4" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="car.model" type="Text" short="Model" VOC:category="7" size="63"/> <DATA:REF name="car.color" type="Text" short="Color" VOC:category="7" size="63"/> <DATA:REF name="car.built.year" type="Number" short="Construction Year" VOC:category="7" size="63"/> <DATA:REF name="car.built.where." type="Postal." short="Construction Place" VOC:category="7" size="63"/> <DATA:REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema"/> </USES></STATEMENT></PROP>
Note that every time a data set is created, it can be implicitly used as a type, just like the car. case above. However, in some situations one may wish to define a type without creating a specific element within the user's repository. This can be accomplished by using the template attribute in the <DATA:REF> . Setting the value to yes, template="1" (default is 0), means that the corresponding data element is part of a type definition only, and is not actually representing a data element with an associated value. For example, HyperSpeed might want to define a GenericModel. type of general utility, and then instantiating it with car. and bike. This could be done with the following schema:
<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 VOC:purp="4" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="GenericModel.model" type="Text" short="Model" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.color" type="Text" short="Color" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.year" type="Number" short="Construction Year" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.where." type="Postal." short="Construction Place" template="1" VOC:category="7" size="63"/> <DATA:REF name="car." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Car"/> <DATA:REF name="bike." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike"/> </USES></STATEMENT></PROP>
Creators of new schema should be aware that unless they place restrictions on the source attribute (i.e. source=0 or use an extension that does not store data in the user data repository), user agents may automatically store elements from the new schema in the user data repository after the user types them in. Some implementations may include user data repositories that do not use security measures appropriate for storing sensitive data.
The formal grammar of P3P is given in this specification using a slight modification of the ABNF defined in http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt . The following is a simple description of the ABNF.
name = (element)
(element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string" or 'string'
Other notations used in the productions are:
| Lorrie Cranor | AT&T |
| Philip DesAutels | Matchlogic |
| Melissa Dunn | Microsoft |
| Daniel Jaye | Engage Technologies |
| Steve Lucas (Chair) | Matchlogic |
| Massimo Marchiori (Editor) | W3C |
| Maclen Marvit | Narrowline |
| Max Metral | Firefly Network Inc. |
| Paul Perry | Firefly Network Inc |
| Martin Presler-Marshall | IBM |
| Joseph Reagle (Project Manager) | W3C |
| Drummond Reed | Intermind |