W3CWD-P3P-Protocols-971217

Platform for Privacy Preference Project (P3P)
Format and Protocol Working Group
Draft White Paper

Authors:
Philip DesAutels, W3C
Melissa Dunn, Microsoft
Dan Jaye, Engage
Jim Miller, W3C
Paul Perry, FireFly
Martin Presler-Marshall, IBM
Editor:
Steve Lucas, MatchLogic

Last modified: Wednesday, December 31, 1997 09:39:42 AM Eastern Standard Time

Most Current Version

http://www.w3.org/P3P/Group/Protocols/WD-P3P-Protocols.html

This Version

http://www.w3.org/P3P/Group/Protocols/WD-P3P-Protocols-971217.html

Previous Version:

http://www.w3.org/P3P/Group/Protocols/971210-white-paper.htm

Introduction

This paper extends the work started in the earlier P3P Working Groups by working through details of the user/service interactions that take place as a user traverses the Web. It is our intention to provide sufficient grounding that the next step, a detailed technical specification of the "bits and bytes," will be a straightforward technical task. Toward that end, we provide in this paper an English language description of the scenarios that form the core of the design as well as the messages (and their content) required to make the scenarios real.

Problem Space

P3P is attempting to:

The negotiation is based on comparing a set of privacy preferences, owned by the user agent, with the privacy practices specified by the service. When the privacy preferences do not match the service's practices, the two sides must come to an agreement by exchanging proposals for alternative privacy practices to be implemented by the service.  Every proposal has a defined set of consequences that can be shown to a human user to explain why the suggested practice may be acceptable in this instance even if the user would not normally allow the practice (for example, the service may offer a discount, offer a bonus, etc.).

Scope

There are a number of tasks related to this problem space which are not part of this Working Group's scope:

  1. The language used to specify these practices is being created by another W3C Working Group. It is our working premise that the precise terms and conditions will not materially affect either the format of the messages needed to convey them or the kinds of negotiation steps required to arrive at agreement.
  2. This Working Group is tasked with creating a universal set of negotiation primitives that can be used to arrive at agreement, as well as answering questions about signatures on these primitives, requirements on the order of use of the primitives and so forth.
  3. This Working Group (and, indeed, W3C itself) is not tasked with defining "value add" work that applies only to the user or service sides of the negotiation. In particular, this Working Group will not advise developers on intelligent strategies or tactics for performing negotiation.
  4. This Working Group is not tasked with creating a transportable format for moving privacy-related configuration information, either on the user (privacy preferences) or service (privacy practices) side.
  5. This Working Group is not tasked with expressing how data will be shared or aggregated. This is the responsibility of the Harmonized Vocabulary Working Group.

Overview of Scenarios

We provide a set of scenarios covering typical uses for the P3P protocol. We do not expect these scenarios to be all-inclusive, but we believe that they cover the most common uses.

These scenarios discuss the interaction between the user agent and the service. In all cases, the user agent may prompt the human user (if any) for guidance before proceeding, or it may operate without user intervention ("seamlessly") based on preferences stored in the user agent. Obviously, robot user agents - which don't have a user to ask for guidance - must always operate seamlessly.

#1: No Negotiation

This case is simplest from the protocol point of view. This case is where the privacy practices of the service are compatible with the privacy preferences of the user-agent. This case can occur without the need for human intervention. The service and user-agent must still exchange a proposal, as the interaction must be covered by some agreement.

#1A: Practices and preferences are compatible

User view
User enters a URL into their Web browser, and the page is displayed.

Service operation

The service requests some information with a given practice. For example, the service is configured to request only the user's clickstream data, for the purposes of system administration.

Agent operation

Considering the service's practice and the user agent's preferences, the user agent decides that they are compatible. Consequently, it agrees to allow the service the access it has requested. For example, the user-agent has configured that the data element "clickstream" is in the "anonymous information" category, and is configured to allow services to collect information of that category if it is used only for system administration.

Note that these discussions are between the user agent and the service. The user agent may need to prompt the user to determine if its preferences are compatible with the request that the service makes, or it may happen automatically ("seamlessly"). For our purposes, these two scenarios are equivalent.

#1B: Practices and preferences are incompatible

User view

User enters a URL into their Web browser, and gets back an error in response.

Service operation

The service requests some information with a given practice. For example, the service is configured to request only the user's governmental ID (for example, National Social Security Number), and may share it with anyone they wish.

Agent operation

Considering the service's practice and the user agent's preferences, the user agent decides that they are not compatible. Further, the user agent decides that does not wish to negotiate with this service. Consequently, it refuses to allow the service the access it has requested, and shows the user an error message. For example, the user-agent has configured that the data element "National Social Security Number" is in the "personally identifying information" category, and is configured to never allow services to collect information of that category.

As mentioned above, this scenario does not specify the interaction between the user agent and the user.

#2: Negotiation

In the next scenario, a service initiates a request to exchange data. The user responds by refusing to provide the data and does not provide a counter proposal. In this case, the user may provide a code or comment as to why the request was denied. The user might also opt to provide a counter proposal where they may agree to provide data if certain conditions are met. For example, the user may agree to partially satisfy the request (example: I will provide my age and zip code but not my name and address).

State that this can be expanded to multiple rounds in an obvious manner.

#2A: User does not provide a counter proposal

User view
User enters a URL into their Web browser. Depending on the preferences the user has set in their browser, they may see a pop-up message requesting that they agree to the service's practices. The page is then displayed.

Service operation

The service requests some information with a given practice. For example, the service requests a service ID so that the user can be anonymously be recognized during this session and in future sessions. The user agent refuses the request and does not make a counter proposal, though it may explain what it objects to. The service then makes an alternative proposal.

Agent operation

Considering the service's practice and the user agent's preferences, the user agent decides that they are not compatible. The user agent refuses the service's request. The service can then make a counter proposal. Assuming that the user agent finds that its preferences are compatible with this new proposal, the user agent agrees to allow the service the access it has requested. For example, the alternative proposal could request a service ID that would only be good for the current session. If the user agent finds that alternative proposal acceptable, it agrees to that request.

#2B: User provides a counter proposal

User view

User enters a URL into their Web browser. The page is then displayed.

Service operation

The service requests some information with a given practice. This request is rejected by the user agent, which makes a counter offer indicating what it finds acceptable. If the service finds this counter offer acceptable, it agrees to this counter offer, and allows access to the requested URL. For example, the service requests a service ID so that the user can be anonymously be recognized during this session and in future sessions. The user agent refuses this request and makes a counter offer, to give the service an ID which is usable for the current session only.

Agent operation

Considering the service's practice and the user agent's preferences, the user agent decides that they are not compatible. The user agent looks at what parts of the request are acceptable, and makes a counter proposal that it finds acceptable. Assuming that the counter offer is acceptable to the service, the user agent gives access to the requested data. The example is given above.

In both of the scenarios above, the P3P protocol does not make any distinction about whether the user is prompted for approval or not. We believe that the interactions, or lack thereof, between the user and the user agent are up to the implementers of the user agents.

Exceptional Scenarios

#1: Request for data without a proposal

To paraphrase the rock band Rush, if you choose not to propose, you have still made a proposal. An empty proposal makes no promises about the use of the data. In other words, if service makes no proposal but also asks for data, and the user agent sends it, then the service is free to do anything it wishes with that information.

#2: Error scenarios

Services have several responsibilities in order to have reasonable error situations:

  1. Services must recognize clients that do not support P3P. For those clients, they must not ever use the P3P mechanisms to ask for data. They must also never use any error-reporting mechanisms defined by P3P.

  2. If a service and a user agent are unable to form an agreement after some number of rounds of negotiation, they must provide a fallback page. This encompasses two tasks. First, we must provide a way to prevent infinite loops of negotiation. Second, certain countries (for example, Germany) will legally require that the services provide some non-personalized version of the requested resource.

User agents are responsible for several error scenarios are well:

  1. User agents must be able to call an end to negotiation. Assuming that this protocol is implemented over HTTP, proposals from the service will be carried in HTTP responses. The user agent must be able to send a request that includes a statement saying that the proposal included in the request - if any - is non-negotiable. This is the only way that the user agent can prevent infinite loops of negotiation. This could be a part of the SRY message, or it could be a seperate message.

Terminology

In addition to the terms defined in earlier P3P documents (definitions are included here in the glossary), the following terms are used consistently throughout this document:

Agreement
An agreement is a small unit of information that is sufficient to indicate that both parties have agreed on a common proposal. This  includes any one of:

  1. the fingerprint of a proposal (if both parties agree that it need not be non-repudiable)
  2. the fingerprint (as above) plus the digital signature and identity information of the assuring party (q.v.) that is countersigning a proposal already signed by the user
  3. the fingerprint (as above) plus the digital signature and identity information of the user that is countersigning a proposal already signed by the assuring party (q.v.)

Technically, this corresponds to a small piece of metadata in RDF (Resource Description Framework) format that may optionally include a DSig 2.0-compliant signature.

Assuring Party
P3P assumes the existence of an entity which assures that the service will abide by its proposal; this assurance may come from the service or an independent assuring party.   The assuring party digitally signs proposals and is responsible for assuring their implementation by the service.

Fingerprint (aka Hash or Digest)
Given any digital information, it is possible to construct a fixed size (about 20 byte) number that is easily computed from the original information but even small modifications to the original result in a different number which is virtually unpredictable. We call these fixed size numbers the fingerprint of the original object. Given a fingerprint and an object it is easy to tell whether the fingerprint refers to that particular object, but it is not easy to predict what object created a given fingerprint. Both generating a fingerprint and verifying its correctness are quickly performed and do not rely on public or private keys, identity information, etc.

In P3P, we use fingerprints both as part of signatures and to identify Proposals so that the entire text of the proposal need not be sent repeatedly. This should significantly reduce the overhead of the protocol.

Identity information
Identity information is any information sufficient to satisfy one party of the identity of another. This may consist of a public key and/or set of certificates that can be used to verify signatures, or it may consist of a shared secret, or some real word identification information (name, social security number, birthdate, etc.)

Proposal
A proposal is an offer by a service to protect information, divulged to it by the user, in a particular manner. Note that the proposal is always a statement made 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. The proposal includes identity information specifying the entity with whom the user is entering into agreement (this need not be the same as the entity that signs the proposal).  A proposal will be encoded using RDF for transfer between the user and the service.

(Digital) Signature
We assume that users and services may have a pair of keys, one public (i.e. known to everyone) and one private. A (digital) signature for an object is generated by calculating the fingerprint (q.v.) of the object and then encrypting it with the private key. Given the public key, the signature, and the digital object it is easy to ensure that the the signature was generated by someone in possession of the corresponding private key and the digital object, and was almost certainly not generated in any other way (this is called signature verification).  While signature verification is an efficient process, generating the signature requires a significant amount of computation.

In P3P, we use digital signatures as specified in the DSig-2.0 specification (for creating signed RDF).  These signatures are always attached to a specific statement; the signature asserts that the entity creating the signature believes the statement to be true.

Signed Proposal
A signed proposal is a proposal (q.v.) that has an attached digital signature (q.v.). A signed proposal from the service is signed by an entity, the assuring party (q.v.),  willing to assure that the service will abide by the proposal.  A signed sroposal from the user is signed by the user. For pragmatic reasons, we assume that all services have an assuring party (which may be the service itself) and that all assuring parties are able to sign proposals, but we do not assume that users are capable of signing proposals.

Assumptions

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

  1. We assume that communication security is achieved through means other than P3P itself (such as SSL). Hence P3P does not provide mechanisms for cryptographically protecting information.
  2. P3P concentrates on providing an agreement between the user and the service, and that there is identifying information about the entities that have reached that agreement. Because it can be expensive to provide non-repudiable evidence of such an agreement, P3P permits the creation of non-repudiable evidence but does not require it.
  3. P3P requires that the service include identifying information about itself in its proposals.  In addition, P3P assumes the existence of an assuring party who digitally signs proposals and is responsible for assuring their implementation by the service.
  4. The user has the right to require a non-repudiable agreement (and thus all services must be prepared to sign their agreements if they expect to do business). But not all users will have a public key, and hence may not be capable of generating non-repudiable agreements.  Thus, a service does not have the right to require a non-repudiable agreement.
  5. Our protocol is intended to be carried over HTTP/1.1 and we assume user-agents implement HTTP/1.1 persistent connections. This is a performance-related assumption, not a correctness-related assumption; our protocol design must be fully backward compatible with HTTP/1.0, and will draw heavily on the existing design work on PEP.
  6. Most sites will have clearly stated privacy policies that are acceptable for their typical users and will.make "take it or leave it" offers. There will be small but important group of services with less popular policies that are willing to explain the reasons for their policies and negotiate with users and user-agents.

Negotiation Primitives

In order to support the scenarios described above, P3P provides a set of primitive operations to use in conversations:

Message Meaning U to S? S to U? After Receiving Expected Response Data in Message Optional in Message
SRY-PROP Refuse Proposal Yes Yes PROP PROP Fingerprint of proposal refused Which practices are unacceptable (To Be Designed)
SRY-RFP I won't give you a Proposal Yes Yes RFP none    
SRY-RFT Proposal Text not available No Yes RFT none Agreement Reason
SRY-TXD Data transfer not accepted Yes No TXD none   Reason
OK-PROP Proposal acceptable Yes Yes PROP none Agreement  
OK-TXD Data transfer successful Yes Yes TXD none [hash of] data transferred  
PROP Here's a Proposal Yes Yes any time OK or SRY or PROP Text of a proposal Signature of initiator, fingerprint of previous Proposal
RFD Request for Data No Yes any time SRY, PROP, RFP, RFT or TXD Names of data elements, sets of data elements, or categories Previous agreement or new PROP
RFP Request for Proposal Yes Yes any time PROPor SRY Must agreement be signed? Set of URLs to be covered
RFT Request for Text of Proposal Yes No Agreement PROP or SRY Agreement  
TXD Transfer Data Yes Yes any time none, OK-TXD or SRY-TXD Data element names and values to be written, as requested Agreement
STP Stop negotiation Yes No any time before reaching an agreement Good question! none  

This section describes each of the operations and specifies who (user or service) can initiate the action and under what circumstances. Under Scenarios, Detailed we revisit the earlier scenarios, but this time showing how they are implemented using these primitive operations. This section also provides some insight into requirements on detailed data formats, which are then gathered together (along with information from the earlier P3P documents) in the section on Formats: Requirements and Specifications. After the detailed description, there is a table summarizing all of these messages.

Request for Proposal (RFP)

At any time, the user can send a request for proposal to the service. The RFP specifies whether or not the user expects to reach a non-repudiable agreement and the set of URLs the user would like the agreement to cover.

This should not be used if the user has a particular proposal that she would like to see adopted by the service; that is best handled (although with some privacy consequences) by using the Here's A Proposal (PROP) primitive.

Here's A Proposal (PROP)

At any time, either participant can send a proposal to the other. The proposal's terms aren't binding until the other side has agreed to them (see the OK primitive). The proposal may be signed by the party that creates it if so desired (recall, though, that the user can refuse to accept an agreement unless the proposal is signed). In addition the PROP may also include the fingerprint of a proposal previously received from the other party (this may help the other party keep track of the negotiation).

There is a privacy implication if the user initiates a proposal.  The service may well use the proposals it receives (from individual users or via statistical sampling techniques) to tailor future proposals that it makes.  In a sense, this is precisely the reason that the user might wish to make a proposal -- in the hope that the service will alter its longterm behavior towards that requested by the user.  On the other hand, revealing preferences by making a proposal does divulge a good deal of valuable information about the current user (in a non-personally-identifying form).

Request for Text of Proposal (RFT)

After the user and service have reached an agreement, the user may request the text of the proposal that is part of that agreement from the service, so that it does not have to store state during the negotiation process. The service should respond either with a PROPosal message including the correct proposal text (which can be verified by the user, since the user has the fingerprint of the proposal text as part of the agreement itself) or with a SRY if the server no longer has a record of the agreement and is unable to regenerate it algorithmically.

Sorry, I Refuse Because (SRY)

The user, after receiving a proposal from the service, can refuse it and request another proposal. The SRY message includes the fingerprint of the proposal being rejected, as well as the reason why it is being refused. The precise reasons for refusing a proposal are not yet specified, but this is an important issue that must be resolved by the Working Group. The reasons must be sufficiently well specified that the service, upon receipt, can make a reasonable decision about a potentially acceptable replacement proposal.

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

  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. It is the responsibility of the user agent to maintain 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 is a common negotiation strategy (the counterproposal), and perfectly appropriate. It implies a refusal, but provides an alternate that the user considers acceptable if accepted by the service. Notice that the service has the right to assume that by making the offer the user is willing to accept it if the service does (no further confirmation is required). Also notice that there is a privacy consideration, discussed earlier, when a user issues a proposal.
  3. Walk away from the negotiation. There is no requirement that the user agent respond at all. The user agent may also choose to respond but use a new connection and a new unique ID so that the service is unaware that it is the same agent.

The service, after receiving a Request for Text (RFT), can respond with a SRY message to indicate that it no longer has access the the text of the proposal requested by the user.  There is a reserved reason code for this purpose.  There is no other case in which the service issues a SRY message.

I Agree (OK)

After receiving a proposal from the other party, either party can respond by accepting the proposal. The response includes an agreement.  Recall that the fingerprint of the agreed upon proposal can be extracted from the agreement, and that the agreement may or may not include digital signatures of both parties.

Request for Data (RFD)

The service can, at any time, request that data be transmitted from the user (this includes the special case of requesting a unique identifier for collecting clickstream data). The request can be transmitted alone (with no commitment by the service as to the use of the data should it be transmitted) or accompanied by either:

There are four proper responses to a RFD: the user may walk away (this cannot be eliminated, since a network failure will cause this to occur even if the protocol were to "require" a response); the user may refuse with a reason (SRY); the user may send its own PROPosal back; or the user may transmit the requested data (TXD).

Transmit Data (TXD)

After the receipt of a Request For Data (RFD), the user may send out the requested data. The message can optionally include the agreement that the user understands is to be applied. The service is bound to honor the agreement if it is valid (signed by both sides if so required, within the proper time limits, and covering the data being transferred). If no agreement is transmitted the service is obliged to follow all of the agreements it has entered into that cover this transfer. (Notice that it is only in the case of signed agreements that the user will have convincing evidence that an agreement was made. In other cases, the user will have to rely on the honesty of the service. Since there is a cost associated with the signatures, this requires users to balance their trust of the service against the cost of the signature.)

The user is not obliged to respond to an RFD with a transfer of all the data requested, since the agreement may include optional elements. It is up to the user agent to decide how many of these to transfer (the agreement will have informed the user the consequences (presumably rewards) of sending the optional items).

Scenarios, Detailed

This section amplifies on the scenarios presented earlier, by providing a detailed description of how a combination of an appropriately configured browser and server can create these scenarios using the negotiation primitives proposed here.The interaction will be shown as a set of HTTP requests and responses, with the important part being the general flow of proposal and response. The precise details of the requests are not filled in at this time.

Lineflows of #1A (no negotiation, compatible practices & preferences):

The transaction begins:

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}

The user agent has requested a Web page, and indicates that it supports the P3P protocol.

HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

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

The service indicates that it supports the P3P protocol, and that it will not serve the requested resource without first reaching an agreement with the user agent. The user agent receives this response, accepts the proposal, and signifies its agreement with it.

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 20996-} {strength must}}
20996-P3P: {{OK-PROP XYZ} {TXD [data transfer with hash LMN]}

The user agent has now made a new request that indicates that it agrees to the previous proposal. The service finds this acceptable, and sends the object.

HTTP/1.1 200 OK
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 62090-} {strength must}}
62090-P3P: {{OK-TXD LMN}}
Content-type: text/html
Content-length: ...

...body...

Lineflows of #1B (no negotiation, incompatible practices & preferences):

We start with:

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}

The user agent has requested a Web page, and indicates that it supports the P3P protocol.

HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

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

The service indicates that it supports the P3P protocol, and that it will not serve the requested resource without first reaching an agreement with the user agent. The user agent receives this response, decides that it is unwilling to negotiate with the service, and the transfer halts.

Lineflows of #2A (negotiation, user agent does not provide a counter proposal):

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}

The user agent has requested a Web page, and indicates that it supports the P3P protocol.

HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

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

The user agent looks at the proposal, decides it is not acceptable, and refuses it.

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 4402-} {strength may}}
4402-P3P: {{SRY-PROP XYZ [explanation]}}

The service looks at the refusal, and offers an alternative proposal.

HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash PDQ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

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

If the user agent finds this alternative proposal acceptable, it accepts it:

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 52294-} {strength may}}
52294-P3P: {{OK-PROP PDQ} {TXD [data transfer with hash ABC]}

The user agent has now made a new request that indicates that it agrees to the previous proposal. The service finds this acceptable, and sends the object.

HTTP/1.1 200 OK
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 62090-} {strength must}}
62090-P3P: {{OK-TXD ABC}}
Content-type: text/html
Content-length: ...

...body...

On the other hand, if the user agent finds this alternative proposal unacceptable, it can refuse the proposal and demand an end to negotiation:

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 31567-} {strength must}}
31567-P3P: {{SRY-PROP PDQ} {STOP}

The user agent has now made a new request, refusing the alternative proposal, and indicating that it is unwilling to continue negotiating. The service can now send a non-personalized version of the requested object - or whatever it chooses to send if it cannot get information from the user agent.

HTTP/1.1 200 OK
Server: Marvin/2.0.1
Content-type: text/html
Content-length: ...

...non-personalized body (or an error message!)...

Lineflows of #2B (negotiation, user agent provides a counter proposal):

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}

The user agent has requested a Web page, and indicates that it supports the P3P protocol.

HTTP/1.1 400 Agreement required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 43-} {strength must}}
43-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 107

<html><body>
<h1>HTTP/1.1 400 Agreement Required</h1>
<p>Agree to this! We demand it!</p>
</body></html>

The user agent looks at the proposal, decides it is not acceptable, and refuses it. It also includes a counter proposal.

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1701-} {strength must}}
1701-P3P: {{SRY-PROP XYZ [explanation]} {PROP [proposal with hash DEF]}}

The service looks at the refusal and the counter proposal, and, if it is acceptable, it accepts that counter proposal.

HTTP/1.1 400 Data Required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1412-} {strength must}}
1412-P3P: {{OK-PROP DEF} {RFD [data request}}

The user now requests the document again, and sends the requested information:

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 4601-} {strength must}}
4601-P3P: {{TXD [data transfer with hash ABC]}

The user agent has now made a new request that sends the information the service needs. The service can now send the requested object:

HTTP/1.1 200 OK
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1414-} {strength must}}
1414-P3P: {{OK-TXD ABC}}
Content-type: text/html
Content-length: ...

...body...

On the other hand, if the service does not find this counter proposal acceptable, and does not wish to continue negotiating, it can refuse the counter proposal and not offer any alternatives. It may send an error message, or it may send a non-personalized version of the requested object. Here we show sending an error message:

HTTP/1.1 400 Agreement Required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 47819-} {strength DEF}}
47819-P3P: {{SRY-PROP {DEF reason-code}}}

At this point the conversation is ended.

All of our scenarios begin with the same action from the user, the request to follow a link that leads to the URL http://www.sales.com/Index.html. This causes the user agent to issue the HTTP request:
GET /Index.html HTTP/1.1

Accept: */*

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

Minimal (best case)

This case is the one we assume to be the most common: the site has practices that are acceptable to the user, and includes a proposal to apply those practices whenever it requests the transmission of data from the user.  This is why an RFD message can include a proposal (or an agreement).  In our case, we assume the service does not have access to an agreement previously made with this user.  This happens when a service wants data from the user:

  • on their first visit
  • when a user has not yet identified themself
  • when a service's policy changes
  • if the service does not store previously negotiated agreements, or
  • the service is configured to always offer a standard proposal

We first show the sequence of messages that occur when no digital signatures are used (hence the agreement might be repudiated by either side) .

HTTP/1.1 417 Request For Data

Server: Marvin/2.0.1

Protocol-Request: {W3C-P3P {P3P-Proposal P3P-RFD}}

P3P-Proposal: ...content of proposal... [note: fingerprint is XYZ]

P3P-RFD: ...list of data elements requested...



GET /Index.html HTTP/1.1

Accept: */*

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

Protocol-Request: {W3C-P3P {PDP-OK P3P-TXD}}

P3P-OK: XYZ [note: in this case, the fingerprint is the agreement]

P3P-TXD: ...data elements as requested...

At this point, the server responds as a current server would have responded to the original request, by supplying the contents of the request page:

HTTP/1.1 200 OK

Server: Marvin/2.0.1

Protocol-Request: {W3C-P3P {P3P-OK}}

P3P-OK: XYZ



Text of the page requested

We now consider the same sequence of messages generated when both the client and the service choose to sign the agreement, providing non-repudiable evidence for both sides that an agreement has been concluded.  Either side can retain  the agreement ("CDQ plus RDF signature (by client) of CDQ") plus the Signed Proposal ("content of proposal plus RDF signature on it (by assuring party) [note: fingerprint is CDQ]") as non-repudiable evidence of the agreement.  The service can, additionally, store the Signed Proposal for some period of time so that it can be retrieved by a client that wishes to review the text of the proposal before actually transmitting the data.

HTTP/1.1 417 Request For Data

Server: Marvin/2.0.1

Protocol-Request: {W3C-P3P {P3P-Proposal P3P-RFD}}

P3P-Proposal: content of proposal plus RDF signature on it (by assuring party)

              [note: fingerprint is CDQ]

P3P-RFD: ...list of data elements requested...



GET /Index.html HTTP/1.1

Accept: */*

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

Protocol-Request: {W3C-P3P {PDP-OK P3P-TXD}}

P3P-OK: CDQ plus RDF signature (by client) of CDQ

P3P-TXD: ...data elements as requested...



HTTP/1.1 200 OK

Server: Marvin/2.0.1

Protocol-Request: {W3C-P3P {P3P-OK}}

P3P-OK: CDQ plus RDF signature (by client) of CDQ



Text of the page requested

The above sequence of messages can be altered slightly to handle another common case: when the service knows the identity of the user and has access to a previously concluded agreement, the same messages will suffice if the agreement replaces the proposal in the RFD message above.

Service Requests Data Without Proposal

  1. At this point, the user-agent has several options: 1) walk away from the transaction, 2) accept the proposal as-is (perhaps after prompting for user intervention), or 3) make a counter-proposal. I present these as follows:
    1. If the user-agent wishes to walk away, we are done. No further communication is required.
    2. If the user-agent wishes to accept the proposal, it could send a request like the following:
      GET /Index.html HTTP/1.1
      Accept: */*
      User-Agent: BugblatterBeast/3.02 (RT-11; english)
      Protocol-Request: {W3C-P3P {P3P-Agreement}}
      P3P-Agreement: ...I agree to proposal #XYZ...

      Assuming that the service is still interested in accepting that proposal, it would respond with:
      HTTP/1.1 200 OK
      Server: Marvin/2.0.1
      Protocol-Request: {W3C-P3P {P3P-Agreement}}
      P3P-Agreement: ...the agreement that the user-agent sent...

      In this scheme, the user-agent has sent the proposal that it finds acceptable, and the service has returned it verbatim, indicating that it also agrees.

    3. If the user-agent wishes to make a counteroffer, the counteroffer follows the same form as accepting the proposal, but with a twist: the agreement is not to proposal XYZ that the service originally proposed, but rather to some variant of XYZ - call it XYZ1. In other words, the user-agent's request looks like:
      GET /Index.html HTTP/1.0
      Accept: */*
      User-Agent: BugblatterBeast/3.02 (RT-11; english)
      Protocol-Request: {W3C-P3P {P3P-Agreement P3P-Proposal}}
      P3P-Proposal: ...content of proposal #XYZ1...
      P3P-Agreement: ...I agree to proposal #XYZ1...

      The service then has three options: 1) refuse the user-agent's counter-proposal, 2) accept the counter-proposal as-is, or 3) offer yet another counter-proposal.
      1. For a service to "walk away", it can simply repeat its original proposal.
      2. For a service to accept the counter-proposal, behaves as in scenario 2) above: send the response, including the agreement that the user-agent sent. The service and user-agent have now exchanged an agreement, and they can now operate under the terms of that agreement.
      3. For a service to offer yet another counter-proposal, we jump back to the second step of this negotiation: the service returns a 416 Agreement Required response, and offers a new proposal.

Formats: Requirements And Specifications


A. Proposal

B. Refusal

C. Request for Data

D. Data

E. Agreement

Glossary

In addition to the terms defined earlier, the following terms are used in other P3P documents.

Access For P3P purposes, a clause that expresses the ability of users to obtain and correct information that an entity has collected about them. A vocabulary may define various degrees of access.
Agreement A statement that a service and a user agent have agreed to abide by.
Clause The "parts of speech" from which P3P statements are constructed.
Credentials Signed statements of authorization, identification, or practice (e.g. certificates granting authority or identity, or signed metadata). These credentials may be presented or be requested by either the user agent or the service.
Data category A quality of a data element or class that may be used by a trust engine to determine what type of element is under discussion (such as anonymous demographics versus personal contact information).
Data class A grouping of data elements such as mailing address (which includes, e.g., name, street address, city, state, and country).
Data element A single data entity such as last name or phone number.
Grammar (From Computing Dictionary) A formal definition of the syntactic structure of a language (see syntax), normally given in terms of production rules which specify the order of constituents and their sub-constituents in a sentence (a well-formed string in the language). Each rule has a left-hand side symbol naming a syntactic category (e.g. "noun-phrase" for a natural language grammar) and a right-hand side which is a sequence of zero or more symbols. Each symbol may be either a terminal symbol or a non-terminal symbol. A terminal symbol corresponds to one "lexeme" - a part of the sentence with no internal syntactic structure (e.g. an identifier or an operator in a computer language). A non-terminal symbol is the left-hand side of some rule.

One rule is normally designated as the top-level rule which gives the structure for a whole sentence. A grammar can be used either to parse a sentence (see parser) or to generate one. Parsing assigns a terminal syntactic category to each input token and a non-terminal category to each appropriate group of tokens, up to the level of the whole sentence. Parsing is usually preceded by lexical analysis. Generation starts from the top-level rule and chooses one alternative production wherever there is a choice.

Grammar (P3P) In P3P, the grammar defines the structure of P3P clauses used to make a valid P3P statement. The grammar are the rules for properly ordering clauses. The following example structures clauses (in the parentheses) to make a simple privacy practice statement:

for (these URIs)
the following (practices) apply
to this (set of data)
P3P data repository A mechanism for storing data under the control of P3P preferences over a period of time. These data might include personal data.
Permissions A set of conditions (e.g., access mode) which are specified on requested P3P data. A service asks the user agent to initially consent to permissions in conjunction with the service's commitment to follow its declared privacy practices.
Persona A persona is the combination of a set of user preferences and P3P data. Personae allow the user to create different views of themselves by changing the data given to a service. The persona may be based upon the service's purpose (e.g., business, gaming, home, etc.), credentials (e.g., level of associated trust), consequences and practices (e.g., personalization, shipping, mailing list), or any user defined rationale (e.g., time of day, phase of moon, etc). A user may have multiple personae.
Policies The collection of all user defined preferences, including, but not limited to, P3P preferences.
Protocol (From the Computing Dictionary) A set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc.
Practice A P3P clause that describes what a service plans to do with data.
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., a PICSRules rule. In this document, preferences govern the types of agreements that can be reached between a user agent and a service.

Within this document, "preferences" are assumed to be P3P preferences.
Proposal A series of statements. A proposal is used when a user agent and a service are negotiating to form an agreement.
Request A message in which a service asks a user agent to transmit (read request) or store (write request) a data element or set of data elements.
Result set The user's data sent to the service by the user agent.
Service A program, for P3P purposes, requesting data from, or providing data to, a user agent. By this definition, a service may be a server, a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent.
Statement A description of what data a service will request, what the service will do with it, and the consequence to the user.
Syntax (From Computing Dictionary) The structure of strings in some language. A language's syntax is described by a grammar. For example, the syntax of a binary number could be expressed as

binary_number = bit [binary_number]

bit = "0" | "1"

meaning that a binary number is a bit optionally followed by a binary number and a bit is a literal zero or one digit. The meaning of the language is given by its semantics.

Trust Engine A mechanism for evaluating incoming statements to make a decision. For P3P purposes, the trust engine evaluates P3P proposals and requests.
User An individual or group of individuals acting as a single entity. For the purposes of this document, the user is further qualified as an entity for which personal data exists and/or can be collected.
User agent A program that acts on a user's behalf. The user agent may act on preferences (rules) for a broad range of purposes, such as content filtering, trust decisions, or privacy. For P3P purposes, a user agent acts on a user's privacy preferences. Users may use different user agents at different times.
Vocabulary (schema) The defined set of words or statements that are allowable in a clause. For instance, a vocabulary may define the practice clause to be one of the two values: 'for system administration', 'for research'.

posted by: philipd@w3.org

Last modified: Wednesday, December 31, 1997 09:39:42 AM Eastern Standard Time