W3C

CC/PP Implementors Guide:
Privacy and Protocols

W3C Working Draft 20 December 2001

This Version:
http://www.w3.org/TR/2001/WD-CCPP-trust-20011220/
Latest Version:
http://www.w3.org/TR/CCPP-trust
Previous Version:
None
Editors:
Hidetaka Ohto < ohto@w3.org>, W3C/Panasonic
Lalitha Suryanarayana <mailto:lalitha@tri.sbc.com >, SBC
Johan Hjelm < johan.hjelm@nrj.ericsson.se>, Ericsson Research Japan

Abstract

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.

Status of this document

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.

1. Introduction

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.

2. Scope of this document

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

3.3 XML Protocol/SOAP

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.

4.Use Cases

4.1 HTTP use case

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.

4.1.1 Trust mechanisms

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.

4.1.2 Using P3P with HTTP

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.

4.1.2.1 P3P and CC/PP vocabularies

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.

5. Examples

5.1 Using P3P with CC/PP Exchange Protocol using thePIMI method

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)


6. References

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

  1. A client must be able to discover the privacy practices of an origin server before revealing private profile information
  2. 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
  3. 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.
  4. Since CC/PP is protocol independent, the privacy mechanism should also be supported on various transport protocols (including HTTP, MIME, SMTP etc)
  5. 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.

  6. It should be possible for the origin server to render content best effort, if the private information is not shared by the user.
  7. 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.
  8. May require user-agent side privacy capability (e.g. P3P user agents) must be supported by such servers/ proxies/ gateways.
  9. As with CC/PP mechanism, the private profile must also support.
  10. 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?]
  11. Any requirements relative to P3P policy asserted by servers to be in XML versus RDF formats?
  12. 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.
  13. 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.

A.2 P3P and the requirements for the trust mechanism

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

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

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

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

  4. 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). .

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

  6. It should be possible for the origin server to render content best effort, if the private information is not shared by the user.

    Fulfilled

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

  8. 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)

  9. As with CC/PP mechanism, the private profile must also support.

    Not fulfilled.

  10. 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)

  11. Any requirements relative to P3P policy asserted by servers to be in XML versus RDF formats?

    Not sure what this requirement means.

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

  13. 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).


Valid HTML 4.01!