WD-P3P-grammar-971014 43.6 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">
<title>W3C P3 Vocabulary Working Draft</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-grammar-971014 </h3>

<h1 align="center">P3P Vocabulary Working Group </h1>

<h2 align="center">Grammatical Model and Data Design Model</h2>

<h3 align="center">W3C Working Draft 14-October-97</h3>

<dl>
  <dt>&nbsp;</dt>
  <dt><strong>Latest Version: </strong></dt>
  <dd><a href="WD-P3P-grammar.html">http://www.w3.org/TR/WD-P3P-grammar</a></dd>
  <dt>This version: </dt>
  <dd>&nbsp;<a href="WD-P3P-grammar-971014.html">http://www.w3.org/TR/WD-P3P-grammar-971014</a></dd>
  <dt>Previous Version:</dt>
  <dd><font color="#FF0000">Member Only:</font> <a
    href="../P3/Group/Vocabulary/wd-p3-vocab-101497.html">http://www.w3.org/P3/Group/Vocabulary/wd-p3-vocab-101497</a></dd>
</dl>

<p><strong>Editor</strong>

<ul>
  <li>Lorrie Cranor, <a href="mailto:lorrie@research.att.com">lorrie@research.att.com</a>,
    AT&amp;T Labs-Research</li>
</ul>

<p><strong>Authors: </strong>

<ul>
  <li>Mark Ackerman, W3C </li>
  <li>Lorrie Cranor, AT&amp;T Labs-Research </li>
  <li>Philip DesAutels, W3C </li>
  <li>Melissa Dunn, Microsoft Research </li>
  <li>Joseph Reagle, W3C </li>
  <li>Upendra Shardanand, Firefly </li>
</ul>

<hr>

<h2>Status of This Document</h2>

<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 will be used, along with the <a
href="WD-P3P-arch.html">P3P Architecture 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>

<h2>Purpose </h2>

<p>The W3C Platform for Privacy Preference Project Vocabulary Working Group presents this
basic model for the P3P privacy conversation between a user agent and a service.</p>

<p>The purpose of this document is to specify:

<ul>
  <li>a grammatical model for expressing <a href="../P3/">P3P</a> service <i>practices</i> and
    user <i>preferences </i>over data in the semantic framework of <a href="../Metadata/">RDF</a>,
    and </li>
  <li>a data design model for expressing and referencing data elements, classes, and
    categories. </li>
</ul>

<p>The P3P <a href="../P3/Group/Architecture/">Architecture Working Group</a> has produced
a <a href="WD-P3P-arch.html">draft document</a> which provides a general overview to the
P3P architecture. </p>

<h2>Definitions </h2>
<div align="center"><center>

<table cellspacing="1" cellpadding="5" width="650" bordercolor="#000000">
  <tr>
    <td width="25%" valign="TOP">Access</td>
    <td width="75%" 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="25%" valign="MIDDLE">Agreement</td>
    <td width="75%" 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="25%" valign="TOP">Clause</td>
    <td width="75%" valign="TOP">The &quot;parts of speech&quot; from which P3P statements are
    constructed.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Credentials</td>
    <td width="75%" 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.
    Credentials need not be accompanied by digital signatures.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP" height="117">Data category</td>
    <td width="75%" valign="TOP" height="117">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 (for example
    anonymous demographics or personal contact information).</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Data class</td>
    <td width="75%" 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="25%" valign="TOP">Data element</td>
    <td width="75%" valign="TOP">A single data entity such as last name or phone number.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Grammar (P3P)</td>
    <td width="75%" 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 caps) to make a simple privacy practice
    statement: <p>for (these URIs)<br>
    the following (practices) apply<br>
    to this (set of data) </p>
    <p><small>Also see <a href="http://wagner.princeton.edu/foldoc/cgi-script?query=grammar">grammar</a>
    at Princeton's Free On-line Dictionary of Computing<small>.</small></small></td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">P3P data repository</td>
    <td width="75%" 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="25%" valign="TOP">Permissions</td>
    <td width="75%" valign="TOP">Permissions are constraints which, when evaluated, allow or
    prevent access or modification of data classes or elements within the&nbsp; data
    repository of a user agent.&nbsp; Permissions are set by a service and evaluated along
    with a user's preferences. Thus permissions serve only to restrict actions permitted by a
    user's preferences; they never allow actions that the user's preferences would otherwise
    prohibit.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Persona</td>
    <td width="75%" valign="TOP">A persona is an image of a user that he or she presents in a
    particular situation. The user's preferences and P3P data may combine to form a persona. A
    user may have multiple personae. The choice of which persona to present to a service 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).</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Policies</td>
    <td width="75%" 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="25%" valign="TOP">Practice</td>
    <td width="75%" valign="TOP">A P3P clause that describes what a service plans to do with
    data.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Preference</td>
    <td width="75%" 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="25%" valign="TOP">Proposal</td>
    <td width="75%" 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="25%" valign="MIDDLE">Request</td>
    <td width="75%" 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="25%" valign="TOP">Result set</td>
    <td width="75%" valign="TOP">The user's data sent to the service by the user agent.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Service</td>
    <td width="75%" 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="25%" valign="TOP">Statement</td>
    <td width="75%" valign="TOP">A description of what data a service will request, what the
    service will do with it, and the consequence to the user. P3P statements are composed of
    clauses, as specified by the&nbsp;P3P grammar.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">Trust Engine</td>
    <td width="75%" valign="TOP">A mechanism for evaluating credentials and policies to make a
    decision. For P3P purposes, the trust engine evaluates P3P proposals and requests, user
    preferences, and possibly other credentials.</td>
  </tr>
  <tr>
    <td width="25%" valign="TOP">User</td>
    <td width="75%" 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="25%" valign="TOP">User agent</td>
    <td width="75%" valign="TOP">A program that acts on a user's behalf. The 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="25%" valign="TOP">Vocabulary (schema)</td>
    <td width="75%" 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>

<hr>

<h2 align="left">Data Design </h2>

<p>In this section we present a data design model for expressing and referencing data
elements, classes, and categories. </p>

<h3>Data Elements and Data Classes </h3>

<p>A <i>data element</i> is a single data entity such &nbsp;as a last name or phone
number. &nbsp;A <i>data class</i> is a named set of data elements and/or other data
classes. &nbsp;Data classes inherit the data elements from all classes they contain.
&nbsp;While most data elements correspond to a specific piece of information that can be
stored as a text string, some data elements represent streams of data such as a user's
click stream. </p>

<p>There is a <i>base set</i> of well known P3P data classes (to be defined by a future
working group).&nbsp;Neither user nor service can change a base data class. This
restriction allows for a common understanding between user agent and service that can
simplify the negotiation process. However, new classes may be introduced by services. A
future P3P working group will recommend a <a href="WD-rdf-syntax/">RDF</a> application for
defining data elements and data classes. </p>

<p>In an attempt to minimize the problem of duplicate information and to allow for the
advantages of standardization, the following naming conventions are proposed:

<ul>
  <li>Multiple word names should use an underscore to separate the words (e.g., Shoe_Size,
    False_Address) </li>
  <li>Data classes should begin with a pound sign to distinguish the name space from a data
    element (e.g., #Demographics, #My_Information) </li>
  <li>Name space identifiers can be used in front of data elements in order to distinguish
    differences in values according to a domain (e.g., Base::Shoe_Size, Nike::Shoe_Size,
    Adidas::Shoe_Size </li>
  <li>Names are case insensitive </li>
</ul>

<p>While these standards will aid in creating some consistency between services and user
agents, the possibility for duplication of information will still arise when there are
requests for the same information using unknown names (e.g., Size_Of_Shoe). In some cases,
this data may already exist under a different heading (i.e., Shoe_Size). In other cases,
there is no duplication, just a new request. The user agent implementation may provide the
user with assistance in determining whether to use an already stored value, create a new
data element, or create a name space replication containing a different value. </p>

<p>A <i>result set </i>is&nbsp;a set of data elements sent by a user agent to the service
as&nbsp;a result of a request. Result sets contain traditional value pairs wherein one
half of the pair describes the value and the other is the value itself. &nbsp;P3P data
repositories may store data in a similar manner, however this will be implementation
dependent. </p>

<p>User agents may also provide users with the ability to create their own groupings of
data elements, for example groups of elements over which the user has similar preferences.
&nbsp;However, this is an implementation detail left up to each implementor. </p>

<h3>Data Categories </h3>

<p>A data category is a quality of a data element or class. The data category is a hint to
the agent regarding the type or sensitivity of a data element that is unrecognized by the
agent. For instance, an agent encountering the previously unknown data element shoe_size
can see that the data element has been categorized by its creator as demographic data.
This can then simplify the user interface and the resulting user experience. User agents
may allow users to express preferences about individual data elements, data classes and
data categories. &nbsp;When a service proposes to request a data element, the agent can
check whether the user has expressed a preference about that particular element. &nbsp;If
so, the agent would follow that preference, otherwise the agent can check the user's
preferences over the category to which that element belongs. Thus categories can be used
to reduce the number of choices users must make while browsing. </p>

<p>Designers of new data class schemas should use data categories to give hints to the
user or the user agent about the characteristics of the data. However, users should have
the option to over-ride or distrust the hints provided by the service. </p>

<p>A data class or element can be described by multiple categories. A data class should be
inherit at least the categories of the contained elements. So for instance, if a data
class contains demographic and contact information elements, the class should be described
as such. The grouping of elements into a class may also deserve an additional
categorization. For instance, a first name or last name alone are not identifiable
information, but together they may be. </p>

<p>[The necessity of the data categories was considered to be questionable among some
members of the working group. &nbsp;However, others felt strongly that data categories
would be important for maintaining a seamless user experience.] </p>

<hr>

<h2>Grammatical Model </h2>

<p>This section describes the grammatical model for <i>proposals</i> and <i>requests</i>.
&nbsp;P3P will define the syntax for a proposal, other parties will describe specific
vocabularies for use in P3P proposals. The Harmonized Vocabulary Working Group will
document the issues related to the development of a uniform vocabulary and may recommend a
single vocabulary if such a vocabulary can be agreed to by the working group. All
statements made by the user agent or service as part of the negotiation are to be defined
by the Protocols and Data Transport Working Group; we expect the results of&nbsp; this
working group to closely follow the grammatical model proposed here. </p>

<h3>Proposals </h3>

<p>Services make proposals to user agents in which they specify one or more sets of terms
under which they are willing to grant the user access. &nbsp;Each set of terms is
expressed as a statement. &nbsp; </p>

<p>Proposals must include a schema, one or more statements, and optionaly any of the
following statement clauses applied globally to the entire proposal: experience space,
contact, agreement with, access, consequence, qualifier, and signature. &nbsp;Each of
these clauses is described in detail below. </p>

<h3>General Form and Pseudocode Form of Grammatical Model </h3>

<p>The general form of a proposal is: </p>

<blockquote>
  <p>using <em>schema<br>
  </em>(for some <em>experience space</em>)<br>
  (you will enter an <em>agreement</em> <i>with </i>this entity)<br>
  (<em>Statement</em>)+<br>
  They will offer:<br>
  (this <em>access)</em><br>
  (and this <em>qualifier)</em><br>
  (Accepting will give you this <em>consequence</em>)<br>
  (for more information, <em>contact</em>)<br>
  (Signature) </p>
</blockquote>

<p>Statements are composed of the following mandatory clauses: experience space, practice,
qualified data set. Statements might also include the following optional clauses:
qualifier, access, consequence, agreement_with, contact. These clauses are further
specified below. &nbsp;The proposed&nbsp; protocols and negotiation working group will
also determine any additional syntax that might be needed for combining statements into
proposals. </p>

<p>The general form of a statement is: </p>

<blockquote>
  <p>(for some <em>experience space</em>)<br>
  (you will enter an <em>agreement</em> <i>with </i>this entity)<br>
  who will apply this (<i>practice </i>to (<i>qualified data set</i>)<i>+ </i><br>
  &nbsp; &nbsp;(with <i>qualifier</i>)* <br>
  &nbsp; &nbsp;(with <i>access</i>)<br>
  )<i>*</i><br>
  (Accepting will give you this <em>consequence</em>)<br>
  (for more information, <em>contact</em>)<br>
  (Signature) </p>
</blockquote>

<p>The general form of a qualified data set is: </p>

<blockquote>
  <p>named set of data<br>
  falling into this (<i>category</i>)+<br>
  using <em>data schema<br>
  </em>Apply the access <em>permission </em>restriction<br>
  (and this <em>qualifier</em>) </p>
</blockquote>

<p>In pseudocode, this might look something like: &nbsp; </p>

<pre>&lt;ablock id=&quot;proposal&quot;&gt;
	&lt;namespace href=&quot;http://www.w3.org/P3_1.0/&quot; as=&quot;P3&quot;/&gt;
	&lt;p3::schema&gt;&quot;http://www.ipwg.org/P3_1.0/&quot;&lt;/P3::schema&gt;
	&lt;P3::for_include&gt;&quot;http://www.w3.org&quot;&lt;/P3::for_include&gt;
	&lt;P3::agreement&gt;&quot;http://www.w3.org/DSig/x509v3/&quot;,&quot;W3CCert&quot;&lt;/P3::agreement&gt;
	&lt;P3::access&gt;&quot;http://www.w3.org/DataAboutYou&quot;&lt;/P3::access&gt;
	&lt;P3::consequence&gt;&quot;http://www.w3.org/WhatYouGet&quot;&lt;/P3::consequence&gt;
	&lt;P3::contact&gt;&quot;mailto:sally@w3.org&quot;&lt;/P3::contact&gt;
	&lt;ablock id=&quot;statement1&quot;&gt;
		&lt;ablock id=&quot;data1&quot;&gt;&lt;P3::practice&gt;3&lt;/P3::practice&gt;
			&lt;P3::data_schema&gt;&quot;OPS2&quot;&lt;/P3::data_schema&gt;
			&lt;P3::named_data&gt;&quot;contact information&quot;&lt;/P3::named_data&gt;
			&lt;P3::permissions&gt;&quot;W3CCert&quot;,&quot;Read&quot;
			&lt;P3::qualifier&gt;&quot;Required&quot;&lt;/P3::qualifier&gt;&lt;/ablock&gt;
		&lt;ablock id=&quot;data2&quot;&gt;&lt;P3::practice&gt;3&lt;/P3::practice&gt;
			&lt;P3::data_schema&gt;&quot;OPS2&quot;&lt;/P3::data_schema&gt;
			&lt;P3::named_data&gt;&quot;computer information&quot;&lt;/P3::named_data&gt;
			&lt;P3::permissions&gt;&quot;W3CCert&quot;,&quot;Read&quot;
			&lt;P3::qualifier&gt;&quot;Optional&quot;&lt;/P3::qualifier&gt;&lt;/ablock&gt;
		&lt;/ablock&gt;
	&lt;/ablock&gt;
&lt;ablock href=&quot;#proposal1&quot; id=&quot;signature&quot;&gt;
	&lt;namespace href=&quot;http:www.w3.org/PICS/DSig_Schema/pkcs7V2_0/&quot; as=&quot;pkcs7&quot;&gt;
	&lt;pkcs7::key&gt;.....&lt;/pkcs7::key&gt;
	&lt;pkcs7::sig&gt;.....&lt;/pkcs7::sig&gt;
	&lt;/ablock&gt;
</pre>

<p>This grammar specifies the ordering and structure of the clauses. However, some clauses
may be further specified. &nbsp;The table below provides a brief description of each
clause. The clauses are further explained in following the table. The rest of the document
specifies further details about each of the clauses. </p>

<h3>Grammar Clauses Described </h3>

<p>The following table briefly describes the clauses specified by the grammar. The
following text are descriptions of the column headings.

<ul>
  <li>The &quot;Applies to&quot; column indicates whether the clause applies to an entire
    proposal, a single statement, or another clause. &nbsp;Some clauses may apply at more than
    one level, in which case the most specific instance of a clause will override any more
    general instances of it in a particular proposal. </li>
  <li>The &quot;Required in Every Proposal&quot; column indicates whether the clause is
    mandatory. &nbsp;If a clause is mandatory it must be included as part of every statement
    or globally for the entire proposal. </li>
  <li>The &quot;Default Type of Label&quot; column indicates the format of the clause in the
    absence of further definitions from a specific vocabulary. &nbsp;For all clauses that may
    take more than one format, some syntax may be necessary to indicate the format being used
    in a particular instance. </li>
  <li>The &quot;May be Defined in Vocabulary&quot; column indicates whether the clause can be
    further defined within a specific vocabulary. </li>
</ul>
<div align="center"><center>

<table border="1" cellspacing="1" bordercolor="#000000" cellpadding="7" width="709">
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Clause</small></small></strong></em></td>
    <td width="24%" valign="TOP"><strong><small><small>Description</small></small></strong></td>
    <td width="13%" valign="TOP"><strong><small><small>Applies to</small></small></strong></td>
    <td width="15%" valign="TOP"><strong><small><small>Required in Every Proposal</small></small></strong></td>
    <td width="14%" valign="TOP"><strong><small><small>Default Type of Label</small></small></strong></td>
    <td width="16%" valign="TOP"><strong><small><small>May be Defined in Vocabulary</small></small></strong></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Access</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>The ability of users to obtain and correct
    information that an entity has collected about them</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>URI or text string</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Agreement With</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>The entity who the user is entering into an
    agreement with</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>certificate, URI, or text string</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Consequence</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>The impact on the user of reaching an agreement</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>URI or text string</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Contact</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>Information for contacting a service with
    inquiries about the service&#146;s privacy practices.</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>URI or text string</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Experience Space</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>The space where a particular statement is valid</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>set of URIs</small></small></td>
    <td width="16%" valign="TOP"><small><small>no</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Practice</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>What a service will do with data</small></small></td>
    <td width="13%" valign="TOP"><small><small>statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>none</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr valign="Top">
    <td width="17%" valign="Top"><em><strong><small><small>Qualified&nbsp;Data Set</small></small></strong></em></td>
    <td width="24%" valign="Top"><small><small>The data a service&nbsp;proposes to collect or
    requests </small></small></td>
    <td width="13%" valign="Top"><small><small>statement</small></small></td>
    <td width="15%" valign="Top"><small><small>yes</small></small></td>
    <td width="14%" valign="Top"><small><small>see&nbsp;definition below</small></small></td>
    <td width="16%" valign="Top"><small><small>no, but qualifier and category components may
    be</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Qualifier</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>Used by the creator of a vocabulary to provide
    extra functionality beyond that in the base P3 Proposal Grammar</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal, statement, or clause</small></small></td>
    <td width="15%" valign="TOP"><small><small>no</small></small></td>
    <td width="14%" valign="TOP"><small><small>none</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
  <tr valign="Top">
    <td width="17%" valign="Top"><em><strong><small><small>Required</small></small></strong></em></td>
    <td width="24%" valign="Top"><small><small>A&nbsp;binary value indicating whether a
    particular practice, qualified data set, or statement is required in&nbsp;an agreement</small></small></td>
    <td width="13%" valign="Top"><small><small>practice clause, qualified data set clause, or
    statement</small></small></td>
    <td width="15%" valign="Top"><small><small>no<br>
    (defaults&nbsp;to&nbsp;1 when not present)</small></small></td>
    <td width="14%" valign="Top"><small><small>0&nbsp;or 1</small></small></td>
    <td width="16%" valign="Top"><small><small>no</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Schema</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>A URI that identifies a particular P3 proposal
    vocabulary</small></small></td>
    <td width="13%" valign="TOP"><small><small>proposal</small></small></td>
    <td width="15%" valign="TOP"><small><small>yes</small></small></td>
    <td width="14%" valign="TOP"><small><small>URI</small></small></td>
    <td width="16%" valign="TOP"><small><small>no</small></small></td>
  </tr>
  <tr>
    <td width="17%" valign="TOP"><em><strong><small><small>Signature</small></small></strong></em></td>
    <td width="24%" valign="TOP"><small><small>Signature and attribution information as
    defined by the Digital Signature effort</small></small></td>
    <td width="13%" valign="TOP"><small><small>Proposal or statement</small></small></td>
    <td width="15%" valign="TOP"><small><small>no</small></small></td>
    <td width="14%" valign="TOP"><small><small>none</small></small></td>
    <td width="16%" valign="TOP"><small><small>yes</small></small></td>
  </tr>
</table>
</center></div>

<h3>Grammar Clauses Specified </h3>

<p>The P3P clauses are described in more detail below. &nbsp;Please note that much of the
specification is incomplete. &nbsp;Also note that some of the working group members
expressed concern about the complexity of the grammar and suggested that the non-essential
clauses be eliminated. &nbsp;In particular, questions were raised about the necessity of
the qualifier and required clauses, and the categories&nbsp;and permissions within the
qualified data sets. &nbsp;The majority of the group members felt that while these clauses
are probably not essential, they are sufficiently useful that they should be retained in
the grammar. </p>

<h4><b>Access</b> </h4>

<p>An access clause expresses&nbsp;the ability of users to&nbsp;obtain and correct
information that an entity has collected about them. A vocabulary may define various
degrees of access, for example 'view' and 'correct'. &nbsp;Access clauses should include a
label that contains or references specific information about how to obtain access. They
either take the form of a URL which can be dereferenced to provide the information or a
text string which provides the information directly. </p>

<p>Example: </p>

<pre>&lt;P3P::access&gt;view, &quot;http://www.w3.org/DataAboutYou&quot;&lt;/P3P::access&gt;
</pre>

<h4>Agreement With </h4>

<p>This is the entity with whom the user is entering into the agreement with. It can
either be expressed as a certificate identifying the entity, a URI which when dereferenced
identifies an entity, or text identifying an entity. There must be at least one agreement
clause in a proposal. The resulting agreement is between the superset of all parties named
in the agreement clause and the user. </p>

<p>When these clauses contain certificates they take the form
&quot;schema&quot;,&quot;data&quot;. The schema defines the data that will follow it.
&nbsp;For example, an agreement clause indicating the party identified by the certificate
&quot;W3CCert&quot; would look like: </p>

<pre>	&lt;P3P::agreement&gt;&quot;http://www.w3.org/DSig/x509v3/&quot;,&quot;W3CCert&quot;&lt;/P3P::agreement&gt;
</pre>

<p>where &quot;http://www.w3.org/DSig/x509v3/&quot; indicates the schema of the data which
follows, in this case an X509v3 certificate as defined at http://www.w3.org/DSig/x509v3/
and &quot;W3CCert&quot; is the identity certificate for W3C. </p>

<p>The party specified in the agreement with clause should not be confused with any of the
other parties who may be mentioned in a proposal, for example, parties associated with the
experience space or parties associated with a signature. </p>

<h4>Consequence </h4>

<p>Consequence clauses are labels that provide information about the impact on the user of
reaching an agreement. Consequence clauses may take the form of a URI which can be
dereferenced to provide the information, a text string which provides the information
directly, or labels enumerated by a vocabulary. An example consequence would be a value
added service such as customized information, or a coupon, or rebate. </p>

<h4>Contact </h4>

<p>Contact clauses are labels that provide information for contacting a service with
inquiries about the service's privacy practices. Contact clauses either takes the form of
a URL which can be dereferenced to provide the information or a text string which provides
the information directly. &nbsp;A vocabulary may place further restrictions on a contact
clause. </p>

<h4>Experience Space </h4>

<p>An experience space identifies the space where a particular statement is valid, not
necessarily with whom the user is having the interaction with. This experience space is
identified by a set of URIs as defined in <a href="http://ds.internic.net/rfc/rfc1738.txt">RFC
1738</a>. This set is made up of included and excluded URIs. For example, the service
w3.org may wish to make a statement about its entire experience space (http://www.w3.org)
minus its user registration area (http://www.w3.org/registration) and minus its mailing
list area (http://www.w3.org/maillist). In pseudo-RDF: </p>

<pre>&lt;ablock&gt;

	&lt;namespace href=&quot;http://www.w3.org/P3/FOR_Schema/&quot; as=&quot;FOR&quot;/&gt;
	&lt;FOR::include&gt;&quot;http://www.w3.org&quot;&lt;/FOR::include&gt;
	&lt;FOR::exclude&gt;&quot;http://www.w3.org/registration&quot;&lt;/FOR::exclude&gt;
	&lt;FOR::exclude&gt;&quot;http://www.w3.org/maillist&quot;&lt;/FOR::exclude&gt;
	&lt;/ablock&gt;
</pre>

<p>The experience space indicates to the user agent (and user) where the stated practice
is in effect. The method for determining and informing the user about which practice is in
effect as they browse the Web is very important but implementation dependent. For
instance, a smart agent would be able to remember for which set of URIs a given agreement
applies. A dumb agent with no memory may have to ask for a new agreement as it encounters
each new URI. However, under no circumstances should the user be misled that their privacy
preferences are being acted upon when this is not the case. Consequently, framed content
or included GIFs from outside an experience space may require their own practice
statements. </p>

<p>A service can state a general practice for its entire experience space that
excludes&nbsp;any pages within that space that have different practices. &nbsp;Upon
encountering such a page, a new agreement must be reached<font color="#ff0000">.</font>
&nbsp; </p>

<h4>Practice </h4>

<p>A practice clause&nbsp;describes what a service will do with data. The practice clause,
as defined in the vocabulary schema, is mandatory in every statement. It is applied
to&nbsp;one or more qualified data sets. </p>

<p>Example: &nbsp;A vocabulary might define practices such as 'used to complete the
transaction', 'used to customize content', or 'disclosed for marketing purposes'. </p>

<h4>Required </h4>

<p>The Required clause is a&nbsp;binary value that indicates whether a particular
practice, qualified data set, or statement is required in&nbsp;an agreement. &nbsp;When
practice clauses, qualified data sets clauses, and statements are not modified by a
required clause, they are assumed to be required by default (required = 1). &nbsp; </p>

<p>Note, the required clause is useful mostly as a short-hand or macro. &nbsp;Without this
clause, a service that was willing to enter into one of many different agreements with a
user would have to enumerate all the agreements. &nbsp;With this clause, such a service
can indicate all optional elements of each agreement with a required = 0. </p>

<h4>Qualified Data Set </h4>

<p>A qualified data set identifies the data that is being referenced in a statement.
&nbsp;It consists of :

<ul>
  <li>an identifier for a named data set (the name of a data class or data element), </li>
  <li>a category or list of categories that the data falls into, </li>
  <li>a schema for the data (identified by a rdf-xml definition or external URI), </li>
  <li>a set of permissions (explained below), and </li>
  <li>optional qualifiers. </li>
</ul>

<h4><i>Permissions</i> </h4>

<p>Permissions are constraints which, when evaluated, allow or prevent access or
modification of data classes or elements within the&nbsp; data repository of a user
agent.&nbsp; Permissions are set by a service and evaluated along with a user's
preferences. Thus permissions serve only to restrict actions permitted by a user's
preferences; they never allow actions that the user's preferences would otherwise
prohibit. </p>

<p>Permissions may only be set or changed as the result of an agreement between a user
agent and a service, and changes may only be made when they do not conflict with
previously set permissions. </p>

<p>A permission rule has the following syntax: </p>

<blockquote>
  <p>&lt;action&gt;* </p>
</blockquote>

<p>The <b>action </b>specifies whether the rule is for read-only access or read/write
access. &nbsp;(Read/write access is permission for a service to store data in a user's P3P
data repository.) </p>

<p>Alternatively, a permission rule might have the following syntax: </p>

<p>&nbsp; &nbsp; &nbsp; &nbsp;&lt;action&gt;*&lt;restriction&gt; </p>

<p>The <b>restriction</b> is a statement in the P3P preference interchange language (to be
specified by a future working group) that restricts access to the data element. &nbsp;For
example, the restriction might prohibit services other than the one that wrote a data
element from reading it. &nbsp; </p>

<p>The working group did not reach an agreement on whether the restriction syntax is
necessary, and is thus not recommending one syntax over the other at this time.
&nbsp;Arguments in favor of the restriction syntax focussed on greater flexibility, and
speculation that this syntax would facilitate and encourage services' storing unencrypted
data in the user's data repository (something that was viewed as desirable from a privacy
perspective). &nbsp;Arguments against the restriction syntax focussed on added complexity,
and speculation that services would be unlikely to trust user agents to enforce a
service's policy and would thus encrypt any proprietary data stored in a user's data
repository any way. &nbsp;It is unclear at this point how much complexity this syntax
would add to a P3P implementation or whether it has other useful applications. </p>

<p>Qualifier </p>

<p>A qualifier clause is used by the creator of a vocabulary to provide extra
functionality beyond that in the base P3P Proposal Grammar. </p>

<p>Example: Vocabulary creators might wish to include a qualifier clause that would allow
assertions about the length of time a particular piece of data will be retained. </p>

<h4>Schema </h4>

<p>The schema clause consists of a URI that identifies a particular P3P proposal
vocabulary. &nbsp;A single schema applies to an entire proposal. A schema must be
identified for a proposal. </p>

<p>example: &quot;http://www.ipwg.org/P3_1.0/&quot; </p>

<h4>Signature </h4>

<p>This is the signature and attribution information as defined by the W3C Digital
Signature effort. A signature on a proposal indicates that the signer believes the
statements in the proposal are true. </p>

<h2>Requests </h2>

<p>After an agreement is reached between a service and user agent, the service may request
that the user agent transmit a data element. &nbsp;All requests must reference a
particular agreement. &nbsp;Requests should only be granted by a user agent if they are
consistent with the referenced agreement (for example, if there is an agreement that the
user agent will provide only the user's zip code and the user agent requests the user's
phone number, the request should be denied). &nbsp;A future working group is expected to
determine the syntax for requests. &nbsp;We expect requests to include a reference to an
agreement, a list of data elements requested, reference to a transport protocol, and
reference to a mechanism for prompting the user for that information. </p>

<hr>

<h2>Sample Vocabulary and Recommended Data Set </h2>

<p>There are two vocabularies which can be defined within the P3P framework. The first is
the data category vocabulary, and the second is the proposal vocabulary. A proposal
vocabulary may define one or more of the clauses used in proposals (such as privacy
practices, access, schema, qualifier, etc.). &nbsp;The data category vocabulary defines
the list of data categories that describes data elements. </p>

<p>A future working group will recommend a detailed specification for the RDF syntax of
these vocabularies. &nbsp; </p>

<h3>Recommended Data Set </h3>

<p>It is proposed that there should be a certain number of base data elements provided
with every privacy user agent. These base data elements may closely follow those commonly
in use today by such mechanisms as VCard. However, there may be data elements contained
within the VCard schema that are considered &quot;rarely used&quot;, such as home pager,
and should probably not be required as part of the base set. </p>

<p>Further, the base set should probably contain data elements not found within the VCard
schema, such as some anonymous demographics. These data elements represent frequently
asked marketing questions that do not require personally identifiable information. </p>

<p>Note: When designing the base schema it should be kept in mind that either the user
agent or the service may expand the data elements hosted on the user&#146;s machine. This
implies that the number of base elements should be kept to a reasonable minimum rather
than attempting to &quot;guess&quot; what elements both user and service would want. </p>

<hr>

<h2>Other Recommendations </h2>

<h4>Preference specification </h4>

<p>It is up to user agent implementors to determine the level of detail at which end users
will be able to specify their preferences.&nbsp;However, we recommend that user agents
allow users to express preferences over all types of clauses contained in the P3P grammar.
&nbsp; </p>

<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>