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.
838 lines
48 KiB
838 lines
48 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
|
|
<HEAD>
|
|
<TITLE>CC/PP Implementors Guide: Privacy and Protocols</TITLE>
|
|
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
|
|
<META content="text/html; charset=iso-8859-1">
|
|
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
|
|
<link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-WD.css">
|
|
</HEAD>
|
|
<BODY>
|
|
|
|
<DIV class="head">
|
|
<A href="http://www.w3.org/"><IMG alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home" height=48 width=72></A>
|
|
|
|
<H1>CC/PP Implementors Guide:<br>
|
|
Privacy and Protocols</H1>
|
|
<H2>W3C Working Draft 20 December 2001</H2>
|
|
|
|
<dl>
|
|
<dt>This Version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/">
|
|
http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/</a></dd>
|
|
<dt>Latest Version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/CCPP-trust">
|
|
http://www.w3.org/TR/CCPP-trust</a></dd>
|
|
<dt>Previous Version:</dt>
|
|
<dd>None</dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Hidetaka Ohto <
|
|
<A href="mailto:ohto@w3.org">ohto@w3.org</A>>,
|
|
W3C/Panasonic</dd>
|
|
<dd>Lalitha Suryanarayana <<A
|
|
href="mailto:lalitha@tri.sbc.com">mailto:lalitha@tri.sbc.com</A>
|
|
>, SBC</dd>
|
|
<dd>Johan Hjelm <<A href="mailto:johan.hjelm@nrj.ericsson.se">
|
|
johan.hjelm@nrj.ericsson.se</a>>,
|
|
Ericsson Research Japan</dd>
|
|
</dl>
|
|
|
|
<!--
|
|
<TABLE
|
|
summary="This table lists URIs for this version, latest public version
|
|
and previous version of this document, and authors of this document.">
|
|
|
|
<TABLE
|
|
<TBODY>
|
|
<TR vAlign=baseline>
|
|
<TD>This version:</TD>
|
|
<TD><A class=loc
|
|
href="http://www.w3.org/TR/2001/WD-CCPP-trust-20011218">
|
|
http://www.w3.org/TR/2001/WD-CCPP-trust-20011218</A></TD></TR>
|
|
<TR vAlign=baseline>
|
|
<TD>Latest version:</TD>
|
|
<TD><A class=loc
|
|
href="http://www.w3.org/TR/CCPP-trust">
|
|
http://www.w3.org/TR/CCPP-trust</A></TD></TR>
|
|
<TR vAlign=baseline>
|
|
<TD>Editors:</TD>
|
|
<TD>Hidetaka Ohto <<A href="mailto:ohto@w3.org">ohto@w3.org</A>>,
|
|
W3C/Panasonic<BR>Lalitha Suryanarayana <<A
|
|
href="mailto:lalitha@tri.sbc.com">mailto:lalitha@tri.sbc.com</A>
|
|
>, SBC<br>
|
|
Johan Hjelm <<A
|
|
href="mailto:johan.hjelm@nrj.ericsson.se">johan.hjelm@nrj.ericsson.se</A>>,
|
|
Ericsson Research Japan</TD></TR></TBODY></TABLE>
|
|
<P>
|
|
-->
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
|
|
Copyright</a> ©2001 <a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><abbr title="Massachusetts Institute of
|
|
Technology">MIT</abbr></a>, <a href="http://www.inria.fr/"><abbr
|
|
lang="fr" title="Institut National de Recherche en Informatique et
|
|
Automatique">INRIA</abbr></a>, <a
|
|
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
|
|
use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
|
|
licensing</a> rules apply.</p>
|
|
</DIV>
|
|
|
|
<HR>
|
|
|
|
<H2><A id=Abstract name=Abstract>Abstract</A></H2>
|
|
<P>This document gives implementors advice on how to protect the privacy of a
|
|
CC/PP user, and outlines how this can be applied using P3P in HTTP with the
|
|
CC/PP Exchange protocol.</P>
|
|
|
|
<H2><A id=status name=status>Status of this document</A></H2>
|
|
|
|
<p>
|
|
This section describes the status of this document at the time of its
|
|
publication. Other documents may supersede this document. The latest
|
|
status of this document series is maintained at the W3C.</p>
|
|
|
|
<p>
|
|
This document is a very preliminary public Working Draft made
|
|
available by the World Wide Web Consortium (W3C) for discussion
|
|
only. It is intended to become a W3C Note. This indicates no
|
|
endorsement of its content. This is work in progress, may be updated,
|
|
replaced, or obsoleted by other documents at any time.
|
|
A list of current W3C working drafts can be found at
|
|
<a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
|
|
|
|
<p>
|
|
This document is produced by the <a href="/Mobile/CCPP/Group/">
|
|
CC/PP working group</a> (member only) (part of the
|
|
<a href="/2001/di">Device Independence activity</a>).
|
|
The working group welcomes feedback and discussion,
|
|
preferably on the public mailing list <a
|
|
href="mailto:www-mobile@w3.org">www-mobile@w3.org</a>, although
|
|
comments may also be sent to the authors.
|
|
Public comments and their responses can be accessed at
|
|
<a href="http://lists.w3.org/Archives/Public/www-mobile/">
|
|
http://lists.w3.org/Archives/Public/www-mobile/</a>.</p>
|
|
|
|
<p>
|
|
|
|
|
|
<!--
|
|
<P>This document is a very preliminary working draft made available by
|
|
the World Wide Web Consortium (W3C) for discussion only. It is
|
|
intended to become a W3C Note. This indicates no endorsement of its
|
|
content. This is work in progress, and future updates and changes are
|
|
likely. Please send comments and feedback to <A
|
|
href="mailto:www-mobile@w3.org">www-mobile@w3.org</A>.</P>
|
|
-->
|
|
|
|
<H2>Table of Contents</H2>
|
|
|
|
<P>Not included in this version.</P>
|
|
<H2><A id=Introduction name=Introduction>1. Introduction</A></H2>
|
|
<P>CC/PP data is not in itself personal, i.e. tied to a named user, but since
|
|
there are a number of ways for the user to be identified as the holder of the
|
|
profile, e.g. by identity transmision in HTTP parameters, or through
|
|
recognition of the IP-number or such, there is a need for a suggested privacy
|
|
method for implementors.</P>
|
|
<P>Descriptions of single features in a description of a terminal or the users
|
|
preferences for how that terminal should be used cannot in themselves be used to
|
|
infringe on a users privacy. However, when a profile contains a collection of
|
|
such properties, it can be used to personalize information; the closer the
|
|
personalization, the bigger risk that the user can be identified from his
|
|
specific use of the terminal; and the bigger the risk of misuse from a privacy
|
|
standpoint. There is also a possible risk that a user can be identified as
|
|
having certain abilities (e.g. if he constantly requests text in double-sized
|
|
fonts, it is likely that he is hard of seeing), and this may be possible to
|
|
misuse.</P>
|
|
<P>Generally speaking, a user may not want to share some or all of the data in a
|
|
CC/PP profile, and may wish to have control over who receives that information
|
|
and when. Origin servers customizing the content should therefore express to the
|
|
user or user agent regarding their privacy practices with regard to the use of
|
|
CC/PP data, so that, the user can make a decision on whether or not to share
|
|
that data with the server.</P>
|
|
<P>P3P is a way for an origin server to express the privacy policy it adheres to
|
|
for the user and/or his terminal. While the match between P3P and CC/PP is not
|
|
perfect, and while the intent and implementation of the two are different, they
|
|
can be used together to enhance the privacy protection of the user.</P>
|
|
<P>CC/PP is an abbreviation of "Composite Capability/Preference Profiles", and
|
|
is an extensible format based on RDF <a href="#RDF">[RDF]</A>
|
|
<a href="#RDF-Schema">[RDF-Schema]</A>
|
|
for describing device capabilities and user preferences. In general, user
|
|
preferences and device capabilities need to be protected from malicious use but
|
|
there is no trust management framework for CC/PP so far. Without trust
|
|
management, sensitive information opens to attacks by malicious servers or
|
|
content providers.</P>
|
|
<P>We do not aim to create new technologies in terms of network security,
|
|
authentication, message validation, personal privacy protection, and
|
|
cryptography. We intend to employ the existing technologies in terms of trust
|
|
management while considering how to apply such technologies well fit into the
|
|
use cases of CC/PP.</P>
|
|
<H2><A id="scope" name="scope">2. Scope of this document</A></H2>
|
|
<P>This document is a discussion document, containing implementation advice for
|
|
developers of services based on CC/PP. It demonstrates the interactions between
|
|
CC/PP and P3P given the current state of implementations. However, since CC/PP
|
|
only specifies a data structure and not a protocol, this work should be taken as
|
|
future input to a formal specification, and currently be seen as advice to
|
|
implementors only.</P>
|
|
<P></P>
|
|
<H2><a id="protocol-transport" name="protocol-transport"></a>
|
|
3. Protocol and transport issues.</H2>
|
|
<P>There is, currently, no CC/PP protocol. There are a number of proposals, but
|
|
for various reasons, the group is not chartered to develop a protocol. It will
|
|
do so as soon as possible, but it does require a rechartering. Meanwhile, there
|
|
are two proposals: The CC/PP Exchange Protocol, and the W-HTTP protocol.</P>
|
|
<P>Note that it would be possible to use the "profile" header Mark Baker
|
|
suggests in draft-baker-xhtml-media-reg-01.txt and
|
|
draft-baker-xhtml-media-reg-02.txt to reference a CC/PP profile (the mechanism
|
|
has been demonstrated by Kiniko Yasuda of Keio University).</P>
|
|
<P>There are two main ways of transporting CC/PP over HTTP: Using the CC/PP
|
|
Exchange Protocol, or using the UAProf W-HTTP Protocol.</P>
|
|
<P></P>
|
|
<H3><a name="ccpp-exchange" id="ccpp-exchange"></a>
|
|
3.1 CC/PP Exchange Protocol</H3>
|
|
<P>The CC/PP Exchange Protocol (CCPP-ex) was presented as a W3C Note on June 24,
|
|
1999. It uses the HTTP Extension Framework <a
|
|
href="#RFC2396">[RFC2396]</a>.
|
|
The intent was to provide
|
|
a framework that was both possible to map into HTTP headers, and that can handle
|
|
defaults as URIs. The idea was to minimize data transfer over the air, a goal
|
|
that was accomplished, as has been demonstrated by <A
|
|
href="/Mobile/CCPP/implday/0011ccpp/Overview.html">Kiniko
|
|
Yasuda of Keio University</A>.</P>
|
|
<P>CCPP-ex uses two headers, one for the defaults and one for the updates
|
|
(profile-diff:s), which are separated using MD5 hashes. A third header carries
|
|
warning information. The protocol is documented in the W3C Note "<A
|
|
href="/TR/NOTE-CCPPexchange">CC/PP exchange protocol based on
|
|
HTTP Extension Framework</A>".</P>
|
|
<P>The CC/PP framework is a mechanism for describing the capabilities and
|
|
preferences associated with users and user agents accessing the World Wide Web.
|
|
Information about user agents includes the hardware platform, system software,
|
|
applications and user preferences. The user agent capabilities and preferences
|
|
can be thought of as metadata, or properties and descriptions of the user
|
|
agent's hardware and software. The CC/PP descriptions are intended to provide
|
|
information necessary to adapt the content and the content delivery mechanisms
|
|
to best fit the capabilities and preferences of the user and its agents.</P>
|
|
<P>The major disadvantage of this format is that it is verbose. Some networks
|
|
are very slow and this would be a moderately expensive way to handle
|
|
metadata.</P>
|
|
<P>There are several optimizations possible to help deal with network
|
|
performance issues. One strategy is to use a compressed form of XML, and a
|
|
complementary strategy is to use references (URIs). Instead of enumerating each
|
|
set of attributes, a reference can be used to name a collection of attributes
|
|
such as the hardware platform defaults. This has the advantage of enabling the
|
|
separate fetching and caching of functional subsets. Another problem is to
|
|
propagate changes to the current CC/PP descriptions to an origin server, a
|
|
gateway or a proxy. One solution is to transmit the entire CC/PP descriptions
|
|
with each change. This is not ideal for slow networks. An alternative is to send
|
|
only the changes.</P>
|
|
<P>The CC/PP exchange protocol does not depend on the profile format that it
|
|
conveys. Therefore another profile format besides the CC/PP description format
|
|
could be applied to the CC/PP exchange protocol. For example, a user agent
|
|
issues a request with URIs which address the profile information, and if the
|
|
user agent changes the value of an attribute, such as turning sound off, only
|
|
that change is sent together with the URIs. When an origin server receives the
|
|
request, the origin server inquires of CC/PP repositories the CC/PP descriptions
|
|
using the list of URIs. Then the origin server creates a tailored content using
|
|
the fully enumerated CC/PP descriptions. The origin server might not obtain the
|
|
fully enumerated CC/PP descriptions when any one of the CC/PP repositories is
|
|
not available. In this case, it depends on the implementation whether the origin
|
|
server should respond to the request with a tailored content, a non-tailored
|
|
content or an error. In any case, the origin server should inform the user agent
|
|
of the fact.</P>
|
|
<P>A warning mechanism has been introduced for this purpose. It is likely that
|
|
an origin server, a gateway or a proxy will be concerned with different device
|
|
capabilities or user preferences. For example, the origin server may have
|
|
responsibility to select content according to the users preferred language,
|
|
while the proxy may have responsibility to transform the encoding format of the
|
|
content. Therefore gateways or proxies might not forward all profile information
|
|
to an origin server. The CC/PP exchange protocol might convey natural language
|
|
codes within header field-values. Therefore internationalization issues must be
|
|
considered. The internationalization policy of the CC/PP exchange protocol is
|
|
based on RFC2277.</P>
|
|
<P>Considering how to maintain a session like RTSP (RFC2326) is worthwhile from
|
|
the point of view of minimizing transactions (i.e. the session mechanism could
|
|
permit the client to avoid resending the elements of the CC/PP descriptions that
|
|
have not changed since the last time the information was transmitted). However a
|
|
session mechanism would reduce cache efficiency, and requires maintaining states
|
|
between a user agent and an origin server. An extension declaration is used to
|
|
indicate that an extension has been applied to a message and possibly to reserve
|
|
a part of the header namespace identified by a header field prefix.</P>
|
|
<P>The HTTP Extension Framework introduces two types of extension declaration
|
|
strength: mandatory and optional, and two types of extension declaration scope:
|
|
hop-by-hop and end-to-end. Which type of the extension declaration strengths
|
|
and/or which type of the extension declaration scopes should be used depends on
|
|
what the user agent needs to do.</P>
|
|
<P>The strength of the extension declaration should be mandatory if the user
|
|
agent needs to obtain an error response when a server(an origin server, a gateway
|
|
or a proxy) does not comply with the CC/PP exchange protocol.</P>
|
|
<P>The strength of the extension declaration should be optional if the user
|
|
agent needs to obtain the non-tailored content when a server does not comply
|
|
with the CC/PP exchange protocol. The scope of the extension declaration should
|
|
be hop-by-hop if the user agent has a priori knowledge that the first hop
|
|
proxy complies with the CC/PP exchange protocol.</P>
|
|
<P>The scope of the extension declaration should be end-to-end if the user agent
|
|
has a priori knowledge that the first hop proxy does not comply with the CC/PP
|
|
exchange protocol, or the user agent does not use a proxy.</P>
|
|
<P>The Profile header field is a request-header field, which conveys a list of
|
|
references which address CC/PP descriptions.</P>
|
|
<P>The grammar for the Profile header field is as follows:</P>
|
|
<TABLE border=1>
|
|
<TBODY>
|
|
<TR>
|
|
<TD>Header field</TD>
|
|
<TD>Grammar</TD></TR>
|
|
<TR>
|
|
<TD>Profile</TD>
|
|
<TD>= profile-field-name ":" 1#reference</TD></TR>
|
|
<TR>
|
|
<TD>profile-field-name</TD>
|
|
<TD>= "Profile"</TD></TR>
|
|
<TR>
|
|
<TD>reference</TD>
|
|
<TD>= <"> ( absoluteURI | profile-diff-name ) <"></TD></TR>
|
|
<TR>
|
|
<TD>profile-diff-name</TD>
|
|
<TD>
|
|
<P>= profile-diff-number "-" profile-diff-digest</P></TD></TR>
|
|
<TR>
|
|
<TD>profile-diff-number</TD>
|
|
<TD>= 1#DIGIT</TD></TR>
|
|
<TR>
|
|
<TD>profile-diff-digest</TD>
|
|
<TD>= sp; < MD5 message digest encoded by base64 ></TD></TR>
|
|
<TR>
|
|
<TD>DIGIT</TD>
|
|
<TD>= <any US-ASCII digit "0".."9"></TD></TR></TBODY></TABLE>
|
|
<P>The Profile header field-value is a list of references. Each reference in the
|
|
Profile header field represents the corresponding entity of the CC/PP
|
|
description.</P>
|
|
<P>A reference is either an absolute URI or a profile-diff-name. An entity of a
|
|
CC/PP description which is represented by an absoluteURI exists outside of the
|
|
request, and an entity of a CC/PP description which is represented by a
|
|
profile-diff-name exisits inside of the request (i.e. in the Profile-Diff header
|
|
field. The profile-diff-name in the Profile header field addresses a CC/PP
|
|
description in the corresponding Profile-Diff header within the same
|
|
request.</P>
|
|
<P>When the Profile header field includes a profile-diff-name, the corresponding
|
|
Profile-Diff header MUST be included within the same request. The main reason
|
|
why the profile-diff-name is introduced is to specify the priority of each CC/PP
|
|
description in the Profile header field-value. The priority is indicated by the
|
|
order of references (i.e. absoluteURI or profile-diff-name) in the Profile
|
|
header field-value. The latest reference in the Profile header field-value has
|
|
the highest priority.</P>
|
|
<P>Therefore a CC/PP description which is represented by the latest reference
|
|
can override CC/PP descriptions which are represented by the precedent
|
|
references. This is the default behavior in the absence of schema rules. All
|
|
profile information could be represented by absoluteURIs in the Profile header.
|
|
In this case, the Profile-Diff header field does not have to be added to the
|
|
request. On the other hand, only one Profile-Diff header can contain all profile
|
|
information. In this case, the Profile header includes only the
|
|
profile-diff-name which indicates the Profile-Diff header.</P>
|
|
<H3><a id="w-http" name="w-http"></a>3.2 W-HTTP</H3>
|
|
<P>The WAP Forum UAProf group has defined a transport for CC/PP over W-HTTP
|
|
(Wireless Profiled HTTP). It can be found in section 9 of the UAProf
|
|
specification. In the case where the mobile terminal supports wireless profiled
|
|
HTTP the profile is transported using meta data defined by
|
|
<!--
|
|
HTTP [W-HTTP] the profile is transported using meta data defined by
|
|
-->
|
|
this
|
|
specification. The CC/PP Framework remains unaltered. The defined mechanism
|
|
provides a functional equivalent for the CC/PP exchange protocol <a href="#CCPP-ex">[CCPP-ex]</a> but
|
|
the definition of the syntax and semantics of the transport remains in this
|
|
specification.</P>
|
|
<P></P>
|
|
<H4><a id="w-http-trans-ccpp" name="w-http-trans-ccpp"></a>
|
|
3.2.1 Using W-HTTP to transport CC/PP</H4>
|
|
<P>The following extension headers are defined to transport CC/PP in W-HTTP. The
|
|
defined extension headers are considered to be end to end headers..</P>
|
|
<P></P>
|
|
<H5>3.2.1.1 X-WAP-PROFILE</H5>
|
|
<P>The x-wap-profile header is a general header field which MUST contain the
|
|
following :</P>
|
|
<P>·a URI referencing the CC/PP profile, or</P>
|
|
<P>·a reference to a profile difference, transported using the
|
|
x-wap-profile-diff or</P>
|
|
<P>·a combination of multiple instances of these two types of data. This data
|
|
MAY be generated by the mobile terminal or attached by an intermediary point in
|
|
a request to an origin server.</P>
|
|
<P>In the case of Push this header MAY be generated as a response to a request.
|
|
In the case of Push this data may be cached. However this header MUST be present
|
|
in any request or response when UAProf is used.</P>
|
|
<P>The x-wap-profile header MAY contain references to instances of the
|
|
x-wap-profile-diff header (defined in the following section ). Each reference
|
|
contains two parts, the sequence number and the profile-digest. The sequence
|
|
number is used to determine the order of how the x-wap-profile-diff headers
|
|
should be applied and the digest is used to validate that the profile-desc in
|
|
the x-wap-profile-diff header value is correct.</P>
|
|
<P></P>
|
|
<H5>3.2.1.2. X-WAP-PROFILE-DIFF</H5>
|
|
<P>The x-wap-profile-diff header is a general header and MAY be generated by the
|
|
mobile terminal or an intermediate proxy to enhance or alter the CPI. There may
|
|
be multiple profile differences, each profile difference must also have a
|
|
reference in the x-wap-profile header which indicates the order in which
|
|
differences should be applied. This header contains two parts, a sequence
|
|
identifier and the entity which represents the part of the CC/PP description
|
|
that is being enhanced. This header MAY be present in a request or response. In
|
|
the case of Push this data may be cached.</P>
|
|
<P></P>
|
|
<H5>3.2.1.3. X-WAP-PROFILE-WARNING</H5>
|
|
<P>The x-wap-profile-warning header is a general header. Essentially, it is the
|
|
same as the X-WAP-PROFILE-WARNING header in the CC/PP Exchange Protocol. Its
|
|
presence indicates the level to which the response has been tailored in relation
|
|
to profile data that has been supplied in the request. This header MAY be
|
|
present in a request or response. The warning codes that are defined fall into
|
|
the following categories :</P>
|
|
<P>·1xx - reserved</P>
|
|
<P>·100 -- reserved</P>
|
|
<P>·2xx - indicates whether the content has been adapted depending on the
|
|
profile</P>
|
|
<P>·5xx - indicates the server is incapable of processing CPI.</P>
|
|
<P>The x-wap-profile-warning may have the following values.</P>
|
|
<P>200Not applied</P>
|
|
<P>This value MUST be included if the content has not been tailored, and is sent
|
|
in a representation, which is the only representation available in the
|
|
server.</P>
|
|
<P>201Content selection applied</P>
|
|
<P>MUST be included if the included content has been selected from one of the
|
|
representations available.</P>
|
|
<P>202 Content generation applied</P>
|
|
<P>MUST be included if the content has been tailored or generated as a result of
|
|
applying the included profile.</P>
|
|
<P>203 Transformation applied</P>
|
|
<P>MUST be added by an intermediate proxy if it applies any transformation
|
|
changing the content-coding based on the CPI data.</P>
|
|
<P>500Not Supported</P>
|
|
<P>Indicates that the entity sending this warning code does not support
|
|
UAProf.</P>
|
|
<P></P>
|
|
<H5>3.2.1.4. Protocol Procedures</H5>
|
|
<P></P>
|
|
<H6>3.2.1.4.1. Over The Air</H6>
|
|
<P>In this transport variant the headers and their values are not compressed for
|
|
over the air transmission. It is recommended that the hardware and software
|
|
manufacturer only use the x-wap-profile header to indicate an absoluteURI as the
|
|
reference for CPI for the mobile terminal when transmitted over the air. However
|
|
this specification does not preclude the use x-wap-profile-diff in this
|
|
case.</P>
|
|
<P></P>
|
|
<H6>3.2.1.4.2. Combining X-WAP-Profile and X-WAP-Profile-Diff</H6>
|
|
<P>If the x-wap-profile-diff header is included the profile-diff-seq MUST match
|
|
a sequence number in the x-wap-profile header otherwise the associated
|
|
profile-diff-desc MUST NOT be processed. The reference to each
|
|
x-wap-profile-diff header contains two parts, a sequence number which governs
|
|
the order in which the x-wap-profile-diff headers are processed and an MD5
|
|
message digest which is used to validate the profile-desc which is contained in
|
|
the x-wap-profile-diff. If either the sequence or the MD5 validation do not
|
|
match, the particular profile-diff MUST be ignored.</P>
|
|
<P>If the x-wap-profile-diff header is added by an intermediate proxy, it MUST
|
|
NOT alter the existing sequence of x-wap-profile-diff headers, the proxy MUST
|
|
append using the next available sequence number in numeric order. The digest
|
|
associated with an x-wap-profile-diff MUST be generated by applying MD5 message
|
|
digest algorithm [RFC1321] and base64 algorithm, section 6.8 in the MIME
|
|
specification [RFC2045] to the corresponding profile-desc part of the header
|
|
field-value.</P>
|
|
<P>The MD5 algorithm takes as input a message of arbitrary length and produces
|
|
as output a 128-bit "fingerprint" or "message digest" of the input. The base64
|
|
algorithm takes as input arbitrary binary data and produces as output printable
|
|
encoding data of the input.</P>
|
|
<P></P>
|
|
<H5>3.2.1.5. Relationship with HTTP Headers</H5>
|
|
<P>The profile information referred to in the x-wap-profile and
|
|
x-wap-profile-diff header does not supersede HTTP request or response header
|
|
information.</P>
|
|
<P></P>
|
|
<H5>3.2.1.5.1. Caching</H5>
|
|
<P>The x-wap-profile-warning header MUST NOT be used for cache control purposes.
|
|
If a server wishes to indicate a caching dependency based on these
|
|
headers then hit should use the Vary header as defined in section
|
|
14.44 of the HTTP 1.1 specification <a href="#HTTP-1.1">[HTTP/1.1]</a>.</P>
|
|
<P></P>
|
|
<H3><a id="soap" name="soap">3.3 XML Protocol/SOAP</a></H3>
|
|
<P>How CC/PP will be transported and handled in of XML Protocol/SOAP is not
|
|
clear. This is something the working group wishes to investigate further.</P>
|
|
<H3><a id="other-proto" name="other-proto"></a>3.4 Other protocols</H3>
|
|
<P>The WAP Forum has provided a mapping to the headers of WSP, the Wireless
|
|
Session Protocol (defined in the WAP UAPROF specification). Work is also ongoing
|
|
in 3GPP to transport CC/PP over RSVP.</P>
|
|
<H2><A id="usecase" name="usecase">4.Use Cases</A></H2>
|
|
<H3><A id="http-usecase" name="http-usecase">4.1 HTTP use case</A></H3>
|
|
<P>Since CC/PP is intended to be protocol neutral, it will work with any
|
|
protocol which can transport it. Mappings have been produced for other
|
|
protocols, most notably WSP. However, it is to be expected that it will be
|
|
implemented for HTTP, using HTTP headers as a transport. The working group also
|
|
intends to look at the transport of CC/PP over SOAP/XML Protocol as a future
|
|
work item.</P>
|
|
<H4><A id="turst-mechanism" name="trust-mechnism">
|
|
4.1.1 Trust mechanisms</A><A></A></H4>
|
|
<P>Policy publishing does not bring trust by itself. Trust has to be obtained in
|
|
other ways, before it is even worth the trouble to publish a policy. In this
|
|
context, <A href="http://www.w3.org/P3P/">P3P</A> should rather be seen as a
|
|
means to retrieve the user's consent for data storage and/or processing. It
|
|
enables the client to retrieve a policy declaration from the server, and match
|
|
this with the preferences of the client. However, P3P is not defined for other
|
|
protocols than HTTP. No other mechanisms exist, to our knowledge, to communicate
|
|
policies between client and server. Note, however, the known problem that P3P
|
|
does nothing to enforce the policy - this is assumed to take place out of
|
|
band.</P>
|
|
<H4><A id="p3p-with-http">4.1.2 Using P3P with HTTP</A></H4>
|
|
<P>In the document CC/PP exchange protocol <a
|
|
href="#CCPP-ex">[CCPP-ex]</a> based on HTTP Extension Framework
|
|
<a href="#HTTP-ext">[HTTPext]</a>, a mechanism to transport CC/PP over HTTP is described. This document
|
|
describes how that interaction could take place, given a P3P interaction as
|
|
well.</P>
|
|
<P>Before a policy can be exchanged, the client must request it from a server.
|
|
If this is not a proxy in a trusted domain, the client will expose his profile
|
|
to a possibly malicious party if the CC/PP Exchange Protocol is used, since the
|
|
profile is sent in its entirety with the first GET request. Thus, a malicious
|
|
server could take this profile and do anything it wanted with it, since no
|
|
relationship has been established.</P>
|
|
<P>One solution to this is to transmit a minimal profile as part of the first
|
|
request, as described in <a href="#pemi">[PEMI]</a>. When the policy has been received and approved,
|
|
a full profile is sent (as a profile-diff). Note that if the policy is rejected,
|
|
there is currently no way for the server to maintain a state over users
|
|
requests, and there is no way for the server to recognize that the client does
|
|
not approve of the policy, since there is no fallback method in P3P.</P>
|
|
<P>Note that it is possible for the profile declared to be a null profile (i.e.
|
|
without content), and the correct profile to be transferred as a diff upon
|
|
approval of the servers policy. Note also that the state management mechanism in
|
|
the server is currently is not specified. It should be possible to use cookies
|
|
for this, although the ramifications of a discussion of this would lead too
|
|
far.</P>
|
|
<P>The interaction with P3P might have two levels of granularity:</P>
|
|
<P>a) where the privacy policy includes all CC/PP vocabulary [generic statement
|
|
stating that all data in the profile and profile diff headers will not be
|
|
retained or misused, or will be used only for the purposes of content
|
|
customization]</P>
|
|
<P>b) where the policy specifically states what attributes (data elements) from
|
|
the CC/PP vocabulary is collected and state the purpose. This can be extended at
|
|
a later date to include negotiation capabilities (which is currently out of the
|
|
scope of P3P1.0) or alternately, the user agent can be smart enough to parse
|
|
these elements out and send only those attributes (as indicated in the policy)
|
|
in the profile and profile diff headers following the acceptable of the site's
|
|
policy.</P>
|
|
<H5><A id="p3p-ccpp" name="p3p-ccpp">4.1.2.1 P3P and CC/PP
|
|
vocabularies</A></H5>
|
|
<P>The P3P vocabulary is defined in XML. The CC/PP vocabularies are defined in
|
|
RDF (using the XML encoding of RDF). The P3P specification <a
|
|
href="#P3P">[P3P]</a> declares that
|
|
an RDF encoding will be made available; when this happens, P3P elements can be
|
|
used inside CC/PP profiles (and vice versa). For further information on mixing
|
|
namespaces in profiles, see <a href="#CCPP">[CCPP]</a> and <a href="#CCPP-vocab">[CCPP-vocab]</a>. Since this effort has been
|
|
advertised, the CC/PP working group has decided not to create any mapping of
|
|
their own, but await the P3P working group efforts. An alternative solution is
|
|
to create a CC/PP data schema in the P3P syntax, but that would seem redundant
|
|
if an RDF version of P3P is forthcoming. The two working groups will continue to
|
|
investigate this. </P>
|
|
<P>4.1.2.2 Safe Zone</P>
|
|
<P>The P3P specification defines a concept of a "safe zone". This concept does
|
|
not exist a priori in CC/PP, since no protocol has been defined. However, the
|
|
PIMI method as described in section 5.1 can be used to provide a safe zone in
|
|
the way that is indicated in the P3P specification, section 2.4.3. As noted
|
|
above, an empty profile can be used while negotiating within the safe zone,
|
|
instead of a minimal one. </P>
|
|
<P>4.1.2.3 APPEL</P>
|
|
<P>No rules language is defined for CC/PP. Existing implementations make use of
|
|
XSLT to predicate transformations (using Xpath, profile documents can be
|
|
addressed from within a style sheet). In the future, it is foreseen that there
|
|
will be a need for a more extensive rule system, such that decisions can concern
|
|
not just the formatting, but the content itself as well. In that regard,
|
|
synergies with the APPEL rules language for P3P could be investigated.</P>
|
|
<H3><a id="trused-interm" name="trusted-interm"></a>
|
|
4.2 Use of trusted intermediaries</H3>
|
|
<P>In the CC/PP Exchange protocol, profiles can be referenced and retrieved by
|
|
an intermediary (a gateway or other proxy). It is also possible that this entity
|
|
could handle the P3P negotiations, if a mechanism to delegate authority to it
|
|
existed, and end-to-end security was not required. This may occur in situations
|
|
where the user is in a trusted domain, which is interfaced with the Internet
|
|
through the proxy or gateway.</P>
|
|
<P>In this case, the P3P negotiation will be terminated in the proxy. It will
|
|
also be necessary for the proxy not just to keep a cache of documents, but to
|
|
maintain a database of user state. It may even be necessary for the proxy to
|
|
become the entity which performs not just transcoding, but also personalization
|
|
on behalf of the origin server.</P>
|
|
<P>The advantage for the user of this would be that the personal information -
|
|
including the CC/PP profile - stays in the trusted proxy. The advantage for the
|
|
origin server owner is harder to identify, since the version of the document
|
|
which has to be delivered will have to be "universal", and there will not be any
|
|
record of the number of retrievals, who retrieved it, etc (which, conversely,
|
|
can be seen as a privacy enhancement for the user).</P>
|
|
<P>As this type of system continues to emerge, e.g. in the scope of the IETF
|
|
WEBI and APEX working groups, we foresee that the issue will become more
|
|
important. However, since the mechanism is transparent to HTTP, and since it can
|
|
be for CC/PP, we will not discuss it to any further extent here.</P>
|
|
<H2><A id="example" name="example">5. Examples</A></H2>
|
|
<H3><A id="p3p-ccpp-exchange" name="p3p-ccpp-exchange">5.1 Using P3P with CC/PP Exchange Protocol using
|
|
the</A><A href="http://www.cs.kau.se/~helena/research/pimi.pdf">PIMI</A>
|
|
method</H3>
|
|
<P>The idea behind the PIMI method is that the client has defined a minimal
|
|
profile with non-contentious information (which cannot be used to infringe on
|
|
the privacy of the client). This minimal profile is used in an initial request
|
|
to get the privacy policy of the server. As demonstrated below, using the
|
|
profile-diff headers of the CC/PP Exchange protocol, it becomes possible for the
|
|
client to signal satisfaction or dissatisfaction with the policy by returning a
|
|
profile difference or not. In response to the empty diff, the server can provide
|
|
a document which does not contain the adaption which would have been done using
|
|
the information which the client will not reveal.</P>
|
|
<P>What constitutes a "minimal profile" is most likely subjective. Ultimately,
|
|
the user will have to determine what information he or she wants to give out.
|
|
However, for the purposes of discussion, we will assume that the properties
|
|
which enable a generic display and data input on the device, without expressing
|
|
any preferences and without any modifications, will constitute a minimum. That
|
|
would imply the following, using the properties defined by the WAP UAProf
|
|
drafting committee:</P>
|
|
<P><EM>Screen size</EM></P>
|
|
<P><EM>Color capable</EM></P>
|
|
<P>In this document, we propose that an empty diff be sent as response (in a
|
|
second GET), which would imply that the profile has not changed. Depending on
|
|
the implementation, the server could return a document containing a different
|
|
information set than the user would have got if he had accepted the policy; or
|
|
returned nothing. This is not specified in the P3P specification, and out of
|
|
scope for the CC/PP work.</P>
|
|
<P>This would apply when the client initially contacted the server during a
|
|
session. During the rest of the session, it would be able to refer to the policy
|
|
first retrieved, or to follow-up policies which can be added later during a
|
|
session (using the LINK tag in HTTP, using a well-known location, or an HTTP
|
|
header).</P>
|
|
<P>The interactions would look as follows:</P>
|
|
<P>1. Client sends request with minimal profile to server. This request can be
|
|
directed to the well-known location of the P3P reference file, /w3c/p3p.xml. It
|
|
can also be directed at another location, if this has been indicated in a LINK
|
|
tag in a document that references this server. The reference file is returned.
|
|
After that, another request will retrieve the policy file. </P>
|
|
<P>2. Server returns policy.</P>
|
|
<P>3. Client reads policy and matches against own rule set</P>
|
|
<P>3'. Client approves policy, sends diff with full information (or a GET with
|
|
full information directed at the URI where the document resides, if the policy
|
|
was retrieved from the well-known or LINK-ed location).</P>
|
|
<P>4'. Client receives document</P>
|
|
<P>3". Client rejects policy, resends request with empty diff</P>
|
|
<P>4". Client receives less important document.</P>
|
|
<P>With protocol interactions, this would look as follows:</P>
|
|
<P><EM>1. Client sends request with minimal profile to server.</EM></P><PRE> GET /a-resource HTTP/1.1
|
|
Host: www.w3.org
|
|
Opt: "http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19
|
|
19-Profile: "http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
|
|
Accept: */*
|
|
Accept-Language: de, en</PRE>
|
|
<P><EM>2. Server returns policy.</EM></P><PRE> HTTP/1.1 200 OK
|
|
P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"
|
|
Content-Type: text/html
|
|
Content-Length: 7413
|
|
Server: CC-Galaxy/1.3.18</PRE>
|
|
<P><EM>3. Client reads policy and matches against own rule set</EM></P>
|
|
<P>(not shown)</P>
|
|
<P><EM>3'. Client approves policy, sends diff with full information</EM></P><PRE> GET /a-resource HTTP/1.1
|
|
Host: www.w3.org
|
|
Opt:"http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19
|
|
19-Profile:"http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
|
|
19-Profile-Diff-1: <?xml version="1.0"?>
|
|
<RDF xmlns="http://www.w3.org/TR/PR-rdf-syntax"
|
|
xmlns:PRF="http://www.example.org/TR/WD-profile-vocabulary#">
|
|
<Description ID="SoftwarePlatform" PRF:Sound="On" />
|
|
</RDF></PRE>
|
|
<P><EM>4'. Client receives document</EM></P>
|
|
<P>(not shown)</P>
|
|
<P><EM>3". Client rejects policy, resends request with empty diff</EM></P><PRE> GET /a-resource HTTP/1.1
|
|
Host: www.w3.org
|
|
Opt:"http://www.w3.org/TR/NOTE-CCPPexchange" ; ns=19
|
|
19-Profile:"http://www.aaa.com/hw","http://www.bbb.com/sw","1-uKhJE/AEeeMzFSejsYshHg=="
|
|
19-Profile-Diff-1: </PRE>
|
|
<P><EM>4". Client receives less important document</EM></P>
|
|
<P>(not shown)</P>
|
|
<P><EM></EM></P>
|
|
<HR>
|
|
|
|
<H2><A id="References" name="References">6. References</A></H2>
|
|
<P><A id="HTTP-ext" name="HTTPext">[HTTPext]</A> <A
|
|
href="http://www.w3.org/Protocols/HTTP/ietf-http-ext/draft-frystyk-http-extensions-03.txt">HTTP
|
|
Extension Framework</A></P>
|
|
<P><A id="HTTP-1.1" name="HTTP-1.1">[HTTP/1.1]</A> <A
|
|
href="http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt">HTTP/1.1,
|
|
Rev6</A></P>
|
|
<P><A id="CCPP" name="CCPP">[CC/PP]</A> <A
|
|
href="http://www.w3.org/TR/NOTE-CCPP">Composite Capability/Preference Profiles
|
|
(CC/PP): A user side framework for content negotiation</A></P>
|
|
<P><A id="RDF" name="RDF">[RDF]</A> <A
|
|
href="http://www.w3.org/TR/REC-rdf-syntax">Resource Description Framework, (RDF)
|
|
Model and Syntax Specification</A></P>
|
|
<P><A id="RDF-Schema" name="RDF-Schema">[RDF-Schema]</A> <A
|
|
href="http://www.w3.org/TR/WD-rdf-schema">Resource Description Framework (RDF)
|
|
Schema Specification</A></P>
|
|
<P><A id="P3P" name="P3P">[P3P]</A> <A href="http://www.w3.org/P3P/">Platform
|
|
for Privacy Preferences P3P Project</A></P>
|
|
<!--
|
|
<P><A id="P3P-Syntax" name="P3P-Syntax1">[P3P-Syntax]</A> <A
|
|
href="http://www.w3.org/TR/WD-P3P/syntax.html">Platform for Privacy
|
|
Preferences [P3P] Syntax Specification</A></P>
|
|
-->
|
|
<P><A id="RFC2396" name="RFC2396">[RFC2396]</A> <A
|
|
href="http://info.internet.isi.edu/rfc/rfc2396.txt">RFC 2396 :
|
|
Uniform Resource Identifiers (URI): Generic Syntax</A></P>
|
|
<!--
|
|
<P><A id="RFC2119" name="RFC2119">[RFC2119]</A> <A
|
|
href="http://info.internet.isi.edu/rfc/rfc2119.txt">RFC 2119 :
|
|
Key words for use in RFCs to Indicate Requirement Levels</A></P>
|
|
-->
|
|
<!--
|
|
<P>[IOTP] <A
|
|
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-protocol-06.txt">Internet
|
|
Open Trading Protocol - IOTP Version 1.0</A></P>
|
|
<P>[IOTPsig] <A
|
|
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-dsig-03.txt">Digital
|
|
Signatures for the Internet Open Trading Protocol</A></P>
|
|
<P>[DOMHASH] <A
|
|
href="ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-hiroshi-dom-hash-03.txt">Digest
|
|
Values for DOM (DOMHASH)</A></P>
|
|
-->
|
|
<P><a id="CCPP-ex" name="CCPP-ex">[CCPP-ex]</a> <A href="http://www.w3.org/TR/NOTE-CCPPexchange">CC/PP exchange
|
|
protocol based on HTTP Extension Framework</A></P>
|
|
<P><a id="pemi" name="pemi">[PEMI]</a> <A href="http://www.cs.kau.se/~helena/research/pimi.pdf">Privacy
|
|
Enhancements in the Mobile Internet, Mikael Nilsson, Helena Lindskog, Simone
|
|
Fischer-Huebner, Karlstad University.(PDF format)</A></P>
|
|
<P><a id="CCPP-vocab">[CCPP-vocab]</a> W3C Note, CC/PP Implementers Guide
|
|
Harmonization with Existing Vocabularies and Content Transformation Heuristics, to be appeared.</p>
|
|
<HR>
|
|
|
|
<P>Appendix</P>
|
|
<H1><a id="req-turst-frame" name="req-trust-frame"></a>
|
|
Basic requirements for trust management frameworks</H1>
|
|
<H3><a id="basic-req" name="basic-req"></a>
|
|
A.1 Basic requirements</H3>
|
|
<P>The basic requirements for the CC/PP trust management framework, which were
|
|
discussed in the 1999 version of this document, are listed below.</P>
|
|
<OL>
|
|
<LI>A client must be able to discover the privacy practices of an origin
|
|
server before revealing private profile information
|
|
<LI>The privacy mechanism must be separable from CC/PP framework so that the
|
|
user has a choice of whether or not privacy mechanism is to be
|
|
used. In other
|
|
|
|
words, enable CC/PP content negotiation with or without privacy
|
|
<LI>The protocol must allow each client individually to determine what
|
|
information is private<BR>Any or all of the profile can be considered private.
|
|
What may be a private piece of information for one user may not be so for
|
|
another.
|
|
<LI>Since CC/PP is protocol independent, the privacy mechanism should also be
|
|
supported on various transport protocols (including HTTP, MIME, SMTP etc)
|
|
<LI>A client must be able to interact with a server to the point of
|
|
discovering its privacy policy without having to disclose any particular item
|
|
of information.
|
|
<P>For example, a user agent first sends non-private profile data to a server,
|
|
which then responds with a privacy policy, as a result of which, the user
|
|
agent may either choose to send or not send any additional (private)
|
|
information to the server for the purposes of receiving tailored content.</P>
|
|
<LI>It should be possible for the origin server to render content best effort,
|
|
if the private information is not shared by the user.
|
|
<LI>Intermediate proxies, servers and gateways asserting profile data must
|
|
also honor the privacy needs of the user. In other words, if the user deems a
|
|
profile attribute to be private, an intermediate proxy must not disclose that
|
|
attribute in its profile diff.
|
|
<LI>May require user-agent side privacy capability (e.g. P3P user agents) must
|
|
be supported by such servers/ proxies/ gateways.
|
|
<LI>As with CC/PP mechanism, the private profile must also support.
|
|
<UL>
|
|
<LI>additions and overrides by other network elements as specified in the
|
|
CC/PP specs
|
|
<LI>inline or URI (indirect) references to the profile information </LI></UL>
|
|
<LI>the privacy mechanism should support the split client model.<BR>Thin
|
|
clients such as for low-end devices (on a mobile network for example), may not
|
|
be able to support the necessary mechanism for privacy (e.g. P3P user agent)
|
|
perhaps due to overhead. Such a function should be enabled on a gateway or
|
|
proxy that acts on behalf of the thin client. [is this within the scope of our
|
|
work?]
|
|
<LI>Any requirements relative to P3P policy asserted by servers to be in XML
|
|
versus RDF formats?
|
|
<LI>The privacy mechanism must be independent of and separable from security
|
|
mechanisms. In other words, it should be possible to transmit private CC/PP
|
|
profile information with or without security.
|
|
<LI>The combined system of capability profiles and privacy practice
|
|
declarations must work in the presence of information caches without leaking
|
|
private information to parties who have not agreed to treat it properly.
|
|
</LI></OL>
|
|
<H3><A id="p3p-req-trust" name="p3p-req-trust">A.2 P3P and the requirements for the trust
|
|
mechanism</A></H3>
|
|
<P>This is an analysis of how the proposed use of P3P would fulfill the basic
|
|
requirements for the CC/PP trust management framework (section 3).</P>
|
|
<OL>
|
|
<LI>A client must be able to discover the privacy practices of an origin
|
|
server before revealing private profile information
|
|
<P><EM>Fulfilled, provided no private information is transmitted..</EM></P>
|
|
<LI>The privacy mechanism must be separable from CC/PP framework so that the
|
|
user has a choice of whether or not privacy mechanism is to be used. In other
|
|
words, enable CC/PP content negotiation with or without privacy
|
|
<P><EM>Protocol dependent. Not possible in the examples given.</EM></P>
|
|
<LI>The protocol must allow each client individually to determine what
|
|
information is private<BR>Any or all of the profile can be considered private.
|
|
What may be a private piece of information for one user may not be so for
|
|
another.
|
|
<P><EM>Fulfilled, provided APPEL, a similar rules language, or a proprietary
|
|
solution in the device, can be applied to profile construction (or various
|
|
profiles can be selected). I.e. not in this version.</EM></P>
|
|
<LI>Since CC/PP is protocol independent, the privacy mechanism should also be
|
|
supported on various transport protocols (including HTTP, MIME, SMTP etc)
|
|
<P><EM>Not fulfilled (P3P can be used with other protocols than HTTP, as noted
|
|
in the specification, but how has not been specified). .</EM></P>
|
|
<LI>A client must be able to interact with a server to the point of
|
|
discovering its privacy policy without having to disclose any particular item
|
|
of information.
|
|
<P>For example, a user agent first sends non-private profile data (or an empty
|
|
profile) to a server, which then responds with a privacy policy, as a result
|
|
of which, the user agent may either choose to send or not send any additional
|
|
(personal) information to the server for the purposes of receiving tailored
|
|
content.</P>
|
|
<P><EM>Fulfilled.</EM></P>
|
|
<LI>It should be possible for the origin server to render content best effort,
|
|
if the private information is not shared by the user.
|
|
<P><EM>Fulfilled</EM></P>
|
|
<LI>Intermediate proxies, servers and gateways asserting profile data must
|
|
also honor the privacy needs of the user. In other words, if the user deems a
|
|
profile attribute to be private, an intermediate proxy must not disclose that
|
|
attribute in its profile diff.
|
|
<P><EM>Fulfilled, if the method above is used..</EM></P>
|
|
<LI>May require user-agent side privacy capability (e.g. P3P user agents) must
|
|
be supported by such servers/ proxies/ gateways.
|
|
<P><EM>Fulfilled (although this is actually a strange requirement)</EM></P>
|
|
<LI>As with CC/PP mechanism, the private profile must also support.
|
|
<UL>
|
|
<LI>additions and overrides by other network elements as specified in the
|
|
CC/PP specs
|
|
<LI>inline or URI (indirect) references to the profile information </LI></UL>
|
|
<P><EM>Not fulfilled.</EM></P>
|
|
<LI>The privacy mechanism should support the split client model.<BR>Thin
|
|
clients such as for low-end devices (on a mobile network for example), may not
|
|
be able to support the necessary mechanism for privacy (e.g. P3P user agent)
|
|
perhaps due to overhead. Such a function should be enabled on a gateway or
|
|
proxy that acts on behalf of the thin client. [is this within the scope of our
|
|
work?]
|
|
<P><EM>Fulfilled? (Not sure)</EM></P>
|
|
<LI>Any requirements relative to P3P policy asserted by servers to be in XML
|
|
versus RDF formats?
|
|
<P><EM>Not sure what this requirement means.</EM></P>
|
|
<LI>The privacy mechanism must be independent of and separable from security
|
|
mechanisms. In other words, it should be possible to transmit private CC/PP
|
|
profile information with or without security.
|
|
<P><EM>Fulfilled.</EM></P>
|
|
<LI>The combined system of capability profiles and privacy practice
|
|
declarations must work in the presence of information caches without leaking
|
|
private information to parties who have not agreed to treat it properly.
|
|
<P><EM>Not fulfilled (since proxies can still be
|
|
transparent).</EM></P></LI></OL>
|
|
|
|
<hr>
|
|
<p>
|
|
<a href="http://validator.w3.org/check/referer"><img border="0"
|
|
src="http://www.w3.org/Icons/valid-html401"
|
|
alt="Valid HTML 4.01!" height="31" width="88"></a>
|
|
</p>
|
|
|
|
</BODY></HTML>
|