NOTE-P3P10-Protocols-19980324
NOTE-P3P10-Protocols-19980324
|
|
|
|
Status of This DocumentThis W3C NOTE is provided for historical purposes only. It is not part of the P3P specification and need not be read to understand P3P. It is an intermediary product, from the Format and Protocol WG, of the P3P Activity. This document was completed in March, but is being released concurrently with the public Working Draft of the Specification. It is published because much of the work and contributors on this document was instrumental to the development of the specification. Parts of this document may be incomplete, it will not be updated and it will not be advanced toward W3C recommendation status. This document is a NOTE made available by the W3 Consortium for archival purposes. This indicates no endorsement of its content. |
|
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 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.
P3P is attempting to provide mechanisms:
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 on alternative practices that both entities can agree to. 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.).
This Working Group is tasked with describing the set of negotiation primitives (and their proper ordering) necessary for arriving at an agreement and answering related questions related to those primitives such as how they can be digitally signed when that technology is deployed. There are a number of tasks related to this problem space which are not part of this Working Group's scope:
In addition to the terms defined in earlier P3P documents, the following terms are used consistently throughout this document:
| Term | Definition |
| Data Element | An individual data entity, such as last name or phone number. |
| Data Category | A significant attribute of a data element or set that may be used by a trust engine to determine what type of element is under discussion, such as physical contact information. |
| Data Set | A known grouping of data elements, such as mailing address. |
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:
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.
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. The hash protocol is an MD5 digest in US-ASCII characters using MIME base-64 encoding.
Assuring Party
Within P3P, an assuring party attests that the service will
abide by its proposal, follows guidelines in the processing of data or other
relevant assetions; this assurance may come from the service or an independent
assuring party.The assuring party musts identify
what they are attesting to as part of the assurance statement. (This may
happen within the statement, or as part of the semantic definition of a meta-data
schema.)
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 collect a
specified set of information (or an offer to provide a service without collecting
any information) from a user for a particular purpose and under a specific
set conditions. 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 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 will 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. This functionality is not available for P3P1.0.
Signed Proposal
A signed proposal is a proposal that has an attached
digital signature. A
signed proposal from
the service is signed by an entity, the assuring party,
willing to assure that the service will abide by the proposal. A
signed sroposal from the user is signed by the user.
In the short term, we assume the likely hood of assuring parties (which may
be the service itself) to sign proposals is greater than that of user agent
signatures because of the lack of a well established client side certificate
infrastructure.
Signed Agreement
A signed aggrement is an agreement between the service
and user that has one or more attached digital signatures. A
signed agreement is signed by the assuring party
and the user. The same caveat regarding the existence of client side certificates
as expressed above applies.
P3P makes several assumptions about the environment in which it works and the problem it is trying to solve.
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.
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.
Service operation
Agent operation
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.
User view
Service operation
Agent operation
As mentioned above, this scenario does not specify the interaction between the user agent and the user.
In the next scenario, a service initiates a request to exchange data. The user responds by refusing to provide the data. 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 -- for example, the user may agree to partially satisfy the initial request. (Such as "I will provide my age and zip code but not my name and address.") If a counter proposal is provided by the user, the service responds by accepting or rejecting it. If no counter proposal is provided, or if it is rejected, the service may send another proposal to the user. This "negotiation" may continue until an offer is accepted or one of the parties decides to end the negotiation.
Service operation
Agent operation
User view
Service operation
Agent operation
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.
A request could be issed in the absense of an agreement. This may because the service believed that it had an agreement whereas the user did not. (Perhaps it never did, or it only has a short memory). A user agent that does not have such a policy will request a proposal. In very rare cases, in some people's implementations other circumstances beyond privacy practices could allow such a request to be issued. (For instance, perhaps the users trusted email application running on the users machine is querying the users' repository for an email address, in this case, the user doesn't require privacy practices from the email application. This is not within the scope of this document however.)
Services have several responsibilities in order to have reasonable error situations:
User agents are responsible for several error scenarios are well:
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 |
| OK-PROP | Proposal acceptable | Yes | Yes | PROP | none | Agreement | Signature of recipient of proposal |
| 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-PROP or PROP | Text of a proposal | Signature of initiator, fingerprint of previous Proposal |
| RFD | Request for Data | No | Yes | any time | SRY-RFD, PROP, RFP, RFT or TXD | Names of data elements, sets of data elements, or categories | Previous agreement if not sent with a new proposal |
| RFP | Request for Proposal | Yes | Yes | any time | PROPor SRY-RFP | Must agreement be signed? | Set of URLs to be covered |
| RFT | Request for Text of Proposal | Yes | No | Agreement | PROP or SRY-RFT | Agreement | |
| SRY-PROP | Refuse Proposal | Yes | Yes | PROP | PROP | Fingerprint of proposal refused, Reason | Which practices are unacceptable (To Be Designed) |
| SRY-RFD | Refuse RFD | Yes | Yes | RFD | none | Agreement refused, Reason | |
| SRY-RFP | I won't give you a Proposal | Yes | Yes | RFP | none | Reason | |
| SRY-RFT | Proposal Text not available | No | Yes | RFT | none | Agreement, Reason | |
| SRY-TXD | Data transfer not successfull | Yes | No | TXD or none | none | Agreement, Reason | |
| STOP | Stop negotiation | Yes | No | any time before reaching an agreement | Good question! | none | |
| TXD | Transfer Data | Yes | Yes | any time | none, OK-TXD or SRY-TXD | Data element names and values to be written, as requested | Agreement |
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 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.
This message is sent after an entity has successfully received the contents of a Transmit Data (TXD) message.
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 (see the OK-PROP 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). If a site wished 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 ambigous; there is not a strong mechanism 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 unambigous proposals.
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).
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:
In time, the capability to send a subset of the user's preferences to better help the service make an informed proposal may exist.
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-RFD); the user may send its own PROPosal back; or the user may transmit the requested data (TXD).
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_RFT, if the server no longer has a record of the agreement and is unable to regenerate it algorithmically.
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.
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 technical cause for refusing a proposal are given by the reason codes. Reasons, such as the user's preferences not matching the site's practices, are not returned at this point. Sites may provide capabilities on their privacy practice page whereby users can inform a site of practices that they did not find appealing. Future versions of P3P may be able to enable the expression of reasons that are sufficiently specified that the service, upon receipt, can make a reasonable decision about a potentially acceptable replacement proposal.
The recipient, after receiving a Request for Data (RFD) can respond with a SRY_RFD message. The reason code describes whether the RFD was denied because the recipient does not recognize an agreement contained in the RFD request or if the recipient wants to terminate the agreement.
The service after receiving a Request for Proposal (RFP) can respond with a SRY-RFP message to indicate that it will not make a proposal.
The service after receiving a Request for Text (RFT) can respond with a SRY-RFT message to indicate that it no longer has access the text of the proposal requested by the user.
The recipient after receiving a Transmit Data (TXD) can respond with a SRY-TXD message to indicate that it did not successfully receive the data. The sender may re-try the TXD message but should prevent an infinite loop of re-tries.
At any time before an agreement is reached, the recipient can respond with a STOP message to indicate that it does not want to continue negotiations. If there is still an http request outstanding, the server should still respond to the request, even if the response is merely an HTML document indicating that the requested object cannot be returned without an agreement.
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).
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.
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...
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.
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 303 Proposal Rejected}}
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 303 Proposal Rejected} {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!)...
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 303 Proposal Rejected} {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 303 Proposal Rejected} {STOP})
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)
This case is the one we assume to be the most common: that 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:
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.
If a service requests data without a proposal 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. These options are described as follows:
The syntax of P3P negotiation primitives is provided below. See notation for a brief description of RFC2234 ABNF.
[1] |
p3p-request |
:= |
start-lineessage-header"OPT" ":" p3p-opt-header [p3p-header-prefix "P3P" ":" p3p-header CRLF] [ messag e-body ]
/* start-line, message-header, CRLF, and |
The user agent communicates to the server using standard methods such as
"GET" or "POST". When placing an initial request to the server, the P3P PEP
header is included to notify the server that the user agent is
P3P-compliant.
The server sets status code 400 for responses other than OK-*, which provides
status 200.
| [2] | p3p-opt-header |
= |
p3p-extension ";" "ns-" p3p-header-prefix |
| [3] | p3p-extension |
= |
<"> http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/ <"> |
| [4] | p3p-header-prefix |
= |
1*digit "-" |
| [5] | p3p-header |
= |
"{" p3p-message+ "}" qualifier*
|
| [6] | qualifier |
= |
"FINAL" | token |
| [7] | p3p-message |
= |
"{" p3p-content "}"
|
| [8] | p3p-content |
= |
OK-PROP-msg | OK-TXD-msg | PROP-msg | RFD-msg | RFP-msg | RFT-msg | SRY-PROP-msg | SRY-RFD-msg | SRY-RFP-msg | SRY-RFT-msg | SRY-TXD-msg | STOP-msg | TXD-msg |
| [9] | OK-PROP-msg |
= |
"OK-PROP" fingerprint [sigblock] |
| [10] | OK-TXD-msg |
= |
"OK-TXD" fingerprint |
| [11] | PROP-msg |
= |
"PROP" 1*(proposal [sigblock] [fingerprint) |
| [12] | RFD-msg |
= |
"RFD" fingerprint data-request |
| [13] | RFP-msg |
= |
"RFP" realm |
| [14] | RFT-msg |
= |
"RFT" fingerprint |
| [15] | SRY-PROP-msg |
= |
"SRY-PROP" fingerprint reason-code |
| [16] | SRY-RFD-msg |
= |
"SRY-RFD" agreement reason-code |
| [17] | SRY-RFP-msg |
= |
"SRY-RFP" reason-code |
| [18] | SRY-RFT-msg |
= |
"SRY-RFT" fingerprint reason-code |
| [19] | SRY-TXD-msg |
= |
"SRY-TXD" fingerprint reason-code |
| [20] | STOP-msg |
= |
"STOP" |
| [21] | TXD-msg |
= |
"TXD" fingerprint data-xfer |
| [22] | proposal |
= |
/* see proposal BNF */ |
| [23] | data-xfer |
= |
/* RDF format data element name-value pairs */ |
| [24] | data-request |
= |
/* (fingerprint)* and RDF format list of data-elements or sets */ |
| [25] | fingerprint |
= |
/* hash of proposal or data-xfer */ The hash protocol is an MD5 digest in US-ASCII characters using MIME base-64 encoding. |
| [26] | sigblock |
= |
/* as per [DSIG] */ |
| [27] | FINAL |
= |
/* The "FINAL" qualifier indicates that the set of proposals represent final offers and no alternative offers will be made if they are all rejected. */ |
The reason codes are as follows
[28] |
reason code |
= |
/* 3xx Rejection Codes*/ "301 Unrecognized Agreement" | /*(SRY-RFD, SRY-RFT, SRY-TXD)*/ "302 Agreement Expired" | /*(SRY-RFD, SRY-RFT, SRY-TXD)*/ "303 Proposal Rejected" | /*(SRY-PROP)*/ "305 Data unavailable" | /*(SRY-RFD)*/ "306 Text unavailable" | /*(SRY-RFT)*/ "307 Agreement Recinded" | /*(SRY-RFD, SRY-RFT)*/ "308 RFP Rejected" | /*(SRY-RFP)*/ "309 Data not accepted" | /*(SRY-RFD, SRY-RFT, SRY-TXD)*/ /* 4xx Error Codes */ "401 Invalid Format" | /*(ALL)*/ "402 Data transfer unsuccessful" | /*(SRY-TXD)*/ "403 Invalid Signature" | /*(SRY-PROP)*/
|
The following schema syntaxes should be used to create well formed (signed) RDF declarations. An example encoding has been created as part of the Harmonization Encoding work. The RDF Schema Working Group will further define the method for specifying RDF schema. The following is in simple BNF, it will have to be modified appropriately so that:
Consensus Note: Much
of the work done on the schema beyond the the proposal (which was defined
first in the P3P
Grammar Working Draft) was conducted under signficant time pressure.
Accordingly, a number of these schema may need to be revisited in the future
by the W3C or other entities as appropriate. Issues encountered in the creation
of the following schema are documented accordingly:
|
| Schema <?namespace
href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pproposal1.0#"
as="proposal"?> Status: Required |
|||
[1] |
proposal |
= |
"in" proposal_schema "for" experience-space entity "will" 1*p3p-statement "assured_by" assurance /* Where "'in' proposal_schema" defines the semantics over all the schema used in P3P1.0 including the ones in the core schemea "proposal": purpose, purpose_qualifier, identifiable, domain_of_use data_set, data_qualifier, data_required, and access */ |
[2] |
experience-space |
= |
/* RDF/XML-experience-space or a URL */ |
[3] |
assurance |
= |
quoted-string :: '"' UTF-7 '"' /*URI:HTML:XML:BASE64 */ |
[4] |
entity |
= |
quoted-string :: '"' UTF-7 '"' |
[5] |
p3p-statement |
= |
"for" experience-space ( (1*purpose)(1*purpose-qualifier) "will apply to" (*data-set *data-category data-required) "with" consequence "see general disclosures at" [disclosure] URL |
[6] |
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" | ("Other Uses" quoted-string))
|
[7] |
consequence |
= |
quoted-string |
[8] |
purpose-qualifier |
= |
identifiable domain-of-use [access] |
[9] |
identifiable |
= |
"("0" | "no") | ("1" | "yes")
|
[10] |
domain-of-use |
= |
("0" | "only ourselves and our agents") |
("1" | "organizations following our practices") |
("2" | "organizations following different practices") |
("3" | "unrelated third parties or public fora")
|
[11] |
data-set |
= |
/* Paul and Philip have a list, also, it may make sense to just make this the data-request */ |
[12] |
data-qualifier |
= |
data-required |
[13] |
data-required |
= |
("0" | "no") | ("1" | "yes") /* default yes */
|
[14] |
quoted-string |
= |
'"' UTF-7 '"' |
[15] |
URL |
= |
/* as defined in RFC-1738 */ |
| /* the following may be optional */ | |||
[16] |
access |
= |
("0" | "no") | ("1" | "yes")
|
| Schema <?namespace
href="hhttp://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pdisclosure1.0#"
as="disclosure"?> Status: Optional |
|||
| [1] | disclosure |
= | access-disclosure assurance-disclosure [other-disclosure] |
| [2] | access-disclosure |
= | ("0" | "Identifiable Data is Not Used") |
("1" | "Identifiable Contact Information") |
("2" | "Other Identifiable Information") |
("3" | "None")
|
| [3] | assurance-disclosure |
"("0" | "no") | ("1" | "yes")
|
|
[4] |
other-disclosure |
= |
[("0" | "change_agreement")] | [("1" | "retention")]
|
| Schema <?namespace
href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pcategories1.0#"
as="categories"?> Status: Optional |
|||
[1] |
data-category |
= |
|
| Schema <?namespace
href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pelements1.0#"
as="dataset"?> Status: Required |
|||
[1] |
data-set |
= |
1*(/*one of the following*/) |
The following are the standard data elements and sets. These data elements and sets may not be modified or deleted by either the service or the user agent
Consensus Note: When
the group was confronted with the issue of which base data elements to include
in the specification, two issues made the development of the data element
set difficult:
The group was not able to definitevely resolve either of these questions. With respect to the first question, we can state that the inclusion of an element does not mean sites should not exercise caution when asking for data. Some things, like session_ID and site_ID, are common and important enough that we did name them and place them under user control. However, we shyed away from including race, religious or health elements in the core set. With respect to the second question, we define a system schema, but include few elements. The issue of which elements are in the P3P base set may require future W3C work, the P3P set is indepedently extensible regardless. |
| #User | Category | Type | Short display name |
| User.Name.Prefix | Demographic | Text | Name Prefix |
| User.Name.First | Physical Contact | Text | First Name |
| User.Name.Last | Physical Contact | Text | Last Name |
| User.Name.Middle | Physical Contact | Text | Middle Name |
| User.Name.Suffix | Demographic | Text | Name Suffix |
| User.Photo | Physical Contact | graphic | User Photograph |
| User.Bdate | Demographic | date | Birthdate |
| User.IDCert | Physical Contact | Text | Identity Certificate |
| #User.Demo | Category | Type | User Demographics |
| User.Demo.Country | Demographic | Country | Country x.520 |
| User.Demo.Postal | Demographic | Text | Postal Code x.520 |
| User.Demo.Age | Demographic | Number | Age |
| User.Demo.Gender | Demographic | Gender | Gender |
| #User.Home | Category | Type | Home |
| User.Home.Formatted_Name | Physical Contact | Text | Formatted Name |
| User.Home.Address.Street1 | Physical Contact | Text | Street Address Line 1 |
| User.Home.Address.Street2 | Physical Contact | Text | Street Address Line 2 |
| User.Home.Address.City | Physical Contact | Text | City |
| User.Home.Address.PostCode | Physical Contact | Text | PostCode |
| User.Home.Address.State_Prov | Physical Contact | Text | State or Province |
| User.Home.Address.Country | Physical Contact | Country | Country |
| User.Home.Phone | Physical Contact | Number | Phone |
| User.Home.Fax | Physical Contact | Number | Fax |
| User.Home.Cellular | Physical Contact | Number | Cellular |
| User.Home.Email | Online Contact | Text | |
| User.Home.URL | Online Contact | URL | HomePage |
| User.Home.TZ | Text | Time Zone | |
| #User.Shipping | Category | Type | Shippin Information |
| User.Shipping.Formatted_Name | Physical Contact | Text | Formatted Name |
| User.Shipping.Address.Street1 | Physical Contact | Text | Street Address Line 1 |
| User.Shipping.Address.Street2 | Physical Contact | Text | Street Address Line 2 |
| User.Shipping.Address.City | Physical Contact | Text | City |
| User.Shipping.Address.PostCode | Physical Contact | Text | PostCode x.520 |
| User.Shipping.Address.State_Prov | Physical Contact | Text | State or Province |
| User.Shipping.Address.Country | Physical Contact | Country | Country x.520 |
| User.Shipping.Method1 | Physical Contact | Text | 1st Preffered shipping method |
| User.Shipping.Method2 | Physical Contact | Text | 2nd preffered shipping method |
| #User.Business | Category | Type | Business |
| User.Business.Company | Physical Contact | Text | Company |
| User.Business.FormattedName | Physical Contact | Text | Formatted Name |
| User.Business.SIC_Code | Text | Industry SIC Code | |
| User.Business.DUNS_Number | Text | D&B Number | |
| User.Ticker.Symbol | Text | Stock Symbol | |
| User.Business.Logo | Graphic | Business Logo | |
| User.Business.JobTitle | Demographic | Text | Job Title |
| User.Business.Department | Physical Contact | Text | Department |
| User.Business.Office | Physical Contact | Text | Office |
| User.Business.Address.Street1 | Physical Contact | Text | Street Address Line 1 |
| User.Business.Address.Street2 | Physical Contact | Text | Street Address Line 2 |
| User.Business.Address.Street3 | Physical Contact | Text | Street Address Line 3 |
| User.Business.Address.City | Physical Contact | Text | City |
| User.Business.Address.Postal | Physical Contact | Text | Postal Code |
| User.Business.Address.State_Prov | Physical Contact | Text | State or Province |
| User.Business.Address.Country | Physical Contact | Country | Country |
| User.Business.Phone | Physical Contact | Phone | Phone |
| User.Business.Fax | Physical Contact | Phone | Fax |
| User.Business.Pager | Physical Contact | Phone | Pager |
| User.Business.Email | Online Contact | ||
| User.Business.URL | Online Contact | URL | Home Page |
| #System.Computer | Category | Type | Short display name |
| System.Computer.Info | Computer Information | Text | Information about your computer, OS, CPU, etc. |
| <otherwise, see http://www.w3.org/TR/NOTE-agent-attributes > | |||
| #System.Web | Category | Type | Short display name |
| System.Web.Client_Click_Stream | Navigation and Click-stream Data | Binary | Click Stream collected on the server. |
| System.Web.Server_Click_Stream |
|
Binary | Click Stream collected on the client. |
| System.Web.Search_Text | Transaction Data | Text | Search keywords |
| System.Web.HTML_Form | Transaction Data | Text | Form data not including search terms |
| System.Web.PUID | Unique Identifiers | Number | Pairwise or Site ID |
| System.Web.TUID | Unique Identifiers | Number | Temporary or Session ID |
The formal grammar of P3P is given in this specification using the ABNF defined in http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt . The following is a simple description of the ABNF.
Other notations used in the productions are:
/* ... */
[This section is very relevant to the Implementation Guide.]
Authors:
The purpose of this section is to describe the nature of the client side data store. This includes the basic building blocks, the general expectations for the client and the standard data categories and elements. This document is not a design specification. It is meant to outline requirements without defining implementation. Therefore, examples should be taken as merely that and should not be used to limit the possible implementations.
| Term | Definition |
| Data Element | An individual data entity, such as last name or phone number. |
| Data Category | A significant attribute of a data element or set that may be used by a trust engine to determine what type of element is under discussion, such as physical contact information. |
| Data Set | A known grouping of data elements, such as mailing address. |
| Persona | One or more data elements used to create a set representing an image or personality presented to a service. |
| Profile | Data entered by the user or the service that describes service specific information, such as user preference categories. |
| Identity | The single persistent attribute by which the individual may always be known. |
The following assumptions are made in this document:
A data element represents a single piece of information. This information may be a singleton, such as last name, or a stream of information, such as the user’s click stream. There is a base set of standard data elements (see the Standard Data Requirements).
Services, or user applications, may create additional data elements as allowed by the user.
In order to prevent accidental duplication of element names, as well as to allow for a certain degree of standardization, the following naming conventions should be applied:
Associated with the data element is an expected data type. The data types of each attribute are expressed in terms of the X.520 specification and [IETF-VCARD]. For example, the birth date (BDAY) is formatted in the same manner as the corresponding BDAY attribute in [IETF-VCARD].
Note: VCARD is used throughout this document by way of example and not as an endorsement of that standard.
The defined formats are:
Data categories are used to classify data elements based upon the conceptual schema underlying the privacy policy. They provide context to proposals but can not be the sole referent of a request for data using P3P methods. A site may not say, "I would like all of your demographic data under this agreement." No data category is implicitly more identifiable than another. Often, identity can be derived from seemingly non-identifiable characteristics like zip-code, gender, and birthdate. Consequently, it is the service's use of data that is identifiable or not. Obviously many of the elements in the category Contact Information will be used in an identifiable way.
Data categories do provide several advantages.
First, data categories can be used to identify the type of information the service will be requesting. The user agent can match the preference to the category without further parsing. If preferences are expressed over categories, and there is not a match, the user agent can reject the service, investigate the specific data set or elements, or move to the start of the next policy statement. However, such an implementations could be abused by services that request sensitive data elements under a relatively non-sensitive data category, this is a major privacy concern. We recommend that implementations parse and make decisions on the basis of requests and preferences over data sets and elements. See note on GUIs.
Second, data categories can identify the type of data element when the element is unknown to the user agent. This may happen when a new data set or element is proposed to the user agent, or when data is collected from a form (HTML_put). This provides a further to the user of the data the service is asking him to provide.
Finally, the user agent can use the category to determine whether the service can write the element into the P3P data repository.
The following are the ten specified P3P data categories (see http://www.w3.org/P3P/Group/Harmonization/Drafts/P3P-harmonization-980120.html for further information)
In the simplest terms, a data set is a named set of data elements. The organization of data elements into logical sets provides a short hand means of requesting a groups of data elements, such as mailing address, without the need to request each data element. This should reduce the amount of time required to request and negotiate for data. Further, the use of a set notation can be used by the implementation to quickly locate the actual set of data elements regardless of the data repository implementation.
The assumption here is that the base set of P3P sets should address 90% of the requests for user data.
It should be remembered that the P3P data repository is not meant to retain all of the information requested by a service. There will be some data elements that will not be requested by many or any other service. It is anticipated that this information will be stored with the service.
Further, the number of services requesting the storage of service specific data elements will be less than the number relying upon common elements. Allowing the service to create it’s own grouping, or set, of data containing those data elements should reduce latency by providing the short hand notation of the data set.
The base set of P3P sets, as defined in the section on Standard Data Elements and Sets, can not be changed by the either the user agent or a service. Data sets share in the naming convention of data elements, adding the following:
Treating data sets as objects gives the advantage of the concept of inheritance. "Inheritance", as meant here, allows a service or user agent to create a new data element grouping without necessarily replicating all of the data elements. For example, if a service wants all of the information in the base shipping_address set, plus a single identification code representing the invoice, all that needs to be stored by the user agent is the service’s set name, a reference to the shipping_address set and the new data element:
#shipping_address
invoice
Data set notation has the advantage of allowing the user agent to track the information requested by any service. However, this is really an implementation detail as to whether the data repository should/would track all information requests and store transactional information, such as the invoice. Due to the fact that this shorthand notation is violated when the user opts to change the shipping address information for the specific occurrence or service, it would be more common to find the service storing the shipping information on their server, rather than be dependent upon the user data repository.
Another advantage of data sets, in the simple case, is the reduction of data replication. If the user wants to reuse the #shipping_address information without change, then associating the set notation with a service’s name space becomes an accurate representation of the data shared without actually needing to maintain and store duplicates (e.g., Nike::#shipping_address)
Since data sets may contain data elements from more than one category, a set may be placed into multiple categories. The way in which this information is stored is implementation specific. However, the transport mechanism may be used to indicate the data categories, as well as the data elements as designed.
Note: it is difficult to expand upon the notion of categories and semantic transport without an understanding of the transport mechanism itself. If RDF is used, then the transport is more graphical in nature, than if XML’s hierarchical notion is chosen. It is assumed that the transport is through HTTP.
[DSIG] Recommendation: DSig 1.0 Signature Labels Specification: Using PICS 1.1 Labels for Making Signed Assertions. Yang-Hua Chu, Philip DesAutels, Brian LaMacchia, Peter Lipp. World Wide Web Consortium. 03-April-1998.
[HTTP1.1] RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1. Fielding, Gettys, Mogul, Frystyk, Berners-Lee. IETF. January 1997.
[ISO 3166] Codes for The Representation of Names of Countries. International Organization for Standardization, December, 1993.
[RDF] Working Draft: Resource Description Framework (RDF) Model and Syntax Specification. Ora Lassila, Ralph R. Swick. World Wide Web Consortium. 16-February-1998.
[MD5] RFC 1321: The MD5 Message Digest Algorithm, Rivest. IETF. April 1992.
[PEP] Working Draft: PEP Specification: an Extension Mechanism for HTTP. Henrik Frystyk Nielsen, Dan Connolly, Rohit Khare, Eric Prud'hommeaux. World Wide Web Consortium. 21-November-1997.
[XML] Recommendation: Extensible Markup Language (XML) 1.0 Specification. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen. World Wide Web Consortium. 10-February-1998.
[VCARD] vCard - The Electronic Business Card Version 2.1. Internet Mail Consortium, September 18, 1996.
posted by: reagle@w3.org