[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

DOCTYPE HTML PUBLIC DTD META

Found at: ftp.icm.edu.pl:70/packages/normos/w3c/NOTE-Web-privacy

<!DOCTYPE  HTML PUBLIC "-//IETF//DTD HTML//EN"><HTML>
<HEAD>
<META CONTENT="text/html; charset=iso-8859-1" HTTP-EQUIV="Content-Type">
<META NAME="Template" CONTENT="C:\MSOffice\Templates\Letters &amp; Faxes\VFPSPEC97.dot">
<META NAME="GENERATOR" CONTENT="Microsoft FrontPage 2.0">
<TITLE>NOTE-Web-privacy</TITLE>
</HEAD>

		
<BODY BGCOLOR="#FFFFFF" VLINK="#551A8B" TEXT="#000000" LINK="#0000EE" ALINK="#FF0000">
<H1>
  <IMG SRC="http://www.w3.org/Icons/WWW/w3c_home" WIDTH="72" HEIGHT="48" ALT="W3C" BORDER="0">
</H1>
<P ALIGN="right">
<B><BIG>NOTE-Web-privacy.html</BIG></B>
<H1 ALIGN="center">
Privacy and Profiling on the Web</H1>
<P>
<B><BIG>&#183; <A HREF="http://www.w3.org/Submission/1997/6/Overview.html">Submitted to
W3C</A> on 02 June 1997 &#183;</BIG></B>
<P>
<DL>
  <DT>
    This version:
  <DD>
    <A HREF="NOTE-Web-privacy.html" W3MIRHREF="http://www.w3.org/TR/NOTE-Web-privacy.html">http://www.w3.org/TR/NOTE-Web-privacy.html</A>
</DL>
<DL>
  <DT>
    Latest version:
  <DD>
    <A HREF="NOTE-Web-privacy.html" W3MIRHREF="http://www.w3.org/TR/NOTE-Web-privacy.html">http://www.w3.org/TR/NOTE-Web-privacy.html</A>
</DL>
<DL>
  <DT>
    Authors:
  <DD>
    <A HREF="mailto:/mwdunn@microsoft.com">Melissa Dunn</A>, Microsoft Corporation<BR>
    <A HREF="mailto:/jamesgw@microsoft.com">James Gwertzman</A>, Microsoft Corporation<BR>
    <A HREF="mailto:/andrewl@microsoft.com">Andrew Layman</A>, Microsoft Corporation<BR>
    <A HREF="mailto:/hadip@microsoft.com">Hadi Partovi</A>, Microsoft Corporation
</DL>
<P>
<BR>
  <HR>
<H2>
  Status of this Document
</H2>
<P>
This document is a NOTE made available by the World Wide Web Consortium for
discussion only. This indicates no endorsement of its content, nor that the
Consortium has, is, or will be allocating any resources to the issues addressed
by the NOTE. A list of current NOTEs can be found at:
<A HREF="./" W3MIRHREF="http://www.w3.org/TR/">http://www.w3.org/TR/</A>.
<P>
This document is part of a complete <A HREF="http://www.w3.org/Submission/">submission</A>
to the W3C. The full submission has been acknowledged by W3C and is available
at
<A HREF="http://www.w3.org/Submission/1997/7/Overview.html">http://www.w3.org/Submission/1997/7/Overview.html</A>
<P>
Note: since working drafts are subject to frequent change, you are advised
to reference the above URL, rather than the URLs for working drafts themselves.
<P>
  <HR>

		

		
<P><FONT SIZE="3">
June 1, 1997
</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>1. Introduction</B></FONT></P>

		
<P><FONT SIZE="2">There has been much discussion recently on how
to provide personalization of Internet services while still
protecting users' privacy. Web sites everywhere want to take
advantage of the 1-to-1 nature of communications on the Internet
to provide customers with personalized information and services,
or to target advertising. To make this personalization and
targeting possible, Web sites often ask visitors for personal
information. Web users suffer the inconvenience of providing the
same information many times to different Web sites without
knowing how the information will be used, or by whom.</FONT></P>

		
<P><FONT SIZE="2">This document shows that it is possible to
leverage <I>existing </I>Internet standards and proposals to
provide sites access to demographic and other personal profile
information while placing users in control of how this
information is disclosed. The technology described in this
document allows a user to provide personal information once for
use across many Web sites, while maintaing privacy by keeping
control over its release. This technology enhances personal
privacy while also providing richer, easier Web site
personalization. As a result, businesses can collect information
about their users and offer services matching each
customer&#146;s needs. </FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>1.1 Maintaining privacy on the
Internet</B></FONT></P>

		
<P><FONT SIZE="2" FACE="Times">As the Internet and the World Wide
Web become an established part of everyday life, users will
become more circumspect of how they release their personal data.
Users are already expressing a desire to retain ownership of both
biographical data and records of their actions (the click
stream). If the industry does not provide a simple, secure
mechanism through which users can protect their rights to
personal data, users may elect to provide little or no
information to sites. </FONT></P>

		
<P><FONT SIZE="2">In order to maintain privacy, users need to
control which personal information gets disclosed or withheld
from a particular Web site. </FONT><FONT SIZE="2" FACE="Times">Users
</FONT><FONT SIZE="2">need to be notified what profile
information is requested from a particular site</FONT><FONT SIZE="2" FACE="Times">, allowing them to choose who may use this
information, for what purposes, and under what conditions;
including retaining the right to publish updated records and to
retract usage permissions. </FONT><FONT SIZE="2">In addition,
information stored locally on a user&#146;s machine may be
encrypted to keep it safe from unauthorized usage.</FONT></P>

		
<P><FONT SIZE="2">This document proposes a mechanism for
resolving these disparate goals using existing Internet
standards. This proposal provides users with direct control over
a locally stored personal profile and provides Web sites a means
of directly requesting this information.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>1.2 The private exchange of
personal information</B></FONT></P>

		
<P><FONT SIZE="2">An individual Web user has a personal profile
that contains his or her personal information. This profile
should be stored locally on the user&#146;s machine, but it may
also be backed up remotely in a global corporate directory.
Management of this profile is the user&#146;s responsibility, but
may also be controlled by a system administrator. If a Web site
requests information from this profile, the client software
should present the user with the choice of whether or not to
release the requested personal data. The Web site benefits from
easy access to this personal information. The user benefits from:
(a) the convenience of maintaining only one set of personal
information for many Web sites, (b) the control over releasing
this private information to new sites, and (c) the security that
can be offered by possibly encrypting the locally stored
information or the transmission of this information to Web sites.</FONT></P>

		
<P><FONT SIZE="2">Figures 1 and 2 below illustrate this process.
The user has control over the profile and can share it across
multiple client machines. Servers can ask for the information,
but the client has control over its release.</FONT></P>

		
<P ALIGN="center"><A NAME="_926721467"></A><FONT SIZE="2"><B><I><IMG SRC="Image1.gif" WIDTH="575" HEIGHT="285" W3MIRSRC="http://www.w3.org/TR/Image1.gif"></I></B></FONT></P>

		
<P ALIGN="center"><FONT SIZE="2"><B>Figure 1. Editing the user
Persona</B></FONT></P>

		
<P ALIGN="center"><A NAME="_926721469"></A><FONT SIZE="2"><B><I><IMG SRC="Image2.gif" WIDTH="575" HEIGHT="263" W3MIRSRC="http://www.w3.org/TR/Image2.gif"></I></B></FONT></P>

		
<P ALIGN="center"><FONT SIZE="2"><B>Figure 2. Exchanging the user
Persona</B></FONT></P>

		
<P><FONT SIZE="2" FACE="Times">The following functionality and
features are required to complete the platform illustrated above:</FONT></P>

		
<TABLE WIDTH="590" CELLSPACING="1" BORDER="1" CELLPADDING="7">
    <TR>
        <TD><FONT SIZE="2">Client side functionality</FONT><UL>
            <LI><FONT SIZE="2">Local (encrypted) storage of
                personal information (Profile)</FONT></LI>
            <LI><FONT SIZE="2">A schema that may be extensible by
                server or client</FONT></LI>
            <LI><FONT SIZE="2">User interface for maintaining
                values in the profile</FONT></LI>
            <LI><FONT SIZE="2">Support for multiple Personae
                (different data values and per-site permissions)</FONT></LI>
            <LI><FONT SIZE="2">Support for roaming users and
                shared workstations</FONT></LI>
            <LI><FONT SIZE="2">Silent updates for accepted sites
                (including retractions)</FONT></LI>
            <LI><FONT SIZE="2">Privacy vocabulary - usage
                policies, data requested, content semantics,
                trust mechanism</FONT></LI>
            <LI><FONT SIZE="2">Client defined consent levels
                based upon informed consent, trusted agents, and
                site certification</FONT></LI>
        </UL>
        </TD>
    </TR>
    <TR>
        <TD><FONT SIZE="2">Server side functionality</FONT><UL>
            <LI><FONT SIZE="2">Mechanism to access secured store</FONT></LI>
            <LI><FONT SIZE="2">Privacy vocabulary</FONT></LI>
            <LI><FONT SIZE="2">Content semantics </FONT></LI>
            <LI><FONT SIZE="2">Retraction mechanism</FONT></LI>
        </UL>
        </TD>
    </TR>
    <TR>
        <TD><FONT SIZE="2">Interchange between client and server</FONT><UL>
            <LI><FONT SIZE="2">Interchange data format</FONT></LI>
            <LI><FONT SIZE="2">Secure (encrypted) transmission</FONT></LI>
        </UL>
        </TD>
    </TR>
</TABLE>

		
<P><FONT SIZE="4" FACE="Arial"><B>1.3 Leveraging existing
standards and proposals</B></FONT></P>

		
<P><FONT SIZE="2">Much of the functionality above can be
accomplished using existing Internet standards and proposals. It
is important to use <I>existing</I> file formats and protocols to
ensure cross-industry support and to ensure interoperability with
existing or new software products. The standards or proposals
used in this document are HTTP, SSL, PFX, vCard, x.509 digital
certificates, and XML (Extensible Markup Language).</FONT></P>

		
<P><FONT FACE="Arial"><B>1.3.1 X.509</B></FONT></P>

		
<P><FONT SIZE="2">Digital certificates based on the CCITT X.509
standard allow verification of personal and organizational
identification using public key cryptography. The IETF Public-Key
Infrastructure (PKIX) working group has adopted the X.509
standard as the basis for defining Internet-wide public key
infrastructure, and support for X.509 certficates has been built
into most major Internet clients and servers as part of the SSL
specification (see the next section). More information about the
X.509 standard may be found in Part I of the PKIX working
group&#146;s </FONT><A HREF="ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-04.txt">Internet
Public Key Infrastructure Internet Draft</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT FACE="Arial"><B>1.3.2 HTTP, SSL, and PFX</B></FONT></P>

		
<P><FONT SIZE="2">The SSL protocol defines a mechanism by which
the channel may be secured between network clients and servers
using X.509 digital certificates. Its specification
has been widely implemented for
use with the HTTP protocol. By encrypting the channel using SSL,
user profiles may be safely exchanged between clients and servers
without fear of interception. More information on SSL can be
found at </FONT><A HREF="http://home.netscape.com/assist/security/ssl/index.html">http://home.netscape.com/assist/security/ssl/index.html</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT SIZE="2">The PFX protocol also provides a mechanism by
which user information may be exchanged among multiple platforms
without fear of interception. PFX encrypts the data itself,
however, instead of the channel, and can therefore be used with
disconnected media such as smart cards or floppy disks as well as
with connected sites that can not support SSL. The PFX
specification has been submitted to
RSA Laboratories as
a candidate in their PKCS standards suite. The protocol has
received support from many companies, and is implemented in
software by Microsoft and Netscape. More information on PFX may
be found on </FONT><A HREF="http://www.microsoft.com/standards/pfx020syntax.htm">http://www.microsoft.com/standards/pfx020syntax.htm</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT FACE="Arial"><B>1.3.3 vCard</B></FONT></P>

		
<P><FONT SIZE="2">The vCard specification provides a file format
for &quot;digital business cards&quot; that can be exchanged
between software applications. The vCard specification is managed
by the Internet Mail Consortium (</FONT><A HREF="http://www.imc.org/">IMC</A><FONT SIZE="2">) and has been
submitted to the Internet Engineering Task Force (IETF) Access,
Searching, and Indexing of Directories (ASID) working group for
inclusion in the MIME specification. More information on vCard
may be found on </FONT><A HREF="http://www.imc.org/pdi/vcardwhite.html">http://www.imc.org/pdi/vcardwhite.html</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT FACE="Arial"><B>1.3.4 XML</B></FONT></P>

		
<P><FONT SIZE="2">The W3C SGML working group defined the
Extensible Markup Language (XML) to provide an open, extensible
grammar for structured data. The XML syntax has broad
cross-industry support and forms the basis for a number of
currently proposed standards. Furthermore, a number of groups are
considering modifying existing standards to use XML in future
versions due to its elegant syntax and easy extensibility. More
information on XML can be found on </FONT><A HREF="http://www.w3.org/MarkUp/SGML/Activity">http://www.w3.org/MarkUp/SGML/Activity</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>1.4 Definition of Terms</B></FONT></P>

		
<P><FONT SIZE="2">The following terms are used throughout this
document:</FONT></P>

		
<TABLE WIDTH="590" CELLSPACING="1" BORDER="1" CELLPADDING="7">
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2"><B>Term</B></FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2"><B>Definition</B></FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2">Profile</FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2">The set of personal
        information associated with an individual end-user. The
        profile may consist of one or many personae.</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2">Persona</FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2">The collection of personal
        data that the client will distribute to a given site.
        Typically organized by the ascribed role the client
        wishes to assume (e.g., work persona, at-home persona,
        gamer persona, etc.)</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2">Schema</FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2">The logical structure and
        semantics of the information stored in a persona.</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2">Click stream</FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2">Actual
        navigational/behavioral data. This information resides
        both within the Web server logs and within the client
        agent cache.</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="50%"><FONT SIZE="2">Secured data storage</FONT></TD>
        <TD WIDTH="50%"><FONT SIZE="2">User and Internet site
        information that is encrypted and stored on the client
        side computer or appropriate remote storage device.</FONT></TD>
    </TR>
</TABLE>

		
<P><FONT SIZE="5" FACE="Arial"><B>2. The </B><B><I>profile</I></B><B>
&#150; a user&#146;s personal information</B></FONT></P>

		
<P><FONT SIZE="2">The <I>profile</I> for a single user contains
all the personal information for that user. This profile includes
a unique user identification, contact information, and
demographic information. The profile may contain one or more <I>personae</I>,
alllowing users to present themselves differently when at work or
at home. Finally, each persona within the profile has an
extensible schema, allowing Web sites or Internet applications to
extend the personal information stored locally on the user&#146;s
machine.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>2.1 The schema for a persona</B></FONT></P>

		
<P><FONT SIZE="2">The schema introduced by the proposed vCard
standard is in wide use among sites on the Internet. The vCard
proposal provides an extensible schema that includes a particular
set of information but also allows new fields to be added. The
schema offered by the vCard proposal provides rich contact
information, but it is aimed primarily at white page/contact
sites rather than those interested in personal data (for
advertising and content purposes). </FONT></P>

		
<P><FONT SIZE="2">Given these limitations, an extended vCard
schema is proposed below that addresses Web site concerns by
providing anonymous demographic information:</FONT></P>

		
<TABLE WIDTH="289" CELLSPACING="0" BORDER="1" CELLPADDING="0">
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2"><B>Category</B></FONT></TD>
        <TD WIDTH="48%"><FONT SIZE="2"><B>Column</B></FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2">Personal Contact</FONT></TD>
        <TD WIDTH="48%">&nbsp;</TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">UserID</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Email</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Certificate</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Common Name*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Given Name</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Last Name</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Middle Name</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Address1</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Address2</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">City</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">State/Province</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Postal Code</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Locality</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Country</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Language Spoken*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Telephone</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Mobile Phone</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2">Demographic</FONT></TD>
        <TD WIDTH="48%">&nbsp;</TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Birthday</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Gender*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Level of education*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Marital Status*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Number of children*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Income Level*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2">Business</FONT></TD>
        <TD WIDTH="48%">&nbsp;</TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Company Postal Code</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Industry</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Professional Title</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Company Size*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Telephone</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Fax</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Pager</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Mobile Phone</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Email</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Organization*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2">Miscellaneous</FONT></TD>
        <TD WIDTH="48%">&nbsp;</TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Persona ID</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Persona Name*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Creation Date*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Creation Name*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Modification Date</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Modification Name*</FONT></TD>
    </TR>
    <TR>
        <TD WIDTH="52%"><FONT SIZE="2">Security</FONT></TD>
        <TD WIDTH="48%">&nbsp;</TD>
    </TR>
    <TR>
        <TD WIDTH="52%">&nbsp;</TD>
        <TD WIDTH="48%"><FONT SIZE="2">Password*</FONT></TD>
    </TR>
</TABLE>

		
<P><FONT SIZE="1">* These columns are extensions of the current
VCard standard</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>2.2 Extensibility of the schema</B></FONT></P>

		
<P><FONT SIZE="2">The schema for a persona in an
individual&#146;s profile needs to be extensible by any Web site.
In this way, sites can add information that they would like to
have maintained on the client, such as number of children or
address. This allows a site to take advantage of the local
storage on the client machine, and it also provides each user
greater control over the personal information that is collected
by various sites.</FONT></P>

		
<P><FONT SIZE="2">Beyond schema extensions requested by
particular Web sites, the click-stream information collected from
the client-side cache during offline browsing can also be
considered an extension of the profile schema and is discussed in
more detail later in this document.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>2.3 A user&#146;s profile may
have multiple personae</B></FONT></P>

		
<P><FONT SIZE="2">An individual may want to present a different
persona at different Web sites or at different times of the day.
The most obvious example is the distinction between the work and
home personae. In the work persona, the individual may use a
formal name and business information, whereas in the home
persona, the user may fill in personal contact information and
anonymous demographic information, leaving the business
information blank.</FONT></P>

		
<P><FONT SIZE="2">The information in a persona is not limited to
the personal or demographic information in a particular schema,
but also includes the permission and content rules that are used
when communicating with a Web site. This flexibility means that
users can create different personae for visiting government
sites, sport sites, etc., in order to release different sets of
information and view different personalized views of content.</FONT></P>

		
<P><FONT FACE="Arial"><B>2.3.1 Privacy and multiple personae per
User ID</B></FONT></P>

		
<P><FONT SIZE="2">The User ID is designed to uniquely identify
the client independently of Web site affiliation. The implication
is that sites no longer need to issue cookies solely for the
purpose of retaining a sense of &quot;membership&quot;. Cookies
will still be needed for state maintenance during a session,
however.</FONT></P>

		
<P><FONT SIZE="2">The assignment of the User ID must remain
neutral, not affiliated with any branded institution. This means
that the client machine must be capable of generating an ID while
off-line. Generation of the user ID can either be through the use
of the UUIDgen algorithm which is widely available, or through
the issuance of an X.509 user certificate to provide verifiable
proof of user identity.</FONT></P>

		
<P><FONT SIZE="2">When using multiple personae, the use of a
single unique User ID results in some privacy concerns. For
example, a user may use more than one persona on a single large
Web site. In this case, it becomes fairly easy for the site to
link the multiple personae based upon the unique user ID or X.509
certificate. </FONT></P>

		
<P><FONT SIZE="2">To protect the user from this privacy breach,
the actual user ID can be hidden from Web sites, and instead a
per-persona ID is used instead. This persona ID may be a simple
hash of the User ID value. The site receiving the persona ID
cannot identify that two different personae represent the same
user. Of course, when using X.509 certificates a user cannot be
protected from this privacy concern, because the X.509
certificate provides Web sites the full unique identity of the
user</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>3. Local storage of profile
information</B></FONT></P>

		
<P><FONT SIZE="2">The data for an individual&#146;s profile needs
to be stored on the local client machine in order to allow the
client software to provide personal information to Web sites and
to allow the user to review and change this personal information
even while working offline. Note that storing the profile
information locally does not preclude backing up this information
remotely, for example in a corporate directory. On a thin client
with no permanent local storage, the locally stored profile may
simply be a temporary cache of the individual&#146;s profile.</FONT></P>

		
<P><FONT SIZE="2">The user&#146;s personal profile must require
little storage space in order to support the notion of
portability, or roaming identity. The data storage requirements
must be small enough to load easily onto a 3.5 floppy or some
card technology such as SmartCard. Of course, compression may be
used to save local storage space, to enable more convenient
portability, or to save bandwidth when sending profile
information to Web sites.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>3.1 Security of the
locally-stored profile</B></FONT></P>

		
<P><FONT SIZE="2">In a multiple user scenario the personal data
from one user should be protected against viewing or modification
by the other users. This is easily accomplished through the use
of passwords and encrypted local storage. </FONT></P>

		
<P><FONT SIZE="2">In addition, it may be desirable to prevent a
user from modifying his or her personal profile. For example, on
a home computer shared by members of a family, a parent may set
up a child&#146;s personal information, making sure that the
birthday is accurate. When the child accesses a site with a
minimum age requirement, the child is unable to falsify the age.
To prevent a user from changing the personal profile, the local
storage requires hierarchical access control lists. This security
mechanism needs to support control over the creation and
modification of columns across personas for a given user as well
as the creation of new personae. In a corporate scenario, a
corporate administrator may need to exert the same control of the
profile information for employees of the corporation.</FONT></P>

		
<P><FONT SIZE="2">Note that local encryption of the personal data
is independent of encryption of data that is sent from the client
machine to a Web site. The site never directly accesses the local
storage for personal data, and instead requests specific fields
of information from the profile. The client software may then
send this data to the Web site via a secure, encrypted protocol
for information exchange.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>3.2 Managing a user&#146;s
profile</B></FONT></P>

		
<P><FONT SIZE="2">The client software must provide a user
interface for creating and maintaining the personal profile.
Authorized users should be able to update personal data, create
and delete personae, and review per-site schema extensions. Once
the user changes personal data, Web sites using this data must be
updated. Rather than send updates to every site, updates are sent
the next time the client visits each site. At this point the user
may be asked for consent, unless he or she has already approved
the site for releasing personal information.</FONT></P>

		
<P><FONT SIZE="2">Note that revisiting a Web site after changing
personal profile information is analogous to visiting a Web site
for the first time. There is little difference between
&quot;refreshing&quot; the information released to a site vs.
simply providing that information for the first time. The only
difference is that a site that has already been visited may be
trusted or pre-approved to silently receive this particular
information, in which case the user no longer needs to provide
consent to the transfer of information </FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>3.3 Roaming users and shared
workstations</B></FONT></P>

		
<P><FONT SIZE="2">To provide a complete solution for corporate
and home users, the profile containing a user&#146;s personal
data must support roaming users and shared client machines.</FONT></P>

		
<P><FONT FACE="Arial"><B>3.3.1 Portability &#150; one user
roaming between many machines</B></FONT></P>

		
<P><FONT SIZE="2">Identify is often tied to a user&#146;s client
machine through site-specific cookies. This creates an unecessary
and inconvenient dependency since users frequently move from
machine to machine. One solution is for users to subscribe to an
identify broker that provide a single Web &quot;passport&quot;
identity. Since not all sites participate in these broker
services, the client must enter redundant information throughout
the Web.</FONT></P>

		
<P><FONT SIZE="2">The concept of local, secure storage reduces
the need for an identity broker &#150; the user becomes his own
broker. The next step is to remove the machine dependency by
allowing the user identity to &quot;roam&quot;. Within a
corporate network, this means that a user can access his profile
from any workstation he logs into. The user should be able to
copy some set of personae from the master machine to a
&quot;mobile&quot; medium such as a SmartCard or floppy disk. The
proposed PFX standard defines a widely accepted mechanism for
securing such information in portable, compact stores.</FONT></P>

		
<P><FONT FACE="Arial"><B>3.3.2 Multi-user &#150; many users
sharing one machine</B></FONT></P>

		
<P><FONT SIZE="2">As mentioned earlier, multiple users can be
hosted within a single data store. This allows for the scenarios
of the shared family or work machine. The specific user is
identified at either machine logon or browser logon. After a user
has logged on to a particular machine, he may access his personal
profile as if he were the only person using the machine.</FONT></P>

		
<P><FONT SIZE="2">In a family scenario, parents will want
administrative control over profiles stored on the home machine.
Likewise, in a corporate scenario, the system administrator
should be able to lockdown or restrict access to personal
profiles, preventing users from misrepresenting corporate contact
or demographic data which is set from the corporate directory.</FONT></P>

		
<P><FONT SIZE="2">Exposing corporate directory information to the
outside world may present security concerns for most
corporations, so the administrator <I>must</I> be able to
restrict corporate users to releasing profile information to a
trusted subset of Web sites, enabling important &quot;<I>externet</I>&quot;
applications without forsaking corporate security.</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>4. Client-server exchange of
personal information</B></FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>4.1 Requesting personal
information</B></FONT></P>

		
<P><FONT SIZE="2">When a user visits a Web site, the site must
request information from the user&#146;s personal profile. A
number of Internet technologies or existing standards may be
leveraged to construct this mechanism. </FONT></P>

		
<P><FONT SIZE="2">First, a Web site must present a declarative
request for personal information, along with a statement of how
this information is to be used. The server can send this semantic
information as part of an HTTP challenge to the client&#146;s
initial HTTP request. The client software must then issue an HTTP
response providing the requested information or rejecting the
request. </FONT></P>

		
<P><FONT SIZE="2">By matching the HTTP challenge with statements
associated with a persona, the client software can follow a
stringent series of client defined rules for accessing and
acquiring client side data. The privacy vocabulary proposed by
the IPWG can be used to provide the basis of the privacy
&quot;dialogue&quot; held between site server and client. Within
this vocabulary, the site can state what it is planning on doing
with the data (internal use, redistributed, aggregate_only) and
which data it wants (common name, email, click_stream). The
client can set its own privacy acceptance levels and associate
data and click stream capture approval.</FONT></P>

		
<P><FONT SIZE="2">These concepts may be expanded to include
references to site content (e.g., content_for_site_is Sports or
content_for_page_is Sports), personae (e.g., use_persona WORK)
and level of trust mechanism. Note that the actual diction for
this semantic information is left to the IPWG vocabulary group.
Once it is defined, the server and client can use this privacy
vocabulary to negotiate the level of access and data permitted. </FONT></P>

		
<P><FONT SIZE="2">Note that the HTTP protocol provides an
extensible mechanism for defining new challenge/response
exchanges such as the one described above. Beyond specifying the
vocabulary mentioned above, however, it is necessary to also
specify its syntax. In the section below titled &quot;Interchange
Format,&quot; the XML lanaguage is suggested as ideal for
expressing the rich structured data of an information
challenge/request or response.</FONT></P>

		
<P><FONT SIZE="2">Using XML in such a circumstance is especially
appropriate because the PICS-NG group is also considering using
the XML language syntax for the next version of the PICS
specification. The evaluation of these semantics may occur
through the rules based technology of PICSRulz.</FONT></P>

		
<P><FONT SIZE="2">Determining the vocabulary and language syntax
for requesting information or declaring rules is a first step.
Without a mechanism for trusting that the site will indeed use
the data for the expressed purpose, any site can use the
vocabulary to &quot;lie&quot; and falsely gather data. Therefore,
some trust mechanisms are required that can be used to validate
the site&#146;s intentions.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>4.2 The trust model for
releasing information</B></FONT></P>

		
<P><FONT SIZE="2">The acceptance, rejection or modification of
personal information and click stream data is based upon the
level of trust between the client and the site. The more secure
the client feels with the site&#146;s statement of purpose, the
more information and access permissions will be allowed.</FONT></P>

		
<P><FONT SIZE="2">Requiring certain forms of &quot;trust&quot;,
such as certificates, may present too high a bar for smaller,
non-commercial sites. In order to make personal information
accessible by all sites while also providing a mechanism for
ensuring strict trust, this proposal outlines a gradation of
trust mechanisms. The end-user is responsible for making the
final decision on whether to release personal data depending on
the trust mechanism used by a particular Web site.</FONT></P>

		
<P><FONT FACE="Arial"><B>4.2.1 Informed consent</B></FONT></P>

		
<P><FONT SIZE="2">Informed consent is the least secure of the
trust mechanisms. When the site attempts to access personal data,
the client software will ask for permission from the user to
release the information, presenting the site&#146;s privacy
policy as HTML. If the site has used the privacy vocabulary, then
the client software can use this information to determine a match
among personae. If there is no vocabulary, or if no persona is
matched, then the user must select a persona or refuse the site.</FONT></P>

		
<P><FONT SIZE="2">Note that this mechanism is unwieldy in that it
requires user intervention whenever data is requested, including
information updates as well as first-time visits. Users may
therefore be interrupted upon every visit to a Web site. There is
also no provision for the user to know whether or not the site is
misrepresenting its policies and identity, just as there is no
provision for the site to prove the validity of the user&#146;s
personal data.</FONT></P>

		
<P><FONT FACE="Arial"><B>4.2.2 Trusted agents</B></FONT></P>

		
<P><FONT SIZE="2">Once an individual releases his or her personal
profile to a Web site, there is no technical way to prevent that
Web site from retaining the information for reuse, or sharing it
with others. In this scenario, a client-trusted third party may
vouch for the integrity of the Web site. This works much the way
label bureaus work today. Sites may subscribe to third party
auditing programs that vouch for good business practices. </FONT></P>

		
<P><FONT SIZE="2">When a Web site requests personal information
from the user&#146;s client software, the client software asks a
trusted agent for information about this site. The agent returns
the privacy policy, and if it is acceptable, the user may make an
informed decision to release information to the site. It is
possible to automate this process so that once a user has
expressed full trust in a particular agent, personal information
is released without user-intervention.</FONT></P>

		
<P><FONT SIZE="2">While this mechanism provides greater assurance
of site integrity, there is still the potential for the site and
the agent to mislead the client. One possible way to tighten
security is for the client to require certificates from the Agent
on behalf of the site. The certification process would be the
same as the one used for a site, as discussed in the Certificates
section.</FONT></P>

		
<P><FONT FACE="Arial"><B>4.2.3 Certificates</B></FONT></P>

		
<P><FONT SIZE="2">To provide strict, verifiable trust, a third
party such as Verisign or the US Postal Service, can certify the
identity of Web sites or users using certificates based on the
X.509 standard. Given the provable identity of a Web site, the
client software must still decide whether or not to release
personal information based on the informed consent of the user or
by consulting a trusted third-party privacy assurance Web site.
Furthermore, for Web sites that require proof of identity from
their customers, users may use X.509 certificates allowing the
client software to identify the user&#146;s identity in a
provable manner. </FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>4.3 Transmission &#150; secure
data transfer via HTTP, SSL, PFX</B></FONT></P>

		
<P><FONT SIZE="2">The data transmitted between the client and the
Web site must be securely encrypted to ensure privacy of the
user&#146;s personal information. As described above, the SSL
standard ensures that all communication between the HTTP client
and HTTP server software is encrypted to prevent eavesdropping
and unintentional breaches of privacy.</FONT></P>

		
<P><FONT SIZE="2">SSL introduces additional latency that may be
of concern for many Web sites. It is therefore important to
provide alternatives that maintain privacy without requiring
encryption of all client-server communication. As mentioned
earlier, PFX provides a secured method for transmitting
information via a non-secure channel. PFX protects only the
private information transmitted between client and server so that
the remaining client-server Web traffic may be transmitted
openly. Alternatively, no encryption may be used and the client
should notify the user that the information is being sent on an
insecure connection and could be intercepted.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>4.4 Interchange format</B></FONT></P>

		
<P><FONT SIZE="2">For the simple contact information and
demographic information presented earlier in this document, it is
possible to use the proposed vCard format as the interchange file
format. In order to allow arbitrary extension of the schema for
the personal information, however, it is desirable to use a file
format that can provide rich structure for expressing complex
schemas. Furthermore, an interchange file format is necessary to
allow a Web site to present specific information requests against
the client-side schema. The proposed XML standard provides an
excellent language for such an interchange format.</FONT></P>

		
<P><FONT SIZE="2">XML provides an infinitely extensible grammar
for structured data. XML contains two principal parts called
&quot;Instance&quot; (the data) and &quot;Document Type
Definition&quot; (usually called &quot;DTD&quot;), where the DTD
is an ISO standard way to express a schema. An XML data instance
looks similar to an HTML document, in that both use tags to
organize textual data. XML, however, is much more formal and
restrictive in that tags must form a strict tree structure. XML
is also extensible: Unlike HTML, new schemas can be created for
any needed purpose, so the tags in any particular document will
be specific to that document&#146;s type. </FONT></P>

		
<P><FONT SIZE="2">Below is an example of personal data expressed
as an XML instance:</FONT></P>

		
<BLOCKQUOTE>
    <PRE>&lt;?XML version=&quot;1.0&quot;?&gt;
&lt;PersonalData&gt;
    &lt;Contact&gt;
        &lt;UserID&gt;Joe&lt;/UserID&gt;
        &lt;Email&gt;Joe@somewhere.org&lt;/Email&gt;
        &lt;CommonName&gt;Joe Smith&lt;/CommonName&gt;
        &lt;GivenName&gt;Joe&lt;/GivenName&gt;
        &lt;FamilyName&gt;Smith&lt;/FamilyName&gt;
        &lt;Address&gt;
            &lt;Line1&gt;50 Greenhill Road&lt;/Line1&gt;
            &lt;City&gt;Mill Valley&lt;/City&gt;
            &lt;State&gt;CA&lt;/State&gt;
            &lt;PostalCode&gt;94941&lt;/PostalCode&gt;
            &lt;Country&gt;USA&lt;/Country&gt;
        &lt;/Address&gt;
    &lt;/Contact&gt;
    &lt;Demographic&gt;
        &lt;Birthday&gt;19541022&lt;/Birthday&gt;
        &lt;Gender&gt;X&lt;/Gender&gt;
        &lt;LevelOfEducation&gt;14&lt;/LevelOfEducation&gt;
    &lt;/Demographic&gt;
&lt;/PersonalData&gt;</PRE>
</BLOCKQUOTE>

		
<P><FONT SIZE="2">XML schemas can be defined in the <I>Document
Type Definition</I> machine-readable format, a specialized form
of BNF. This DTD syntax declares the relationship and grammatic
rules for creating a valid <I>Instance</I> of XML. Below is the
DTD syntax for expressing the personal data schema above:</FONT></P>

		
<BLOCKQUOTE>
    <P><FONT SIZE="2" FACE="Courier New">&lt;!ELEMENT
    PersonalData (Contact?, Demographic?, Business?,
    Miscellaneous?, Security?)&gt;<BR>
    &lt;!ELEMENT Contact (UserID?, Email+, Certificate+,
    CommonName?, GivenName?, FamilyName?,MiddleName?, Address+,
    LanguageSpoken+, Telephone+, MobilePhone+) &gt;<BR>
    &lt;!ELEMENT UserID #PCDATA &gt;<BR>
    &lt;!ELEMENT Email #PCDATA &gt;<BR>
    &lt;!ELEMENT Certificate #PCDATA &gt;<BR>
    &lt;!ELEMENT CommonName #PCDATA &gt;<BR>
    &lt;!ELEMENT GivenName #PCDATA &gt;<BR>
    &lt;!ELEMENT FamilyName #PCDATA &gt;<BR>
    &lt;!ELEMENT MiddleName #PCDATA &gt;<BR>
    &lt;!ELEMENT Address ( (Line1, Line2?)?, City?, State?,
    PostalCode?, Locality?, Country?) &gt;<BR>
    &lt;!ELEMENT Address1 #PCDATA &gt;<BR>
    &lt;!ELEMENT Address2 #PCDATA &gt;<BR>
    &lt;!ELEMENT City #PCDATA &gt;<BR>
    &lt;!ELEMENT State #PCDATA &gt;<BR>
    &lt;!ELEMENT PostalCode #PCDATA &gt;<BR>
    &lt;!ELEMENT Locality #PCDATA &gt;<BR>
    &lt;!ELEMENT Country #PCDATA &gt;<BR>
    &lt;!ELEMENT LanguageSpoken #PCDATA &gt;<BR>
    &lt;!ELEMENT Telephone #PCDATA &gt;<BR>
    &lt;!ELEMENT MobilePhone #PCDATA &gt;<BR>
    &lt;!ELEMENT Fax #PCDATA &gt;<BR>
    &lt;!ELEMENT Pager #PCDATA &gt;<BR>
    &lt;!ELEMENT Demographic (Birthday?, Gender?,
    LevelOfEducation?, MaritalStatus?, NumberOfChildren?,
    IncomeLevel?)&gt;<BR>
    &lt;!ELEMENT Birthday #PCDATA &gt;<BR>
    &lt;!ELEMENT Gender #PCDATA &gt;<BR>
    &lt;!ELEMENT LevelOfEducation #PCDATA &gt;<BR>
    &lt;!ELEMENT MaritalStatus #PCDATA &gt;<BR>
    &lt;!ELEMENT NumberOfChildren #PCDATA &gt;<BR>
    &lt;!ELEMENT IncomeLevel (Currency?, Quantity) &gt;<BR>
    &lt;!ELEMENT Currency #PCDATA&gt;<BR>
    &lt;!ELEMENT Quantity #PCDATA&gt;<BR>
    &lt;!ELEMENT Business (PostalCode?, Industry?,
    ProfessionalTitle?, CompanySize?, Telephone?, Fax?, Pager?,
    MobilePhone?, Email?, Organization? &gt;<BR>
    &lt;!ELEMENT Industry #PCDATA &gt;<BR>
    &lt;!ELEMENT ProfessionalTitle #PCDATA &gt;<BR>
    &lt;!ELEMENT CompanySize #PCDATA &gt;<BR>
    &lt;!ELEMENT Miscellaneous (Persona?, Creation?,
    Modification?) &gt;<BR>
    &lt;!ELEMENT Persona (ID, Name) &gt;<BR>
    &lt;!ELEMENT ID #PCDATA &gt;<BR>
    &lt;!ELEMENT Name #PCDATA &gt;<BR>
    &lt;!ELEMENT Creation (Date?, Name?) &gt;<BR>
    &lt;!ELEMENT Date #PCDATA &gt;<BR>
    &lt;!ELEMENT Modification (Date?, Name?) &gt;<BR>
    &lt;!ELEMENT Security (Password?) &gt;<BR>
    &lt;!ELEMENT Password #PCDATA &gt;</FONT></P>
</BLOCKQUOTE>

		
<P><FONT SIZE="2">The above DTD is merely an example and an
initial recommendation as to how the XML language may be used for
the transmission of personal profile information. While this
document does not present a final recommendation of the exact XML
DTD for passing personal information conforming to an extensible
schema, it should be clear that the proposed and broadly
supported XML standard provides an <I>extremely </I>rich language
for the expression of such information. Furthermore, the language
provides an equally rich syntax for the expression of server-side
information requests and content-matching rules for
personalization of the content presented to a user. For more
details on content personalization, see the section below.</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>5. Clickstream Information</B></FONT></P>

		
<P><FONT SIZE="2">The clickstream information describing a Web
user&#146;s activity on a site is very valuable. The number of
hits that a site receives has become a key benchmark in comparing
site popularity and is crucial to sites that depend on
advertising revenue. Sites also use these &quot;traffic
reports&quot; for decision support, to determine how they can be
improved.</FONT></P>

		
<P><FONT SIZE="2">Server based information is limited, however,
since many page-views are never reported back to servers. Local
caches and proxy servers are used to reduce network latency and
bandwidth consumption, but hits that are satisfied locally are
not reported back to the server. Some sites get around this
limitation by using uncacheable dynamically generated pages, but
this consumes unnecessary bandwidth.</FONT></P>

		
<P><FONT SIZE="2">The obvious solution is for Web browsers to
support client-side logging of offline hits, keeping track of the
user&#146;s browsing behavior locally. This information can then
be periodically posted back to Web servers. This will be
especially important in the next generation of Web client
software that will support off-line or disconnected operation.
Log reporting has several privacy and security ramifications,
however.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>5.1 Security &amp; Privacy</B></FONT></P>

		
<P><FONT SIZE="2">Just as the user must have control over the
release of persona information, so too must the user have control
over the release of click stream data. Users must be able to
control which sites can receive it, how much they can receive,
and whether or not the data is provided anonymously. This is
especially important since click stream data is gathered for the
most part without any direct user intervention and paints a very
accurate picture of the user&#146;s interests and activities.</FONT></P>

		
<P><FONT SIZE="2">The sections above on secure data transmission
and trust models are obviously relevant. Users must be able to
trust that sites will follow good business practices in their use
of click stream data, or else users will not authorize release of
the data, or may wish to have their data released anonymously.
Users must also be assured that other sites can not steal their
data while it&#146;s being exchanged, and that a site can not
gather the data meant for another by spoofing its identity. These
requirements call for the same encryption mechanisms discussed
above to be used for exchanging click through data. </FONT></P>

		
<P><FONT SIZE="2">As an additional requirement, however, clients
need to provide a mechanism by which the click stream data can be
semantically filtered. A user may wish to require, for example,
that no click stream data containing references to &quot;Adult
sites&quot; be recorded. This requirement can be observed using
XML or PICS rating tags.</FONT></P>

		
<P><FONT SIZE="2">Finally, in order to meet international privacy
standards, the client must provide some means for the user to
view the click stream data that will be sent. This requirement
applied to the transmission of a user&#146;s persona above,
however it was easily met since the user could directly edit the
profile. This is not necessarily the case for click stream data.</FONT></P>

		
<P><FONT SIZE="4" FACE="Arial"><B>5.2 Click Stream Transmission</B></FONT></P>

		
<P><FONT SIZE="2">Although the XML standard could be easily used
as the exchange format for click stream data, practical concerns
dicate that clients should instead transmit this data in a
standard server log-file format. All competitive usage analysis
software products understand the most common server-log formats,
such as the Extended Log File Format, so client click stream data
should be posted in this format. This format has been proposed as
a standard to the W3C. More information on this format can be
found at </FONT><A HREF="WD-logfile.html" W3MIRHREF="http://www.w3.org/TR/WD-logfile.html">http://www.w3.org/TR/WD-logfile.html</A><FONT SIZE="2">.</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>6. Personalization</B></FONT></P>

		
<P><FONT SIZE="2">Once a standard mechanism for exchanging user
information has been defined, sites can begin to tailor their
content and services directly to the end user. Examples range
from simple targeted local advertising based on zipcode to
complex information retrieval based on explicit user preferences
and implicit observed user behavior.</FONT></P>

		
<P><FONT SIZE="2">This sort of personalization may be performed
on either the client or the server. In either case, once the user
persona is exposed via a standard mechansim as described above,
then any of the existing mechanisms for generating dynamic
content may be used to generate dynamic <I>personalized </I>content.
In addition, a variety of vendors provide software that is
explicity designed to provide personalized content based on user
profiles. These vendors will be able to easily import data from
the persona into their systems, eliminating the need for
proprietary, user profile collection mechanisms. This applies to
systems based on content targeting rules or collaborative
filtering mechanisms.</FONT></P>

		
<P><FONT SIZE="2">New content delivery systems can also be
designed that take full advantage of the richness of XML. One of
the primary goals of the XML specificaton is to provide
meta-content that fully describes a site&#146;s content. Once
user preferences are also described with XML it will be possible
to author rules in XML that describe the relationships between
content and users. This may make it even easier for sites to
construct rich personalized content, and it will also make it
easier for users to describe the content that they wish to
receive.</FONT></P>

		
<P><FONT SIZE="5" FACE="Arial"><B>7. Conclusion</B></FONT></P>

		
<P><FONT SIZE="2">It is possible to provide a rich, secure
platform for exchanging user profile information between Web
users and Web sites without inventing new file formats or wire
protocols. This proposal uses HTTP as the wire protocol, SSL and
PFX to secure information exchange, XML to express server queries
and profile information, vCard to provide a standard schema of
contact information, and X.509 certificates to optionally
identify sites or users.</FONT></P>

		
<P><FONT SIZE="2">To complete this proposal, one must use the
existing extension mechanisms of the above standards. HTTP
provides extensible challenge/response, XML is by definition an
extensible language for expressing rich structured data, and
vCard&#146;s schema was designed to be extended with additional
properties. Future proposals can be expected to provide
additional details on these extensions, particularly the HTTP
challenge/response mechanism and the IPWG vocabulary to be
expressed in XML.</FONT></P>
</BODY>
</HTML>

		
.

NEW PAGES:

[ODDNUGGET]

[GOPHER]