You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
629 lines
31 KiB
629 lines
31 KiB
<html>
|
|
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
|
|
<meta name="Template" content="C:\Program Files\Microsoft Office\Office\html.dot">
|
|
<title>P3P Architecture Working Group WD-P3P-arch</title>
|
|
</head>
|
|
|
|
<body text="#000000" link="#0000FF" vlink="#800080" bgcolor="#FFFFFF">
|
|
|
|
<h3 align="right"><a href="http://www.w3.org/" target><img
|
|
src="http://www.w3.org/pub/WWW/Icons/WWW/w3c_home" alt="W3C" align="left" border="0"
|
|
hspace="0"></a>WD-P3P-arch-971022 </h3>
|
|
|
|
<h1 align="center">P3P Architecture Working Group </h1>
|
|
|
|
<h2 align="center">General Overview of the P3P Architecture</h2>
|
|
|
|
<h3 align="center">W3C Working Draft 22-October-97</h3>
|
|
|
|
<dl>
|
|
<dt> </dt>
|
|
<dt><strong>Latest Version: </strong></dt>
|
|
<dd><a href="WD-P3P-arch.html">http://www.w3.org/TR/WD-P3P-arch</a></dd>
|
|
<dt>This version: </dt>
|
|
<dd><a href="WD-P3P-arch-971022.html">http://www.w3.org/TR/WD-P3P-arch-971022</a></dd>
|
|
<dt>Previous Version:</dt>
|
|
<dd><font color="#FF0000">Member Only:</font> <a
|
|
href="../P3/Group/Architecture/wd-p3-arch-971008.html">http://www.w3.org/P3/Group/Architecture/wd-p3-arch-971008</a></dd>
|
|
</dl>
|
|
|
|
<p><strong>Editor:</strong></p>
|
|
|
|
<blockquote>
|
|
<p>Mark Ackerman, <a href="mailto:ackerman@binky.ics.uci.edu">ackerman@binky.ics.uci.edu</a>,
|
|
UC Irvine</p>
|
|
</blockquote>
|
|
|
|
<p><strong>Authors</strong>:
|
|
|
|
<dir>
|
|
<p>(In reverse alphabetical order) Joseph Reagle, Martin Presler-Martin, Melissa Dunn,
|
|
Philip DesAutels, Lorrie Cranor, Mark Ackerman </p>
|
|
</dir>
|
|
|
|
<hr>
|
|
|
|
<p><b>Status of This Document</b></p>
|
|
|
|
<p>This is a W3C Working Draft for review by W3C members and other interested parties. It
|
|
is a draft document and may be updated, replaced or obsoleted by other documents at any
|
|
time. It is inappropriate to use W3C Working Drafts as reference material or to cite them
|
|
as other than "work in progress". A list of current W3C working drafts can be
|
|
found at: <a href="./">http://www.w3.org/TR/</a> </p>
|
|
|
|
<p>This document represents a work in progress. It is not intended to be advanced
|
|
toward W3C recommendation status, but rather it should be used, along with the <a
|
|
href="WD-P3P-grammar.html">P3P Grammatical Model and Data Design Model Working Draft</a>,
|
|
as a basis for developing the Protocols and Data Transport Working Group's deliverable of
|
|
a specification, fully specifying the conversational framework for
|
|
user-agent/service interaction. It is strongly recommended that only experimental software
|
|
be implemented to this specification. The Platform for Privacy Preferences Project will
|
|
not allow early implementations to affect their ability to make changes to the framework
|
|
described in this document.</p>
|
|
|
|
<p>Comments on this working draft should be sent to the P3P Project Manager, <a
|
|
href="mailto:philipd@w3.org">Philip DesAutels</a></p>
|
|
|
|
<p>This document is part of the <a href="../P3/">Platform for Privacy Preferences Activity</a>.</p>
|
|
|
|
<hr>
|
|
<b>
|
|
|
|
<p>Purpose</p>
|
|
</b>
|
|
|
|
<p>The purpose of this document is to provide a general overview to the P3P architecture.
|
|
We define terms and concepts which form the underpinning of the Personal Privacy
|
|
Preferences (P3P) system.</p>
|
|
<b>
|
|
|
|
<p>Introduction</p>
|
|
</b>
|
|
|
|
<p>P3P addresses the twin goals of meeting the data privacy expectations of consumers on
|
|
the Web while assuring that the medium remains available and productive for electronic
|
|
commerce. Both goals can be achieved by following the principles of consumer notice,
|
|
choice, and control with respect to site privacy practices and data control.</p>
|
|
|
|
<p>The goal of this document is to clearly delineate the design space from the
|
|
implementation and to determine which issues remain to be addressed. This document does
|
|
not provide specific details of the privacy practice grammar, data design, nor the
|
|
transport and negotiation protocols. Please see the relevant working group drafts for that
|
|
information.</p>
|
|
<i><b>
|
|
|
|
<p>Scope of P3P</p>
|
|
</b></i>
|
|
|
|
<p>The term "privacy" covers a very wide range of concerns, and it is important
|
|
that one understands from the outset the precise scope of the P3P work. P3P will enable
|
|
sites to express privacy practices and for user to express their preferences about those
|
|
practices and have their agent act on it accordingly. The user agent can then provide the
|
|
user a safe and seamless experience. </p>
|
|
|
|
<p>A P3P interaction will result in an agreement between the service and the user agent
|
|
regarding the practices associated with a user's implicit (i.e., click stream) or explicit
|
|
(i.e., user-answered) data. The agreement may include service side permissions regarding
|
|
the storage and release of data written by the service and accepted by the user agent.
|
|
Allowing client side storage of user data in a data repository increases the user's access
|
|
to and control of data, while providing a mechanism so that the user need not repeatedly
|
|
enter frequently solicited information. This architecture enhances personal privacy while
|
|
providing richer, easier access to Web services. </p>
|
|
|
|
<p>The larger goal of P3P is to create a framework that promotes trust and confidence in
|
|
the Web. We believe that the key ideas are:
|
|
|
|
<ul>
|
|
<li>The disclosure of site privacy practices. </li>
|
|
<li>The expression of a user's preferences with respect to which practices they prefer. </li>
|
|
<li>The ability of the site and user agent to reach an agreement about their interactions
|
|
with respect to data privacy. </li>
|
|
<li>Subsequent to an agreement, the controlled and secure exchange of data on behalf of the
|
|
user to the service that defined or requested the data.</li>
|
|
</ul>
|
|
<b>
|
|
|
|
<p>Definitions</p>
|
|
</b>
|
|
|
|
<p>We define the following elements:</p>
|
|
<div align="center"><center>
|
|
|
|
<table border="1" cellspacing="1" bordercolor="#000000" cellpadding="5" width="673">
|
|
<tr>
|
|
<td width="23%" valign="TOP">Access</td>
|
|
<td width="77%" valign="TOP">For P3P purposes, a clause that expresses the ability of
|
|
users to obtain and correct information that an entity has collected about them. A
|
|
vocabulary may define various degrees of access.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="MIDDLE">Agreement</td>
|
|
<td width="77%" valign="MIDDLE">A statement that a service and a<font color="#00ff00"> </font>user
|
|
agent have agreed to abide by.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Clause</td>
|
|
<td width="77%" valign="TOP">The "parts of speech" from which P3P statements are
|
|
constructed.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Credentials</td>
|
|
<td width="77%" valign="TOP">Signed statements of authorization, identification, or
|
|
practice (e.g. certificates granting authority or identity, or signed metadata). These
|
|
credentials may be presented or be requested by either the user agent or the service. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP" height="71">Data category</td>
|
|
<td width="77%" valign="TOP" height="71">A quality of a data element or class that may be
|
|
used by a trust engine to determine what type of element is under discussion (such as
|
|
anonymous demographics versus personal contact information).</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Data class</td>
|
|
<td width="77%" valign="TOP">A grouping of data elements such as mailing address (which
|
|
includes, e.g., name, street address, city, state, and country).</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Data element</td>
|
|
<td width="77%" valign="TOP">A single data entity such as last name or phone number.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Grammar</td>
|
|
<td width="77%" valign="TOP">(From Computing Dictionary) A formal definition of the
|
|
syntactic structure of a language (see syntax), normally given in terms of production
|
|
rules which specify the order of constituents and their sub-constituents in a sentence (a
|
|
well-formed string in the language). Each rule has a left-hand side symbol naming a
|
|
syntactic category (e.g. "noun-phrase" for a natural language grammar) and a
|
|
right-hand side which is a sequence of zero or more symbols. Each symbol may be either a
|
|
terminal symbol or a non-terminal symbol. A terminal symbol corresponds to one
|
|
"lexeme" - a part of the sentence with no internal syntactic structure (e.g. an
|
|
identifier or an operator in a computer language). A non-terminal symbol is the left-hand
|
|
side of some rule.<p>One rule is normally designated as the top-level rule which gives the
|
|
structure for a whole sentence. A grammar can be used either to parse a sentence (see
|
|
parser) or to generate one. Parsing assigns a terminal syntactic category to each input
|
|
token and a non-terminal category to each appropriate group of tokens, up to the level of
|
|
the whole sentence. Parsing is usually preceded by lexical analysis. Generation starts
|
|
from the top-level rule and chooses one alternative production wherever there is a choice.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Grammar (P3P)</td>
|
|
<td width="77%" valign="TOP">In P3P, the grammar defines the structure of P3P clauses used
|
|
to make a valid P3P statement. The grammar are the rules for properly ordering clauses.
|
|
The following example structures clauses (in the parentheses) to make a simple privacy
|
|
practice statement: <p>for (these URIs)<br>
|
|
the following (practices) apply<br>
|
|
to this (set of data)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">P3P data repository</td>
|
|
<td width="77%" valign="TOP">A mechanism for storing data under the control of P3P
|
|
preferences over a period of time. These data might include personal data.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Permissions</td>
|
|
<td width="77%" valign="TOP">A set of conditions (e.g., access mode) which are specified
|
|
on requested P3P data. A service asks the user agent to initially consent to permissions
|
|
in conjunction with the service's commitment to follow its declared privacy practices.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Persona</td>
|
|
<td width="77%" valign="TOP">A persona is the combination of a set of user preferences and
|
|
P3P data. Personae allow the user to create different views of themselves by changing the
|
|
data given to a service. The persona may be based upon the service's purpose (e.g.,
|
|
business, gaming, home, etc.), credentials (e.g., level of associated trust), consequences
|
|
and practices (e.g., personalization, shipping, mailing list), or any user defined
|
|
rationale (e.g., time of day, phase of moon, etc). A user may have multiple personae.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Policies</td>
|
|
<td width="77%" valign="TOP">The collection of all user defined preferences, including,
|
|
but not limited to, P3P preferences<font color="#008000">.</font></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Protocol</td>
|
|
<td width="77%" valign="TOP">(From the Computing Dictionary) A set of formal rules
|
|
describing how to transmit data, especially across a network. Low level protocols define
|
|
the electrical and physical standards to be observed, bit- and byte-ordering and the
|
|
transmission and error detection and correction of the bit stream. High level protocols
|
|
deal with the data formatting, including the syntax of messages, the terminal to computer
|
|
dialogue, character sets, sequencing of messages etc. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Practice</td>
|
|
<td width="77%" valign="TOP">A P3P clause that describes what a service plans to do with
|
|
data. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Preference</td>
|
|
<td width="77%" valign="TOP">A rule, or set of rules, that determines what action(s) a
|
|
user agent will take or allow when involved in a conversation or negotiation with a
|
|
service. A preference might be expressed as a formally defined computable statement; e.g.,
|
|
a PICSRules rule. In this document, preferences govern the types of agreements that can be
|
|
reached between a user agent and a service. <p>Within this document,
|
|
"preferences" are assumed to be P3P preferences.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Proposal</td>
|
|
<td width="77%" valign="TOP">A series of statements. A proposal is used when a user agent
|
|
and a service are negotiating to form an agreement.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="MIDDLE">Request</td>
|
|
<td width="77%" valign="MIDDLE">A message in which a service asks a user agent to transmit
|
|
(read request) or store (write request) a data element or set of data elements.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Result set</td>
|
|
<td width="77%" valign="TOP">The user's data sent to the service by the user agent.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Service</td>
|
|
<td width="77%" valign="TOP">A program, for P3P purposes, requesting data from, or
|
|
providing data to, a user agent. By this definition, a service may be a server, a local
|
|
application, a piece of locally active code, such as an ActiveX control or Java applet, or
|
|
even another user agent.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Statement</td>
|
|
<td width="77%" valign="TOP">A description of what data a service will request, what the
|
|
service will do with it, and the consequence to the user.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Syntax</td>
|
|
<td width="77%" valign="TOP">(From Computing Dictionary) The structure of strings in some
|
|
language. A language's syntax is described by a grammar. For example, the syntax of a
|
|
binary number could be expressed as<font face="Courier New"><p>binary_number = bit
|
|
[binary_number]</p>
|
|
<p>bit = "0" | "1"</font> </p>
|
|
<p>meaning that a binary number is a bit optionally followed by a binary number and a bit
|
|
is a literal zero or one digit. The meaning of the language is given by its semantics. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Trust Engine</td>
|
|
<td width="77%" valign="TOP">A mechanism for evaluating incoming statements to make a
|
|
decision. For P3P purposes, the trust engine evaluates P3P proposals and requests.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">User</td>
|
|
<td width="77%" valign="TOP">An individual or group of individuals acting as a single
|
|
entity. For the purposes of this document, the user is further qualified as an entity for
|
|
which personal data exists and/or can be collected. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">User agent</td>
|
|
<td width="77%" valign="TOP">A program that acts on a user's behalf. The user agent may
|
|
act on preferences (rules) for a broad range of purposes, such as content filtering, trust
|
|
decisions, or privacy. For P3P purposes, a user agent acts on a user's privacy
|
|
preferences. Users may use different user agents at different times. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="23%" valign="TOP">Vocabulary (schema)</td>
|
|
<td width="77%" valign="TOP">The defined set of words or statements that are allowable in
|
|
a clause. For instance, a vocabulary may define the practice clause to be one of the two
|
|
values<font color="#008000">: </font>'for system administration', 'for research'.</td>
|
|
</tr>
|
|
</table>
|
|
</center></div>
|
|
|
|
<p align="CENTER"> </p>
|
|
<b>
|
|
|
|
<p>P3P Architecture</p>
|
|
</b>
|
|
|
|
<p>The P3P Architecture Working Group is charged to create a robust and efficient
|
|
architecture for the Platform for Privacy Preferences.</p>
|
|
|
|
<p>It is important to note that the P3P architecture provides mechanisms that are
|
|
policy-neutral. It provides a general architecture that can allow a range of social and
|
|
commercial policies to be implemented. </p>
|
|
<b>
|
|
|
|
<p>Entities in the architecture</p>
|
|
</b>
|
|
|
|
<p>The P3P architecture contains two basic entities: the user agent and the service. Each
|
|
is defined in terms of its functionality, and each is considered largely as a black box.
|
|
The <i>service</i> requests data from a user. The service, in the P3P architecture, states
|
|
that it does not collect data or it collects some specified set of data according to some
|
|
specified set of practices.</p>
|
|
|
|
<p>A <i>user agent</i> handles these requests or statements on behalf of the user. </p>
|
|
|
|
<p align="CENTER"><img src="wd-p3p-arch-figure1.gif" alt="P3P Figure 1" start="fileopen"
|
|
border="0" width="512" height="144"></p>
|
|
|
|
<p>This functionality-based architecture is distinct from a client-server model. For
|
|
example, in the P3P architecture, there is only one user agent. However, in reality, the
|
|
user agent is a black box functionality. The implementation may have any number of
|
|
different agents on any number of machines. The user agent may be in close communication
|
|
with the user through some graphical user interface, or it may act as an automatic proxy.
|
|
The user agent may even act on behalf of multiple users (e.g., a family) or for privileged
|
|
users (e.g., a parent). From the viewpoint of P3P, the relations among users and user
|
|
agents are all outside the scope of this project.</p>
|
|
|
|
<p>The implementation of a service (e.g., the relationship between a service and its
|
|
servers) is also not specified within this architecture. </p>
|
|
<i><b>
|
|
|
|
<p>Data repositories</p>
|
|
</b></i>
|
|
|
|
<p>In the P3P architecture, it is presumed that the user agent has access to any data that
|
|
the user wishes to safeguard. This data is kept within the <i>data repository</i>. The
|
|
nature of both the data repository and how the data is accessed is not specified by this
|
|
architecture. For example, in the case of a hand-held device with little onboard memory
|
|
and storage, the user agent may act through another agent to obtain access to the data
|
|
repository located on a third-party. </p>
|
|
|
|
<p>Data would be read from the data repository to provide personal information to a
|
|
service. Services might also write information to the data repository; this would allow
|
|
the capabilities provided by "cookies" in HTTP today.</p>
|
|
|
|
<p>The functional description of the data repository is provided in the Vocabulary Working
|
|
Group's working draft. The data repository may include data elements written by both user
|
|
agents and services. The user agent can help the user evaluate whether to allow reads from
|
|
or writes to the data repository. Note that the reading and writing of data are always
|
|
under the control (implicitly or explicitly) of the user. </p>
|
|
<i><b>
|
|
|
|
<p>Trust engines and the P3P "sphere of coverage"</p>
|
|
</b></i>
|
|
|
|
<p>Users evaluate Web services on the basis of many criteria in addition to privacy
|
|
considerations. These "trust" criteria may include, among other issues, content,
|
|
authority, cost, and governmental regulations. For example, a user may decide whether to
|
|
look at a specific Web page because it contains sports, was authored by someone at the
|
|
Boston Globe, and costs less than five cents. Users' evaluations are complex and based
|
|
upon many personal nuances.</p>
|
|
|
|
<p>User agent implementations, then, may need to check for the existence of a variety of
|
|
inputs: statements from services, labels on content, credentials, and other environmental
|
|
information (IP Address, time of day, etc). These user agents will react to these
|
|
statements. For instance, the user agent might restrict access to a site, control
|
|
information flow to service, or allow the execution of active content. The user agent
|
|
would act according to a broad set of preferences (rules) a user has established with that
|
|
agent. (Some or all of these preferences may have been obtained from a third party, such
|
|
as a government sanctioned preference bureau, a social or religious affiliated service, or
|
|
other trusted source.) Furthermore, these statements may be acted on individually or in
|
|
combination. </p>
|
|
|
|
<p>User agents, then, will serve as proxies in the evaluation process by users. Within the
|
|
user agent, there will be some type of <i>trust engine</i> that makes this evaluation on
|
|
behalf of the user. A variety of mechanisms may be employed by trust engine
|
|
implementations. For example, one might implement such a trust engine using expert system
|
|
rules or a neural network. </p>
|
|
|
|
<p>Users may specify their <i>preferences</i> using a variety of interfaces (determined by
|
|
the implementation of the user agent they use). At some point these preferences might be
|
|
stored using a standard language. They might be stored as purpose-specific practices
|
|
(e.g., PICSRules for PICS labels, another language for P3P privacy preferences) or in a
|
|
more general language. The set of all stored preferences is a user's <i>policy</i>. </p>
|
|
|
|
<p align="CENTER"><img src="wd-p3p-arch-figure2.gif" width="544" height="343"
|
|
alt="P3P Figure 2"></p>
|
|
|
|
<p>A user’s policy might include preferences regarding P3P statements, signer
|
|
credentials, RSACi labels, digital signature algorithms, safe-code labels, domain name
|
|
restrictions (the server is in *.domain.com or *.edu), or locally defined
|
|
statements/labels. For example, a user may restrict interest to the domains *.foobar.com
|
|
or *.edu. As another example, the user might keep a database of sites she’s visited
|
|
and generate personally meaningful labels for them. Or if a site presents no statements or
|
|
labels, the user might fetch the page and generate one for it ("contains no
|
|
profanity" or "does not include Java applets."). The user’s policy
|
|
might also include rules for identifying how all of the practices should interact. </p>
|
|
|
|
<p align="CENTER"><img src="wd-p3p-arch-figure3.gif" width="512" height="280"
|
|
alt="P3P Figure 3" start="fileopen"></p>
|
|
|
|
<p>Users who have a different set of preferences based upon type of sites, time of day,
|
|
etc., are creating policies that combine P3P preferences with preferences about other
|
|
input statements and credentials. Together, P3P statements and preferences are part of a
|
|
larger picture. The trust engine, as mentioned, will evaluate many types of incoming data,
|
|
including P3P statements. One of the reasons to keep the user agent and service as block
|
|
boxes is to restrict the scope of P3P to privacy considerations. By treating the user
|
|
agent as a black box, no consideration of the trust engine implementation is required. We
|
|
merely assume that, in some way, the user agent is able to evaluate P3P practice
|
|
statements on behalf of the user. </p>
|
|
<b>
|
|
|
|
<p>P3P statements and requests</p>
|
|
</b>
|
|
|
|
<p>There are 8 types of statements or requests that can be made in P3P: The form of the
|
|
statements and requests is still to be specified.
|
|
|
|
<ol>
|
|
<li>Request for data - A service may request data from a user agent. </li>
|
|
<li>Request for practice (query). A user agent may request practices from a service to open
|
|
a conversation.</li>
|
|
<li>Request for preferences - A service, such as a search engine or a trusted proxy, may ask
|
|
for preferences from a user agent. </li>
|
|
<li>Transfer of practice. In a <i>proposal</i>, the service provides a statement or
|
|
statements detailing the service’s practices with regard to specified personal data.
|
|
See the vocabulary working group document for the definition of the practice statements.
|
|
Note a service need not request data later, but only wish to inform the user about its
|
|
privacy practices</li>
|
|
<li>Transfer of preferences. User agents may wish to transfer their preferences to a trusted
|
|
intermediary, such as a search engine.</li>
|
|
<li>Request for transfer of data. This is the request for the transfer of P3P data by the
|
|
service. This statement may be combined with the statement of the service’s
|
|
practices. </li>
|
|
<li>Agreement. The statement that the user agent agrees with a practice statement from the
|
|
service. There are three replies: yes, no (but negotiation is possible), and final no. </li>
|
|
<li>The transfer of data. This may be combined with the agreement statement. The request for
|
|
the transfer of data will include the transfer protocol used in this step.</li>
|
|
</ol>
|
|
|
|
<p>Statements 1, 4, and 6 may be combined by a service. The request for data and the
|
|
request for the transfer of data have been separated to allow different negotiation
|
|
mechanisms, and they may be combined in future P3P protocols.</p>
|
|
|
|
<p>Additionally, some negotiation between the user agent and the service may take place.
|
|
The negotiation statements will be specified by a future working group.</p>
|
|
|
|
<p>User agents must deal with unsolicited proposals. As the user moves between servers
|
|
within the same experience space, the servers (within the same service) may need to send
|
|
unsolicited proposals.</p>
|
|
|
|
<p>It is recommended that user agents at least keep the last agreement in the current
|
|
experience space. The user agent can then compare requests and agreements, allowing
|
|
optimization. </p>
|
|
<i><b>
|
|
|
|
<p>Scenarios considered</p>
|
|
</b></i>
|
|
|
|
<p>In the simplest scenario, a service understands P3P, but collects no information. If
|
|
the browser does not understand P3P, it should look to the browser as it does currently.
|
|
If the browser understands P3P, it has the option of returning an agreement as an
|
|
acknowledgement. </p>
|
|
<div align="center"><center>
|
|
|
|
<table cellspacing="0" border="0" cellpadding="7" width="705">
|
|
<tr>
|
|
<td width="7%" valign="TOP"></td>
|
|
<td width="37%" valign="TOP"><u>Service</u></td>
|
|
<td width="56%" valign="TOP"><u>User agent</u></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">1</td>
|
|
<td width="37%" valign="TOP"></td>
|
|
<td width="56%" valign="TOP">Request of "index.html" from <a
|
|
href="http://www.random-site.com/">www.random-site.com</a>. </td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">2</td>
|
|
<td width="37%" valign="TOP">Service sends P3P statement and index.html.</td>
|
|
<td width="56%" valign="TOP"></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">3</td>
|
|
<td width="37%" valign="TOP"></td>
|
|
<td width="56%" valign="TOP">(optional) User agent returns agreement.</td>
|
|
</tr>
|
|
</table>
|
|
</center></div>
|
|
|
|
<p align="CENTER">In a standard scenario, both the service and user agent are
|
|
P3P-compliant, and the service will request personal data from the user agent. </p>
|
|
<div align="center"><center>
|
|
|
|
<table cellspacing="0" border="0" cellpadding="7" width="703">
|
|
<tr>
|
|
<td width="7%" valign="TOP"></td>
|
|
<td width="37%" valign="TOP"><u>Service</u></td>
|
|
<td width="56%" valign="TOP"><u>User agent</u></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">1</td>
|
|
<td width="37%" valign="TOP"></td>
|
|
<td width="56%" valign="TOP">Request of "index.html" from <a
|
|
href="http://www.random-site.com/">www.random-site.com</a>; user agent makes request for
|
|
proposal from service</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">2</td>
|
|
<td width="37%" valign="TOP">Service sends P3P proposal.</td>
|
|
<td width="56%" valign="TOP"></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">3</td>
|
|
<td width="37%" valign="TOP"></td>
|
|
<td width="56%" valign="TOP">User agent returns agreement.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">4</td>
|
|
<td width="37%" valign="TOP">Service sends request for data.</td>
|
|
<td width="56%" valign="TOP"></td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">5</td>
|
|
<td width="37%" valign="TOP"></td>
|
|
<td width="56%" valign="TOP">User agent transfers data to service.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="7%" valign="TOP">6</td>
|
|
<td width="37%" valign="TOP">Service sends index.html.</td>
|
|
<td width="56%" valign="TOP"></td>
|
|
</tr>
|
|
</table>
|
|
</center></div>
|
|
|
|
<p>Steps 4 to 6 may be done in any order and may be done multiple times. Steps 1 through 6
|
|
may be bundled together in various ways (e.g., 2 and 4 together) for optimization. </p>
|
|
<b>
|
|
|
|
<p>Recommendations for future action and open issues</p>
|
|
</b>
|
|
|
|
<p>The following are implementation recommendations considered important by the
|
|
architecture group:
|
|
|
|
<ol>
|
|
<li>Users should be allowed to view and update any personal data within their data
|
|
repository. </li>
|
|
</ol>
|
|
|
|
<ul>
|
|
<ul>
|
|
<li>The user or user agent should be queried as to whether new data should be permanently
|
|
stored for later use. </li>
|
|
<li>The user agent should provide a mechanism for locking data at the element or personae
|
|
level. This recommendation is made because some users should not be able to modify or
|
|
specify new personal data. For example, parents may with to set up their children's
|
|
personal information including birthdate. Children should not have the capability to
|
|
change their ages in order access adult services. </li>
|
|
<li>It should not be required that user agents or services log the agreements they reach.</li>
|
|
</ul>
|
|
</ul>
|
|
|
|
<ol>
|
|
<li>An interchange format for preferences should be specified. In order to comply with
|
|
regulations and standard for different countries or local governments, it may become
|
|
important that users be able to obtain preferences from third parties. This may also be
|
|
important for acceptance and adoption by users.</li>
|
|
<li>The method by which services and user agents can determine whether one or both are
|
|
P3P-compliant must be simple and straight-forward. </li>
|
|
<li>Levels of compliance to P3P should be specified. This may include validation suites,
|
|
benchmarks, or scenarios.</li>
|
|
</ol>
|
|
|
|
<p>The architecture group notes the following open issues:
|
|
|
|
<ol>
|
|
<li>Negotiation has been left largely undefined. Its mechanisms, steps, and scope need to be
|
|
defined.</li>
|
|
<li>We have not discussed how digital certificates and signatures fit into this system. The
|
|
issues of identification, authentication, and authorization all need to be addressed. </li>
|
|
<li>The question of whether P3P agreements are legal contracts was left unresolved. While
|
|
the W3C has no ability to resolve the legal interpretations of the P3P system, we will
|
|
need to make suggestions to the people who will make those interpretations. </li>
|
|
<li>There may need to some mechanism for mandating explicit informed consent from the user
|
|
rather than implicit acceptance via the user’s agent. This may be important for some
|
|
countries, such as Germany.</li>
|
|
<li>We do not believe that we have explored all the issues relating to implementing this
|
|
architecture on hand-held and other storage- and processor-contstrained devices. </li>
|
|
</ol>
|
|
|
|
<hr>
|
|
|
|
<p>
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">
|
|
Copyright</A> © 1997 <A href="http://www.w3.org">W3C</A>
|
|
(<A href="http://www.lcs.mit.edu">MIT</A>,
|
|
<A href="http://www.inria.fr/">INRIA</A>,
|
|
<A href="http://www.keio.ac.jp/">Keio</A> ), All Rights Reserved. W3C
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#Legal Disclaimer">liability,</A>
|
|
<A href="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3C Trademarks">trademark</A>,
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
|
|
use </A>and
|
|
<A href="http://www.w3.org/Consortium/Legal/copyright-software.html">software
|
|
licensing </A>rules apply.
|
|
<p><a href="../Help/Webmaster.html">Webmaster</a> 28 Oct 97</p>
|
|
</body>
|
|
</html>
|