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 and 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/).
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, along with its normative references and the other chapters of the P3P specification, includes all the specification necessary for the implementation of interoperable P3P applications.
This document includes the main body of the P3P specification. The detailed -- natural language -- semantics of the privacy disclosure vocabulary can be found in [HARMV]. The detailed syntax and datatypes of the base data set is found in [BASEDATA].
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. However, note that such syntax is only a grammar representative of the XML syntax: all the syntactic flexibilities of XML are also implicitly included; e.g. whitespace rules, quoting using either single quote (') or double quote ("), character escaping, and case sensitivity.
When a user encounters a Web service, the Web service may declare its privacy practices and solicit information from the user by sending the user the URI of a P3P proposal and an identifier for that proposal called a propID. The proposal and propID are transmitted using an extension to the HTTP transport mechanism.
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 one or more specified realms -- a Web resource or "tree" of Web resources referenced by a single URI.
If a user agent finds a proposal acceptable, it can signal agreement to the web site by returning the proposal identifier. If the proposal includes a request for data to be sent using P3P data transfer methods, the corresponding data is returned with the proposal identifier.
Servers may offer multiple alternative proposals for each realm. 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 an identifier of the agreement, called the propID. Rather than sending a new proposal URI and propID to the user agent on every contact, a site may send the propID of an existing agreement.
Services may also embed <LINK> tags into HTML content that reference a P3P proposal. This allows services to assert that they follow the practices specified in a P3P proposal without requiring that they use a P3P-compliant server.
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 | |
| 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 |
| Harmonized Vocab | harmonized vocabulary | MUST | see the harmonized vocabulary [HARMV] 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. |
| propID repository | SHOULD | full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists. | |
| 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 attributes "matched-form" and "extension" | MAY | agents support multiple, extensible mechanisms by which information is solicited. |
Note that services need not use P3P-compliant servers in order to make P3P proposals available to user agents.
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 highlights 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 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 |
| 1 | No | Yes | - |
| 2 | Yes | No | - |
| 3 | Yes | Yes | - |
| 4 | - | - | Yes |
The protocol model is based on a single round interaction, where the client performs an action (like requesting a proposal), and the server completes the interaction with another action (for example, suggesting a proposal back). 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:
The P3P protocol uses the HTTP Extension Framework [HTTP-EXT]. P3P includes four header extensions, which may be added to any standard HTTP request. The HTTP Extension Framework requires 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:
This section describes the actions P3P-compliant clients and servers take to carry out the P3P protocol as an extension to the HTTP protocol. This section includes references to the various error codes that must be reported in carrying out the protocol. These codes are defined and discussed in more detail in section 3.4.
P3P clients MUST be able to:
Opt: "http://www.w3.org/TR/WD-P3P/"
or Man: "http://www.w3.org/TR/WD-P3P/"
Generally the Opt header should be used. However, if the client wishes to express that it requires P3P support, the mandatory extension may be used along with the methods M-GET, M-POST, etc. A P3P-compliant server should not treat Man headers any differently than it treats Opt headers.
Any request that contains a P3P HTTP header extension is an implied request for a proposal. A P3P-compliant server will always send the propID and proposal P3P extension headers when a relevant proposal is available.
If a client wishes to just request a proposal, without content, the client may issue an OPTIONS or HEAD request.
If a client wishes to simultaneously request a proposal and content, the client SHOULD issue a GET request (or other relevant request). If the server is willing to provide content regardless of whether a P3P agreement is reached, the server will provide the appropriate content along with the propID and proposal P3P extension headers. If the server is not willing to provide content until an agreement is reached, the server will respond with the SRY-AR code in a P3P status header and possibly an HTTP 510 error code. If the proposal is acceptable the client SHOULD repeat the original request, this time including an extension header with the relevant propID.
Note, when a user directs a P3P-compliant user agent to reach agreements with web sites before exchanging data, that client should not transfer data to a URI for which there is no corresponding P3P agreement. Thus, while a POST request is also an implicit request for a proposal, it should not be used that way by clients configured not to transfer data without agreement. Instead an OPTIONS or HEAD request should be made. Once the propID has been obtained, then the POST request can be made. Likewise, clients configured not to transfer data without an agreement should issue an OPTIONS or HEAD request before sending a GET request that includes form data (generally such a request would include a question mark) to a realm with which no agreement exists. In addition, there may be other cases where client implementations may need to be careful not to transfer data prior to reaching an agreement.
The client SHOULD submit any required data the first time it includes a given propID in a request. If a client submits a request including a propID and does not submit the required data, the server may request the data by sending a P3P SRY-DR in a status header and possibly also an HTTP 510 error. If the client receives a SRY-DR it SHOULD repeat the request with the required data if it still wishes to access the requested resource.
P3P servers MUST be able to:
When a client requests proposals or human readable privacy policies by issuing a GET request to a URI indicated by a proposal header, P3P LINK tag, or a discuri tag within a proposal, the server MUST fulfill the request without requiring an agreement.
When reporting errors involving multiple proposals, the server may either report a single error and list all of the propIDs to which that error applies, or it may report an error for each propID. If different errors apply to each propID, they MUST be reported seperately.
The following is an example of how interactions between P3P-compliant clients and servers will typically proceed. Examples of client and server actions are shown in the shaded boxes.
1. Client requests resource using GET or POST or whatever method it pleases. Client also sends P3P extension header to indicate that it is P3P-enabled.
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/" |
2a. If server does not a require P3P agreement, the server returns content and propID and proposal headers. Multiple sets of propID and proposal headers may be used to indicate that the server offers a choice of multiple alternative proposals. (Client may optionally fetch and evaluate each proposal before displaying the content.) [If all proposals are unacceptable skip to step 3b, otherwise skip to step 5]
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml Opt: "http://www.w3.org/TR/WD0P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-proposal: http://coolcatalog.com/P3PProposal2.xml . . . Content-Type: text/html . . . |
2b. If the server requires a P3P agreement, the server returns one or more propID/proposal headers, a status: SRY-AR header, and optionally an HTTP 510 error code.
HTTP/1.1 510 Not Extended Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml 1-status: SRY-AR Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-proposal: http://coolcatalog.com/P3PProposal2.xml 2-status: SRY-AR . . . |
(If the client needs to evaluate the proposal, it fetches it by issuing a GET request to the URI indicated by the proposal header. After fetching the proposal, the client may optionally interact with the user to determine whether the proposal is acceptable and/or display information to the user.)
GET coolcatalog.com/P3PProposal1.xml HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/" |
3a. If the proposal is acceptable, the client resubmits the request, this time including propID and any requested data. (If more than one proposal is available, the client should select only one and include the corresponding propID in its response.)
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-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"> 1-data: <DATA:REF name="user.name.first" value="Sheila"> 1-data: <DATA:REF name="user.name.second" value="Doherty"> 1-data: </TXD> . . . |
3b. If the proposal is not acceptable or if there is some other error, the client repeats the request with the appropriate SRY or ERR header (unless the request was a successful POST request or some other request that would have an undesirable side effect if repeated). [return to step 2 but client should give up after a small number of failed attempts to avoid infinite loop]
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-status: SRY-PR Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-status: SRY-PR |
Alternatively, this may be written:
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 1-status: SRY-PR |
4a. If the propID is valid and there are no problems, the server returns content plus proposal/propID headers.
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . Content-Type: text/html . . . |
4b. If there is some other problem (for example, the client did not actually send the required data), the server returns a status header with the appropriate SRY or ERR code, and proposal/propID headers. The server may optionally return an HTTP 510 error code if the request is not fulfilled. [return to step 3 to try again, but client should give up after a small number of failed attempts to avoid infinite loop]
HTTP/1.1 510 Not Extended Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Xorq/ZJbTpVaFRD4qfA== 1-status: SRY-DR 2-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 2-proposal: http://coolcatalog.com/P3PProposal1.xml Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 3-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 3-proposal: http://coolcatalog.com/P3PProposal2.xml . . . |
[time passes]
5. The client requests the same resource as before. It includes a propID header in order to indicate that it agrees to the proposal.
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: "Ed3Oorq/ZJbTpVaFRD4qfA==" . . . |
6a. If the agreement is still valid and the server doesn't need the data again (or if the server does not require a P3P agreement), it simply returns the content, together with proposal/propID headers (as in step 4a).
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . Content-Type: text/html . . . |
6b. If the agreement is still valid, but the server needs the data again, it asks the client to resubmit data by sending a status: SRY-DR header and optionally an HTTP 510 error code. [continue to step 3]
HTTP/1.1 510 Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml 1-status: SRY-DR . . . |
6c. If there is some other problem, the server returns a status header with the appropriate SRY or ERR codes, proposal/propID headers, and optionally an HTTP 510 error code. [return to step 5 to try again, but client should give up after a small number of failed attempts to avoid infinite loop]
HTTP/1.1 510 Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-status: ERR-IF 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . |
Each protocol action can trigger an error, due to various reasons. For example, the proposal could be malformed, or the referenced agreement could be unknown, and so forth. An error message is issued using the following P3P extensions:
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.
P3P extensions must only include status headers when they are reporting errors.
In all the other cases (that is to say, when receipt of the contents
of the proposal or data extension have been completed successfully), no status
header must be included. Applications that do not understand the status extension
must ignore the p3p-message.
| Reason Token | Description | Sent by | Explaination |
| SRY-AR | the agreement is required | server | Sent (together with a propID) if a prior agreement (corresponding to the propID) is required. Clients should evaluate the proposal (this might require them to download it first) and according to the user's preferences resubmit (with or without data), send a SRY(-PR) or end the communication. |
| SRY-AU | the agreement is unkown | server | Sent if a client sent an unkown propID along with its request. If a new proposal is available that requires agreement, the site would also have to send a SRY-AR (see above). If no "SRY-AR" is present, client can re-submit the request without referencing any propID. |
| SRY-DR | the data is required | server | Sent if the client agreed to an agreement (referenced by the corresponding propID), but did not send the proper data. Clients would need to resubmit the same request but also include the required (according to the proposal) data, if they want to access the resource. |
| SRY-DU | the data is unavailable | client | Sent if a client cannot provide the requested data, because they are not available. |
| SRY-PR | the proposal is rejected | client | Sent if the proposal is unacceptable. Servers can log this and optionally redirect the client or offer a different page/proposal. |
| SRY | sorry | server or client | Sent if receipt of the contents of the proposal or data extension failed, despite syntactically correct, and all the other SRY- codes are not applicable, or for privacy reasons (see afterwards). |
| ERR-IF | invalid format | server or client | The P3P message that was received was syntactically invalid or semantic garbage. |
| ERR-TF | data transfer failed | server or client | 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 | server or client | a request was not understood or received properly. This code can be sent when all the other ERR- codes are not applicable, or for privacy reasons (see afterwards). |
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.
Server MUST at least support sending out SRY-AR and ERR. Clients MUST understand at least the three specific SRY- error codes that can be sent by the server, that is to say they MUST be able to (if the user wants) accept a proposal (by sending the propID) and send data if necessary (again at the user's discretion). In case of SRY-AU, clients MUST be able to resubmit the request without referencing a (probably outdated or unknown) propID.
Finally, note than more than one reason codes can be used to specify an error status; for example, a client as a response to proposal suggestion by the server could return SRY-DU to indicate some requested data is not available, and ERR-IF to indicate that some part of the proposal was syntactically incorrect too:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=14
14-status: SRY-DU
14-status: ERR-IF
14-propID: 94df1293c1p8
14-proposal: http://www.privacy.org/newP3PProposal
...
[Content]
A limited version of the P3P protocol may be executed without using the HTTP header extension mechanism. Instead, servers may serve HTML content with embedded LINK tags that indicate the location of relevant P3P proposals. This limited protocol requires a P3P-aware client, but does not require a P3P-aware server (content may be modified to include the embedded link tags without requiring any changes to the way the server operates).
A service that uses the limited protocol may declare that it will abide by a given P3P proposal by embedding a LINK tag of the following form in the <HEAD> area of an HTML document:
<LINK rel="p3p:propID" href="URI">
URI indicates the location of the P3P proposal and "p3p:propID" is a relation name used to distinguish this special P3P link and to encode the propID of the proposal. For example, if a proposal at http://www.privacy.org/P3PProposal has propID x3tYwafhfKSqGV0Q+eSOZw==, we would use <LINK rel="p3p:x3tYwafhfKSqGV0Q+eSOZw==" href="http://www.privacy.org/P3PProposal">.
P3P-compliant clients MUST search for such LINK tags whenever they make a request that results in the return of HTML content without the inclusion of propID and proposal headers. In addition, P3P-compliant clients MAY search for LINK tags embedded in HTML content at any time. If a client finds a P3P LINK tag in addition to propID and proposal headers in the same document, it should consider them to reference multiple alternative proposals.
The limited protocol is not suitable for services that wish to use P3P methods for data collection, offer a choice of proposals, or require explicit agreement to proposals.
The following is an example of how interactions between P3P-compliant clients and non-P3P-compliant servers will typically proceed. Examples of client and server actions are shown in the shaded boxes.
1. Client requests resource using GET or POST or whatever method it pleases. Client also sends P3P extension header to indicate that it is P3P-enabled.
GET coolstore.com/index.html HTTP/1.1 Host: coolstore.com Opt: "http://www.w3.org/TR/WD-P3P/" |
2. Server is not P3P enabled so it ignores the P3P extension header (unless it is a mandatory extension and/or the server is not extension enabled, in which case the server reports back that it is not P3P enabled) and sends the requested content.
3. Client checks the returned content for an embedded link tag with attribute rel="p3p:propID". If no such link tag exists and the requested resource is not in a realm with which the client already has an agreement, the client can assume there is no P3P proposal available and behaves accordingly. If the link tag does exist, the client may fetch the proposal by issuing a GET request to the URI indicated by the href attribute of the link tag, evaluate the proposal, and act according.
Note, in all cases the appropriate behavior after evaluating a proposal and/or determining that no proposal exists depends on the user's preferences and how the client is configured. Clients may proceed with a request, display information, prompt the user, or take some other action.
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, via a web form, your gender and (optionally) your home address to customize our entry catalog pages 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
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retentionWe collect:
dynamic.cookies
user.gender
user.home. (optional)
For purpose: Customization of the site to individuals, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
Consequence: A site with clothes you would appreciateWe collect:
dynamic.clickstream.server
dynamic.http.useragent
For purpose: Web site and system administration, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
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="none" retention="yes" change_agreement="yes"/> <USES> <STATEMENT VOC:id="nonid"> <CONSQ v="a site with clothes you would appreciate"/>
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="uniqueid"/>
<VOC:PURPOSE v="financial"/> <DATA:REF name="dynamic.cookies" source="service"/> <DATA:REF name="user.gender" source="matched-form"/> <DATA:REF name="user.home." optional="yes" source="matched-form"/> </STATEMENT> </USES> <USES> <STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="admin"/>
<VOC:PURPOSE v="develop"/> <DATA:REF name="dynamic.clickstream.server" source="service"/> <DATA:REF name="dynamic.http.useragent" source="service"/> </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"` " entity=" quoted-URI ">" 1*statement-block disclosure [assurance] 1*realm `</PROP>` |
| [3] | realm |
= |
"<REALM" " uri=" quoted-URI "/>" |
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" [STATE] the domain of the server.
Each URI may name a specific resource or a set of resources qualified by the URI. In the HTTP URI scheme, a URI ending in "/" references the file system tree below that path (for example, http://www.w3.org/P3P/" would apply to "http://www.w3.org/P3P/foo/schema.html" as well); on the other hand, a URI that does not end in "/" would apply only to that specific resource (for example, "http://www.w3.org/P3P/data.html" wot apply to "http://www.w3.org/P3P/foo/schema.html").
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 [5] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [4] | disclosure |
= |
"<VOC:DISCLOSURE" " discuri=" quoted-URI " access=" `"` access-disclosure `"` [" retention=" `"` yesno `"`] |
| [5] | access-disclosure |
= |
"nonident" | ; Identifiable Data is Not Used "contact" | ; Identifiable Contact Information "other" | ; Other Identifiable Information |
| [6] | yesno |
= |
"yes" | "no" |
| [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 assurance services, specified via multiple occurrences of ASSURANCE.
If a website links to a P3P proposal, the website is stating that it is willing to honor that proposal for any user agent that sends a reference to that proposal to the website in the header of its http requests.
If a website links to multiple P3P proposals, this means that the website is only bound by the P3P proposal that the user agent chooses out of the multiple proposals. The user agent signals that it has chosen a specific P3P proposal by sending a reference to that proposal in the headers.
A website is not bound by any P3P proposal if the user agent does not reference a P3P proposal in the headers of its requests, even if that website has only one P3P proposal. Therefore user agents that do not support p3p do not bind the website to any particular P3P proposal. Furthermore, the first request a user agent makes of a website is unlikely to be covered by any P3P proposals, since the user agent probably does not yet know what P3P proposal to reference in the headers of the request.
Websites with web servers that do not support p3p should avoid linking to multiple proposals, as the website probably has no way of determining which proposal the user agent has chosen. If, despite this advice, a website links to multiple proposals, the website is bound to somehow honor whichever proposal the user agent has selected, no matter what difficulty this places on the website.
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.
| [8] | TXD-msg |
= |
(`<RDF:RDF>` 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" |
| The values of [11-13] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [11] | purposevalue |
= |
"current" | ; Completion and Support of Current Activity
"admin" | ; Web Site and System Administration
"custom" | ; Customization of the Site to Individuals
"develop" | ; Research and Development
"contact" | ; Contacting Visitors for Marketing of Services or Products
"other" [" (" string ")"] ; Other Uses
|
| [12] | recipientvalue |
= |
"ours" | ; only ourselves and our agents "same" | ; organizations following our practices "other" | ; organizations following different practices "published" ; unrelated third parties or public forum |
| [13] | idvalue |
= |
"nonid" | ; non identifiable |
Multiple consequences can be indicated using multiple CONSQ elements, each with one of the consequences. This way, multi-lingual versions of the consequences can be encoded, using the xml:lang attribute.
| [14] | consequence |
= |
"<CONSQ v=" quoted-string [xml:lang= LanguageID ] "/>" |
xml:lang and its value type LanguageID are defined in the [XML] specification. |
|||
Multiple values can be indicated using multiple PURPOSE elements, each with one of the values.
| [15] | purpose |
= |
"<VOC:PURPOSE v=" `"` purposevalue `"` "/>" |
| The values of [16] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [16] | purposevalue |
= |
"current" | ; Completion and Support of Current Activity
"admin" | ; Web Site and System Administration
"custom" | ; Customization of the Site to Individuals
"develop" | ; Research and Development
"contact" | ; Contacting Visitors for Marketing of Services or Products
"other" [" (" string ")"] ; Other Uses
|
Multiple values can be indicated using multiple RECPNT elements, each with one of the values.
| [16] | recipient |
= |
"<VOC:RECPNT v=" `"` recipientvalue `"` "/>" |
| The values of [17] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [17] | recipientvalue |
= |
"ours" | ; only ourselves and our agents "same" | ; organizations following our practices "other" | ; organizations following different practices "published" ; unrelated third parties or public forum |
The following six attributes are only used when a new (not defined in the P3P [BASEDATA]) data element or set is referenced.
In addition, the namespace of REF can be overridden, using for example an in-line xmlns attribute, with an URI denoting the name of the data schema the data element/set specified in name belongs to. The default namespace of REF is declared in the PROP element, but it can be overridden using a local namespace declaration in a DATA:REF element.
| [18] | data-reference |
= |
"<DATA:REF" " name=" quoted-string " source=" `"` sourcevalue `"` [" optional=" yesno] [" value=" quoted-string] [" type=" quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" VOC:category=" category] [" short=" quoted-string] [" long=" quoted-string] [" size=" `"` number `"`] ; default is 0 (unlimited size) "/>" |
| [19] | sourcevalue |
= |
"service" | "agent" | "matched-form" | "extension" |
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.phone and collect them through a matched form, the service would send the following references inside a P3P proposal:
<DATA:REF name="user.home.city" source="matched-form"/>
<DATA:REF name="user.home.phone." optional="yes"
source="matched-form"/>
<DATA:REF name="user.business." source="matched-form"/>
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.city" value="Cambridge"/>
<DATA:REF name="user.home.phone.intcode" value="1"/>
<DATA:REF name="user.home.phone.loccode" value="617"/>
<DATA:REF name="user.business.street" value="254 Windsor
St."/>
<DATA:REF name="user.business.city" value="Cambridge"/>
... (the other values of user.business.) ...
In some cases, only some of the values in a data set could have a value (for example, the user could not have a home page, or a fax, or a middle name, etc.). That is to say, for some elements there can be no defined value at all in the user's repository: in such case, elements are said to have a null value. The way a client signals that an element has a null value is simply by omitting the corresponding DATA:REF reference. For example, if a client agrees to provide all the user's name information (user.name.), and then sends
<DATA:REF name="user.name.first." value="Sheila"/>
<DATA:REF name="user.name.last" value="Doherty"/>
<DATA:REF name="user.name.formatted" value="Sheila Doherty"/>
that means that in the user's repository all the other fields (prefix, suffix,
middle name, nickname) are not defined.
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:
<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 (the latter case is obtained by multiple <REF> elements referencing the same data but with different source's).
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).
In the current version of P3P, the following tokens are used to denote data categories:
| [20] | category |
= |
"physical" | ; Physical Contact Information "online" | ; Online Contact Information "uniqueid" | ; Unique Identifiers "financial" | ; Financial Account Identifiers "computer" | ; Computer Information "navigation" | ; Navigation and Click-stream Data "interactive" | ; Interactive Data "pref" | ; Preference Data "demograph" | ; Demographic and SocioEconomic Data "content" ; 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 [HARMV].
P3P uses categories to give users and user agents additional hints as to what type of information is requested from a services. While most data in the Base Data Set 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"). We will briefly describe both types of elements in the two sections below.
Most of the elements in the base data set are so called "fixed" data elements: they belong into one or at most two category classes. By assigning a category invariably to elements in the base data set, services and users 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 prevent their user agent from giving out any data element in a certain category.
When creating new data schemas (see the next section "Creating New Data Sets") for fixed data elements, schema creators have to explicitly enumerate the categories that these element belong to. For example:
<DATA:REF name="postal.street.line1" type="text"
short="Street Address, Line 1" VOC:category="physical" template="yes"/>
In case of multiple categories, multiple elements referencing the same data can be used, each with a different category). For example, in case we want to declare that the data elements in user.name. have both category "physical" and "demograph" we can use:
<DATA:REF name="user.name." type="personname."
short="User's Name" VOC:category="physical" template="yes" /><DATA:REF name="user.name." type="personname."
short="User's Name" VOC:category="demograph" template="yes" />
Please note that the category classes of fixed data elements can not be overridden, for example by writing rules or proposals that assign a different category to a known fixed base data element. User Agents MUST ignore such categories and instead use the original category (or set of categories) listed in the schema definition. User Agents CAN preferably alert the user that a fixed data element is used together with a non-standard category class.
Not all data elements in the base data set belong to a pre-determined category class. Some elements can contain information from a range of categories, depending on a particular situation. Such elements are called variable-category data elements (or "variable data element" for short). Although most variable data elements in the P3P Base Data Set are combined in the dynamic. element set, they can appear in any data set, even mixed with fixed-category data elements.
When creating a schema definition for such elements, schema authors MUST NOT list an explicit category attribute, otherwise the element becomes a fixed data element. For example when specifying the "Year" data type, which can take various categories depending on the situation (e.g. when used for a credit card expiration date vs. for a birth date), the following schema definition is used:
<DATA:REF name="date.year" type="number" size="6"
short="Year" template="yes"/> <!-- Variable Data Element -->
This allows new schema extensions that reference such variable-category data types to assign a specific category to derived elements, depending on their usage in that extension. For example, an E-commerce schema extension could thus define a credit card expiration date as follows:
<DATA:REF name="Card.ExpDate." type="date."
short="Card Expiration Date" VOC:category="financial" template="yes"/>
Under these conditions, the variable data type date. is assigned a fixed category Financial Account Identifiers when being used for specifiying a credit card expiration date. Please see the next section "Creating New Data Sets" for more information.
Note that while user preferences can list such variable data elements without any additional category information (effectively expressing preferences over any usage of this element), services MUST always explicitly specify the categories that apply to the usage of a variable data element in their particular proposal. This information has to appear as an attribute to the corresponding DATA:REF element listed in the proposal, for example as in:
<P3P:PROP>
...
<DATA:REF name="dynamic.cookies" VOC:category="uniqueid">
...
</P3P:PROP>
where a service declares that cookies are used for identifying the user at this site (i.e. category Unique Identifiers).
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 namespace of the corresponding REF element.
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:id="nonid">
<VOC:RECPNT v="ours"/> <VOC:PURPOSE v="contact"/> <DATA:REF name="car.model" type="text" short="Model" VOC:category="pref" size="63"/> <DATA:REF name="car.color" type="text" short="Color" VOC:category="pref" size="63"/> <DATA:REF name="car.built.year" type="number" short="ConstructionYear" VOC:category="pref" size="63"/> <DATA:REF name="car.built.where." type="postal." short="Construction Place" VOC:category="pref" 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="yes" (default is "no"), 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:id="nonid">
<VOC:RECPNT v="ours"/> <VOC:PURPOSE v="contact"/> <DATA:REF name="GenericModel.model" type="text" short="Model" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.color" type="text" short="Color" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.year" type="number" short="Construction Year" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.where." type="postal." short="Construction Place" template="yes" 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="service" 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.
In order to provide multilingual support for data schema files, a server can supply the right alternative based on the HTTP Accept-Language header.
P3P allows users to store frequently requested information, such as user name and postal address, in a client-side repository. While most data in the P3P Base Data Set [BASEDATA] (as well the majority of schema extensions) will most likely be stored in the repository, P3P also supports the use of non-repository data. Such data is either information that is never stored in a repository and has to be manually entered by the user every time the element is requested, or data that constitutes information which is dynamically created by the user agent or operating system, such as clickstream information or the browser identification string.
When creating new schema definitions, schema designers can either specify that user agents should try to create corresponding fields in the user's repository (thus facilitating repeated transmission of the information), or that the element is dynamic and should not be included in the repository. The following subsections explain those two concepts in more detail.
Any element in a schema definition is assumed to be part of the user's repository. Thus, a standard schema definition of a (fixed) repository element would look like this:
<DATA:REF name="personname.first" type="text"
short="First Name" VOC:category="physical" template="yes"/>
However, even though an element is part of the user repository, a P3P proposal could explicitly specify that it wants the user to manually enter it (for example through an HTML form), ignoring any available data in the repository:
<P3P:PROP>
...
<DATA:REF name="user.name.first" source="service">
...
</P3P:PROP>
Applications can of course still offer a repository-based auto-fill functionality, even though the site did not request any repository data. Also note that it is up to user agent implementations to decide what action to take when encountering a new repository-stored data schema. Some implementation could for example automatically add the element to the user's repository (with an empty value), others might want to prompt the user for a decision.
As explained before, attribute values set in data schema definitions can
not be overridden. Thus, in order to force a certain data element to always
be outside of the user repository, schema designers simply have
to set the source attribute to service:
<DATA:REF name="dynamic.clickstream.client"
short="Click-stream collected on the client"
type="boolean" source="service"
VOC:category="navigation" template="yes"/>
The above example ensures that dynamic.clickstream.server will
never become part of the user's repository, but is instead either manually
collected (for example through HTML forms) or implicitly transmitted as part
of the connection (which is the case for clickstream data). In either case,
a P3P user agent could (depending on the user's preferences) inform the user
about the collection of this data element and its terms, but would take no
further action for transmitting the 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:
The following individuals participated in the P3P Specification Working Group:
[fill in later]
The P3P Specification Working Group inherited most of the specification from previous P3P working groups. The Working Group would like to acknowledge the contributions of the members of these previous groups:
[fill in later]