Goals and Features

    P3P enables Web sites to express their privacy practices and enables users to exercise preferences over the release of personal information. P3P-compliant products will be able to inform users of site practices (in both machine- and human-readable formats), allow users delegate decisions to their computers when appropriate, and tailor users' relationships to specific sites. Sites whose practices are compatible with a user's preferences can, at the user's option, be accessed seamlessly. If the site practices and the user preferences are incompatible, users will be notified of a site's practices and have the opportunity to agree to those terms or other terms.

    The P3P specification provides mechanisms:

  1. To inform a user agent about a site's data collection and privacy practices.
  2. For a user agent and Web service to automatically negotiate contracts and to come to an agreement satisfactory to both parties; alternatively, for the user agent to notify the user and receive instructions from the user concerning proposed data exchanges.
  3. To exchange data when such exchange is authorized by the user and consistent with a user's preferences and any outstanding agreement.

    4. P3P can be incorporated into browsers, browser plug-ins, servers, or proxy servers that sit between a client and server.

Verification and Enforcement

    While the P3P1.0 specification provides a syntax for specifying proposals and a protocol and associated syntax for exchanging information between a Web site and user agent, it does not define how to verify the information of a P3P proposal nor does it provide a mechanism for enforcement in case of privacy violations. However, P3P will support future digital certificate and digital signature capabilities.

Technical Specification

    A P3P user agent communicates to Web servers using standard HTTP methods such as GET and POST [8] . P3P was designed to transport data between the agent and the service in the headers of a P3P HTTP extension 1 . When placing an initial request to a Web server, the user-agent may include the p3p-opt-header to notify the server that the user agent is P3P-compliant. If the user-agent sends this OPT header, and the server implements the P3P protocol, then the server must:

  1. Send the OPT header that indicates that it understands P3P.
  2. If it has a P3P proposal that covers the page in question, it MUST send it.

    3. The following section describes and explains the grammar of P3P. This grammar was taken from the current P3P working draft [5] . Because P3P is still in progress, changes to the P3P specification may be introduced as it advances toward recommendation 2 status.

P3P Grammar

    A P3P request is issued using HTTP, by adding the P3P information to the HTTP message header.

    [1] p3p-request = start-line

    *message-header

    "OPT" ":" p3p-opt-header CRLF

    [p3p-header-prefix "-P3P1.0: " p31*p3p-content CRLF]

    [message-body]

    ; start-line, message-header, CRLF, and

    ; message-body are as defined in the

    ; HTTP 1.1 specification [HTTP1.1].

    The following parts of the grammar 3 define the content of the P3P message header in a P3P request.

    [2] p3p-opt-header = p3p-extension ";" "ns-" p3p-header-prefix

    [3] p3p-extension = `"` "http://www.w3.org/.../" `"`

    [4] p3p-header-prefix = number

    [5] digit = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"

    [6] number = 1*digit

    [7] yesno = `"` ("0"|"1") `"` ; 0 = No, 1 = Yes

    p3p-content (8) 4 describes the four different kinds of messages the P3P content of a HTTP request can contain. A P3P proposal (19), which is usually sent by a Web server, describes a Web site's privacy policy regarding information obtained from users. The other message types are response messages to a P3P proposal. An OK-msg (9) or a SRY-msg (10) are used to agree or to reject a proposal respectively when no data needs to be sent back to the Web server. A TXD-msg (11) is sent as a response to an acceptable proposal which asks for data. The TXD-message contains the values for the required information elements. P3P uses the Extensible Markup Language (XML) [14] for the exchange of such messages.

    [8] p3p-content = OK-msg | PROP-msg | SRY-msg | TXD-msg

    [9] OK-msg = "<OK" message-attribute "/>"

    [10] SRY-msg = "<SRY"

    [" final=" yesno] ; default is 0 (No)

    message-attribute "/>"

    [11] TXD-msg = "<TXD" message-attribute ">" data-xfer "</TXD>"

    [12] message-attribute = agreementid-attribute | reason-attribute |

    data-hash-attribute

    [13] agreementid-attribute = " agreeID=" `"` agreement-id `"`

    [14] reason-attribute = " r=" `"` reason-code `"`

    [15] data-xfer = <XML formatted data element name-value pairs>

    [16] agreement-id = <base64 of 128 bit MD5 digest of

    proposal as per RFC 1864>

    [17] data-hash-attribute = " dh=" `"` <base64 of MD5 digest

    of data-xfer> `"`

    ; used to acknowledge the receipt of data

    [19] PROP-msg = `<P3P xmlns="http://www.w3.org/.../"

    xmlns:VOC="http://www.w3.org/.../vocab"

    xmlns:DATA="http://www.w3.org/.../basedata">`

    1*(short-proposal | long-proposal) `</P3P>`|

    (`<RDF:RDF

    xmlns:RDF="http://www.w3.org/TR/WD-rd f-syntax/">`

    `<P3P xmlns="http://www.w3.org/.../"

    xmlns:VOC="http://www.w3.org/.../vocab"

    xmlns:DATA="http://www.w3.org/.../basedata">`

    1*(short-proposal | long proposal )

    `</P3P>` `</RDF:RDF>`))

    [20] short-proposal = `<STATES><PROP `

    (("agreeID=" `"` quoted-string `"` ">") |

    ("propURI=" quoted-URI ">"))

    "</PROP></STATES>"

    [21] long-proposal = `<STATES><PROP`

    [" final=" yesno] ; default is 0 (No)

    [agreementid-attribute]

    [" agrexp=" `"` datetime `"`] ;default is six months

    " realm=" `"` URI *(" " URI) `"`

    " entity=" quoted-URI

    [" postURI=" quoted-URI]

    [" optional=" yesno] ;default is 0 (No)

    ">"

    1*statement-block

    disclosure

    1*assurance

    "</PROP></STATES>"

    [22] schemaURI = `"` "http://www.w3.org/.../ " `"`

    [23] quoted-string = `"` string `"`

    [24] string = <[UTF-8] string (with " and & escaped)>

    [25] quoted-URI = `"` URI `"';`

    [26] URI = <URI as per RFC 2068 [URI]>

    [27] datetime = <date/time as per section 3.3 of RFC 2068>

    Inside a P3P proposal a Web site (or a P3P agent) can define which information elements are covered by the proposal as well as the respective terms and conditions for each element. Such information elements are called data references (see grammar element 37, data-reference).

    [28] statement-block = "<USES>"

    "<STATEMENT"

    [" action=" `"` action `"`]

    " VOC:purp=" `"` purpose *("," purpose) `"`

    " VOC:recpnt=" `"` recipients

    *("," recipients) `"`

    " VOC:id=" yesno

    [" consq=" quoted-string]

    [" source=" `"` ("agent"|"form"|URI) `"`]

    ; default is agent

    ">"

    *(datablock)

    "</STATEMENT>"

    "</USES>"

    [29] action = ("r" | "rw") ; r=read, rw=read&write, default is read

    [30] 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

    [31] recipient = "0" | ; only ourselves and our agents

    "1" | ; organizations following our practices

    "2" | ; organizations following different practices

    "3" ; unrelated third parties or public forum

    [32] id = yesno

    A proposal can contain more information than just the terms and conditions. The following grammar elements define assurance and disclosure statements. The assurance statement (36) describes a service that attests that the entity will abide by its proposal and follow certain guidelines or assertions in the processing of data. A disclosure statement (33) offers information regarding service access capabilities, how long data is retained, and whether the entity makes disclosures regarding changing the agreement for data already collected.

    [33] disclosure = "<VOC:DISCLOSURE"

    " discURI=" quoted-URI

    " access=" `"` access-disclosure `"`

    [" other=" `"`

    other-disclosure *("," other-disclosure) `"`]

    "/>"

    [34] access-disclosure = "0" | ; Identifiable Data is Not Used

    "1" | ; Identifiable Contact Information

    "2" | ; Other Identifiable Information

    "3" | ; None

    [36] assurance = "<ASSURANCE"

    " service=" quoted-URI

    [" text=" quoted-string]

    [" image=" quoted-URI

    [" width=" `"` number `"`]

    [" height=" `"` number `"`]

    [" alt=" quoted-string] ]

    "/>"

    [35] other-disclosure = "0" | ; change agreement

    "1" ; retention

    The last three grammar definitions describe the structure of referencing information elements. A Web site that requests information with a P3P proposal lists the respective data references 5 in the proposal.

    [37] data-reference = "<DATA:REF" " name=" quoted-string

    [" xmlns:DATA=" quoted-URI]

    [" optional=" yesno]

    [" value=" quoted-string]

    [" type="quoted-string]

    [" typeschema=" quoted-URI]

    [" template=" yesno]

    [" VOC:category=" categories]

    [" short=" quoted-string]

    [" long=" quoted-string]

    [" size=" `"` number `"`]

    ; default is 0 (unlimited size)

    [" ext=" quoted-URI]

    "/>"

    [38] datablock = *datareference |

    ( *datareference

    "<WITH><DATA:PREFIX" " name=" quoted-string

    [" xmlns:DATA=" quoted-string]

    [" optional=" quoted-string]

    [" value=" quoted-string]

    [" type=" quoted-string]

    [" typeschema=" quoted-string]

    [" template=" yesno]

    [" VOC:category=" quoted-string]

    [" short=" quoted-string]

    [" long=" quoted-string]

    ">"

    datablock

    "</DATA:PREFIX></WITH>"

    datablock )

    [39] categories = `"` *(number ",") number `"`

Sample P3P Transaction

    This scenario was taken from the latest public P3P working draft, which is available at W3C's P3P Web site [5] . This line flow scenario describes a user who directs his Web browser for the first time to the home page of CoolCatalog. When he requests CoolCatalog's home page, his browser indicates that it understands P3P.

    The initial request from the user's browser to the Web site will look like:

    P3P Transaction: Initial P3P request (user agent).

    GET / HTTP/1.1

    Accept: */*

    User-Agent: BugblatterBeast/3.02 (RT-11; English)

    Host: www.CoolCatalog.com

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-42

    The CoolCatalog Web site receives this request and recognizes that the visitor is using a P3P-compliant browser. CoolCatalog responds by sending a proposal that includes information about the site's privacy practices and disclosures. It also requests an identifier (PUID) and the user's gender in order to be able to personalize the content of the Web site to the user 6 :

    P3P Transaction: First P3P proposal (server).

    HTTP/1.1 409 Agreement required

    Server: Marvin/2.0.1

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1944

    1944-P3P1.0:

    <P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/"

    xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"

    xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">

    <STATES>

    <PROP realm="http://www.CoolCatalog.com/"

    entity="http://www.CoolCatalog.com" >

    <USES>

    <STATEMENT VOC:purp="2" VOC:id="0" VOC:recpnt="0"

    consq="a personalized site!"/>

    <DATA:REF name="Web.PUID"/>

    <DATA:REF name="User.Gender"/>

    </STATEMENT>

    </USES>

    <VOC:DISCLOSURE

    text="http://www.CoolCatalog.com/PrivacyPractice.html"

    access="3" other="0,1"/>

    <ASSURANCE org="http://www.TrustUs.org"

    text="third party" image="http://www.TrustUs.org/Logo.gif"/>

    </PROP>

    </STATES>

    </P3P>

    Content-Type: text/html

    Content-Length: 110

    <html><body>

    <h1>HTTP/1.1 409 Agreement Required</h1>

    <p>We need an agreement before we can continue.</p>

    </body></html>

    The user's browser receives the proposal as the first response from CoolCatalog. The browser's P3P agent rejects this proposal 7 and sends a sorry message back to CoolCatalog.

    P3P Transaction: Sorry message (user agent).

    GET / HTTP/1.1

    Accept: */*

    User-Agent: BugblatterBeast/3.02 (RT-11; English)

    Host: www.CoolCatalog.com

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/ "; ns-1776

    1776-P3P: <SRY r="R-3" agreeID="e3a5d71297d1" />

    CoolCatalog's Web site receives the user's sorry message and decides to send another proposal. This time the site requests an automatic return identifier and the user's name and age (optional), both for the purpose of customizing the site.

    P3P Transaction: Second P3P proposal (server).

    HTTP/1.1 409 Agreement required

    Server: Marvin/2.0.1

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1492

    1492-P3P1.0:

    <P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/"

    xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"

    xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">

    <STATES>

    <PROP realm="http://www.CoolCatalog.com/"

    entity="http://www.CoolCatalog.com" >

    <USES>

    <STATEMENT VOC:purp="2" VOC:id="0" consq="a personalized site!">

    <WITH><DATA:PREFIX name="User.">

    <DATA:REF name="Name.First"/>

    <DATA:REF name="Bdate.Year" optional="1"/>

    </DATA:PREFIX></WITH>

    <DATA:REF name="Web.PUID"/>

    </STATEMENT>

    </USES>

    <VOC:DISCLOSURE

    text="http://www.CoolCatalog.com/PrivacyPractice.html"

    access="3" other="0,1"/>

    <ASSURANCE org="http://www.TrustUs.org"

    text="third party" image="http://www.TrustUs.org/Logo.gif"/>

    </PROP>

    </STATES>

    </P3P>

    Content-Type: text/html

    Content-Length: 110

    <html><body>

    <h1>HTTP/1.1 409 Agreement Required</h1>

    <p>We need an agreement before we can continue.</p>

    </body></html>

    This time, the user's P3P agent accepts the proposal and delivers the requested data (except the user's age which was optional) in a TXD message.

    P3P Transaction: Txd message (user agent).

    GET / HTTP/1.1

    Accept: */*

    User-Agent: BugblatterBeast/3.02 (RT-11; English)

    Host: www.CoolCatalog.com

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1861

    1861-P3P1.0: <TXD r="S-0" agreeID="94df1293a3e5" >

    <DATA:REF VOC:purp="2" name="User.Name.First" value="Joseph"/>

    <DATA:REF VOC:purp="2" name="User.PUID" value="1234567"/>

    </TXD>

    At this point, both the server and the user are satisfied and the CoolCatalog Web site sends back its home page:

    P3P Transaction: Ok message (server).

    HTTP/1.1 200 OK

    Server: Marvin/2.0.1

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1950

    1950-P3P: <OK DH="s24fd20kuqexg5xk" />

    Content-Type: text/html

    Content-Length: xxx

    [content of the CoolCatalog homepage]

    On subsequent visits to CoolCatalog, the user agent can automatically provide the required data on the user's initial request. Again, the user's name and the identifier are sent in a TXD message which refers to the proposal that the user and CoolCatalog had previously agreed on:

    P3P Transaction: Return to Web site using a Txd message (user agent).

    GET / HTTP/1.1

    Accept: */*

    User-Agent: BugblatterBeast/3.02 (RT-11; English)

    Host: www.CoolCatalog.com

    OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/ "; ns-2001

    2001-P3P: <TXD agreeID="94df1293a3e5" >

    <DATA:REF name="User.PUID" value="1234567"/>

    <DATA:REF VOC:purp="2" name="User.Name.First" value="Joseph"/>

    </TXD>

    The service then responds by sending the homepage as shown above.

1. There might be instances in which the content of P3P data could exceed the expected length of a header in some HTTP implementations. Hence, P3P implementations should be able to conform to other methods of exchange. Those methods are likely to be within the HTTP extension header, at a specified URI that a client or server then obtains with a HTTP GET request, or as part of the content of a XML or HTML page.

2. W3C working groups, such as the P3P working group, produce specifications in the form of working drafts. Eventually, a working draft may be put forward to the W3C membership as a proposed recommendation. After an advisory vote by the membership, the W3C Director may issue the proposal as a recommendation [4] .

3. The grammar as presented in this document uses the Augmented Backus-Naur Form (ABNF) notation, which is specified in RFC 2234. Because of limited space and for clarity reasons , the text string "..." was used as a replacement for the string TR/1998/WD-P3P-19981109.

4. Numbers in parenthesis (8) refer to the grammar element with the same number.

5. More information about data references can be found in the P3P Base Data Set, available at the W3C Web site [15] .

6. The proposal was split across multiple lines for readability; over the network, a carriage-return line-feed (CRLF) pair would be added only after the </P3P> element. Multiple lines are also used in the following P3P code samples.

7. "e3a5d71297d104f1" is used as the agreementID (hash) of CoolCatalogs first proposal.

April 9, 1999 · Jörg Meyer · jmeyer@almaden.ibm.com