WD-P3P-Syntax-19980519
WD-P3P-Syntax-19980519
|
|
Status of This DocumentThis is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and will be updated at least once (the first within 6 weeks) before being advanced towards proposed recommendation status. This document has been produced as part of the P3P Activity, and will eventually be advanced toward W3C Recommendation status. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." While this is the first public draft the underlying concepts of the draft are fairly stable and we encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document. For instance, XML elements and attributes are presently named for readability, though they may shortened to decrease the size of the encodings. This draft document will be considered by W3C and its members according to W3C process. This document is made public for the purpose of receiving comments that inform the W3C membership and staff on issues likely to affect the implementation, acceptance, and adoption of P3P. Comments should be sent to p3p-comments@w3.org. ___ Copyright © 1998 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. |
The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices and users to exercise preferences over those practices. P3P compliant products will allow users to be informed of site practices (in both machine and human readable formats), to delegate decisions to their computer when appropriate, and allow users to tailor their relationship to specific sites. Site practices that are compatible with a user's preferences can, at the user's option, be accessed "seamlessly". Otherwise users will be notified of a site's practices and have the opportunity to agree to those terms or other terms and continue browsing if they wish.
P3P gives users the ability to make informed decisions regarding their Web experience and their the ability to control the use of their information. Sites can use P3P to increase the level of confidence users place in their services, as well as improve the quality of the services offered, customize content, and simplify site access.
P3P uses RDF/XML for the exchange of structured data and assertions. P3P will support future digital certificate and digital signature capabilities. P3P can be incorporated into browsers, browser plug-ins, servers, or proxy servers that sit between a client and server.
The P3P specification provides mechanisms:
This document includes all the specification necessary for the implementation of interoperable P3P applications. This specification was built upon the work of previous working groups and includes:
We use the following typographical conventions for representing the status of text:
| Schema definition in ABNF notation. |
The ABNF notation used in this specification is specified in RFC2234 and summarized in an appendix. The DTDs provided in the Appendix are non-normative and are provided only as an exercise in ensuring the robustness of the data structures.
A P3P proposal consists of one or more statements, each of which expresses
privacy practices for a set of data elements. The P3P proposal should cover
all relevant data elements and practices: if a service wants to collect a
data element, it must be mentioned in the proposal. Note that most declarations
in P3P are positive, meaning you state what you do, rather than what you
do not do.
A core concept to the P3P specification is that of a P3P agreement. A P3P
agreement is a proposal agreed to by both the service and user agent. User
agents compare the privacy practices specified in a proposal with the user's
preferences to determine whether to enter into an agreement. An agreement
applies to all data exchanged between the user agent and service within a
specified realm -- a Web resource or "tree" of Web resources referenced by
a single URI, or list of Web resources referenced by a list of URIs.
Once an agreement is reached the enumerated data elements that are included
in the agreed-to proposal should be interpreted by the user agent as data
requests from the service. It is possible to have an agreement without
referencing data elements. Such an agreement states that no information is
collected.
When privacy practices do not match the user's preferences, the two sides can come to an agreement by exchanging alternative proposals. Every proposal can have a set of consequences that can be shown to a human user to explain why the suggested practice may be valuable in a particular instance even if the user would not normally allow the practice. We expect user agents will record the agreements reached, indexed by a fingerprint of the agreement, called the agreementID.
Rather than sending a new proposal to the user agent on every contact, a site may send the agreementID of an existing agreement. This is 1) asserting that the service and the user agent have already agreed to a proposal, 2) signaling which proposal and privacy practices it is operating under, and 3) requesting those data elements referenced in the agreement. The user agent may turn away, respond with the requested data, or request a full proposal -- if either it has no record of such an agreement or it desires a new one.
Sites also have the capability, as part their proposal, to request that a Temporary or Pairwise Unique ID (TUID/PUID) be automatically sent to the site when the user agent returns. A PUID is similar to a cookie but under P3P control and limited to a numerical field.
Our design is such that applications can be efficiently implemented independent of our assumptions or expectations regarding the latency of multi-round communications, the cacheability of proposals, the use of user agent or server side data repositories, and the size of the agreement repositories.
P3P makes several assumptions about the environment in which it works and the problem it is trying to solve.
The following scenarios are designed to illustrate several possible ways that P3P might be used. Each scenario highlights a different P3P feature. Scenario 1 shows how a basic P3P agreement is established. Scenarios 2 and 3 show what happens when a user returns to a site where an agreement has already been reached. Scenarios 4 and 5 highlight the use of the user data repository given existing agreements.
The scenarios illustrate interactions in which no negotiation occurs. However, any scenario could be expanded to one in which a site initially offers multiple proposals, or one in which a series of proposals and/or counter-proposals are exchanged between the site and the user. The expanded example scenario in the Appendix includes an example of negotiation.
The table below summarizes the features of each scenario. A "-" in the table
indicates a feature about which no assumptions (neutral) are made in a given
scenario.
| Scenario | Existing Agreement | New Proposal | PUID Requested | Data Requested | Data Written |
| 1 | No | Yes | Yes | - | - |
| 2 | Yes | No | No | - | - |
| 3 | Yes | Yes | Yes | - | - |
| 4 | - | - | - | Yes | No |
| 5 | - | - | - | Yes | Yes |
Protocol Scenario: Client sends OPT header to server. If server does not support P3P, it will merely return content. (This content could be a HTML form which transfers information to a server using traditional CGI methods.) If the server supports P3P and has a relevant proposal, server shall return 409 with content and a proposal for P3P clients in a header, HTML header, or as referenced by a URI.
Protocol Scenario: Client sends OPT header to server, and all relevant returnIDs. Server returns relevant content or (orthogonally) can send subsequent P3P data-requests (TXD with agreementID).
Protocol Scenario: Scenario 5 is an extension of scenario 4 which assumes that scenario 4 ended with the user agent sending an OK and optionally a TXD to the server. Now the server will reply with its own TXD sending the appropriate data elements to the client. If successful the user agent will respond with an OK/200 return code; if unsuccessful the client will respond with SRY/500 return code.
The following section specifies primitives necessary for forming an agreement and transferring any subsequent data if appropriate.
P3P was designed to exchange the primitives and their content in the headers of a P3P HTTP extension. However, we foresee instances in which the content of the PROP or TXD primitives could exceed the expected length of a header in some HTTP implementations (e.g. a large graphical image). Hence, as an application of RDF/XML, P3P implementations should be able to conform to methods of RDF/XML exchange when those methods are completely specified. Those methods are likely to be:
P3P1.0 specifies a required method for methods 1-3.
| Scenario | Proposal-URI | Post-URI | Proposal Embedded in Content |
| 6 | Yes | - | No |
| 7 | No | - | Yes |
| 8 | - | Yes | - |
The service believes that an intermediary proxy cache might truncate long HTTP headers, or the service would like to its proposal to be cached at a proxy:
The proposal-URI is not relevant to the definition of the realm. Rather, implementations which need to make trust decisions on the basis of the realm should make them with respect to the REALM defined in the proposal, and the original URI they fetched in scenario (1).
Content providers may wish to declare simple privacy practices without the sending modified HTTP headers. In such a case, sites MAY embed a simple P3P proposal within the HTML HEAD tag. Since a P3P proposal does not contain content within tags (<tag>content</tag>) we need not worry that older versions of HTML browsers will render such data. However, such a proposal has the following constraints:
Consequently,
Note: We hesitate to recommend this method because of the potential (undetermined) overhead of having to seek proposals in the content and the complexity of managing a site with embedded proposals. Consequently, this method should only be used for sites which 1) do not use P3P data methods and 2) have a few, simple, non-overlapping proposals for their site.
The service requests a large binary file, or prefers to process data as it did with forms/CGI and wishes to have that information presented using POST.
The post-URI is an implicit part of the REALM. Consequently, information may be posted to the provided post-URI under an agreementID even if the URI is not within the REALM-URI.
The user agent communicates to the server using standard HTTP methods such as "GET" or "POST". P3P uses the mandatory extension mechanism [MANDA] for transporting data between the agent and service. When placing an initial request to the server, the user-agent MAY include the p3p-opt-header to notify the server that the user agent is P3P-compliant. If the user-agent sends the OPT header, and the server implements the P3P protocol, then it MUST:
| [1] | p3p-request |
= |
start-line *message-header "OPT" ":" p3p-opt-header [p3p-header-prefix "P3P1.0" ":" p3p-header CRLF] [message-body]
|
| [2] | p3p-opt-header |
= |
p3p-extension ";" "ns-" p3p-header-prefix |
| [3] | p3p-extension |
= |
`"` http://www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD/ `"` |
| [4] | p3p-header-prefix |
= |
1*digit "-" |
| [5] | p3p-header |
= |
"<p3p" p3p-qualifier* ">" 1*p3p-content "</p3p">" |
| [6] | p3p-qualifier |
= |
( ("FINAL=" | "FIN=") yesno ) |
(<"> token <"> "=" token)
|
| [7] | yesno |
= |
(`"` "1" `"` | `"` "Yes" `"`
) | (`"` "0" `"` | `"` "No" `"` ) |
The following table summarizes the meaning of the P3P primitives as well as their relations, content, and HTTP return codes. All primitives may be sent by a service or agent.
| Message | Meaning | After Receiving | Expected Response | Data in Message | Optional in Message | HTTP Return Code |
| OK | Proposal acceptable or data transfer successful | PROP or TXD | none | MD5 hash of agreement or data transferred | 2xx | |
| PROP | Here's a Proposal | Any time | OK, SRY, or PROP | Text of a proposal | Signature of initiator, fingerprint of previous Proposal | 409 |
| SRY | Sorry - request not processed | PROP, TXD | PROP or none | Reason code and MD5 hash of proposal or data transferred | Which practices are unacceptable | 409 |
| TXD | Transfer Data | Any time | none, OK or SRY | Data element names and values to be written, as requested | Agreement | 2xx |
This section describes each of the operations and specifies who (user or service) can initiate the action and under what circumstances.
This message is sent when an entity agrees to a proposal, or when a data transfer has succeeded. If the OK is sent in response to a proposal, the OK message includes the agreementID. If the OK is sent in response to a TXD message, the OK message includes the MD5 hash of the data that has been transferred.
At any time, either participant can send one or more proposals to the other, these are sent in the prop-msg. The proposal's terms aren't binding until the other side has agreed to them (by responding with the OK or TXD primitives). The proposal may be signed by the party that creates it if so desired. In addition the PROP MUST nclude the agreementID of a proposal previously received from the other party (this may help the other party keep track of the negotiation). If a site wishes to express that a data element is optional, it may do so within the proposal; the user agent will return the optional elements it feels appropriate. An agreement over a proposal with optional purposes or qualifiers is ambiguous; there is no clear way for the agent to express that one purpose was agreed to, but another was not. Consequently, optional purposes or qualifiers MUST be expressed through multiple unambiguous proposals.
If a proposal isn't automatically acceptable to the user agent, there are three options. The user agent must be programmed in some manner to decide which response is appropriate (including prompting a user for guidance):
If the proposal is acceptable to the user-agent, it should transmit the data to the service along with its OK. By transmitting the data under an agreementID, the user agent indicates that it has accepted the proposal. The TXD includes the agreementID of the accepted proposal, and the service can determine which optional data elements the user has sent by inspecting the data objects transmitted.
This message is sent in response to a proposal (PROP) or a data transfer (TXD). It indicates that the request could not be processed. The refusal includes two pieces of information: a reason code and agreementID. The reason code indicates what type of request is being refused and why it is being refused. Since multiple proposals may be sent, the agreementID is necessary to identify which request is being refused. The particular causes for refusing a proposal are given by the reason codes.
Finally, the SRY message can be used in response to a Transmit Data (TXD) message when the data transfer fails. The sender SHOULD NOT retry the TXD message.
Note: When a proposal is refused, P3P1.0 does not include a mechanism to specify exactly what portions of the proposal are unacceptable. A mechanism to indicate what part of a proposal is unacceptable may be included in a future version of the P3P protocol. In P3P1.0, a possible work-around for services or user agents which wish to do detailed negotiation is to send a counter-proposal, modifying or deleting those portions of the original proposal which were unacceptable. Implementers should be wary of the privacy implications of releasing user privacy preferences in either case.
After the receipt of a proposal, the user agent may send out the requested data. The user agent MUST include the agreementID(s) it believes it is operating under. The service MUST honor the agreements if they are valid. If the agreementID refers to an invalid or nonexistent agreement, the service MUST respond to the TXD with a SRY message, setting the response code to 401 (Unrecognized Agreement).
If the proposal requests optional elements, the TXD may not include all the requested data elements. It is up to the user agent to decide how many of these to transfer; the agreement MAY inform the user of the consequences (presumably rewards) of sending the optional items.
There is no primitive to end negotiation. Instead, this capability is provided through a qualifier on a P3P message. Any PROP or SRY message can include the FINAL qualifier. When a service receives a PROP with a FINAL qualifier, it MUST respond with either an OK or a SRY. The response MUST include a content-body, though it may be as simple as an HTML document which states that the requested object cannot be returned without an agreement. When a user-agent receives a PROP with the final qualifier, it should understand that the service has presented its "final offer", and that further negotiation is likely to be pointless.
| [8] | p3p-content |
= |
OK-msg | PROP-msg | SRY-msg | TXD-msg | extension-msg |
| [9] | OK-msg |
= |
"<ok" message-attribute "/>" |
| [10] | PROP-msg |
= |
(short-proposal | proposal) |
| [11] | SRY-msg |
= |
"<sry" message-attribute "/>" |
| [12] | TXD-msg |
= |
"<txd" message-attribute ">" data-xfer "</txd>" |
| [13] | extension-msg |
= |
"<" token message-attribute ">" *token "</" token ">" |
| [14] | message-attribute |
= |
agreement-id | reason-attribute | data-hash-attribute |
| [15] | reason-attribute |
= |
"r" "=" `"` reason-code `"` |
| [16] | data-xfer |
= |
<XML formatted data element name-value pairs> |
| [17] | agreement-id |
= |
<base64 of 128 bit MD5 digest of proposal as per RFC 1864> |
| [18] | data-hash-attribute |
= |
"dh" "=" <base64 of MD5 digest of data-xfer> ; used to acknowledge the receipt of data |
Reason codes are optionally sent within P3P headers: every SRY message carries an implied 400 reason code, and every other message carries an implicit 200 reason code; including a reason code in the message overrides these defaults. Reason codes can be divided into three main classes: success codes, rejection codes and error codes. A detailed explanation of these three classes follows.
This class of reason code indicates that the request was successfully received, understood, and accepted.
This class of reason codes indicates that the request was successfully received and understood, but not acceptable. These codes MUST be sent only in a SRY message.
This class of reason codes indicates that the request was not received successfully, or that the request was received but could not be understood. These codes MUST be sent only in a SRY message.
| [19] | reason-codes |
= |
200 | 400 | 430 | 431 | 432 | 433 | 434 | 500 | 530 | 531 |
This section describes the schema for 1) P3P proposals and 2) data transfer. A more complete English language description of the terms used in a proposal may be found within [HARMV].
We would like to encode the following statement; it is one proposal, with two statements within which are logical ANDs. "Other disclosures" automatically apply to the whole proposal.
CoolCatalog, a member of PrivacyAssured, makes the following statement for the Web pages at http://www.CoolCatalog.com/catalogue/.We collect your name, age, and gender to customize our entry catalog pages for the type of clothing you are likely to be interested in and for our own research and product development. We do not use this information in identifiable form. We also collect your shipping information so that we can send you your order; this is of course is identifiable. We do not redistribute any of this information outside of our organization. We do not provide access capabilities to information we may have from you, but we do have retention and opt-out policies, which you can read more about at our privacy page http://www.CoolCatalog.com/PrivacyPractice.html..
The following is a more formal description, where comments are preceded by a semicolon:
in proposal schema
CoolCatalog makes ; entity
this statement for http://www.CoolCatalog.com/catalogue/ ; realm, where the * is assumed
with assurance from PrivacyAssured
we read ; read is default
(User.Name.First) ; required is default
(User.Bdate.Year OPTIONAL)
(User.Gender)
for the purpose of (2 3) ; Customization of the Site to Individuals, R&D
in (0) ; Non-Identifiable Form and the recipients are (0) ; only ourselves and agents
with consequence of ("a site with clothes you'd appreciate.") ; optional
we read&write
(User.Shipping.) ; this is a whole data set.
for the purpose of (0) ; Completing the Current Transaction
in (1) ; Identifiable Form and the recipients are (0) ; only ourselves and agentsaccess disclosure (3) ; no access to identifiable data
other disclosures (0 1) ; we make disclosures regarding changing agreement and retention
at http://www.CoolCatalog.com/PrivacyPractice.html
The following RDF captures the information as expressed above. P3P proposals MUST be statements that are properly expressed according to the syntax model of RDF as well as valid and well-formed XML. As a specific application of RDF we make a number of assumptions about RDF:
<?xml:namespace ns=":http//www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD" prefix="p3p"?> <?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#" prefix="RDF"?> <RDF:RDF><proposal REALM="http://www.CoolCatalog.com/catalogue/" ENTITY="CoolCatalog" ASSURANCE="http://www.TrustUs.org"> <uses> <statement PURPOSE="2, 3" RECIPIENT="0" ID="0" CONSEQUENCE="a site with clothes you'd appreciate."> <with><prefix NAME="User."> <ref NAME="Name.First"/> <ref NAME="Bdate.Year" OPTIONAL="1"/> <ref NAME="Gender"/> </prefix></with> </statement> </uses> <uses> <statement ACTION="read&write" PURPOSE="0" RECIPIENT="0" ID="1"> <ref NAME="User.Shipping."/> </statement> </uses> <DISCLOSURE TEXT="http://www.CoolCatalog.com/PrivacyPractice.html" ACCESS="3" OTHERDISCLOSURE="0 1"/> </proposal></RDF:RDF>
The REALM attribute defines the scope of the agreement. It is used by the user agent, for example, to determine whether to automatically transmit a ReturnID or whether to allow a data transfer request. If the proposal is not digitally signed, then each of the Realm URIs must "domain-match" [Kristol] the domain of the server. If the proposal is digitally signed, then the Realm is implicitly expanded to include the current request URI whenever a server outside the original Realm makes a digitally signed proposal referencing an existing agreement.
As noted above, the user agent uses the Realm to determine if the current request URI is subject to any existing agreements. The user agent automatically transfers the ReturnID with the request if a valid agreement requested the ReturnID. This provides a mechanism for the service to maintain state or capture visitor-level statistics.
The short-proposal is sent when a site wishes to assumes that a agent is aware of the agreement or wishes to refer the agent to a complete proposal at the proposal-URI.
| [21] | short-proposal |
= |
"<proposal" ("AGREEMENTID=" | "AGRID=") agreementID
["proposal-URI=" URI]
"/>"
"</proposal>"
|
The longer proposal includes all of the necessary attributes.
| [22] | long-proposal |
= |
"<proposal"
("AGREEMENTID=") quoted-string
["AGREXP=" datetime] ;default is six months
"REALM=" `"` URI *(" " URI) `"`
"ENTITY=" quoted-string
[("ASSURANCE=") `"` URI `"`]
["postURI=" `"` URI `"`]
">"
1*statement-block
disclosure
"</proposal>"
|
| [23] | schemaURI |
= |
<"> "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD" <"> |
| [24] | quoted-string |
= |
<UTF-8 quoted string> |
| [25] | URI |
= |
<quoted URI as per RFC 2068 [URI]> |
| [26] | datetime |
= |
< date/time as per section 3.3 of RFC 2068> |
- PURPOSE=
- purposes for data processing relevant to the Web.
- RECIPIENT=
- an organizational area, or domain, beyond the service provider and its agents where data may be distributed.
- ID=
- is data used in a way that is personally identifiable -- including linking it with identifiable information about you from other sources?
- ACTION=
- read the data, or read and write
| [27] | statement-block |
= |
"<uses>"
"<statement"
[("ACTION=" | "ACT=") `"` action `"`]
[("PURPOSE=" | "PUR=") `"` purpose *("," purpose) `"` ] ; defaults 0
[("ID=" `"` identifiable `"`)] ; defaults 0
[("RECIPIENT=" | "REC=" )] `"` recipients *("," recipients) `"` ; defaults 0
[("CONSEQUENCE=" | "CON=") quoted-string]
">"
*(datablock)
"<statement>"
"</uses>"
|
| [28] | 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" string))
|
| [29] | recipient |
= |
("0" | "only ourselves and our agents")
("1" | "organizations following our practices")
("2" | "organizations following different practices")
("3" | "unrelated third parties or public forum")
|
| [30] | identifiable |
= |
("0" | "no") | ("1" | "yes") ; default no
|
| [31] | action |
= |
("r" | "read") | ("rw" | "read&write") ; default read
|
Categories are attributes of data elements which provide hints to users and
user agents as to the intended uses of the data. Categories are vital to
making P3P user agents easier to implement and use; they allow users to express
more generalized preferences and rules over the exchange of their data.
Categories are often included when defining
a new element or referring to form data.
Membership of data elements in categories is generally disjoint; most data
elements should belong to just one category. However data elements may belong
to more than one category when necessary. In addition, a data set belongs
to all of the categories to which its elements belong. Base data elements
have all been assigned a default
category in the P3P specification. When a service proposes a new data element,
the proposal should include the default category or categories for the element,
however the user and/or user agent retains final control over the category
assignment.
| [32] | categories |
= |
`"` *(data-category ",") data-category `"` |
| [33] | data-category |
= |
("0" | "Physical Contact Information") |
("1" | "Online Contact Information") |
("2" | "Unique Identifiers") |
("3" | "Financial Account Identifiers") |
("4" | "Computer Information") |
("5" | "Navigation and Click-stream Data") |
("6" | "Transaction Data") |
("7" | "Preference Data") |
("8" | "Demographic and SocioEconomic Data") |
("9" | "Content")
|
Simple disclosures regarding service access capabilities, and binary values as to whether the entity makes disclosures regarding changing the agreement (opt-out) for data already collected and how long data is retained.
- DISCLOSURE=
- URI of the English language statement
- ACCESS=
- the ability of the individual to view identifiable information and address questions or concerns to the service provider.
- OTHER=
- does the site make a its policy regarding change_agreement and retention known at its disclosureURI?
| [34] | disclosure |
= |
("DISCLOSURE=" | "DIS=" ) URI
|
| [35] | access-disclosure |
= |
("0" | "Identifiable Data is Not Used") |
("1" | "Identifiable Contact Information") |
("2" | "Other Identifiable Information") |
("3" | "None")
|
| [36] | other-disclosure |
= |
[("0" | "change_agreement")] | [("1" | "retention")]
|
References to data sets/elements are all enclosed within a statement using the <ref> tag. The <ref> tag has the following attributes: NAME, DATASCHEMA, VALUE, OPTIONAL, CATEGORY, TYPE, TYPESCHEMA, SHORT.
The following four attributes are only used when a new (not defined in the P3P1.0 base) data element or set is referenced.
| [37] | data-reference |
= |
"<ref" "NAME=" `"` data_element `"` [("DATASCHEMA=" | "DSCH=") `"` URI `"`]
[("OPTIONAL=" | "OPT=") `"` yesno `"`]
["TYPE="quoted- string] [("TYPESCHEMA=" | "TSCH=") `"` URI `"`]
["CATEGORY=" categories]
["SHORT=" quoted-string]
|
As an example, to request the the user's shipping address city, all the elements of the data set User.Business.Info. and (optionally) all the elements of the data set User.Home.Info.Phone. the service would send the following references inside a P3P proposal:
<ref NAME="User.Shipping.Info.Address.City"/>
<ref NAME="User.Home.Info.Phone." optional="1"/>
<ref NAME="User.Business.Info"/>
If the user agrees to returning the city and business information and only the international phone code of her home phone number, she returns the following inside the txd tag:
<ref NAME="User.Shipping.Info.Address.City" VALUE="Boston"/>
<ref NAME="User.Home.Info.Phone.IntCode" VALUE="1"/>
<ref NAME="User.Business.Info.Address.Street" VALUE="12 Main
St."/>
<ref NAME="User.Business.Info.Address.City"
VALUE="Cambridge"/>
<ref NAME="User.Business.Info.Address.Name" VALUE="Smith"/>
...
In a set of data references, many element names may share a common parent.
For instance, "User." is a common occurrence in the references directly above.
The <with><prefix> tags can be used to associate a string
prefix to the names of a group of data elements or sets. Consequently, this
can be used to shorten the length of the names or to reference new
data sets and elements. If a prefix tag is present within a data block, then
the block is equivalent to one where the prefix tag is omitted,
and each NAME value is prefixed by the prefix. For instance, the
above example could be rewritten as:
<with><prefix NAME="User.">
<ref NAME="Shipping.Info.Address.City"
VALUE="Boston"/>
<ref NAME="Home.Info.Phone.IntCode" VALUE="1"/>
<ref NAME="Business.Info.Address.Street" VALUE="12 Main
St."/>
<ref NAME="Business.Info.Address.City"
VALUE="Cambridge"/>
<ref NAME="Business.Info.Address.Name" VALUE="Smith"/>
...
</prefix></with>
The <with><prefix> tags can be nested; the prefixes have to be added proceeding from the innermost <with><prefix> ... </prefix></with> combination (here, innermost means that there are no other <with><prefix> tags within. So, the above example could be rewritten even more compactly in the following way:
<with><prefix
NAME="User.">
<ref NAME="Shipping.Info.Address.City"
VALUE="Boston"/>
<ref NAME="Home.Info.Phone.IntCode"
VALUE="1"/>
<with><prefix
NAME="Business.Info.Address.">
<ref NAME="Street" VALUE="12
Main St."/>
<ref NAME="City"
VALUE="Cambridge"/>
<ref NAME="Name"
VALUE="Smith"/>
...
</prefix></with>
...
</prefix></with>
Note: use of two tags (<with><prefix>) in place of one (just <prefix>) is technically due to the fact we are employing the RDF encoding.
| [38] | datablock |
= |
*datareference |
( *datareference
"<with><prefix" "NAME=" quoted-string [("DATASCHEMA=" | "DSCH=") quoted-string]
[("OPTIONAL=" | "OPT=") quoted-string]
["TYPE=" quoted-string] [("TYPESCHEMA=" | "TSCH=") quoted-string]
["CATEGORY=" quoted-string]
["SHORT=" quoted-string]
|
Services have the capacity to ask that information be written to the user repository. Consider a P3P agent receiving the following request as part of a proposal:
<statement ACTION="r" PURPOSE="2" ID="0"/>
<ref NAME="Web.PUID"/>
<ref NAME="User.PersonName.First"/>
</statement>
<statement ACTION="rw" PURPOSE="2" ID="0">
<ref NAME="FineShoes.shoesize"
DATASCHEMA="http://www.FineShoes.com/Schema1.0"
/>
</statement>
The user could be prompted, asked if she agrees to this proposal, and then shown a form like interface with the User.PersonName.First auto-filled (assuming she's entered that before) and a blank field for FineShoes.shoesize. The user would enter this information and transmit it (TXD).
The user sends:
<txd r="200" AGREEMENTID="94df1293a3e519bb" />
<ref NAME="User.PersonName.First" VALUE="Josephine"/>
<ref NAME="Web.PUID" VALUE="1234567"/>
<ref NAME="FineShoes.Shoesize"
DATASCHEMA="http://www.FineShoes.com/Schema1.0"
VALUE="7"/>
</txd>
Whenever the attribute "rw" is applied to a data element, and a new value is provided by the user, the user agent must attempt a write to the data repository. If that attempt fails, the agent should return the appropriate response code. This auto-write eliminates the need for the service to retransmit information back to the user agent. However, the service may send a (TXD) at any time. For instance, even though the user provided their shoesize as 7, the service wishes to convert it into European shoe sizes and write that value instead.
As described elsewhere, optional elements are denoted by the
optional attribute of the <ref> tag. Since elements
are part of a statement, they are associated with the purpose, actions, and
qualifiers of that statement -- for brevity we shall only refer to the purpose
in this section. Consequently, an optional element should be read as "this
element is optional for the purposes declared in this statement." For instance,
Web.PUID and User.Home.Info.First are collected for purpose
2 and 3 in non identifiable form:
<statement PURPOSE="2, 3" ID="0" RECIPIENT="0"
CONSEQUENCE="a personalized site!"/>
<ref NAME="Web.PUID"/>
<ref NAME="User.Home.Info.First"/>
</statement>
In order to avoid ambiguity an element may only appear once in a proposal. If an element is desired (required or optional) for a single purpose its representation is unambiguous. That element only appears in one statement and (if optional) is returned if the user opts to do so.
The case in which a single element is required for one purpose but optional for other purposes is problematic. First, how does the service represent this state in its proposal? Second, how does the agent unambiguously represent the fact that it is providing the element, but for only one of the purposes? For instance, a service may wish to have shipping information for sending the user a product and (optionally) use it for contacting the user for marketing purposes.
A non-conformant proposal could be created where the element appears in one statement for the purpose of shipping, but appears optionally in another statement for marketing. However, the data transfer syntax does not support a method of returning the data and representing which of the required and optional purposes the user agreed to for a single element. This is why an element may only appear once in a proposal. Purposes which are optionally applied to an element that is required elsewhere MUST be represented with multiple proposals. When the constraint is followed, each agreementID as applied to the returned data is an unambiguous representation of what the user agreed to.
For example, if a service requires shipping information for completing the transaction and would like to optionally use all of this data for optionally for marketing purposes, it should send the following two proposals.
<?xml:namespace
ns="http://www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD"
prefix="p3p"?>
<?xml:namespace ns="http://www.w3.org/TR/WD-rdf-syntax#"
prefix="RDF"?>
<proposal AGREEMENTID="1e3a5d71297d104f>"
REALM="http://www.CoolCatalog.com/catalogue/"/>
<uses>
<statement PURPOSE="2" ID="1"
CONSEQUENCE="We can ship your order to your door
step">
<ref NAME="User.ShipTo."/>
</statement> </uses>
<DISCLOSURE
text="http://www.CoolCatalog.com/PrivacyPractice.html"
ACCESS="3" OTHERDISCLOSURE="0 1"/>
</proposal>
<proposal AGREEMENTID="2e3a5d71297d104f"
REALM="http://www.CoolCatalog.com/catalogue/"
optional="1"> ; note optional is in
header.
<uses>
<statement PURPOSE="4" ID="1"
CONSEQUENCE="We will send you our world-renown
catalogue!">
<ref
NAME="User.ShipTo."/>
</statement> </uses>
<DISCLOSURE
text="http://www.CoolCatalog.com/PrivacyPractice.html"
ACCESS="3" OTHERDISCLOSURE="0 1"/>
</proposal>
Multiple proposals should be constructive so as to be additive and discrete. Proposals should not be constructed such that a user must choose between two proposals (A+B) and (A), where A and B represent policies. Rather, they should be presented with (A) and (B) and choose as many as appropriate.
In our example, if the user only agrees to the proposal for using the shipping information for the completion of the transaction, it would return the information under that agreement ID.
<txd r="200" AGREEMENTID="1e3a5d71297d104f" />
<with><prefix NAME="User.ShipTo.Info.">
<ref NAME="User.Info.Posal.Name"
VALUE="Josephine Hound"/>
...
<ref NAME="Phone.Number"
VALUE="617.555.7621"/>
</prefix></with>
Note that this solution results in the transmission of potentially redundant information in multiple proposals and data transfers. However this is preferable to the greater complexity and latency of reaching the agreement if services can send unambiguous proposals and user agents must then return unambiguous representations of their agreement.
Within a proposal, new data elements and data sets can be created. This occurs when a reference to an unknown data element or data set is encountered within the proposal. In such an event, if the user agrees, the new data elements are created within the user's repository. In order to create a new data element, the agent needs the following: its name, the data schema it belongs to, the category, the data type (and, in case, the data schema where the type has been defined), and the short display name.
Also, a service may optionally provide a more detailed description of the data element in the form of a special schema-statement statement. This information can be provided in two ways:
If information is inline and the origin server URI does not match the dataschema URI, the information in the main data schema MUST be checked in order to verify the consistency of the information. Otherwise, the information in the main data schema MAY be checked in order to verify consistency of the information. In case of a mismatch, a 530 return code (Invalid Format) must be returned. If for any other reason the user is unable to reconstruct the needed information, a 433 code (Data Unavailable) must be returned.
The format of a new data schema is a special statement of the form
<?xml:namespace ns="http://www.w3.org/TR/WD-P3P-syntax#" prefix="P3P"?> <proposal><uses><statement> .... <statement></uses><proposal>
A data block is enclosed within the <data> tags and contains references to the data elements. References can be made using the <ref> tag and its attributes:
NAME (to define the name of the data element)
CATEGORY (to define the category)
TYPE (to define the type)
TYPESCHEMA (to define the data schema where the type is defined)
SHORT (to define the short display name, no more than 30
characters.)
LONG (to provide a longer description of the data item, no more
than 250 characters)
Like in the data transfer, the <prefix> tag can be used to shorten the schema definition, by associating a common prefix to many <ref> attributes.
For every data element, all of the information except LONG is mandatory.
If one of the attributes is missing, it is presumed to be present with an
empty string. In the case of the TYPESCHEMA, the empty string
value has the special meaning that the type schema coincides with the value
of the DATASCHEMA attribute.
For example, suppose the company HyperSpeed wants to build the following data schema:
car.model
car.color
car.built.year
car.built.where. (of basic type Postal.)
car.price
bike.model
bike.color
bike.built.year
bike.built.where. (of basic type Postal.)
bike.price
Then, it could just place the following code at http://www.HyperSpeed.com/models-schema
<?xml:namespace ns="http://www.w3.org/TR/WD-P3P-syntax#" prefix="P3P"?> <proposal> <uses> <statement> <with><prefix NAME="car." SHORT="Car"> <ref NAME="model" TYPE="Text" SHORT="Model"\> <ref NAME="color" TYPE="Text" SHORT="Color"\> <with><prefix NAME="built." SHORT="Construction data"> <ref NAME="year" TYPE="Number" SHORT="Year"\> <ref NAME="where." TYPE="Postal."\> </prefix></with> </prefix></with> <ref NAME="bike." TYPE="car." TYPESCHEMA="http://www.HyperSpeed.com/models-schema" SHORT="Bike "\> </uses> </statement> </proposal>
Note that every time a data set is created, it can be implicitly used as a type, just like the car. case above. However, in some situations one may wish to define a type without creating a specific element within the user's repository. This can be accomplished by using the TEMPLATE attribute in the <ref> . Setting the value to yes, TEMPLATE="1" (default is "No", or 0), means that the corresponding data element is part of a type definition only, and is not actually representing a data element with an associated value. For example, HyperSpeed might want to define a GenericModel. type of general utility, and then instantiating it with car. and bike. This could be done with the following schema:
<?xml:namespace ns="http://www.w3.org/TR/WD-P3P-syntax#" prefix="P3P"?> <proposal> <uses> <statement> <with><prefix NAME="GenericModel." TEMPLATE="Yes"> <ref NAME="model" TYPE="Text" SHORT="model"\> <ref NAME="color" TYPE="Text" SHORT="color"\> <with><prefix NAME="built." SHORT="Construction data"> <ref NAME="year" TYPE="Number" SHORT="Year"\> <ref NAME="where." TYPE="Postal."\> </prefix></with> </prefix></with> <ref NAME="car." TYPE="GenericModel." TYPESCHEMA="http://www.HyperSpeed.com/models-schema" SHORT="Car"\> <ref NAME="bike." TYPE="GenericModel." TYPESCHEMA="http://www.HyperSpeed.com/models-schema" SHORT="Bike"\> </uses> </statement> </proposal>
The following are the base data elements and sets. These data elements and
sets (as named) may not be modified or deleted by either the service or the
user agent. However the user can provide any arbitrary value. For instance
the agent may return no value or a value that differs depending on the active
persona. We expect that in the future, there will be demand for the creation
of other data sets and elements. Obvious applications include catalogue,
payment, and agent/system attribute schemas. (An extensive set of system
elements is provided in a white paper
draft
and are based on
http://www.w3.org/TR/NOTE-agent-attributes.)
Each table below specifies a set, the elements within the
set, the category associated with the element, its type, and the display
name shown to users. More than one category may be associated with an element,
particularly Web.Abstract. However, we have designed the base categories
such that the base elements do no overlap or belong to more than one category
when possible. We recommend that data schema designers do the same.
The Web. data set includes specific queries to the user agent.
| Web. | Category | Type | Short display name |
| PUID | Unique Identifiers | Number | Pairwise or Site ID |
| TUID | Unique Identifiers | Number | Temporary or Session ID |
This data set includes elements used to uniquely identify a user to a single service. TUIDs are used for the purpose of retaining state for a given session. PUIDs are used to retain state over multiple sessions. Neither of these terms imply that users are personally identifiable nor that they are required to share a single UUID with multiple sites. Rather, each ID should be unique such that if both Jane's and Adam's user agents create an ID for interaction with the Cool.Com site, each of their IDs will be unique.
The Web.Abstract. data set serves the purpose of referencing HTTP data collection activity that is not collected through P3P methods.
| Web.Abstract. | Category | Type | Short display name |
| ClientClickStream | Navigation and Click-stream Data, * | Boolean | Click-stream collected on the server. |
| ServerClickStream |
|
Boolean | Click-stream collected on the client. |
| StoreNegotiation | Transaction Data | Boolean | Server stores the negotiation history |
| Form | * | Boolean | Data entered through forms |
| Form.SearchText | Transaction Data | Boolean | Search terms |
Unlike all other data elements that have values which are generated or stored by the agent, the WebAbstract elements do not have associated data values. Rather, they allow a service to declare the collection of data by means other than a request for a P3P data transfer. We call these elements abstract. When abstract elements appear within the same statement as other elements, this asserts that once the data is collected through the abstract method, the service will likely wish to read or write that information to the specific elements within the user's repository in the future.
These elements are often implicit in navigation or Web interactions. They should be used with categories to describe the type of information collected through these methods. Form includes information collection methods controlled by the service, such as HTML forms or Java(script) interfaces. Form.SearchText is a specific type of form solicitation used for searching and indexing sites. Consequently, if the only form fields on a search engine page are search fields, it need only disclose that data element.
The User. data set includes general information about the computer user.
| User. | Category | Type | Short display name |
| Name. | Physical Contact Information, Demographic and SocioEconomic Data | PersonName. | User's Name |
| Bdate. | Demographic and SocioEconomic Data | Date. | User's Birth Date |
| Cert | Unique Identifiers | Text | User's Identity Certificate |
| Gender | Demographic and SocioEconomic Data | Gender | User's Gender |
| Employer | Demographic and SocioEconomic Data | Text | Name of user's employer |
| Department | Demographic and SocioEconomic Data | Text | Department or division of organization where user is employed |
| JobTitle | Demographic and SocioEconomic Data | Text | User's job title |
| Home. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
Info. | User's Home Contact Information |
| Business. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
Info. | User's Business Contact Information |
| BillTo. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
Info. | User's Billing Address |
| ShipTo. | Physical Contact Information, Online Contact Information, Demographic and SocioEconomic Data |
Info. | User's Shipping Address |
Note, that this data set includes elements that are actually sets of data
themselves. These sets are defined in the data types
subsection of this document. The short display name for an individual element
contained within a data set is defined as the concatenation of the short
display names that have been defined for the set and the element, separated
by commas. For example, the short display name for
User.Home.Postal.PostalCode would be "User's Home Contact Information,
Postal Address Information, Postal Code". User agent implementations may
prefer to develop their own short display names rather than using the
concatenated names when prompting users for information.
The Date. type is a structured type that specifies a date.
| Date. | Category | Type | Short display name |
| Year | Demographic and SocioEconomic Data | Number | Year |
| Month | Demographic and SocioEconomic Data | Number | Month |
| Day | Demographic and SocioEconomic Data | Number | Day |
| Hour | Demographic and SocioEconomic Data | Number | Hour |
| Minute | Demographic and SocioEconomic Data | Number | Minute |
| Second | Demographic and SocioEconomic Data | Number | Second |
| FractionSecond | Demographic and SocioEconomic Data | Number | Fraction of Second |
| TimeZone | Demographic and SocioEconomic Data | Text | Time Zone |
The PersonName. type is a structured type that specifies information about the naming of a person.
| PersonName. | Category | Type | Short display name |
| Prefix | Demographic and SocioEconomic Data | Text | Name Prefix |
| First | Physical Contact Information | Text | First Name |
| Last | Physical Contact Information | Text | Last Name |
| Middle | Physical Contact Information | Text | Middle Name |
| Suffix | Demographic and SocioEconomic Data | Text | Name Suffix |
| Nickname | Demographic and SocioEconomic Data | Text | Nickname |
The PhoneNum. type is a structured type that specifies the characteristics of a phone number.
| PhoneNum. | Category | Type | Short display name |
| IntCode | Physical Contact Information | Number | International Phone Code |
| LocCode | Physical Contact Information | Number | Local Phone Area Code |
| Number | Physical Contact Information | Number | Phone Number |
| Ext | Physical Contact Information | Number | Phone Extension |
| Comment | Physical Contact Information | Text | Phone Optional Comments |
The Info. type is a structured, redirected, type to other types. This is done so that requests for data need not collect information they do not need even if they wish to use the abbreviate set notation in a request.
| Info. | Category | Type | Short display name |
| Postal. | Physical Contact Information, Demographic and SocioEconomic Data |
Postal. | Postal Address Information |
| Telecom. | Physical Contact Information | Telecom. | Telecommunications Information |
| Online. | Online Contact Information | Online. | Online Address Information |
The Postal. type is a structured type that specifies a postal mailing
address.
| Postal. | Category | Type | Short display name |
| Name. | Physical Contact Information, Demographic and SocioEconomic Data |
PersonName. | Name |
| Street | Physical Contact Information | Text | Street Address |
| City | Physical Contact Information | Text | City |
| StateProv | Physical Contact Information | Text | State or Province |
| PostalCode | Physical Contact Information | Text | Postal Code |
| CountryCode | Physical Contact Information | Country | Country |
| Country | Physical Contact Information | Text | Country String |
The Telecom. type is a structured type that specifies telecommunication information about a person.
| Telecom. | Category | Type | Short display name |
| Phone | Physical Contact Information | PhoneNum. | Phone Number |
| Fax | Physical Contact Information | PhoneNum. | Fax Number |
| Mobile | Physical Contact Information | PhoneNum. | Mobile Phone Number |
| Pager | Physical Contact Information | PhoneNum. | Pager Number |
The Online. type is a structured type that specifies telecommunication information about a person.
| Online. | Category | Type | Short display name |
| Online Contact Information | Text | Email Address | |
| URI | Online Contact Information | URI | Home Page Address |
This specification uses the following primitive data element
datatypes, we reference specifications in
keeping with XML1.0,
HTTP/1.1,
and XML-data
as ordered.
| Primitive DataType | Definition |
| Text | UTF-8 |
| Gender | Text of character "M" or "F". |
| Boolean | Text of character "0" or "1". |
| Binary | Base64 per RFC-1531. [MIME] |
| Number | Text of characters composed with the digits "0", "1", "2", "3", "4", "5", "6", "7", "8", "9". |
| UUID | [UUID] |
| Country | ISO 1366 |
| URI | [URI] |
[1] |
data-set |
= |
1*<the prefix ending with a dot of a data element> |
This scenario is based on scenarios 1/5 and 3 and includes negotiation.
A user directs their Web browser to go to home page of CoolCatalog. She has never been there before; she requests a P3P proposal as part of the request by advertising that her browser understands P3P.
GET / HTTP/1.1 Accept: */* User-Agent: BugblatterBeast/3.02 (RT-11; English) Host: www.CoolCatalog.com OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-42
CoolCatalog sends a proposal, including privacy practices, disclosures, and the data elements to which they apply. In this instance, the service asks to be given the PUID as part of the returnID automatically in the future and requests the user's gender from the user repository.
HTTP/1.1 409 Agreement required Server: Marvin/2.0.1 OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1944 1944-P3P1.0: <P3P><?xml:namespace ns=":http//www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD" prefix="p3p"?> <proposal AGREEMENTID="94df1293a3e519bb" REALM="http://www.CoolCatalog.com/" ENTITY="CoolCatalog" ASSURANCE="http://www.TrustUS.org" /> <uses> <statement PURPOSE="2" ID="0" RECIPIENT="0" CONSEQUENCE="a personalized site!"/> <ref NAME="Web.PUID"/> <ref NAME="User.Gender"/> </statement> </uses> <DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html" ACCESS="3" OTHERDISCLOSURE="0 1"/> </proposal></P3P> Content-Type: text/html Content-Length: 110 <html><body> <h1>HTTP/1.1 409 Agreement Required</h1> <p>We need an agreement before we can continue.</p> </body></html>
[Note that the proposal is split across multiple lines for readability; over the network, a CRLF pair would be added only after the </proposal>. We will use this in the example lineflows below as well.]
The user refuses this proposal. Imagine that the agreementID (hash) of the above proposal is "e3a5d71297d104f1"; the user's next HTTP request would look like the following:
GET / HTTP/1.1 Accept: */* User-Agent: BugblatterBeast/3.02 (RT-11; English) Host: www.CoolCatalog.com OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1776 1776-P3P: <sry r="432" AGREEMENTID="e3a5d71297d104f1" />
The site offers a new proposal, this time it requests the automatic returnID, and from the user's repository the first name and optional age, both for the purposes of customizing the site.
HTTP/1.1 409 Agreement required Server: Marvin/2.0.1 OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1492 1492-P3P1.0: <P3P><?xml:namespace ns=":http//www.w3.org/TR/1998/WD-P3P10-syntax#proposal.DTD" prefix="p3p"?><proposal REALM="http://www.CoolCatalog.com/" ENTITY="CoolCatalog" ASSURANCE="http://www.TrustUs.org"/> <uses> <statement PURPOSE="2" ID="0" CONSEQUENCE="a personalized site!"> <with><prefix NAME="User."> <ref NAME="Name.First"/> <ref NAME="Bdate.Year" optional="1"/> </prefix></with> <ref NAME="Web.PUID"/> </statement> </uses> <DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html" ACCESS="3" OTHERDISCLOSURE="0 1"/> </proposal></P3P> Content-Type: text/html Content-Length: 110 <html><body> <h1>HTTP/1.1 409 Agreement Required</h1> <p>We need an agreement before we can continue.</p> </body></html>
The user agrees only to the provision of the automatic returnID and first name for customization only, and sends the data. Assume that the agreementID of the above proposal is "94df1293a3e519bb".
GET / HTTP/1.1 Accept: */* User-Agent: BugblatterBeast/3.02 (RT-11; English) Host: www.CoolCatalog.com OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1861 1861-P3P1.0: <P3P><txd r="200" AGREEMENTID="94df1293a3e519bb" > <ref PURPOSE="2" NAME="User.Name.First" VALUE="Josephine"/> <ref PURPOSE="2" NAME="User.PUID" VALUE="1234567"/> </txd></P3P>
At this point, the service would return the CoolCatalog homepage.
HTTP/1.1 200 OK Server: Marvin/2.0.1 OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1950 1950-P3P: <ok DH="s24fd20kuqexg5xk" /> Content-Type: text/html Content-Length: xxx [content of the CoolCatalog homepage]
The user returns to the site a day later, sending the returnID automatically.
GET / HTTP/1.1 Accept: */* User-Agent: BugblatterBeast/3.02 (RT-11; English) Host: www.CoolCatalog.com OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-2001 2001-P3P: <txd AGREEMENTID="94df1293a3e519bb" > <ref NAME="User.PUID" VALUE="1234567"/> </txd>
However, the server again needs the user's first name, so it asks for it under the previous agreement.
HTTP/1.1 409 Agreement required Server: Marvin/2.0.1 OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-2010 2010-P3P: <proposal AGREEMENTID="94df1293a3e519bb"/> </proposal> Content-Type: text/html Content-Length: 70 <html><body> <h1>HTTP/1.1 400 Agreement Required</h1> </body></html>
The user returns their first name and PUID.
GET / HTTP/1.1 Accept: */* User-Agent: BugblatterBeast/3.02 (RT-11; English) Host: www.CoolCatalog.com OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1968 1968-P3P1.0: <P3P><txd AGREEMENTID="94df1293a3e519bb" > <ref NAME="User.Name.First" VALUE="Josephine"/> <ref NAME="User.PUID" VALUE="1234567"/> </txd></P3P>
The service would then respond with their homepage, as before:
HTTP/1.1 200 OK Server: Marvin/2.0.1 OPT: "http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD"; ns-1950 1950-P3P1.0: <ok DH="s24fd20kuqexg5xk" /> Content-Type: text/html Content-Length: xxx [content of the CoolCatalog homepage]
The DTD's provided in the Appendix are provided for showing an example of the name space in use, and as a non-normative exercise in ensuring the robustness of the data structures. However, it is known to be incomplete. The normative notation for this specification is ABNF. The scope of the DTD's name space is provided through the following mechanism for each of the three sections below:
<pre ID="proposal.DTD"> ... </pre>
<!--
Typical usage:
<?XML version="1.0" encoding="UTF-8" ?>
<!DOCTYPE proposal SYSTEM
"http://www.w3.org/TR/1998/WD-P3P10-harmonization#proposal.DTD">
<proposal> ... </proposal>
-->
<!--======= Import TXD and Qualifier DTD =======-->
<!ENTITY % TXD PUBLIC
"http://www.w3.org/TR/1998/WD-P3P10-harmonization#TXD.DTD">
%TXD;
<!ENTITY % qualifier PUBLIC
"http://www.w3.org/TR/1998/WD-P3P10-harmonization#qualifier.DTD">
%qualifier;
<!--======= Internal Entities for Terseness =======-->
<!ENTITY % proposal-schema
"http://www.w3.org/TR/1998/WD-P3P10-harmonization#Proposal.DTD">
<!--======= The Proposal =======-->
<!ELEMENT proposal (uses,disclosure) >
<!ATTLIST proposal
SCHEMA CDATA %proposal-schema
REALM CDATA #REQUIRED <!-- URIs -->
ASSURANCE CDATA #REQUIRED <!-- URI -->
ENTITY CDATA #REQUIRED
OPTIONAL ("0" | "1") "0"
>
<!ELEMENT uses (statement+) >
<!ELEMENT statement (qualifier,data+) >
<!ATTLIST statement
ACTION ("r" | "rw" ) "r"
CONSEQUENCE CDATA #IMPLIED
>
<!ELEMENT disclosure EMPTY>
<!ATTLIST disclosure
DISCLOSURE CDATA #REQUIRED
ACCESS ( ("0" | "Identifiable Data is Not Used") |
("1" | "Identifiable Contact Information") |
("2" | "Other Identifiable Information") |
("3" | "None") ) "0"
OTHER (("0" | "change_agreement") | ("1" | "retention")) #IMPLIED
<!ELEMENT qualifier EMPTY>
<!ATTLIST qualifier
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) ) "0"
recipient ( ("0" | "Only Ourselves and our Agents") |
("1" | "Organizations Following Our Practices") |
("2" | "Organizations Following Different Practices") |
("3" | "Unrelated Third Parties or Public Fora") ) "0"
id ("0" | "1") "0"
>
<!ELEMENT data (prefix,ref+)>
<!ELEMENT prefix EMPTY>
<!ATTLIST prefix
name CDATA #REQUIRED
schema CDATA #IMPLIED <!-- URI -->
>
<!ELEMENT ref EMPTY>
<!ATTLIST ref
name CDATA #IMPLIED
optional ("0" | "1") "0"
>
P3P uses fingerprints (Message Digest, Hash) as a means of identifying proposals and data sets. These fingerprints yield a fixed size value resulting from the application of a hash function to a set of data. Fingerprints are easily computed, but even small modifications to the original information result in a different fingerprint value. Consequently, fingerprints are often used as methods of assuring information integrity. We use the MD5 digest algorithm for P3P fingerprints. This yields a 128-bit value which will be encoded and exchanged in P3P communications. Both agent and service can use these fingerprints to reference a given proposal and to ensure the integrity of the transaction (validating proposal against fingerprint).
The process for generating a fingerprint is fairly straight forward. For fingerprints to be identical, the data fingerprinted by sender and recipient must be identical. Our goal is to render the data to be fingerprinted into a standard form (canonicalized) such that the effect of any reformatting by intermediaries is nullified. After this is done, we use the canonicalized version of the proposal to generate the fingerprint. Given the same proposal, both the service and agent should be able to arrive at the same fingerprint value.
As an example, consider the following XML:
<rdf:rdf><proposal AGREEMENTID="94df1293a3e519bb" REALM="http://www.CoolCatalog.com/catalogue/" ENTITY="CoolCatalog"
ASSURANCE="http://www.TrustUs.org">
<uses>
<statement CONSEQUENCE="a site with clothes you'd appreciate."
PURPOSE="2, 3" RECIPIENT="0" ID="0">
<with><prefix NAME="User.">
<ref NAME="Name.First"/>
<ref NAME="Bdate.Year" OPTIONAL="1"/>
<ref NAME="Gender"/>
</prefix></with>
</statement>
</uses>
<uses>
<statement ACTION="read&write" PURPOSE="0" RECIPIENT="0" ID="1">
<ref NAME="User.Shipping."/>
</statement>
</uses>
<disclosure TEXT="http://www.CoolCatalog.com/PrivacyPractice.html"
ACCESS="3" OTHERDISCLOSURE="0 1"/>
</proposal></rdf:rdf>
|
After canonicalization, it would look like:
<proposal AGREEMENTID="94df1293a3e519bb" REALM="http://www.CoolCatalog.com/catalogue/" ENTITY="CoolCatalog" ASSURANCE="http://www.TrustUs.org"> <uses> <statement CONSEQUENCE="a site with clothes you'd appreciate." PURPOSE="2, 3" RECIPIENT="0" ID="0"> <with> <prefix NAME="User."> <ref NAME="Name.First"/> <ref NAME="Bdate.Year" OPTIONAL="1"/> <ref NAME="Gender"/> </prefix> </with> </statement> </uses> <uses> <statement ACTION="read&write" PURPOSE="0" RECIPIENT="0" ID="1"> <ref NAME="User.Shipping."/> </statement> </uses> <disclosure TEXT="http://www.CoolCatalog.com/PrivacyPractice.html" ACCESS="3" OTHERDISCLOSURE="0 1"/> </proposal> |
Once the proposal is canonicalized, we use the MD5 algorithm to generate the P3P fingerprint. This section provides an overview of MD5 and an explanation of how a MD5 digest is encoded.
The MD5 hash algorithm is defined in
The MD5 Message Digest Algorithm, R.L. Rivest, RFC 1321, April 1992
The MD5 algorithm (Message Digest 5) is a cryptographic message digest algorithm.
MD5 was designed by Ron Rivest, who is also the `R' in `RSA' in 1991. MD5 is described in RFC1321. C source code is included with the RFC. It is basically MD4 with "safety-belts" and while it is slightly slower than MD4, it is more secure. The algorithm consists of four distinct rounds, which have a slightly different design from that of MD4. Message-digest size, as well as padding requirements, remains the same. Den Boer and Bosselaers [B. den Boer and A. Bosselaers. Collisions for the compression function of MD5. In Advances in Cryptology - Eurocrypt '93, pages 293-304, Springer-Verlag, 1994.] have found pseudo-collisions for MD5 (see RSA FAQ Question 98), but there are no other known cryptanalytic results.
The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA or PGP.
For further information on MD5, see:
Computing the MD5 digest yields 4 32-bit values. All values are encoded using the standard base-64 representation of a byte-array containing the two's-complement representation of the value to encode. The first byte in this array is the high-order byte. The minimal number of bytes necessary is used to represent a certain value, so no leading zero-bytes are allowed.
The BNF below shows how a MD5 digest is encoded for P3P communications.
resource-hash ::= '"base64-string encoding of 128 bit MD5 message
digest of the information resource."'
base64-string ::=as defined in RFC-1521, section 5.2.
The formal grammar of P3P is given in this specification using a slight modification of the ABNF defined in http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt . The following is a simple description of the ABNF.
name = (element)
(element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string" or 'string'
Other notations used in the productions are:
| Lorrie Cranor | AT&T |
| Philip DesAutels | Matchlogic |
| Melissa Dunn | Microsoft |
| Daniel Jaye (Editor) | Engage Technologies |
| Kevin Jones | Intermind |
| Steve Lucas (Chair) | Matchlogic |
| Massimo Marchiori (Editor) | W3C |
| Maclen Marvit | Narrowline |
| Max Metral | Firefly Network Inc. |
| Paul Perry | Firefly Network Inc |
| Martin Presler-Marshall | IBM |
| Joseph Reagle (Project Manager) | W3C |
| Drummond Reed | Intermind |
This work was based on other documents, specifically the
as well as the :