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.
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.
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
http://www.w3.org/TR/.
This document is produced by the
CC/PP working group (member only) (part of the
Device Independence activity).
The working group welcomes feedback and discussion,
preferably on the public mailing list www-mobile@w3.org, although
comments may also be sent to the authors.
Public comments and their responses can be accessed at
http://lists.w3.org/Archives/Public/www-mobile/.
Table of Contents
Not included in this version.
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.
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.
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.
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.
CC/PP is an abbreviation of "Composite Capability/Preference Profiles", and
is an extensible format based on RDF [RDF]
[RDF-Schema]
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.
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.
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.
3. Protocol and transport issues.
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.
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).
There are two main ways of transporting CC/PP over HTTP: Using the CC/PP
Exchange Protocol, or using the UAProf W-HTTP Protocol.
3.1 CC/PP Exchange Protocol
The CC/PP Exchange Protocol (CCPP-ex) was presented as a W3C Note on June 24,
1999. It uses the HTTP Extension Framework [RFC2396].
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 Kiniko
Yasuda of Keio University.
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 "CC/PP exchange protocol based on
HTTP Extension Framework".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The Profile header field is a request-header field, which conveys a list of
references which address CC/PP descriptions.
The grammar for the Profile header field is as follows:
| Header field |
Grammar |
| Profile |
= profile-field-name ":" 1#reference |
| profile-field-name |
= "Profile" |
| reference |
= <"> ( absoluteURI | profile-diff-name ) <"> |
| profile-diff-name |
= profile-diff-number "-" profile-diff-digest |
| profile-diff-number |
= 1#DIGIT |
| profile-diff-digest |
= sp; < MD5 message digest encoded by base64 > |
| DIGIT |
= <any US-ASCII digit "0".."9"> |
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.
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.
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.
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.
3.2 W-HTTP
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
this
specification. The CC/PP Framework remains unaltered. The defined mechanism
provides a functional equivalent for the CC/PP exchange protocol [CCPP-ex] but
the definition of the syntax and semantics of the transport remains in this
specification.
3.2.1 Using W-HTTP to transport CC/PP
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..
3.2.1.1 X-WAP-PROFILE
The x-wap-profile header is a general header field which MUST contain the
following :
·a URI referencing the CC/PP profile, or
·a reference to a profile difference, transported using the
x-wap-profile-diff or
·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.
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.
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.
3.2.1.2. X-WAP-PROFILE-DIFF
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.
3.2.1.3. X-WAP-PROFILE-WARNING
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 :
·1xx - reserved
·100 -- reserved
·2xx - indicates whether the content has been adapted depending on the
profile
·5xx - indicates the server is incapable of processing CPI.
The x-wap-profile-warning may have the following values.
200Not applied
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.
201Content selection applied
MUST be included if the included content has been selected from one of the
representations available.
202 Content generation applied
MUST be included if the content has been tailored or generated as a result of
applying the included profile.
203 Transformation applied
MUST be added by an intermediate proxy if it applies any transformation
changing the content-coding based on the CPI data.
500Not Supported
Indicates that the entity sending this warning code does not support
UAProf.
3.2.1.4. Protocol Procedures
3.2.1.4.1. Over The Air
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.
3.2.1.4.2. Combining X-WAP-Profile and X-WAP-Profile-Diff
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.
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.
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.
3.2.1.5. Relationship with HTTP Headers
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.
3.2.1.5.1. Caching
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 [HTTP/1.1].
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.
3.4 Other protocols
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.
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.
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, P3P 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.
In the document CC/PP exchange protocol [CCPP-ex] based on HTTP Extension Framework
[HTTPext], 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.
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.
One solution to this is to transmit a minimal profile as part of the first
request, as described in [PEMI]. 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.
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.
The interaction with P3P might have two levels of granularity:
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]
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.
The P3P vocabulary is defined in XML. The CC/PP vocabularies are defined in
RDF (using the XML encoding of RDF). The P3P specification [P3P] 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 [CCPP] and [CCPP-vocab]. 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.
4.1.2.2 Safe Zone
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.
4.1.2.3 APPEL
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.
4.2 Use of trusted intermediaries
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.
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.
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).
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.
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.
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:
Screen size
Color capable
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.
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).
The interactions would look as follows:
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.
2. Server returns policy.
3. Client reads policy and matches against own rule set
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).
4'. Client receives document
3". Client rejects policy, resends request with empty diff
4". Client receives less important document.
With protocol interactions, this would look as follows:
1. Client sends request with minimal profile to server.
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
2. Server returns policy.
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
3. Client reads policy and matches against own rule set
(not shown)
3'. Client approves policy, sends diff with full information
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>
4'. Client receives document
(not shown)
3". Client rejects policy, resends request with empty diff
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:
4". Client receives less important document
(not shown)
[HTTPext] HTTP
Extension Framework
[HTTP/1.1] HTTP/1.1,
Rev6
[CC/PP] Composite Capability/Preference Profiles
(CC/PP): A user side framework for content negotiation
[RDF] Resource Description Framework, (RDF)
Model and Syntax Specification
[RDF-Schema] Resource Description Framework (RDF)
Schema Specification
[P3P] Platform
for Privacy Preferences P3P Project
[RFC2396] RFC 2396 :
Uniform Resource Identifiers (URI): Generic Syntax
[CCPP-ex] CC/PP exchange
protocol based on HTTP Extension Framework
[PEMI] Privacy
Enhancements in the Mobile Internet, Mikael Nilsson, Helena Lindskog, Simone
Fischer-Huebner, Karlstad University.(PDF format)
[CCPP-vocab] W3C Note, CC/PP Implementers Guide
Harmonization with Existing Vocabularies and Content Transformation Heuristics, to be appeared.
Appendix
Basic requirements for trust management frameworks
A.1 Basic requirements
The basic requirements for the CC/PP trust management framework, which were
discussed in the 1999 version of this document, are listed below.
- A client must be able to discover the privacy practices of an origin
server before revealing private profile information
- 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
- The protocol must allow each client individually to determine what
information is private
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.
- Since CC/PP is protocol independent, the privacy mechanism should also be
supported on various transport protocols (including HTTP, MIME, SMTP etc)
- 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.
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.
- It should be possible for the origin server to render content best effort,
if the private information is not shared by the user.
- 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.
- May require user-agent side privacy capability (e.g. P3P user agents) must
be supported by such servers/ proxies/ gateways.
- As with CC/PP mechanism, the private profile must also support.
- additions and overrides by other network elements as specified in the
CC/PP specs
- inline or URI (indirect) references to the profile information
- the privacy mechanism should support the split client model.
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?]
- Any requirements relative to P3P policy asserted by servers to be in XML
versus RDF formats?
- 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.
- 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.
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).
- A client must be able to discover the privacy practices of an origin
server before revealing private profile information
Fulfilled, provided no private information is transmitted..
- 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
Protocol dependent. Not possible in the examples given.
- The protocol must allow each client individually to determine what
information is private
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.
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.
- Since CC/PP is protocol independent, the privacy mechanism should also be
supported on various transport protocols (including HTTP, MIME, SMTP etc)
Not fulfilled (P3P can be used with other protocols than HTTP, as noted
in the specification, but how has not been specified). .
- 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.
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.
Fulfilled.
- It should be possible for the origin server to render content best effort,
if the private information is not shared by the user.
Fulfilled
- 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.
Fulfilled, if the method above is used..
- May require user-agent side privacy capability (e.g. P3P user agents) must
be supported by such servers/ proxies/ gateways.
Fulfilled (although this is actually a strange requirement)
- As with CC/PP mechanism, the private profile must also support.
- additions and overrides by other network elements as specified in the
CC/PP specs
- inline or URI (indirect) references to the profile information
Not fulfilled.
- The privacy mechanism should support the split client model.
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?]
Fulfilled? (Not sure)
- Any requirements relative to P3P policy asserted by servers to be in XML
versus RDF formats?
Not sure what this requirement means.
- 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.
Fulfilled.
- 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.
Not fulfilled (since proxies can still be
transparent).
