WD-P3P-arch-971022 31 KB

Raw Blame History Permalink

<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>&nbsp;</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 &quot;work in progress&quot;. 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.&nbsp;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&nbsp; 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 &quot;privacy&quot; 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 &quot;parts of speech&quot; 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. &quot;noun-phrase&quot; 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
    &quot;lexeme&quot; - 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,
    &quot;preferences&quot; 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&nbsp;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 = &quot;0&quot; | &quot;1&quot;</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">&nbsp;</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 &quot;cookies&quot; 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 &quot;sphere of coverage&quot;</p>
</b></i>

<p>Users evaluate Web services on the basis of many criteria in addition to privacy
considerations. These &quot;trust&quot; 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&#146;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&#146;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 (&quot;contains no
profanity&quot; or &quot;does not include Java applets.&quot;). The user&#146;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&#146;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&#146;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 &quot;index.html&quot; 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 &quot;index.html&quot; 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&#146;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> &nbsp;&copy;&nbsp; 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>