W3C WD-P3P-19981109/syntax

 

 

Platform for Privacy Preferences (P3P1.0)
Syntax Specification

W3C Working Draft 9-November-1998

 

This Version 
http://www.w3.org/TR/1998/WD-P3P-19981109/syntax
Latest Version: 
http://www.w3.org/TR/WD-P3P/syntax
Previous Version: 
http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/
Editors 
Massimo Marchiori, W3C (massimo@w3.org)
Dan Jaye, Engagetech (djaye@engagetech.com)

Status of This Document 

This is a subspecification of the P3P1.0 specification for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and will eventually be advanced toward W3C Recommendation status. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." The underlying concepts of the draft are fairly stable and we encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document.

This draft document will be considered by W3C and its members according to W3C process. This document is made public for the purpose of receiving comments that inform the W3C membership and staff on issues likely to affect the implementation, acceptance, and adoption of P3P.

Send comments to www-p3p-public-comments@w3.org (archived at http://lists.w3.org/Archives/Public/www-p3p-public-comments/).

___

Copyright ©  1998 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Index

  1. Introduction
    1. Problem space
    2. About this specification
    3. Conformance requirements
    4. Operational description and design
    5. Terminology
    6. Assumptions
  2. Agreement scenarios
    1. No existing agreement, site sends proposal and requests PUID
    2. Existing realm agreement
    3. Existing realm agreement, new proposal
    4. Service wants data from client repository
  3. Transport, primitives and reason codes
    1. Data transport
    2. P3P requests
    3. Negotiation primitives
      1. Success (OK)
      2. Here's A Proposal (PROP)
      3. Sorry (SRY)
      4. Transmit Data (TXD)
      5. Ending negotiation with final
      6. Syntax of negotiation primitives
    4. Reason codes definition
      1. Success codes
      2. Rejection codes
      3. Error codes
  4. P3P markup and processing
    1. Example proposal
      1. English language proposal
      2. XML/RDF encoding
    2. Proposals
      1. Proposal structure: the PROP element:
      2. Processing Realms and URI's
      3. Soliciting user info: the source attribute
      4. Attesting to a proposal: the ASSURANCE element:
    3. Statements
      1. Privacy statements: the STATEMENT element
      2. General disclosures: the VOC:DISCLOSURE element
    4. Data References
      1. Referencing data: the REF element
      2. Prefixing references: the <WITH><PREFIX> elements
      3. Describing references: the category attribute
      4. Client side writes: the action attribute
      5. Unambiguous optional elements and purposes
      6. Creating new data sets
        1. Data definition
        2. Data schema format
  5. Appendices
    Appendix 1: References (Normative)
    Appendix 2: Fingerprints and Canonicalization (Normative)
    Appendix 3: Line-flow Scenario (Non-normative)
    Appendix 4: ABNF Notation (Non-normative)
    Appendix 5: Working Group Contributors (Non-normative)


1. Introduction

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.

1.1 Problem space

The P3P specification provides mechanisms:

While P3P provides mechanisms to address this problem spaces, not all all implementations must support all specified operations and features. [see next section]

1.2 About this specification

This document, its chapters, and its normative references, includes all the specification necessary for the implementation of interoperable P3P applications. This specification was built upon the work of previous working groups and includes:

  1. Protocol primitives.
  2. Protocol schemas, including the privacy practice vocabularies of the proposal.
  3. Protocol syntax and encoding, including the data structures and formats.

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 chapter:

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab

The detailed syntax and datatypes of the base data set is found in the chapter

http://www.w3.org/TR/1998/WD-P3P-19981109/basedata

Note, that while use of this 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:

The ABNF notation used in this specification is specified in RFC2234 and summarized in Appendix 3.

1.3 Conformance requirements

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 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.

This 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.

To address this, conformance is separated into 3 levels as described below, where each level is inclusive of the previous:

  1. Level 1: Implementations will be protocol interoperable with any other level, contain the basic concepts of P3P and the a "privacy notification" feature set.
  2. Level 2: Implementations support data exchange.
  3. Level 3: Implementations support P3P cookie replacement mechanisms, multiple encoding and transport methods, as well as extensible (external to the base) data sets.

For an implementation to be of a level, it must support ALL of the features/operations listed, including the previous levels:

Level 1: The Privacy Notifier
a useful privacy friendly practice notifer, appropriate and useful, for example, to children.
Section Feature/Operation Explanation

2.0 Agreement scenarios

propID propID uniquely identifies any privacy proposal

3.1 Data transport

the HTML LINK tag agents and services must be able to locate a proposal in this location
  the HTTP extension mechanism agents and services must be able to locate a proposal in this location
  propURI a proposal must be able to be located at an external URI

4.1.2 XML/RDF encoding

XML parsing 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.
4.4 Data References data reference syntax agents must be able to understand that syntax of solicited information
Base 3.0 Abstract Elements abstract elements methods of references data exchanged through mechanisms other than P3P
Harmonized Vocab harmonized vocabulary see the harmonized vocubarly for requirements; they must be followed otherwise the implementation abuses consensus on adequate levels of privacy disclosure
Level 2: Privacy and Information Agent
an agent which has the capability to remember user profiles and privacy agreements to assist users in managing relationships to sites which have acceptable practices.
2.0 Agreement scenarios propID repository full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists.
  data repository frequently requested user profile information is stored and managed by the user.
3.3 Negotiation primitives protocol primitives (OK,SRY, PROP, TXD) negotiation, multiple proposals, and counter proposals are acceptable.
3.4 Reason Codes S-?, R-?, E-? 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.
  postCGI information is returned (by a P3P or HTML agent) by CGI methods

 

Level 3: Sophisticated P3P Agent
an agent implementing the full capabilities of P3P.
2 Agreement Scenarios PUID/TUID Efficient anonymous clickstream tracking under P3P control.
3.1 Data Transport XML encoded data through HTTP and postURI data may be returned as XML data in the header or at a specified URI
4.4.1 Data Definitions new schema instantiation schemas other than the base set can be instantiated and supported by the agent.
4.2.4 source attribute source attribute agents support multiple, extensible mechanisms by which information is solicited.
  client access DOM ?

Note, that the following key words are used throughout the document and should be read as interoperability requirements for Level 1. The words are used as defined in RFC2119 [KEY] for defining the significance of each particular requirement. These words are:

MUST
This word or the adjective "required" means that the item is an absolute requirement of the specification.
SHOULD
This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course for a Level 1 implementation.
MAY
This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item for a Level 1 implementation.

An implementation is not Level 1 compliant if it fails to satisfy one or more of the MUST requirements it implements.

1.4 Operational description and design

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.

When privacy practices do not match the user's preferences, the two sides can come to an agreement by exchanging alternative 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. We expect user agents will record the agreements reached, indexed by a fingerprint of the agreement, called the agreementID.

Rather than sending a new proposal to the user agent on every contact, a site may send the agreementID 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.

Sites also have the capability, as part of their proposal, to request that a Temporary or Pairwise Unique ID (TUID/PUID) be automatically sent to the site when the user agent returns. A PUID is similar to a cookie but under P3P control and limited to a numerical field.

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.

1.5 Terminology

Assuring Party
Within P3P, an assuring party is a legal entity (person or organization) that makes a statement of assurance about a proposal (e.g. that practices are audited, or are in compliance with certain data collection guidelines). Assurance may come from the service itself or from an independent third party. The assuring party must identify what it is attesting to as part of the assurance statement within the proposal, at a specified URI, or as part of the semantic definition of a meta-data schema.
Agreement
A proposal to which both the service and user agent agree. This agreement is applied within the realm and is often represented by a an agreementID. The non-repudiability of such agreements will be strengthened by the support of certificate and digital signature capabilities in future versions of P3P; however this is not specified in version 1.0. We do provide the appropriate fields for the inclusion of such tokens within P3P1.0 (e.g. a digital signature from the assuring party.)
AgreementID
A small unit of information that indicates both parties have agreed on a common proposal. An agreementID is the fingerprint of an accepted proposal. The presence of the agreementID in the P3P headers is the definitive declaration of which agreements are in effect for a given realm.
Data Element
An individual data entity, such as last name or phone number. For interoperability, P3P 1.0 specifies a base set of data elements.
Data Category
A significant attribute of a data element or data set that may be used by a trust engine to determine what type of element is under discussion, such as "Contact Information." P3P 1.0 specifies 10 base data categories.
Data Set
A known grouping of data element, such as such as "User.Home.Postal.". A set is represented with a trailing period. P3P 1.0 specifies a number of base data sets.
Fingerprint (Hash, Digest)
A fixed size value resulting from the application of a hash function to a set of data. Fingerprints are easily computed, but even small modifications to the original information result in a virtually unpredictable value. Consequently, fingerprints are often used as a key to entries in a table or databases, or as methods of assuring information integrity. We use the [MD5] digest algorithm for P3P fingerprints. This yields a 128-bit value that will be encoded and exchanged in P3P communications.
Preference
A rule, or set of rules, that determines what action(s) a user agent will take or allow when involved in a conversation or negotiation with a service. A preference might be expressed as a formally defined computable statement (e.g., the APPEL preference exchange language). In this document, preferences govern the types of agreements that can be reached between a user agent and a service.
Proposal
A proposal is a collection of one or more privacy statements together with information asserting the identity, URI, assurances, and disclosures of the service covered by the proposal. A proposal is always created from the point of view of the service and contains identifying information for the service, but it may be created by the user and sent to the server for approval.
PUID
PUID := hash(UUID(Realm, agreementID)). The PUID is an optional way for the user to identify herself to a service under a particular agreement over an extended period of time. PUIDs directly correspond to a specific realm and agreement. PUIDs are sent within the P3P header as part of the ReturnID with any GET request.
Realm
The realm is the experience space from which requests under a given agreement may be issued -- it broadly defines the area to which a proposal applies.   It is referenced by one or more URIs. The definitive declaration of which agreements are in effect for a given URI is determined by the presence of agreementIDs. Each URI may name a specific resource or a set of resources qualified by the URI. For instance, in the HTTP URI scheme, a URI ending with an object (home.html) applies to that specific object, a URI that is a path http://www.w3.org/P3P/   references the file system tree below that path.   If the proposal is not digitally signed, then each of the URIs must be from a domain that domain-matches the origin server. Domain matching is covered in the HTTP state management mechanism internet draft [STATE].
Repository
A mechanism for storing user information under the control of P3P.
ReturnID
ReturnID = (agreementID, [PUID], [TUID]), where PUID and TUID are optionally returned.
Service
A program that issues proposals and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent.
Statement
A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements, sets, and categories. The enumerated elements act as an embedded data request. A statement which references no data, requests no data.
TUID
TUID := hash(UUID(session salt)) A temporary ID generated by the user agent that is returned to a service for the duration of one session. A new TUID should be generated for every session at every service. If a service wants a persistent ID across sessions, they should request a PUID.
URI
A Uniform Resource Identifier used to identify Web resources. For definitive information on URI syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," (which replaces RFCs 1738 and RFC 1808). This document refers to the following URIs:
propURI: URI at which a proposal may be fetched.
postURI: URI which information may be transmitted to.
discURI: URI of the complete natural language privacy statement of the proposal.
User Agent
A program whose sole purpose is to mediate interactions with services on behalf of the user under the user's preferences. A user may have more than one user agent, and agents need not reside on the user's desktop, but any agent must be controlled by and act on behalf of only the user. The trust relationship between a user and her agent may be governed by constraints outside of P3P. For instance, an agent may be trusted as a part of the user's operating system or Web client, or as a part of the terms and conditions of a ISP or privacy proxy.
UUID
A mechanism used for creating PUIDs and TUIDs. UUID is specified by [UUID]. P3P does not specify a method for soliciting UUIDs.

1.6 Assumptions

P3P makes several assumptions about the environment in which it works and the problem it is trying to solve.

  1. P3P allows a service to include identifying information about itself in its proposals. Since the registered owner of a domain name may not correspond to the entity responsible for a service, this information MUST be provided.
  2. Strong non-repudiable evidence of identities and agreements will be provided by future versions of the protocol. At this time, no clear/dominant PKI model exists for use in P3P. In the future both users and services may require signatures and certificates.
  3. We assume that communication security is achieved through means other than P3P itself [SSL]. Hence, P3P does not provide mechanisms for cryptographically protecting information in storage or transit.
  4. P3P agreements are end-to-end: between the user and the service. Intermediaries such as telecommunication providers, internet service providers, proxies and others may be privy to the exchange of data between a service and a user but those practices are not included in the agreement between the end parties.
  5. While P3P can make profitable use of the protocol extension features [MANDA], which are based on [HTTP1.1], P3P should be able to work with [HTTP1.0] servers/proxies. In fact, XML proposals and data may be exchanged through any transport method. However, we only specify functionality deriving from returnIDs (agreementIDs when using multiple purposes; PUIDs and TUIDs for clickstream) when present in HTTP.
  6. P3P covers all data generated or exchanged via HTTP.

2. Agreement scenarios

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 proposals, or one in which a series of proposals and/or counter-proposals are exchanged between the site and the user. 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 PUID Requested Data Requested Data Written
1 No Yes Yes - -
2 Yes No No - -
3 Yes Yes Yes - -
4 - - - Yes No
5 - - - Yes Yes

Scenario 1) No existing agreement, site sends proposal and requests PUID

  1. User goes to the home page of CoolCatalog (CoolCatalog/*), she has never been there before but is P3P-compliant.
  2. CoolCatalog makes a proposal, including privacy practices, disclosures, and the data elements to which they apply. In this instance, the service asks to be automatically given the PUID as part of the returnID in the future.
  3. User agrees to proposal, and agrees to send the PUID in the returnID on all future requests to the realm specified in the proposal.
Protocol Scenario: Client sends OPT header (see [MANDA]) to server.  If server does not support P3P, it will merely return content. (This content could be a HTML form which transfers information to a server using traditional CGI methods.) If the server supports P3P and has a relevant proposal, server shall return 409 with content and a proposal for P3P clients in a header, HTML header, or as referenced by a URI.

Scenario 2) Existing realm agreement

  1. User has previously done scenario 1.
  2. User returns to CoolCatalog and -- following the existing agreement -- furnishes the returnID on all page requests in the realm of the agreement.
Protocol Scenario: Client sends OPT header to server, and all relevant returnIDs. Server returns relevant content or (orthogonally) can send subsequent P3P data-requests (TXD with agreementID).

Scenario 3) Existing realm agreement, new proposal

  1. User has previously completed scenario 1.
  2. User returns to CoolCatalog and furnishes returnID of Agreement(1) on all page requests.
  3. User goes to order page on CoolCatalog (CoolCatalog/Order/*) and sends returnID of Agreement(1) and the service makes a new proposal because its policies at the order page differ from the rest of the site. In this instance, it wants actual order information.
  4. The user considers the new proposal. We consider two cases, differing on whether a new PUID (as part of a returnID) is requested.

Scenario 4) Service wants data from client repository

Scenario 5) Client write information to service

Protocol Scenario: scenario 5 is an extension of scenario 4 which assumes that scenario 4 ended with the user agent sending an OK and optionally a TXD to the server. Now the server will reply with its own TXD sending the appropriate data elements to the client. If successful the user agent will respond with an OK/S-0 reason code; if unsuccessful the client will respond with SRY/E-0 reason code.

3. Transport, primitives and reason codes

The following section specifies primitives necessary for forming an agreement and transferring any subsequent data if appropriate.

3.1 Data transport

P3P was designed to exchange the primitives and their content in the headers of a P3P HTTP extension. However, we foresee instances in which the content of the PROP or TXD primitives could exceed the expected length of a header in some HTTP implementations (e.g. a large graphical image). Hence, as an application of RDF/XML, P3P implementations should be able to conform to methods of RDF/XML exchange when those methods are completely specified. Those methods are likely to be:

  1. Within the HTTP extension header.
  2. At a specified URI that a client or server then obtains with a HTTP GET request.
  3. As part of the content of a XML or HTML page; if HTML, it should not be rendered by older implementations.

P3P1.0 implementations MUST support each of methods 1-3; we illustrate them by means of scenarios.

The following table summarizes the features of each scenario, whether or not it uses propURI, postURI. and whether or not the proposal is embedded in content.

Scenario Proposal-URI Post-URI Proposal Embedded in Content
6 Yes - No
7 No - Yes
8 - Yes -

Also, please see the note at the description of the source attribute regarding how information is exchanged.

Scenario 6) Service references proposal at URI

The service believes that an intermediary proxy cache might truncate long HTTP headers, or the service would like its proposal to be cached at a proxy:

  1. User sends GET to service and requests proposal.
  2. Service sends prop-message with the propURI.
    <PROP agreeID="94df1293a3e5"
    propURI="http://www.CoolCatalog.com/P3P.RDF" />
  3. User sends GET to the propURI.
  4. The service at the propURI sends the proposal.

The propURI is not relevant to the definition of the realm. Rather, implementations which need to make trust decisions on the basis of the realm should make them with respect to the realm defined in the proposal, and the original URI they fetched in scenario 1.

Scenario 7) Service references proposal in HTML content

Content providers may wish to declare simple privacy practices without sending modified HTTP headers. In such a case, sites MAY embed a reference to a P3P proposal within the HTML  HEAD tag. This is accomplished by using the HTML LINK tag in the following way:

<LINK rel="p3p-prop" href="URI" ?agreeID=""?>

Here, URI points to the P3P proposal, and p3p-prop is the relation name used to distinguish this special P3P link.

Note that only a single proposal may be made for any realm. No overlapping proposals are permitted.

Consequently,

  1. User sends GET to service and requests a proposal through the presence of the optional header.
  2. Service returns content without header.
  3. User agent MUST examine the HEAD tag of the HTML-content looking for a LINK relationship with the p3p-prop relation.
  4. Upon finding such a header, it would fetch the proposal from the URI.

Note: This may increase the latency of fetching a proposal since it must now be sought in the content. However, such proposals can be cahced. 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.

Scenario 8) Client posts information to a URI

The service requests a large binary file, or prefers to process data as it did with forms/CGI and wishes to have that information presented using POST.

  1. User sends GET to service and requests proposal.
  2. Service sends a proposal that includes a postURI.
  3. User posts RDF/XML encoded information at the postURI.

The postURI is an implicit part of the realm. Consequently, information may be posted to the provided postURI under an agreementID even if the URI is not within the realm-URI.

3.2 P3P requests

The user agent communicates to the server using standard HTTP methods such as "GET" or "POST". P3P uses the mandatory extension mechanism [MANDA] for transporting data between the agent and service. When placing an initial request to the 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 the OPT header, and the server implements the P3P protocol, then it MUST:

  1. Send the OPT header that indicates that it understands P3P.
  2. If it has a proposal that covers the page in question, it MUST send it.
[1] p3p-request = start-line 
*message-header 
"OPT" ":" p3p-opt-header CRLF 
[p3p-header-prefix "-P3P1.0: " 1*p3p-content CRLF] 
[message-body] 

; start-line, message-header, CRLF, and  
; message-body are as defined in the  
; HTTP 1.1 specification [HTTP1.1]. 

[2]
p3p-opt-header
=
p3p-extension ";" "ns-" p3p-header-prefix
[3]
p3p-extension
=
`"` "http://www.w3.org/TR/1998/WD-P3P-19981109/" `"`
[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

3.3 Negotiation primitives

The following table summarizes the meaning of the P3P primitives as well as their relations, content, and HTTP return codes. All primitives MUST be supported and may be sent by a service or agent.

Message  Meaning  After Receiving  Expected Response  Data in Message  Optional in Message  HTTP Return Code
OK Proposal acceptable or data transfer successful PROP or TXD none MD5 hash of agreement or data transferred   2xx
PROP Here's a Proposal Any time OK, SRY, or PROP Text of a proposal Signature of initiator, fingerprint of previous Proposal 409
SRY Sorry - request not processed PROP, TXD PROP or none Reason code and MD5 hash of proposal or data transferred Which practices are unacceptable 409
TXD Transfer Data Any time none, OK or SRY Data element names and values to be written, as requested Agreement 2xx

This section describes each of the operations and specifies who (user or service) can initiate the action and under what circumstances.

3.3.1 Success (OK)

This message is sent when a participant agrees to a proposal, or when a data transfer has succeeded. If the OK is sent in response to a proposal, the OK message includes the agreementID. If the OK is sent in response to a TXD message, the OK message includes the MD5 hash of the data that has been transferred.

3.3.2 Here's A Proposal (PROP)

At any time, either participant can send one or more proposals to the other, these are sent in the prop-msg. The proposal's terms aren't binding until the other side has agreed to them (by responding with the OK or TXD primitives). The proposal may be signed by the party that creates it if so desired. In addition the PROP MUST include the agreementID of a proposal previously received from the other party (this may help the other party keep track of the negotiation). If a site wishes to express that a data element is optional, it may do so within the proposal; the user agent will return the optional elements it feels appropriate. An agreement over a proposal with optional purposes or qualifiers is ambiguous; there is no clear way for the agent to express that one purpose was agreed to, but another was not. Consequently, optional purposes or qualifiers MUST be expressed through multiple unambiguous proposals.

If a proposal isn't automatically acceptable to the user agent, there are three options. The user agent must be programmed in some manner to decide which response is appropriate (including prompting a user for guidance):

  1. Refuse (SRY) the proposal. This implies a desire to receive a new proposal from the service. Notice that there is a potential for an infinite loop if the user agent continues to send a SRY message should the same proposal be sent repeatedly. The user agent is responsible for maintaining sufficient state to detect this case and respond using one of the other techniques after it determines that a sufficient number of negotiation rounds have occurred; the service might, after all, choose to change its proposal if the agent appears sufficiently obstinate.
  2. Return a Proposal of its own. This implies a refusal, but provides an alternate that the user considers acceptable if accepted by the service. The service has the right to assume that by making the offer the user is willing to accept it if the service does.
    Note: the creation of a counter-proposal by the user agent is not required for P3P1.0 compliance.
  3. Walk away from the negotiation. There is no requirement that the user agent respond at all. The user agent may simply not send another request to the service.

If the proposal is acceptable to the user-agent, it should transmit the data to the service along with its OK. By transmitting the data under an agreementID, the user agent indicates that it has accepted the proposal. The TXD includes the agreementID of the accepted proposal, and the service can determine which optional data elements the user has sent by inspecting the data objects transmitted.

3.3.3 Sorry (SRY)

This message is sent in response to a proposal (PROP) or a data transfer (TXD). It indicates that the request could not be processed. The refusal includes two pieces of information: a reason code and agreementID. The reason code indicates what type of request is being refused and why it is being refused. Since multiple proposals may be sent, the agreementID is necessary to identify which request is being refused. The particular causes for refusing a proposal are given by the reason codes.

Finally, the SRY message can be used in response to a Transmit Data (TXD) message when the data transfer fails. The sender SHOULD NOT retry the TXD message.

Note: When a proposal is refused, P3P1.0 does not include a mechanism to specify exactly what portions of the proposal are unacceptable. A mechanism to indicate what part of a proposal is unacceptable may be included in a future version of the P3P protocol. In P3P1.0, a possible work-around for services or user agents which wish to do detailed negotiation is to send a counter-proposal, modifying or deleting those portions of the original proposal which were unacceptable. Implementers should be wary of the privacy implications of releasing user privacy preferences in either case.

3.3.4 Transmit Data (TXD)

After the receipt of a proposal, the user agent may send out the requested data. The user agent MUST include the agreementID(s) it believes it is operating under. The service MUST honor the agreements if they are valid. If the agreementID refers to an invalid or nonexistent agreement, the service MUST respond to the TXD with a SRY message, setting the response code to R-1 (Unrecognized Agreement).

If the proposal requests optional elements, the TXD may not include all the requested data elements. It is up to the user agent to decide how many of these to transfer; the agreement MAY inform the user of the consequences (presumably rewards) of sending the optional items.

3.3.5 Ending negotiation with final

There is no primitive to end negotiation. Instead, this capability is provided through a qualifier on a P3P message. Any PROP or SRY message can set the final qualifier to 1. When a service receives a PROP with a final="1" qualifier, it MUST respond with either an OK or a SRY. The response MUST include a content-body, though it may be as simple as an HTML document which states that the requested object cannot be returned without an agreement. When a user-agent receives a PROP with the final="1" qualifier, it should understand that the service has presented its "final offer", and that further negotiation is likely to be pointless.

3.3.6 Syntax of negotiation primitives

[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

3.4 Reason codes definitions

Reason codes are MAY be sent within P3P headers: every SRY message carries an implicit R-0 reason code, and every other message carries an implicit S-0 reason code; including a reason code in the message overrides these defaults. Consequently, there MUST be a semantic value associated with a missing code. Reason codes can be divided into three main classes: success codes, rejection codes and error codes. A detailed explanation of these three classes follows.

3.4.1 Success codes

This class of reason code indicates that the request was successfully received, understood, and accepted.

S-0 OK

3.4.2 Rejection codes

This class of reason codes indicates that the request was successfully received and understood, but not acceptable.  These codes MUST be sent only in a SRY message.

R-0 Other Rejection

R-1 Unrecognized Agreement

R-2 Agreement Expired

R-3 Proposal Rejected

R-4 Data Unavailable

R-5 Data Not Accepted

3.4.3 Error codes

This class of reason codes indicates that the request was not received successfully, or that the request was received but could not be understood. These codes MUST be sent only in a SRY message.

E-0 Other Error

E-1 Invalid Format

E-2 Data Transfer Unsuccessful

[18]
reason-code
=
S-0 | R-0 | R-1 | R-2 | R-3 | R-4 | R-5 | E-0 | E-1 | E-2

4. P3P markup and processing

This section describes the schema for 1) P3P proposals and 2) data transfer. A more complete English language description of the terms used in a proposal may be found within [HARMV].

4.1 Example proposal

4.1. English language proposal

We would like to encode the following statement; it is one proposal, with two statements within which are logical ANDs. "Other disclosures" automatically apply to the whole proposal.

CoolCatalog, a member of PrivacyAssured, makes the following statement for the Web pages at http://www.CoolCatalog.com/catalogue/.

We collect your name, age, and gender 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 collect your shipping information so that we can send you your order; this of course is identifiable. We do not redistribute any of this information outside of our organization. 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 following is a more formal description, where comments are preceded by a semicolon:

in proposal schema
www.CoolCatalog.com makes entity
this statement for http://www.CoolCatalog.com/catalogue/ ;   realm
with assurance from PrivacyAssured
we read ; read is default
   (User.Name.First) ; required is default
   (User.Bdate.Year optional)
   (User.Gender)
    for the purpose of  (2 3) ; Customization of the Site to Individuals, R&D
    in (0) ; Non-Identifiable Form
    and the recipients are (0) ; only ourselves and agents
    with consequence of ("a site with clothes you'd
                                        appreciate.") ; optional
we read&write
    (User.Shipping.) ; this is a whole data set.
    for the purpose of (0) ; Completing the Current Transaction
    in (1) ; Identifiable Form
    and the recipients are (0) ; only ourselves and agents

access disclosure (3) ; no access to identifiable data
other disclosures (0,1) ; we make disclosures
         regarding changing agreement and retention

at http://www.CoolCatalog.com/PrivacyPractice.html

4.1.2 XML/RDF encoding of proposal

The following 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.

<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax/">
<P3P><STATES>
<PROP 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"
 realm="http://www.CoolCatalog.com/catalogue/" 
 entity="http://www.CoolCatalog.com" agreeID="94df1293a3e5">
  <USES>
  <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
   consq="a site with clothes you'd appreciate.">
    <WITH><DATA:PREFIX name="User.">
     <DATA:REF name="Name.First"/>
     <DATA:REF name="Bdate.Year" optional="1"/>
     <DATA:REF name="Gender"/>
    </DATA:PREFIX></WITH>
  </STATEMENT>
  </USES>
  <USES>
  <STATEMENT action="read&write" VOC:purp="0" VOC:recpnt="0" VOC:id="1">
    <DATA:REF name="User.Shipping."/>
  </STATEMENT>
  </USES>
  <VOC:DISCLOSURE discURI="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>
</RDF:RDF>

4.2 Proposals

This section defines the key elements, attributes and processing heuristics for operating on a proposal. All proposals are encoded using [UTF-8].

4.2.1  <b>Proposal structure: the PROP element.

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

<PROP>
includes one or more statements. Each statement includes a set of disclosures as applied to a set of data elements.
agreeID
the agreementID (fingerprint of an accepted proposal)
final
signals the eventual conclusion of the negotiation
propURI
URI at which a proposal may be fetched
postURI
URI which information may be transmitted to
realm
the list of URIs to which the proposal applies. 
entity
URI referencing a domain name and path that can be associated with the legal entity making the representation of the privacy practices contained in the proposal.
agrexp
the date on which an agreement, if reached, will expire. Default is 6 months. The agreement expiration is the last date when a user agent can transfer data to the service under the agreement. The service continues to be bound by the restrictions of the agreement for data collected under the agreement, even after the expiration. Proposals expire after the time indicated by the "EXPIRES" HTTP header. The default expiration is 1 hour
optional
indicates whether or not the proposal is optional (see Section 4.3.5).
 
[19]
PROP-msg
=
`<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">` 
 1*(short-proposal | long-proposal) `</P3P>`|
 (`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax/">`
  `<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">`
   1*(short-proposal | long proposal ) `</P3P>`
  `</RDF:RDF>`))

The short-proposal is sent when a site wishes to assume that an agent is aware of the agreement or wishes to refer the agent to a complete proposal at the propURI.

[20]
short-proposal
=
 `<STATES><PROP ` 
(("agreeID=" `"` quoted-string `"` ">") | ("propURI=" quoted-URI ">"))
 "</PROP></STATES>"

The longer proposal includes all of the necessary attributes.  

[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/TR/1998/WD-P3P-19981109/ " `"`
[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>  

4.2.2 Processing realms and URI's

The realm attribute defines the scope of the agreement. It is used by the user agent, for example, to determine whether to automatically transmit a ReturnID or whether to allow a data transfer request. If the proposal is not digitally signed, then each of the Realm URIs must "domain-match" [Kristol] the domain of the server. If the proposal is digitally signed, then the Realm is implicitly expanded to include the current request URI whenever a server outside the original Realm makes a digitally signed proposal referencing an existing agreement.

As noted above, the user agent uses the Realm to determine if the current request URI is subject to any existing agreements. The user agent automatically transfers the ReturnID with the request if a valid agreement requested the ReturnID. This provides a mechanism for the service to maintain state or capture visitor-level statistics.

Schemes:

P3P is designed around the HTTP and related schemes (such as HTTPS). The protocol may be extended in the future covering data enchange and negotiation using other schemes, such as FTP or NNTP. 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.

entity

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 URI's 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.

realm

The realm attribute representing the set of URI's that are used to determine whether a given URI for an HTTP request is subject to a particular agreement. The realm is one or more URI's that domain-match the entity attribute or a URI pointing to a digital certificate representing the set of URI's for which the agreement will be binding. Consider the following scenario:

  1. User requests page http://www.romulus.com.
  2. Service returns proposal for realm= "http://maps.romulus.com/ http://www.romulus.com/" and entity="romulus.com" (notice that www.romulus.com and maps.romulus.com domain-match [KRISTOL] the root of the domain of the request URI, romulus.com). The proposal requests PUID (ID.PUID), the nickname of the user (User.Name.Nickname), her home address (User.Home.Postal.), year and month of her birthday (User.Bdate.Year and User.Bdate.Month) for non-identifiable use for the purpose of site administration and tailoring the user's experience
  3. User accepts proposal and reaches agreement with agreeID=X
  4. User visits maps.romulus.com which falls within the realm of agreeID=X, and automatically transmits PUID to maps.romulus.com.

4.2.3 Soliciting user info: the source attribute

This attribute allows information to be solicited through a form rather than a native P3P agent interface. This is accomplished by relating the element names of a proposal with the form INPUT names of the associated HTML form (HTTP content). The HTML-client/P3P-agent may also wish to auto-fill values when appropriate.

A P3P element is solicited when:

  1. the source attribute is equal to "form" and one of the elements in the form is the abstract data element Form.Data_
  2. the HTML form field INPUT names correspond to data element  names in the proposal.

Permissible values of this field are:

agent the default value, the P3P agent must solicit the user.
form solicitation happens through the form implicit in the associated HTML content
URI information is solicited by the resource at the given URI.

For example, a service wishes to have the solicitation under their own presentational control. Also, let us presume that the service will want to receive the data through the post mechanism described in scenario 8.

<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax/">
<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/catalogue/"
 entity="ttp://www.CoolCatalog.com" agreeID="94df1293a3e5"
 postURI="http://www.CoolCatalog.com/cgi-bin"/>
<USES>
   <STATEMENT action="rw" VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
    source="form"
    consq="a catalogue of shoes that fit you.">
     <WITH><DATA:PREFIX name="Cool." xmlns:DATA="http://www.CoolCatalog.com/productschema.html">
     <DATA:REF name="ShoeSize"/>
     </DATA:PREFIX></WITH>
     <DATA:REF name="Form.Data_"/>
   </STATEMENT>
   </USES>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>
</STATES>
</P3P>
</RDF: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="P3P_User_First"
  size="20" value="Your Name Here"> Shoesize <input type="text" name="Cool.ShoeSize"
  size="20" value="9 1/2"></p>
</form>
</body></html>

Note, this is different than the abstract element Form.Data_ which is used to say that information beyond that which is enumerated in the proposal is collected (e.g., through HTML or Java form methods). The source attribute specifies how information enumerated in the proposal is solicited. Information is returned based on the methods associated with the source method. So for instance, if source="form", information is returned by HTML/HTTP post. If source="agent" information is returned in the P3P-HTTP-extension, or at the postURI if specified. If Java applets were to become a common way of soliciting information, they would likely return information through their own methods.

4.2.4 Attesting to a proposal: the ASSURANCE element

<ASSURANCE>
describes a services that attests that the entity will abide by its proposal, follows guidelines in the processing of data, or other relevant assertions.
service
URI of the assurance service
text
short textual description of the type of assurance service (e.g., third party, legal, etc.)
image
URI of an image logo of the assurance service
width
width in pixels of the image logo
height
height in pixel of the image logo
alt
very short textual description of the image logo
[36]
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.

4.3 Statements

This section defines the key elements and attributes for making privacy statements and disclosures using the P3P Harmonized Vocabulary. While we specify {purp, recpnt, and id} attribute names within this document for reference purposes, the normative definitions and values are defined at:

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab

4.3.1 Privacy statements: the STATEMENT element

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

<STATEMENT>
purposes and their qualifiers as applied to data elements.
VOC:purp
purposes for data processing relevant to the Web.
VOC:recpnt
an organizational area, or domain, beyond the service provider and its agents where data may be distributed.
VOC:id
is data used in a  way that is personally identifiable -- including linking it with identifiable information about you from other sources?
action
read the data, or read and write 
source
allows information to be solicited through other ways (e.g. forms) rather than a native P3P agent interface 
[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
The values of [30-32] are provided for reference only. The normative specification is in the harmonized vocabulary document.
[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 

Note: many of these elements and attributes are related to the vocabulary namespace. 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 interoperability: 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.

4.3.2 General disclosures: the VOC:DISCLOSURE element

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

<VOC:DISCLOSURE>
Simple disclosures regarding service access capabilities, and binary values as to whether the entity makes disclosures regarding changing the agreement (opt-out) for data already collected and how long data is retained.
discURI
URI of the natural language privacy statement of the proposal, which should include information on how to contact the service with questions or concerns.
access
the ability of the individual to view identifiable information and address questions or concerns to the service provider.
other
does the site make its policy regarding change agreement and retention known at its discURI?
The values of [33-35] are provided for reference only. The normative specification is in the harmonized vocabulary document.
[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
[35]
other-disclosure
=
"0" | ; change agreement
"1"   ; retention

4.4 Data References

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

4.4.1 Referencing data: the <DATA:REF> tag

References to data sets/elements are all enclosed within a statement using the <DATA:REF> tag. The <DATA:REF> tag has the following attributes: name, xmlns:DATA, value, optional, type, typeschema, short, long, category, size and ext.

The following six attributes are only used when a new (not defined in the P3P1.0 base) data element or set is referenced.

[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] "/>"

As an example, to request the user's shipping address city, all the elements of the data set User.Business. and (optionally) all the elements of the data set User.Home.Telecom.Phone.   the service would send the following references inside a P3P proposal:

<DATA:REF name="User.Shipping.Postal.City"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1"/>
<DATA:REF name="User.Business."/>

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.Shipping.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.) ...

4.4.2 Prefixing references: <WITH><DATA:PREFIX>

In a set of data references, many element names may share a common parent. For instance, "User." is a common occurrence in the references directly above. The <WITH><DATA:PREFIX> tags can be used to associate a string prefix to every attribute of the <DATA:REF> tag. Consequently, this can be used to  shorten the length of the names or to reference new data sets and elements. If a sequence of <DATA:REF> tags is enclosed by the <WITH><DATA:PREFIX> tags, then the block is equivalent to one where the enclosing <WITH><DATA:PREFIX> tags are omitted, and the value of each attribute of a <DATA:REF> tag is prefixed by the corresponding value of the attribute of the <DATA:PREFIX> tag. For instance, the above example could be rewritten as:

<WITH><DATA:PREFIX name="User.">
  <DATA:REF name="Shipping.Postal.City" value="Boston"/>
  <DATA:REF name="Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="Home.Telecom.Phone.LocCode" value="617"/>
  <DATA:REF name="Business.Postal.Street" value="12 Main St."/>
  <DATA:REF name="Business.Postal.City" value="Cambridge"/>
  ... (the other values of User.Business.) ...
</DATA:PREFIX></WITH>

The <WITH><DATA:PREFIX> tags can be nested; the prefixes have to be added proceeding from the innermost <WITH><DATA:PREFIX> ... </DATA:PREFIX></WITH> combination (here, innermost means that there are no other <WITH><DATA:PREFIX> tags within). So, the above example could be rewritten even more compactly in the following way:

<WITH><DATA:PREFIX name="User.">
  <DATA:REF name="Shipping.Postal.City" value="Boston"/>
<WITH><DATA:PREFIX name="Home.Telecom.Phone.">
  <DATA:REF name="IntCode" value="1"/>
  <DATA:REF name="LocCode" value="617"/>
  </DATA:PREFIX></WITH>
  <WITH><DATA:PREFIX name="Business.Postal.">
    <DATA:REF name="Street" value="12 Main St."/>
    <DATA:REF name="City" value="Cambridge"/>
    ... (the other values of User.Business.Postal.) ...
  </DATA:PREFIX></WITH>
  ... (the other values of User.Business.) ...
</DATA:PREFIX></WITH>

Note: use of two tags (<WITH><DATA:PREFIX>) in place of one (just <DATA:PREFIX>) is technically due to the fact we are employing the RDF data model.

[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 )

4.4.3 The VOC:category attribute

This section defines the categories used to described data elements or sets. While we specify the category attribute for reference purposes, the normative definitions and values are defined at:

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab/#Categories

Categories are attributes of data elements which 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 referring to form data.

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.

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

In the current version of P3P, the following numbers can be 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

For a more detailed explanation of the above categories, see the P3P Harmonized Vocabulary Specification.

4.4.4 Client side writes: the action attribute

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="ID.PUID"/>
    <DATA:REF name="User.Name.First"/>
</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" />
</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 (TXD).

The user sends:

<TXD r="S-0" agreeID="94df1293a3e5">
<DATA:REF name="User.Name.First" value="Josephine"/>
<DATA:REF name="ID.PUID" value="1234567"/>
<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 must 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) at any time. For instance, even though the user provided their shoesize as 7, the service wishes to convert it into European shoe sizes and write that value instead.

4.4.5 Unambiguous Optional Elements and Purposes

A desired feature of P3P is the ability of a service to optionally request actions over elements (read&write capabilities) or indirectly apply optional qualifiers (purposes, recipients, identifiable usage) to an element.

An optional action (read or read&write) over an element is easy to represent. Optional elements are denoted by the optional attribute of the <DATA:REF> tag. Those elements that are optionally solicited for reading or writing but which are not acceptable to the client are simply not acted upon: data is not returned or written.

Representing an optional qualifier is problematic. If the element is needed for concluding the transaction, but is optionally requested for direct marketing, simply returning the element is an ambigous representation of what the user agreed to. Consequently, in order to avoid ambiguity the following requirement MUST be followed:

For example, if a service requires shipping information for completing the transaction and would like to optionally use all of this data for marketing purposes, it should send the following two proposals.

<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 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"
 agreeID="1e3a5d71297d>"

 realm="http://www.CoolCatalog.com/catalogue/">
  <USES>
   <STATEMENT VOC:purp="2" VOC:recpnt="0" VOC:id="1"
    consq="We can ship your order to your door step">
      <DATA:REF name="User.ShipTo."/>
   </STATEMENT> </USES>
 <VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
 access="3" other="0,1"/>
</PROP></STATES>
<STATES>

<PROP agreeID="2e3a5d71297d"
 realm="http://www.CoolCatalog.com/catalogue/"
optional="1">
; note optional is in header.
  <USES>
   <STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="1"
    consq="We will send you our world-renown catalogue!">
      <DATA:REF name="User.ShipTo."/>
   </STATEMENT> </USES>
 <VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
 access="3" other="0,1"/>
</PROP></STATES>
</P3P>

When employing multiple proposals to represent a complex privacy policy, the following rules need be followed:

  1. When a proposal contains only optional elements, the optional flag for the entire proposal MUST be set to 1.
  2. When a site sends multiple proposals to a user, if the user wishes to enter into an agreement with that site he or she should return the agreementIDs for one or more of the non-optional proposals and zero or more of the optional proposals. If they agree only to an optional proposal, the site may deny them access to that realm.

In our example, if the user only agrees to the proposal for using the shipping information for the completion of the transaction, it would return the information under that agreement ID.

<TXD r="S-0" agreeID="1e3a5d71297d" />
<WITH><DATA:PREFIX name="User.ShipTo.">
      <DATA:REF name="Postal.Name" value="Josephine Hound"/>
      ...
      <DATA:REF name="Telecom.Phone.Number" value="2532442"/>
</DATA:PREFIX></WITH>

Note that this solution results in the transmission of potentially redundant information in multiple proposals and data transfers. However this is preferable to the greater complexity and latency of requiring clients to send back which parts of anmbigous proposal they agreed to.

4.4.6 Creating New Data Sets

4.4.6.1 Data Definition

Within a proposal, new data elements and data sets can be created. This occurs when a reference to an unknown data element or data set is encountered by the user agent. In such an event, if the user agrees, the new data elements are created within the user's repository. In order to create a new data element, the agent needs the following: its name, the data schema it belongs to,  the category, the data type (and, in case, the data schema where the type has been defined), and the short display name.

Also, a service may optionally provide a more detailed description of the data element in the form of a special schema statement. This information can be provided in two ways:

  1. inline within the <DATA:REF> tags, using the corresponding attributes category, type, typeschema, short (see the next subsection); or
  2. outline, within the definition of the data schema provided by the xmlns:DATA attribute.

If information is inline and the origin server URI does not match the data schema URI, the information in the main data schema MUST be checked in order 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, a E-1 reason code (Invalid Format) must be returned. If for any other reason the user is unable to reconstruct the needed information, a R-4 reason code (Data Unavailable) must be returned.

4.4.6.2 Data Schema Format

The format of a new data schema is a special statement of the form

<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>
<USES><STATEMENT>
  ....
</STATEMENT></USES></PROP></STATES></P3P>

A data block is enclosed within the <data> tags and contains references to the data elements. References can be made using the <DATA:REF> tag and its attributes:

Like in the data transfer, the <DATA:PREFIX> tag can be used to shorten the schema definition, by associating a common prefix to many <DATA:REF> attributes.

For every data element, all of the information except long is mandatory. If one of the attributes 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 just place the following code at http://www.HyperSpeed.com/models-schema

<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>
<USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0">
<WITH><DATA:PREFIX name="car." short="Car" VOC:category="7" size="63">
 <DATA:REF name="model" type="Text" short="Model"/>
 <DATA:REF name="color" type="Text" short="Color"/>
 <WITH><DATA:PREFIX name="built." short="Construction data">
  <DATA:REF name="year" type="Number" short="Year"/>
  <DATA:REF name="where." type="Postal."/>
 </DATA:PREFIX></WITH>
</DATA:PREFIX></WITH>
<DATA:REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike "/>
</USES></STATEMENT></PROP></STATES></P3P>

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:

<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>
<USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0">
<WITH><DATA:PREFIX name="GenericModel." template="1" VOC:category="7" size="63">
 <DATA:REF name="model" type="Text" short="model"/>
 <DATA:REF name="color" type="Text" short="color"/>
 <WITH><DATA:PREFIX name="built." short="Construction data">
  <DATA:REF name="year" type="Number" short="Year"/>
  <DATA:REF name="where." type="Postal."/>
 </DATA:PREFIX></WITH>
</DATA:PREFIX></WITH>
<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></STATES></P3P>

Note that there are no commands to enforce "secure" storage of the critical data in a new data set: this because critical data can be securely stored using encryption, or just using a reference URI.


5. Appendices

Appendix 1: References (Normative)

[DSIG]
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp. "DSig 1.0 Signature Labels Specification: Using PICS 1.1 Labels for Making Signed Assertions," World Wide Web Consortium, Recommendation. 03-April-1998.
[RDF]
O. Lassila, R. Swick. "Resource Description Framework (RDF) Model and Syntax Specification."  World Wide Web Consortium, Working Draft. 14-August-1998.
[HARMV]
J. Reagle. "P3P Harmonized Vocabulary Specification,"  World Wide Web Consortium, Working Draft. 30-March-1998. (Working Draft)
[HTTP1.0]
T. Berners-Lee, R. Fielding, H. Frystyk Nielsen, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," W3C/MIT, UC Irvine, W3C/MIT, May 1996.
[HTTP1.1]
R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "RFC2068 -- Hypertext Transfer Protocol -- HTTP/1.1," UC Irvine, Digital Equipment Corporation, MIT.
[ISO3166]
"ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[KEY]
S. Bradner. "RFC2119 -- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
[MANDA]
H. Frystyk Nielsen, P. Leach, S. Lawrence. "Mandatory Extensions in HTTP," (draft-ietf-http-ext-mandatory-00). March 1998. IETF Internet Draft.
[MD5]
R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT. April 1992.
[MIME]
N. Freed, N. Borenstein. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.
[SSL]
A. Freier, P. Karlton,  P. Kocher. "SSL 3.0 Specification." (http://home.netscape.com/eng/ssl3/index.html)
[STATE]
Network Working Group, D. Kristol, Bell Laboratories, Lucent Technologies; Category: Standards Track  HTTP State Management Mechanism. (ftp://ftp.isi.edu/in-notes/rfc2109.txt)
[URI]
T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." 1997. (Work in progress; see updates to RFC1738.)
[UTF-8]
F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
[UUID]
The Open Group. "Universal Unique Identifier. Appendix CAE Specification C706." DCE 1.1: Remote Procedure Call. 1997.
[VCARD]
"RFC2426 -- vCard MIME Directory Profile", September 1998.
[XML]
T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommandation. 10-February-1998.
[XML-Data]
A. Layman et al. "XML-Data." World Wide Web Consortium, Note. 05-January-1998.
[XML-Name]
T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Working Draft. 16-September-1998.

Appendix 2: Fingerprints and Canonicalization (Normative)

P3P uses fingerprints (Message Digest, Hash) as a means of identifying proposals and data sets. These fingerprints yield a fixed size value resulting from the application of a hash function to a set of data. Fingerprints are easily computed, but even small modifications to the original information result in a different fingerprint value. Consequently, fingerprints are often used as methods of assuring information integrity. We use the MD5 digest algorithm for P3P fingerprints. This yields a 128-bit value which will be encoded and exchanged in P3P communications. Both agent and service can use these fingerprints to reference a given proposal and to ensure the integrity of the transaction (validating proposal against fingerprint).

The process for generating a fingerprint is fairly straight forward. For fingerprints to be identical, the data fingerprinted by sender and recipient must be identical. Our goal is to render the data to be fingerprinted into a standard form (canonicalized) such that the effect of any reformatting by intermediaries is nullified. After this is done, we use the canonicalized version of the proposal to generate the fingerprint. Given the same proposal, both the service and agent should be able to arrive at the same fingerprint value.

Proposal canonicalization rules

As an example, consider the following XML:

<rdf:rdf>
<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 agreeID="94df1293a3e5" realm="http://www.CoolCatalog.com/catalogue/" entity="htp://www.CoolCatalog.com" >   <USES>   <STATEMENT consq="A site with clothes you'd appreciate." VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"> <WITH><DATA:PREFIX name="User.">       <DATA:REF name="Name.First"/>       <DATA:REF name="Bdate.YEAR" optional="1"/>       <DATA:REF name="Gender"/>     </DATA:PREFIX></WITH>   </STATEMENT>   </USES>   <USES>   <STATEMENT ="rw" VOC:purp="0" VOC:recpnt="0" VOC:id="1"> <DATA:REF name="User.shipping."/>   </STATEMENT>   </USES>   <VOC:DISCLOSURE discURI="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> </rdf:rdf>

After canonicalization, it would look like:

<PROP realm="http://www.CoolCatalog.com/catalogue/" entity="http://www.CoolCatalog.com" >
<USES>
<STATEMENT consq="A site with clothes you'd appreciate." VOC:purp="2,3" VOC:recpnt="0" VOC:id="0">
<WITH>
<DATA:PREFIX name="user.">
<DATA:REF name="name.first"/>
<DATA:REF name="bdate.year" optional="1"/>
<DATA:REF name="gender"/>
</DATA:PREFIX>
</WITH>
</STATEMENT>
</USES>
<USES>
<STATEMENT ="rw" VOC:purp="0" VOC:recpnt="0" VOC:id="1">
<DATA:REF name="user.shipping."/>
</STATEMENT>
</USES>
<VOC:DISCLOSURE discuri="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>

Generating the MD5 fingerprint

Once the proposal is canonicalized, we use the MD5 algorithm to generate the P3P fingerprint. This section provides an overview of MD5 and an explanation of how a MD5 digest is encoded.

MD5 Overview

The MD5 hash algorithm is defined in

The MD5 Message Digest Algorithm, R.L. Rivest, RFC 1321, April 1992

The MD5 algorithm (Message Digest 5) is a cryptographic message digest algorithm.

MD5 was designed by Ron Rivest, who is also the `R' in `RSA' in 1991. MD5 is described in RFC1321. C source code is included with the RFC. It is basically MD4 with "safety-belts" and while it is slightly slower than MD4, it is more secure. The algorithm consists of four distinct rounds, which have a slightly different design from that of MD4. Message-digest size, as well as padding requirements, remains the same.

The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA or PGP.

For further information on MD5, see:

P3P Encoding

Computing the MD5 digest yields 4 32-bit values. All values are encoded using the standard base-64 representation of a byte-array containing the two's-complement representation of the value to encode. The first byte in this array is the high-order byte. The minimal number of bytes necessary is used to represent a certain value, so no leading zero-bytes are allowed.

The BNF below shows how a MD5 digest is encoded for P3P communications.

resource-hash     = '"base64-string encoding of 128 bit MD5 message
                      digest of the information resource."'
base64-string     = as defined in RFC-1521, section 5.2.

Appendix 3: Line-flow Scenario (Non-normative)

This scenario is based on scenarios 1/5 and 3 and includes negotiation.

A user directs their Web browser to go to home page of CoolCatalog. She has never been there before; she requests a P3P proposal as part of the request by advertising that her browser understands P3P.

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

CoolCatalog sends a proposal, including privacy practices, disclosures, and the data elements to which they apply. In this instance, the service asks to be given the PUID as part of the returnID automatically in the future and requests the user's gender from the user repository.

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>

[Note that the proposal is split across multiple lines for readability; over the network, a CRLF pair would be added only after the </PROP>. We will use this in the example lineflows below as well.]

The user refuses this proposal. Imagine that the agreementID (hash) of the above proposal is "e3a5d71297d104f1"; the user's next HTTP request would look like the following:

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" />

The site offers a new proposal, this time it requests the automatic returnID, and from the user's repository the first name and optional age, both for the purposes of customizing the site.

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>

The user agrees only to the provision of the automatic returnID and first name for customization only, and sends the data. Assume that the agreementID of the above proposal is "94df1293a3e519bb".

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="Josephine"/>
 <DATA:REF VOC:purp="2" name="User.PUID" value="1234567"/>
</TXD>

At this point, the service would return the CoolCatalog homepage.

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]

The user returns to the site a day later, sending the returnID automatically.

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"/>
</TXD>

However, the server again needs the user's first name, so it asks for it under the previous agreement.

HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-2010
2010-P3P: <PROP agreeID="94df1293a3e5"/>
</PROP>
Content-Type: text/html
Content-Length: 70

<html><body>
<h1>HTTP/1.1 400 Agreement Required</h1>
</body></html>

The user returns her first name and PUID.

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-1968
1968-P3P1.0: <TXD agreeID="94df1293a3e5" >
 <DATA:REF name="User.Name.First" value="Josephine"/>
 <DATA:REF name="User.PUID" value="1234567"/>
</TXD>

The service would then respond with their homepage, as before:

HTTP/1.1 200 OK 
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1950
1950-P3P1.0: <OK DH="s24fd20kuqexg5xk" />
Content-Type: text/html
Content-Length: xxx
[content of the CoolCatalog homepage]

Appendix 4: ABNF Notation (Non-normative)

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) 
where <name> is the name of the rule, <elements> is one or more rule names or terminals combined through the operands provided below. Rule names are case-insensitive. 
(element1 element2)
elements enclosed in parentheses are treated as a single element, whose contents are strictly ordered.
<a>*<b>element
at least <a> and at most <b> occurrences of the element.
(1*4<element> means one to four elements.)
<a>element
exactly <a> occurrences of the element.
(4<element> means exactly 4 elements.)
<a>*element
<a> or more elements
(4*<element> means 4 or more elements.)
*<b>element
0 to <b> elements.
(*5<element> means 0 to 5 elements.)
*element
0 or more elements.
(*<element> means 0 to infinite elements.)
[element]
optional element, equivalent to *1(element).
([element] means 0 or 1 element.)
"string" or 'string'
matches a literal string matching that given inside the double quotes.

Other notations used in the productions are:

; or /* ... */
comment.

Appendix 5: Working Group Contributors (Non-normative)

Lorrie Cranor AT&T
Philip DesAutels Matchlogic
Melissa Dunn Microsoft
Daniel Jaye (Editor) 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

This work was based on other documents, specifically the

as well as the :