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.
837 lines
44 KiB
837 lines
44 KiB
<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> </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> <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&T Labs-Research</li>
|
|
</ul>
|
|
|
|
<p><strong>Authors: </strong>
|
|
|
|
<ul>
|
|
<li>Mark Ackerman, W3C </li>
|
|
<li>Lorrie Cranor, AT&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 "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 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 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 "parts of speech" 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 data
|
|
repository of a user agent. 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,
|
|
"preferences" 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 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 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 as a last name or phone
|
|
number. A <i>data class</i> is a named set of data elements and/or other data
|
|
classes. Data classes inherit the data elements from all classes they contain.
|
|
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). 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 a set of data elements sent by a user agent to the service
|
|
as 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. 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.
|
|
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. When a service proposes to request a data element, the agent can
|
|
check whether the user has expressed a preference about that particular element. 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. 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>.
|
|
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 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. Each set of terms is
|
|
expressed as a statement. </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. 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. The proposed 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>
|
|
(with <i>qualifier</i>)* <br>
|
|
(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: </p>
|
|
|
|
<pre><ablock id="proposal">
|
|
<namespace href="http://www.w3.org/P3_1.0/" as="P3"/>
|
|
<p3::schema>"http://www.ipwg.org/P3_1.0/"</P3::schema>
|
|
<P3::for_include>"http://www.w3.org"</P3::for_include>
|
|
<P3::agreement>"http://www.w3.org/DSig/x509v3/","W3CCert"</P3::agreement>
|
|
<P3::access>"http://www.w3.org/DataAboutYou"</P3::access>
|
|
<P3::consequence>"http://www.w3.org/WhatYouGet"</P3::consequence>
|
|
<P3::contact>"mailto:sally@w3.org"</P3::contact>
|
|
<ablock id="statement1">
|
|
<ablock id="data1"><P3::practice>3</P3::practice>
|
|
<P3::data_schema>"OPS2"</P3::data_schema>
|
|
<P3::named_data>"contact information"</P3::named_data>
|
|
<P3::permissions>"W3CCert","Read"
|
|
<P3::qualifier>"Required"</P3::qualifier></ablock>
|
|
<ablock id="data2"><P3::practice>3</P3::practice>
|
|
<P3::data_schema>"OPS2"</P3::data_schema>
|
|
<P3::named_data>"computer information"</P3::named_data>
|
|
<P3::permissions>"W3CCert","Read"
|
|
<P3::qualifier>"Optional"</P3::qualifier></ablock>
|
|
</ablock>
|
|
</ablock>
|
|
<ablock href="#proposal1" id="signature">
|
|
<namespace href="http:www.w3.org/PICS/DSig_Schema/pkcs7V2_0/" as="pkcs7">
|
|
<pkcs7::key>.....</pkcs7::key>
|
|
<pkcs7::sig>.....</pkcs7::sig>
|
|
</ablock>
|
|
</pre>
|
|
|
|
<p>This grammar specifies the ordering and structure of the clauses. However, some clauses
|
|
may be further specified. 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 "Applies to" column indicates whether the clause applies to an entire
|
|
proposal, a single statement, or another clause. 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 "Required in Every Proposal" column indicates whether the clause is
|
|
mandatory. If a clause is mandatory it must be included as part of every statement
|
|
or globally for the entire proposal. </li>
|
|
<li>The "Default Type of Label" column indicates the format of the clause in the
|
|
absence of further definitions from a specific vocabulary. 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 "May be Defined in Vocabulary" 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’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 Data Set</small></small></strong></em></td>
|
|
<td width="24%" valign="Top"><small><small>The data a service 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 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 binary value indicating whether a
|
|
particular practice, qualified data set, or statement is required in 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 to 1 when not present)</small></small></td>
|
|
<td width="14%" valign="Top"><small><small>0 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. Please note that much of the
|
|
specification is incomplete. 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. In particular, questions were raised about the necessity of
|
|
the qualifier and required clauses, and the categories and permissions within the
|
|
qualified data sets. 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 the ability of users to obtain and correct
|
|
information that an entity has collected about them. A vocabulary may define various
|
|
degrees of access, for example 'view' and 'correct'. 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><P3P::access>view, "http://www.w3.org/DataAboutYou"</P3P::access>
|
|
</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
|
|
"schema","data". The schema defines the data that will follow it.
|
|
For example, an agreement clause indicating the party identified by the certificate
|
|
"W3CCert" would look like: </p>
|
|
|
|
<pre> <P3P::agreement>"http://www.w3.org/DSig/x509v3/","W3CCert"</P3P::agreement>
|
|
</pre>
|
|
|
|
<p>where "http://www.w3.org/DSig/x509v3/" indicates the schema of the data which
|
|
follows, in this case an X509v3 certificate as defined at http://www.w3.org/DSig/x509v3/
|
|
and "W3CCert" 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. 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><ablock>
|
|
|
|
<namespace href="http://www.w3.org/P3/FOR_Schema/" as="FOR"/>
|
|
<FOR::include>"http://www.w3.org"</FOR::include>
|
|
<FOR::exclude>"http://www.w3.org/registration"</FOR::exclude>
|
|
<FOR::exclude>"http://www.w3.org/maillist"</FOR::exclude>
|
|
</ablock>
|
|
</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 any pages within that space that have different practices. Upon
|
|
encountering such a page, a new agreement must be reached<font color="#ff0000">.</font>
|
|
</p>
|
|
|
|
<h4>Practice </h4>
|
|
|
|
<p>A practice clause 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 one or more qualified data sets. </p>
|
|
|
|
<p>Example: 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 binary value that indicates whether a particular
|
|
practice, qualified data set, or statement is required in an agreement. 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). </p>
|
|
|
|
<p>Note, the required clause is useful mostly as a short-hand or macro. 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. 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.
|
|
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 data repository of a user
|
|
agent. 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><action>* </p>
|
|
</blockquote>
|
|
|
|
<p>The <b>action </b>specifies whether the rule is for read-only access or read/write
|
|
access. (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> <action>*<restriction> </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. For
|
|
example, the restriction might prohibit services other than the one that wrote a data
|
|
element from reading it. </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.
|
|
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). 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. 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. A single schema applies to an entire proposal. A schema must be
|
|
identified for a proposal. </p>
|
|
|
|
<p>example: "http://www.ipwg.org/P3_1.0/" </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. All requests must reference a
|
|
particular agreement. 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). A future working group is expected to
|
|
determine the syntax for requests. 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.). 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. </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 "rarely used", 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’s machine. This
|
|
implies that the number of base elements should be kept to a reasonable minimum rather
|
|
than attempting to "guess" 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. However, we recommend that user agents
|
|
allow users to express preferences over all types of clauses contained in the P3P grammar.
|
|
</p>
|
|
|
|
<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>
|