OPES Working Group                                         A. Barbir
   Internet Draft                                            N. Bennett
   Document: draft-barbir-opes-fsp-02.txt                      R. Penno
                                                        Nortel Networks

   H. T. Pham                                                  R. Menon
   Alcatel                                                        Intel

   J. Mysore                                                S. Sengodan
   Motorola                                                       Nokia

                                                              June 2002


                  A Framework for Service Personalization


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

   Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.

Abstract

   This document discusses a Framework for Service Personalization
   (FSP) defined within the bounds of the Open Pluggable Edge Services
   (OPES) Framework. The work described here aims to provide a
   Framework and Protocols for the delivery of the optimal content
   variant for a given requestor based on subscriber profile and
   policies, content profile and its associated policies. This document
   provides a general outline of FSP that could be used as a vehicle
   for performing personalization services in edge and intermediary
   devices or at Content origins.



   Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002

               A Framework for Service Personalization

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Conventions used in this document..................................3
   1. Introduction....................................................3
   2. Definitions and Terminology.....................................4
   3. What is Service Personalization?...............................10
   3.1 Service Personalization at the Content Source.................12
   3.2 Service Personalization at the User Agent.....................13
   3.3 Service Personalization at the Network Edge...................14
   3.4 Service Personalization at Intermediaries.....................15
   3.4.1 Service Personalization at Caching Proxies..................16
   3.4.2 Service Personalization at Surrogates.......................17
   3.5 Hybrid approaches to Service Personalization..................18
   3.6 Goals of FSP..................................................19
   3.7 Subscriber and Content Profiles...............................19
   3.8 Content Selection.............................................20
   3.9 Quality of Delivery (Origin Server Selection ?)...............21
   3.10 Privacy and Security.........................................22
   4. Security Considerations - Security Threats and Mechanisms......23
   4.1 Threat Analysis...............................................23
   4.1.1 Malicious entity accesses subscriber profile................23
   4.1.2 Malicious entity modifies subscriber profile................23
   4.1.3 Eavesdropping on a subscriber profile in transit............24
   4.1.4 Malicious entity accesses content profile...................24
   4.1.5 Malicious entity modifies content profile...................24
   4.1.6 Eavesdropping on a content profile in transit...............24
   4.1.7 Authorized entity later repudiates a request................24
   4.2 Security Mechanisms...........................................25
   4.2.1 Application layer security designed for FSP.................25
   4.2.2 S/MIME and PGP..............................................25
   4.2.3 TLS.........................................................25
   4.2.4 IPSec.......................................................25
   5. Related Personalization Developments...........................25
   5.1 The Liberty Alliance and Microsoft Passport...................26
   6. Acknowledgments................................................26
   7. References.....................................................27
   8. Authors' Addresses.............................................27
   9. Full Copyright Statement.......................................29

   Barbir, et al.       Expires December 2002                [Page 2]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC-2119].

1. Introduction

   In the Internet today, personalization and profiling services are
   provided to subscribers by portals. Portals usually require
   subscribers to log on to their sites, which helps to identify the
   subscriber. Portals usually perform subscriber profiling by tracking
   their habits and preferences. In order to be able to create accurate
   subscriber profiles, the portals must rely on co-located subscriber
   identification and profiling from participating web sites.

   Current schemes for providing personalization services rely on
   piecemeal subscriber identification and profiling. The schemes
   require the subscriber to repeatedly log on to various portals or
   web sites, since each portal has a finite number of web sites with
   which it has arrangements to share subscriber information. As a
   consequence, subscriber information gets duplicated in various
   locations across the Internet, in a number of different formats.

   At least two major initiatives are addressing some aspects of
   personalization services, primarily focusing on various aspects of
   purchasing goods and services over the Internet. The Liberty
   Alliance and Microsoft Corporation's Passport service appear to be
   the two most widely recognized of these initiatives. Section 5.1
   discusses this in more detail.

   A major drawback of current personalization schemes is their
   reliance on content origin web servers to perform the
   personalization tasks. As a consequence content providers need to
   store and manage different content for different subscribers, or
   alternately, there is no storage of content on a per-user basis, but
   rather a large collection of content to choose from based on
   personal profiles and other criteria. This approach leads to
   scalability and optimality issues. This is because the
   personalization task is done based on incomplete information about
   the subscriber. The content provider may not be aware of many types
   of information about the subscriber, including geographic location,
   QoS policy, device type, and access rate, which could dramatically
   increase the efficiency of any personalization task undertaken on
   their behalf. A potential solution to this problem is to shift
   responsibility for personalizing content to an intermediary device.
   This has many advantages over current solutions, and represents an
   important value-added service that could be provided by network edge
   caching proxies or other intermediary devices.


   Barbir, et al.       Expires December 2002                [Page 3]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Network edge caching proxies are currently deployed in the Internet
   in order to accelerate web content delivery, reduce the load on
   origin servers, and reduce the bandwidth requirements between the
   caching proxy and the content origin. Since these intermediaries
   function as gateways between subscribers and content providers, it
   is possible to use them for intelligent services beyond simple
   caching. Examples of such services include among others [ESFNEP]
   virus scanning, ad insertion, caching of personalized web pages,
   limited client bandwidth adaptation, request filtering, and creation
   of uniform subscriber profiles. In the IETF, OPES [ESFNEP] is
   defining the scope of caching proxies to perform extended services
   at the edge of the network.

   This document and its companion document [CALLOUT] discuss a
   Framework for Service Personalization (FSP) defined within the
   bounds of the Open Pluggable Edge Services (OPES) Framework [O-
   MODEL]. While FSP is defined within the scope of OPES, some effort
   is made within this document to provide insight into general and
   abstract requirements for such a framework. Detailed discussion of
   the implementation of this framework, including analysis of the
   integration of the proposed framework into the larger OPES scope is
   covered in the companion document [CALLOUT]. It should be noted that
   at this stage, these documents are not intended to completely define
   an abstract, implementation-independent FSP, but rather one which
   builds on and functions within the scope of the OPES.

   This document defines the scope of personalization and introduces
   the concept of a Framework for Service Personalization (FSP). This
   framework defines the essential components and mechanisms that are
   needed in order to provide consistent personalization services to
   subscribers, delivering high quality personalized content to
   subscribers in a secure and reliable manner. This document also
   establishes a framework and requirements for developing an OPES FSP
   call-out server. The document is organized as follows: section 2
   defines the terms used throughout the document, section 3 provides
   an overview of FSP, while section 4 discusses security threats and
   mechanisms.

2. Definitions and Terminology

   This section consists of the definitions of a number of terms used
   to refer to the roles, participants, and objects potentially
   involved in FSP implementations. Although the following uses many
   terms employed in [RFC-2616] and [RFC-3040], there is no necessary
   connection to HTTP or web caching technology. FSP and this
   vocabulary are applicable to other protocols and content networks.
   Words enclosed within 'single quotes' are defined terms within this
   document.

   ACTION
   A form of a policy action [RFC-3040] that results in the execution
   of a 'service module' when 'conditions' of a 'rule' are met.

   Barbir, et al.       Expires December 2002                [Page 4]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization


   AUTHORITATIVE DOMAIN
   A logical domain in which the network elements have rights, either
   delegated or inherited, to act authoritatively on behalf of a party
   (typically the content owner or the subscriber). This logical domain
   may be wholly contained within the administrative domain [ESFNEP] of
   the party, or it may be a collection of administrative domains to
   which the party rights have been delegated.

   CACHE (REFERENCE DEFINITION  [RFC-2616])
   A program's local store of response messages and the subsystem that
   controls its message storage, retrieval, and deletion. A cache
   stores cacheable responses in order to reduce the response time and
   network bandwidth consumption on future, equivalent requests. Any
   client or server may include a cache, though a cache cannot be used
   by a server that is acting as a tunnel.


   CACHING PROXY (REFERENCE DEFINITION  [RFC-3040])
   A proxy with a cache, acting as a server to clients, and a client to
   servers. Caching proxies are often referred to as "proxy caches" or
   simply "caches". The term "proxy" is also frequently misused when
   referring to caching proxies.

   CLIENT (REFERENCE DEFINITION  [RFC-2616])
   A program that establishes connections for the purpose of sending
   requests.

   CONDITION
   A form of a policy condition [POLICY] that is an expression, which
   is used to determine whether a 'rule' 'action' should be executed.

   CONTENT CONSUMER
   The 'client' that is the final destination of content delivery.

   CONTENT PATH
   The content path describes the path that content requests and
   responses take through the network. Typically, content requests and
   responses flow between a client, and/or an 'intermediary', and a
   'content server'. Note that the paths of the requests and responses
   may not always be symmetric.

   CONTENT PROFILE
   A content profile consists of a set of elements that describe
   available variants for given content. The profile also includes
   policy information about allowable transformations, adaptations, and
   Digital Rights Management that are applicable for that content. The
   profile can be applicable to a specific piece of content, a set or
   class of content, or an aggregation of content from several
   locations.



   Barbir, et al.       Expires December 2002                [Page 5]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   CONTENT SERVER
   The server from which content is delivered. It may be an 'origin
   server', replica server, 'surrogate' or parent proxy.

   CONTENT SERVICE
   A service operating on and providing a value-add to content.

   DELEGATE
   A 'caching proxy' located near or at the network access point of the
   'user agent', delegated the authority to operate on behalf of, and
   typically working in close co-operation with a group of 'user
   agents'.

   IN-PATH
   In-Path Content Services are within the normal message path of the
   application they are associated with. This may be an Application
   proxy, gateway, or (in the extreme case) one of the end-hosts that
   is party to the application [C-MODEL].

   INTERMEDIARY
   Intermediaries are application gateway devices located in the
   'content path' between 'client' and 'origin server'. 'Caching
   proxies' and 'surrogates' are probably the most commonly known and
   used intermediaries today.

   OPES ADMINISTRATIVE SERVER
   An OPES administrative (or "admin") server performs authentication,
   authorization and accounting (AAA) functions for an OPES 'edge
   services network'. These functions include, but are not limited to,
   downloading of 'proxylets' and 'rule modules' from trusted parties,
   authorization and authentication of 'OPES services', the collection
   of accounting and log data, and other administrative tasks. It must
   be a member of the 'authoritative domain' of the parties for which
   it is authorizing 'content services'. It must also be a member of
   the 'authoritative domain' of the parties on whose behalf it is
   provisioning 'content services'.

   OPES ENGINE
   An OPES engine allows new services to be defined and executed on
   'OPES intermediaries' according to the policies set up by an 'OPES
   admin server'. An OPES engine contains a message parser, and a rule
   processor that reside in the flow of content passing through the
   'OPES intermediary'. Collectively these form a 'PEP'. The 'OPES
   engine' calls 'actions', which reside in either the 'proxylet run-
   time system' or as 'remote call-out stubs'.

   OPES INTERMEDIARY
   An "intermediary" device integrating a compliant 'OPES engine'. OPES
   intermediaries are typically hosted on 'delegates' or 'surrogates'.

   OPES SERVICE

   Barbir, et al.       Expires December 2002                [Page 6]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   An OPES service is an authorized 'content service' performed on a
   message flowing through the 'content path' by a 'OPES service
   module'.

   OPES SERVICE MODULE
   OPES service modules are executable code modules that are executed
   either on the local 'proxylet run-time system' or on the 'remote
   call-out server'.

   ORIGIN SERVER (REFERENCE DEFINITION  [RFC-2616])
   The server on which a given resource resides or is to be created.

   OUT-OF-PATH
   Out-of-Path Content Services are not natively in the transport path
   of an application. In other words, they are not necessarily resident
   (or co-resident) on entities that are natively in the path of
   application flows.

   PCS - PERSONALIZATION CALL-OUT SERVER
   A 'remote call-out server' that performs the task of generating
   dynamic 'rule modules' that are either encoded or could be extracted
   from a 'subscriber profile', and which represent a 'subscriber's
   personalization preferences and subsequently loading them onto the
   appropriate 'OPES admin servers' or 'OPES Engines'.

   PDP See 'policy decision point'.

   PEP See 'policy enforcement point'.

   POLICY DECISION POINT (REFERENCE DEFINITION [POLICY])
   A logical entity that makes policy decisions for itself or for other
   network elements that request such decisions.

   POLICY ENFORCEMENT POINT (REFERENCE DEFINITION [POLICY])
   A logical entity that enforces policy decisions.

   PROXYLET
   A proxylet is 'OPES service module' that runs on the 'OPES
   intermediary' within the 'proxylet run-time system' and provides a
   service on 'content path' requests or responses.

   PROXYLET LIBRARY
   A proxylet library is a library provided to support runtime services
   in the 'proxylet runtime system'.

   PROXYLET META-DATA
   Proxylet meta-data describes the characteristics, features and
   requirements associated with a proxylet. Examples for such meta-data
   are the name of the 'proxylet', its functionality, its version
   number, where to get it, license related information, execution
   environments, etc. The meta-data can physically be separated from

   Barbir, et al.       Expires December 2002                [Page 7]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   the 'proxylet' code, but it must be possible to uniquely associate
   meta-data with 'proxylets' and vice versa.

   PROXYLET PROVIDER
   A proxylet provider is the party that provides the 'proxylet' 'OPES
   service module' to the 'OPES admin server'.

   PROXYLET RUN-TIME SYSTEM
   The local execution environment on an 'OPES intermediary'.
   'Proxylets' execute as local (as opposed to 'remote call-out')
   'actions' within this environment.

   REMOTE CALL-OUT
   A remote procedure call made via a 'remote call-out protocol" to a
   'remote call-out server' that is invoked as the result of an
   'action'.

   REMOTE CALL-OUT PROTOCOL
   The network protocol that encapsulates and transports a 'remote
   call-out' between an 'OPES intermediary' and a 'remote call-out
   server'.

   REMOTE CALL-OUT STUB
   A remote procedure call stub running on the 'OPES intermediary' that
   binds a 'remote call-out' to the 'OPES engine' as 'actions'. The
   stub marshals the 'action' to/from the 'remote call-out protocol'.

   REMOTE CALL-OUT SERVER
   A cooperating server that runs 'OPES service modules' as the result
   of a 'remote call-out'.

   RESOURCE
   A network data object or service that can be identified by a URI.
   Resources may be available in multiple representations ('variants')
   (e.g. multiple languages, data formats, size, resolutions) or vary
   in other ways.

   ROLE (REFERENCE DEFINITION [POLICY])
   An administratively specified characteristic of a managed element
   (for example, an interface). It is a selector for policy rules and
   'rule modules', to determine the applicability of the rule/'rule
   module' to a particular managed element.

   Note: The term "Provisioning Class" has been replaced by 'rule
   module' in the context of this document, as 'rule modules' are
   instances of Provisioning Classes within the OPES application
   domain.

   RULE
   Rules are forms of policy rules [POLICY] that contain 'conditions'
   and 'actions' that are to be executed if the 'conditions' are met.


   Barbir, et al.       Expires December 2002                [Page 8]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   RULE AUTHOR
   The rule author is the party that authors and provides a 'rule
   module' to the 'OPES admin server'.

   RULE MODULE
   A rule module is a form of a policy Provisioning Class [POLICY] that
   contains a set of 'rules' and information about the rule module
   owner. A rule module is either encoded or extracted from a
   'subscriber profile', and represent a 'subscriber's personalization
   preferences.

   SUBSCRIBER
   A human being, or user, using a 'client' or 'user agent' to connect
   to a network in order to make requests for personalized content or
   services.

   SUBSCRIBER PROFILE
   A subscriber profile consists of a set of elements that define a
   'subscriber's personalization preferences. This includes, but is not
   limited to a description of the device capabilities, Quality of
   Service (QOS), access rate, accounting information, content type
   preferences, and policies regarding allowable content. A 'subscriber
   profile' may also include 'rule modules' that allow an OPES engine
   to perform personalization.

   SURROGATE (REFERENCE DEFINITION [RFC-3040])
   A gateway co-located with an origin server, or at a different point
   in the network, delegated the authority to operate on behalf of, and
   typically working in close co-operation with, one or more origin
   servers. Responses are typically delivered from an internal cache.
   Surrogates may derive cache entries from the origin server or from
   another of the origin server's delegates. In some cases a surrogate
   may tunnel such requests. Where close co-operation between origin
   servers and surrogates exists, this enables modifications of some
   protocol requirements, including the Cache-Control directives in
   [RFC-2616]. Such modifications have yet to be fully specified.
   Devices commonly known as "reverse proxies" and "(origin) server
   accelerators" are both more properly defined as surrogates.

   TRIGGER
   See 'condition'.

   USER AGENT  [RFC-2616]
   The client that initiates a request. These are often browsers,
   editors, spiders (web-traversing software "robots"), or other end
   user tools.

   VARIANT (ALSO: CONTENT VARIANT)
   A specific representation of a network data object or service
   (resource) identifiable by a URI. A 'variant' is differentiable from
   other representations of a resource due to language, data format,
   size, resolution or other distinguishing characteristics.

   Barbir, et al.       Expires December 2002                [Page 9]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Editor's note: does each variant have a different URI? The request
   for content (one URI), in combination with the subscriber profile,
   allows the OPES engine to perform personalization, and help select
   the best variant, but the variant may not have an externally visible
   separate URI. Does it matter?

3. What is Service Personalization?

   The end goal of any personalization effort is to enable content
   services on network traffic in a personalized manner. (i.e. "end
   user content that is delivered to clients") Content services can be
   further categorized as being in-path services and out-of-path
   services. Examples of such services include: virus scanning, content
   translation, packet filtering, content adaptation, and others. What
   is desired is some means of allowing subscribers to specify
   explicitly or implicitly which services should be applied to their
   traffic stream, and under what circumstances. The goal of this draft
   is to define an open, extensible means of encoding these subscriber
   preferences, as well as similar preferences on behalf of the content
   owner, and provide a generalized architecture for the application of
   these preferences to subscriber content streams. If necessary, one
   or more languages will be specified or supplied to express these
   preferences. In this regard, such options are already considered
   within OPES.

   Traditionally, in dial-up and other narrowband applications, the
   process of user identification and authentication is closely tied
   with the process of machine identification and participation in a
   network. As a result, many current content services are designed in
   such a way as to perpetuate this link. In the general case (and
   certainly in the broadband case), these two functions are separate
   and distinct, and represent differing characteristics of a user
   session.

   There are, in fact, four different categories of information upon
   which content services are based. These are:

   1) Subscriber Profile Information - Here a subscriber refers to the
     human being in the interaction making use of content services.

   2) Device Information - This includes access device capabilities,
     machine identification, and other factors.

   3) Network Topology/Identification Information - This can include
     information regarding the network path from Subscriber to Content.
     Editor Note: Can this info be considered as the "dynamic" piece of
     "device information"?

   4) Content Profile Information - This includes content metadata and
     other content-related information.


   Barbir, et al.       Expires December 2002               [Page 10]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   There are several levels of differentiated experience that can be
   defined in which the customization of content or content services is
   performed based on knowledge of information or influence in some
   subset of these categories. These levels can be represented in the
   following matrix format:

   ED. NOTE: This is preliminary and needs more work! These
   categorizations are merely an example and need to be hashed out more
   rigorously.

               Subscriber    Device     Network      Content
   Basic           X
   Moderate        X                                    X
   Advanced        X           X                        X
   Total           X           X           X            X

   It should be noted that not all forms of differentiated content or
   content services constitute personalization. Service Personalization
   MUST involve differentiation of content and/or services based on
   user or subscriber information. That is, in order for a given form
   of differentiation of content or content services to be called
   personalized, the differentiation must be performed based at least
   on subscriber information.

   The precise level of service personalization that can be achieved
   depends on where in the network these personalization functions are
   deployed, how much access to information those functions have and
   the scope of influence these functions have over various aspects of
   these information categories.

   Editor Note 1: Check for consistency in terminology - should we say
   "personalization of content" or "service personalization"? Or is it
   truly just "personalization" as it may apply to "services" and
   "content"?

   Editor Note 2: More here on how different places in the content path
   & placement of personalization functions will limit or allow certain
   functions in terms of the level of personalization achieved.

   In general, service personalization can occur at any point in the
   network that has access to the request, the content, the content
   profile, and the subscriber profile (content and subscriber profiles
   are discussed in a subsequent section). Essentially, any point in
   the content path is a potential point at which personalization
   decisions could be made. Logically, the points in the content path
   reduce to the following scenarios for implementing a personalization
   service:
   1) service personalization at the content source
   2) service personalization at the user agent
   3) service personalization at the network edge
   4) service personalization at intermediaries such as caching proxies
     and surrogates

   Barbir, et al.       Expires December 2002               [Page 11]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   5) hybrid service personalization approaches.

   Each of these is discussed in detail in the sections below.

3.1 Service Personalization at the Content Source

   The first option is to perform service personalization at the
   content source. This is akin to the current technique of using
   portal sites to personalize content. A subscriber logs in to the
   portal site, which allows the content source to retrieve the
   subscriber's personal profile and preferences. Content is then
   dynamically constructed at the content source and delivered to the
   subscriber based on those preferences. For relatively small sets of
   content, with a reasonably low number of subscribers, this is a
   cost-effective solution. There are, however several major drawbacks
   to this approach:

   1. This solution does not scale well. As the number of concurrent
     subscribers increases, performance and reliability degrade
     rapidly. This is because the same computing resources that are
     used to generate the content are also being used to deliver the
     content. Determining which data is required for a given dynamic
     content variant, accessing and aggregating the required data,
     invoking any application-specific computing required, and
     appropriately formatting the content for delivery to a subscriber
     is highly compute- and I/O- intensive. In effect, the content
     source becomes the bottleneck in the content path.

   2. Personalized content can only be delivered from sites that have a
     working agreement with the portal. Since explicit registration of
     content sources with the portal is required, the applicability of
     the subscriber profile is severely limited.

   3. Since many such portals exist in the Internet today, subscribers
     are required to authenticate themselves with multiple portals,
     duplicating and maintaining personal preferences in diverse
     locations, which are stored in largely incompatible, un-
     standardized formats, with little or no data sharing between
     portals. As discussed in section 5.1, the Liberty Alliance and
     Microsoft Passport address aspects of this issue.

   4. Because subscriber profiles are stored on the portal, subscribers
     have little or no real control over where information relating to
     their preferences is kept, what information is gathered about
     their usage habits, or what parties have access to that
     information and what they choose to do with it. This raises some
     rather serious privacy concerns.

   5. Since content is personalized at the content source, the
     applicability of delivered content is severely restricted to at
     best a tiny fraction of the overall subscriber audience. This
     restriction is due to the fact that compromises are made in

   Barbir, et al.       Expires December 2002               [Page 12]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

     representing a relatively huge subscriber base with a small number
     of parameters that represent each subscriber. This means that the
     increase in performance nominally provided by caching proxies and
     other intermediaries is largely negated.

   6. As usage increases, the incremental cost in infrastructure at the
     content source to maintain acceptable levels of performance and
     reliability increases rapidly. Such infrastructure includes
     replication of servers and content storage bolstered with load
     balancers and other "data center"/networking equipment to cater to
     increased capacity requirements needed to meet the performance and
     reliability criteria.

   Editor Note: We need to bring out one very critical factor here -
   the extra demands put on content creators/authors to be creative
   enough to ensure that the content that is delivered in various
   personalized forms will actually contain relevant content
   components. The authoring process becomes essentially more complex
   and time consuming.

3.2 Service Personalization at the User Agent

   On the other end of the spectrum (and the content path), one could
   consider personalizing content strictly at the user agent. This has
   some advantages over the first option. Subscriber preferences and
   other information are stored at the user agent, addressing some of
   the more serious privacy concerns of the first option. Also,
   delivered content will be generic in nature, allowing for more
   efficient use of cache technologies. However, these advantages are
   offset by several critical drawbacks:

   1. Little or no subscriber information is available at the content
     source. This precludes virtually any subscriber-specific
     application layer functionality from being used on delivered
     content at the content source. This is potentially crippling for
     the content owners, as it prevents them from providing even the
     most basic level of subscriber awareness to the back-end
     application layer. This restriction alone makes this a trivially
     valuable and unrealistic option.

   2. The content services available to the subscriber are entirely
     determined by the available functionality and capabilities of
     their access device. In many cases (e.g. mobile phones and
     handheld PDAs being prime examples), this restriction is
     prohibitive. Not only do such devices have extremely limited
     computing and display capabilities, but also they are often unable
     to make use of large parts of delivered content. A mobile phone,
     for example, may not even be able to display straightforward HTML,
     let alone high quality images, streaming media, or active content
     technologies. This means that the subscriber is left with
     virtually useless content. Since the rest of the content path is
     completely oblivious to the limitations of such access devices,

   Barbir, et al.       Expires December 2002               [Page 13]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

     very large quantities of useless data will be transferred across
     the network, increasing congestion, and adversely affecting the
     performance and reliability of the network as a whole.

   3. Should the personalization solution be restricted to those access
     devices that are capable of providing meaningful content services,
     a large segment of potential subscribers will be unable to take
     advantage of the added value that personalization delivers.
     Consequently, such a solution would be of marginal value.

   EDITOR'S NOTE: Perhaps some commentary about benefits of this
   scenario should be added.
   Example on benefits: In the case of a certain subset of the
   subscriber class - user agents on powerful desktops/laptops with
   enough compute, storage and network connectivity _ bandwidth etc _
   resources, personalization at the access device may not be a bad
   option. In fact, many of the personalization functions can be
   "offloaded" to these user agents from the content portals; think of
   these user agents as running extensions/"avatars" of the
   portal/content source. Then, these user agents can transmit relevant
   subscriber information back to the portals/sources providing them
   with subscriber information.

3.3 Service Personalization at the Network Edge

   The network edge, where the subscriber access network meets the rest
   of the Internet, presents a somewhat more promising potential
   location for the implementation of personalization services. Several
   clear advantages exist over the scenarios previously discussed.

   1. A trust relationship already exists between the subscriber and
     their ISP. The ISP is already responsible for authenticating the
     user, authorizing their access to the Internet, and gathering
     accounting data related to their service usage. Furthermore, by
     necessity, the ISP has pre-existing facilities for storing and
     securing subscriber-specific data, and for guaranteeing an agreed-
     upon level of privacy.

   2. Since content is personalized at the network edge, subscribers
     will benefit from the increased performance provided by caching
     proxies and other acceleration technologies. This will
     significantly reduce network traffic and congestion.

   3. The applicability of cached content when servicing requests from
     multiple subscribers is increased because personalization occurs
     after content is retrieved from source.

   4. Content sources will be able to provide higher levels of
     throughput at reduced costs because the computations required to
     personalize content have been off-loaded, and content output
     required from the content source may be greatly diminished as

   Barbir, et al.       Expires December 2002               [Page 14]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

     there are fewer clients (network edge devices) that need to be
     served than the typically large numbers of end user devices.

   5. Because personalization services are being provided on network
     devices located at the network edge, better control over Quality
     of Service (QoS) can be achieved.

   NOTE: In scenarios where the access network is invariably the
   bottleneck link (e.g. wireless telecom networks where a combination
   of mechanisms such as DiffServ and overprovisioning are used to
   provide service assurances in the wired part of the end-to-end
   path), if the edge device is located one network hop away from the
   wireless client, it will enable the device to learn the status of
   the network and take appropriate actions in a timely manner.

   Editor Note: we need to be consistent on the use of "intermediary"
   vs. "edge device"; the section 3.4 below defines intermediaries as
   different from edge devices; however, are there usages of these
   terms which are interchangeable elsewhere in the document?

   Editor Note 1: Satisfying the QoS requirements of a user requires
   network-wide mechanisms as the bottlenecked link can be anywhere on
   the content path. Therefore, in general, we need a feedback loop
   running between a client and server of a flow. However, it is
   possible in some engineered scenarios, especially in networks with
   wireless links that the bottlenecked link is in the last hop. In
   such cases alone, the above point may be valid. One interesting
   deployment would be to install two intermediaries, one near the
   client and one near the server, in effect establishing an edge-to-
   edge feedback system providing a range of services that impact the
   perceived QoS by the client. (Note: There are multiple "edges" in
   the network and every content "hop" is potentially an edge location.
   As such, there are opportunities to position intermediaries at these
   multiple edges along the way). This idea deserves more careful
   examination.
   Editor Note 2: It could be argued that QoS assurance or guarantees
   is a content service and as such is not a part of core
   personalization functionality.

3.4 Service Personalization at Intermediaries

   Editor Note: This is where we need to draw attention to the
   existing/proposed work and drafts in OPES, centered around proxy
   caches etc.)

   Network devices on the content path between the client and the
   content source are known as intermediaries. Network edge devices,
   while technically intermediaries are covered separately in the
   previous section. The remaining intermediaries include two types of
   commonly used devices that are of particular interest as potential
   personalization service platforms. These are caching proxies, and
   surrogates. Both of these types of intermediaries have certain

   Barbir, et al.       Expires December 2002               [Page 15]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   advantages over previously discussed alternatives. However, they
   also present added complications, most noticeably in the areas of
   privacy and security.

3.4.1 Service Personalization at Caching Proxies

   Caching proxies, due to their role and placement in the network,
   have some added advantages over network edge devices as platforms
   for personalization services. Specifically:

   1. Because caching proxies reside at various points in the "core" of
     the Internet, but close to the network edge, they are ideally
     placed to provide personalization services which are not tied to a
     specific service provider, while still minimizing network traffic
     to content sources.

   2. Caching proxies, by their very nature, already have built-in
     functionality for examining network traffic and making decisions
     based on the nature of that traffic (i.e. deciding whether or not
     to cache a given piece of content).

   3. Standardized, well-defined interfaces exist for controlling the
     lifecycle of cached content, including deletion, replacement, and
     expiry of cached content.

   4. Because caching proxies potentially service subscribers from many
     ISPs, their audience is much larger. This means that algorithms
     for selectively caching certain personalized variants of content
     can be contemplated since a larger audience increases the
     probability that multiple subscribers will express similar or
     identical preferences. For example, if a caching proxy is located
     in France, the likelihood that multiple subscribers will request
     content translation into French is quite high. This fact has the
     potential to allow for significant increases in performance and
     overall quality of the subscriber experience.
   Editor Note: Contrast these with the statements made in Sec 3.1,
   item 5.

   5. Well-understood network engineering techniques and technologies
     exist to scale the capacity of caching proxies to handle very
     large numbers of concurrent subscriber requests efficiently. The
     return on investment in such equipment is significantly higher
     than for either content sources or network edge devices, and the
     incremental improvements in performance and reliability are
     effective for a larger audience of subscribers.

   These added advantages are offset by some complications and
   considerations that must be addressed:

   1. Caches are meant to speed up delivery of content to the devices
     and any additional processing at these devices impact in the
     content delivery process. Since personalization is performed per

   Barbir, et al.       Expires December 2002               [Page 16]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

     subscriber, the performance impact is potentially large enough to
     raise concerns on the very purpose caches are meant for _ web
     acceleration.

   2. There is no pre-existing trust relationship between subscribers
     and caching proxies. Because caching proxies do not necessarily
     fall under the administrative domain of the ISP or access network,
     the facilities provided by the network edge for authentication and
     authorization do not cover these devices. Because personalization
     services require subscriber-specific information as to their
     preferences and policies, there is an increased risk of tampering
     and/or invasion of subscriber privacy in transferring such
     information to a caching proxy.

   3. This means that a mechanism must exist for authenticating a
     caching proxy's identity and authorizing its access to subscriber
     profile information.

   4. No matter what the type of connectivity between the access
     network and the caches, steps must be taken to ensure that any
     transfer of subscriber profile information is secure.

   5. Caching proxies, by design, are intended to operate transparently
     to the end user. Since personalization involves the potential
     modification, filtering, or other adaptation/alteration of content
     received in response to a subscriber request, any personalization
     service that resides on a caching proxy must have a mechanism
     whereby the subscriber's explicit authorization is required to
     enable content adaptation.

   6. Since caching proxies' primary function is to cache data,
     subscribers must have some means of controlling what (if any)
     information contained in the subscriber profile persists on the
     device at any time during or after a subscriber session.

   7. Once the caching proxy has retrieved subscriber information, a
     mechanism must exist to ensure that no access to that information
     is allowed by any entity save by the explicit authorization of the
     subscriber.

3.4.2 Service Personalization at Surrogates

   Surrogates exhibit many of the same characteristics as caching
   proxies, and present similar opportunities for optimization of
   personalization services as caching proxies. They also pose
   comparable challenges. Because of their placement near the content
   source, however, the specific advantages and complications are
   different enough to warrant closer examination. The placement of
   surrogates in the content path presents some unique characteristics
   that make them well suited to the implementation of certain kinds of
   personalization services:


   Barbir, et al.       Expires December 2002               [Page 17]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   1. Because surrogates are delegated to operate on behalf of, and
     often in close co-operation with one or more content sources, they
     provide an ideal platform for the aggregation of related content
     from a select set of origins. Personalization services at this
     point in the content path can take advantage of more efficient and
     practical access to back-end application layer functionality,
     allowing for the creation of more dynamic aggregated content,
     while allowing for balancing incurred load that such dynamic
     content incurs.

   2. While the benefits that personalization services enjoy when co-
     located with caching proxies with respect to decreased network
     traffic are less significant in this scenario, surrogates do
     provide the widest possible audience of subscribers for a given
     set of content. This means that the odds of certain types
     personalized content variants having applicability beyond a single
     subscriber request or session are maximized.

   3. One very common form of surrogate is the reverse proxy.
     Implementation of personalization services on such devices will
     allow for potentially large numbers of related content sources to
     take advantage of personalization while also leveraging existing
     load-balancing and scalability solutions for content sources.
     Because reverse proxy network topologies are themselves scalable,
     personalization service capacity can be scaled appropriately to
     meet subscriber demand for even very high traffic content sources.

   As with all other potential platforms for personalization services,
   surrogates present their own challenges and issues to be addressed.
   Among these are:

   1. Because surrogates are closely tied to content sources,
     subscriber information will have to be transmitted across a
     significant portion of the content path over the public Internet.
     This makes the requirement for a secure mechanism for subscriber
     profile transfer, and other security and privacy considerations
     discussed in Section 3.4.1 even more important.

   2. Because surrogates tend to be deployed very near the content
     source, the incremental cost in network traffic and bandwidth
     significantly offsets the benefits of this approach.

3.5 Hybrid approaches to Service Personalization

   It is possible to envision personalization services that are
   distributed. That is, ones which reside on more than one of the
   previously discussed points in the content path. Such hybrid systems
   might allow for more sophisticated decision-
   making algorithms to be implemented.

   For example: If one were to install personalization services on both
   the network edge devices (or even the caching proxies) and the

   Barbir, et al.       Expires December 2002               [Page 18]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   surrogates, one could establish a feedback loop, or edge-to-edge
   system, providing a variety of services that could affect the
   perceived QoS of subscriber sessions.

   There are many other possible combinations and benefits which could
   arise from such hybrid systems. Further investigation of the
   possibilities is recommended.

3.6 Goals of FSP

   FSP aims to provide a Framework and Protocols for the delivery of
   the optimal content variant for a given request to the requestor
   based on the subscriber profile and policies, and the content
   profile and its associated policies. The next sub-sections discuss
   the basic components of FSP.

3.7 Subscriber and Content Profiles

   Editor Note: CPExchange and its applicability to FSP.

   In order for FSP to be able to deliver to the subscriber the optimal
   content variant for their request based on the subscriber profile
   and policies, these profiles and policies must be able to completely
   describe a subscriber's personalization preferences. To this end, a
   precise definition must be developed that allows for the creation of
   a subscriber profile that also includes associated policies. The
   subscriber profile must also be able to be stored either in a
   centralized location, or be distributed across multiple locations in
   the Internet, including the user agent.

   The Composite Capabilities/Personal Preferences [CC/PP] work
   establishes a framework for defining how subscribers may codify
   their device capabilities and their preferences about the use of
   these capabilities. CC/PP defines a Resource Description Framework
   (RDF) schema and associated vocabularies for describing device
   capabilities and user preferences. However, a subscriber's profile
   may also include other components such as the QoS expected by the
   user and the capabilities of the access network through which the
   device is connected to the rest of the Internet. In addition, mobile
   users may have an elaborate description of how they would like their
   service to be adapted as resource levels change during the course of
   a long-running network session. A subscriber's profile must
   completely encapsulate all of the information about a subscriber
   that is needed to make any of the personalization decisions required
   for a given content request. This implies that there is the need to
   develop a vocabulary for encoding policies within a subscriber's
   profile, as well as additional preference information unrelated to
   device capabilities. This vocabulary forms a superset of that
   defined in the existing CC/PP work.

   The set of elements that comprise a subscriber's profile includes
   among others a description of the device capabilities, Quality of

   Barbir, et al.       Expires December 2002               [Page 19]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Service (QoS), access rate, accounting information, and content type
   preferences. A subscriber profile also includes policies that define
   what constitutes acceptable content (e.g. topic, explicit content,
   linked content origin, acceptable manipulations, filtering policies)
   that the subscriber is willing to receive. It may also contain
   information related to the level of service that a subscriber
   considers adequate; for example, trading off cost of service vs.
   response time, accuracy etc. (Subscriber A may want to get language
   translation free of cost while accepting poor quality, accuracy,
   response time; subscriber B may be willing to pay for better
   accuracy, response time etc. for translation)

   Content profiles and policies, on the other hand, encapsulate
   information about the content. This includes information such as
   available variants at the content source, encoding method,
   dimensions (for graphics), etc. Content profiles and policies also
   include information about what is and is not allowed in terms of use
   or manipulation of that content (e.g. do not allow legal documents
   to be translated into another language, do not perform "down
   sampling" of higher quality multimedia/streaming content). A content
   provider may provide hints to a personalization intermediary in
   choosing the most suitable transformations to apply in some form
   (e.g. INFOPYRAMID provides one such representation).

   Content policies are an integral part of the content profile for a
   given piece of content. A content profile must encapsulate all of
   the information about the content which is needed to make any of the
   personalization decisions required for that content, including
   whether or not a given personalization transformation is allowed.
   [RFC-2295] provides the means for automatically and efficiently
   retrieving the best content variant from a content source in HTTP.
   This specification defines transparent content negotiation as an
   extension on top of the HTTP/1.1 protocol [RFC-2616]. This work,
   combined with a schema and vocabulary for defining a content profile
   that is similar to, and consistent with the subscriber profile,
   could provide a sound basis for defining a more generalized,
   protocol-independent process for retrieving the appropriate content
   variant from the content source. More work will be needed to
   incorporate content policy enforcement into this process.

3.8 Content Selection

   Content selection involves choosing the most appropriate or optimal
   available content variant from a content source for transmission
   back to the subscriber. The choice of optimal content source in this
   context is restricted to the task of identifying the best content
   variant that could be adapted to suit the subscriber. This task is
   separate and distinct from the process of choosing the content
   source that is optimal from a network perspective, based on network
   delay, server load, or other such metrics.


   Barbir, et al.       Expires December 2002               [Page 20]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   There are various criteria that can be used to determine the most
   appropriate content variant to retrieve from the content source. The
   simplest of these is choosing a variant that completely or most
   closely fits the subscriber's preferences. This is, however, only
   one possible form of content selection.

   In the event that there is no content variant that completely fits
   the subscriber's preferences, alternate content selection criteria
   may apply. The task of selecting the most appropriate content
   variant may be performed as a function of the ease of translation of
   the content into the appropriate format provided that the content
   policy allows for the needed adaptation. Here, it is important to
   note the distinction between "most appropriate" content to retrieve
   from the content source and the "optimal content" to deliver to the
   subscriber.

   In HTTP Web sites, authors are allowed to store multiple versions of
   the same information under a single URL. In [RFC-2295], Transparent
   Content Negotiation (TCN) is proposed as a mechanism to select the
   best appropriate variant of the content. The TCN mechanism is
   layered on top of HTTP, and provides a mechanism for automatically
   selecting the best content variant when the URL is accessed.
   However, as is discussed in section 3.7 above, further work will be
   needed to enhance and generalize the existing TCN architecture to
   leverage the capabilities enabled by the content profile.

   Some complementary technologies are aimed at enabling the
   aggregation of distributed content fragments into a customized whole
   at the network edge through the specification of inclusion
   mechanisms. Edge Side Includes [ESI] represents one such technology.
   ESI provides a means to embed inclusion instructions into content
   for execution at the network edge. It also provides mechanisms for
   specifying conditions under which such inclusions should be made,
   and for invalidating content fragments that are cached at network
   intermediaries. This work could be enhanced to allow the
   specification of conditions and policies for inclusion within a
   subscriber profile, maximizing the effectiveness of ESI for
   personalization purposes. Further investigation into this area is
   required.

3.9 Quality of Delivery (Origin Server Selection ?)

   This criterion only applies in the case where there are multiple
   sources from which content can be obtained, and the personalization
   framework has some influence over the content source selection. In
   this case, it makes some sense to define a quality of delivery
   (QoD). In the case where there is only one content source from which
   content can be obtained, or where the personalization framework has
   no influence over which site gets chosen, quality of delivery
   reduces to whatever quality the chosen content source can deliver.


   Barbir, et al.       Expires December 2002               [Page 21]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Within the scope of an OPES implementation of this framework, there
   have been discussions on "late binding" of Rules to Actions and the
   Policy framework to allow essentially to select from a variety of
   content sources. The selection will be influenced by policies/rules
   stipulated on behalf of the end user/subscriber. At this point this
   topic will be left unexplored in the interests of clarity of
   discussion within OPES.

3.10 Privacy and Security

   Privacy issues are an important component of personalization. In
   this regard, the issues of privacy that are related to shopping
   habits, the willingness to accept or refuse certain type of
   advertisement, and subscriber profiling are already addressed by the
   Platform for Privacy Preferences [P3P] at W3C. It is important to
   note that while P3P provides a technical mechanism to ensure that
   the subscriber is informed of the privacy policy of a content
   source, it does not specify any mechanism for policy enforcement.
   This is an area in which FSP may play a role in strengthening the
   enforcement of privacy policies.
   Editor Note: Through request anonymization, we may be able to
   prevent the content source from gathering metrics that are
   undesirable to the subscriber. We have to be careful here, however,
   because this will not make some content providers happy.
   Additionally, anonymization is really more of a content service than
   it is core personalization. Maybe what we have is a selective
   anonymization based on privacy policy enforcement during
   personalization. We may wish to investigate the technical
   feasibility of this idea.

   Editor Note: The above should not be a major issue as (1) P3P will
   be a fact of life. (2) Personalization can be denied for anonymous
   requests?

   In performing personalization, there should be a mechanism that
   ensures that the transition of a subscriber profile across the
   Internet is done in a secure and reliable manner. Furthermore, there
   should be a mechanism that authorizes any entity that is interested
   in accessing a subscriber profile.
   In general, security considerations for personalization must address
   the following issues:

   1) Subscriber Profile Integrity - FSP must ensure that a subscriber
     profile is unadulterated in whole or in part when it reaches a
     decision point.

   2) Content Profile Integrity - FSP must ensure that a content
     profile is unadulterated in whole or in part when it reaches a
     decision point.

   3) Trust Relationships - There must be a proper mechanism that
     decides the entity that is authorized to configure, update,

   Barbir, et al.       Expires December 2002               [Page 22]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

     change, and delete a subscriber profile. There must be a proper
     mechanism that authorizes any entity that will perform
     personalization across the content adaptation chain. This includes
     trusted third parties and repositories.

   4) Non-repudiation of request - Non-repudiation of any subscriber
     profile configuration/update/change/deletion may be required.


   5) Data Confidentiality - Preventing eavesdroppers from gaining
     access to a subscriber profile is important. Note that this
     requirement is different from subscriber privacy.

4. Security Considerations - Security Threats and Mechanisms

   Section 3.10 described several security requirements for FSP. In
   this section, we provide a threat analysis for FSP, and discuss
   trade-offs between different security mechanisms/solutions.

4.1 Threat Analysis

   In this section, we describe a set of threats, their effect on the
   system, and the corresponding requirement in order to combat the
   threat.

4.1.1 Malicious entity accesses subscriber profile

   Threat: A malicious entity is able to access a subscriber profile.

   Effect: A subscriber's privacy is compromised.

   Requirement: Any access to subscriber profile has to be authorized.

4.1.2 Malicious entity modifies subscriber profile

   Threat: A malicious entity is able to configure/modify/delete a
   subscriber profile.

   Effect: The stored subscriber profile is different from that which
   the subscriber desires.

   Requirement: There are two scenarios by which a malicious entity may
   modify a subscriber profile - one in which the
   configuration/modification/deletion request is originated by the
   malicious entity, and the other in which an authorized entity issues
   the configuration/modification/deletion request which gets modified
   by the malicious entity in transit. In order to tackle the first
   scenario, any configuration/modification/deletion of subscriber
   profile has to be authorized. To tackle the latter case,
   additionally, integrity protection of such requests also needs to be
   provided.


   Barbir, et al.       Expires December 2002               [Page 23]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

4.1.3 Eavesdropping on a subscriber profile in transit

   Threat: An unauthorized entity eavesdrops on a request to
   configure/update/modify a subscriber profile

   Effect: The subscriber's privacy is compromised.

   Requirement: Data confidentiality of such requests is needed.

4.1.4 Malicious entity accesses content profile

   Threat: A malicious entity is able to access a content profile.

   Effect: Certain content meta-data that the content owner does not
   wish to divulge to unauthorized entities may be divulged. Potential
   attackers may also be able to exploit such information to launch
   more sophisticated attacks.

   Requirement: Any access to content profile has to be authorized.

4.1.5 Malicious entity modifies content profile

   Threat: A malicious entity is able to configure/modify/delete a
   content profile.

   Effect: The stored content profile is different from that which the
   content owner desires.

   Requirement: There are two scenarios by which a malicious entity may
   modify a content profile - one in which the
   configuration/modification/deletion request is originated by the
   malicious entity, and the other in which an authorized entity issues
   the configuration/modification/deletion request which gets modified
   by the malicious entity in transit. In order to tackle the first
   scenario, any configuration/modification/deletion of content profile
   has to be authorized. To tackle the latter case, additionally,
   integrity protection of such requests also needs to be provided.

4.1.6 Eavesdropping on a content profile in transit

   Threat: An unauthorized entity eavesdrops on a request to
   configure/update/modify a content profile

   Effect: Certain content meta-data that the content owner does not
   wish to divulge to unauthorized entities may be divulged. Potential
   attackers may also be able to exploit such information to launch
   more sophisticated attacks.

   Requirement: Data confidentiality of such requests is needed.

4.1.7 Authorized entity later repudiates a request


   Barbir, et al.       Expires December 2002               [Page 24]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Threat: An entity that is authorized to make a certain request
   claims at a later time that it did not make that request.

   Effect: The maintainer of the database of subscriber profiles may be
   held liable for unauthorized changes to a subscriber profile.
   Similarly, the maintainer of the database of content profiles may be
   held liable for unauthorized changes to a content profile.

   Requirement: Non-repudiation of requests for
   configuring/modification/deletion of subscriber and content profile
   needs to be provided.

4.2 Security Mechanisms

   One or more appropriate security mechanisms need to be employed in
   order to combat the various threats to a FSP system, and to meet the
   requirements described earlier. Below, we give a comparison of some
   of these mechanisms:

4.2.1 Application layer security designed for FSP

   Application layer mechanisms have the advantage of being tailor-made
   for the purpose, and hence can be more efficient than other general-
   purpose mechanisms. However, care needs to be taken to ensure that
   the mechanisms devised are indeed secure.

4.2.2 S/MIME and PGP

   Mechanisms such as S/MIME and PGP could be used for providing
   security services to the application. These mechanisms provide a
   wide range of security services - authentication, integrity,
   confidentiality and non-repudiation.

4.2.3 TLS

   The Transport Layer Security (TLS) may be used when the underlying
   transport is a reliable one. Hence, TLS can be used with TCP but not
   with UDP.

4.2.4 IPSec

   IPSec provides two headers - Authentication Header (AH) and
   Encapsulating Security Payload (ESP) - in order to provide several
   security services at the IP layer. Since these security services are
   provided at the IP layer, the transport protocol or the application
   itself is immaterial to IPSec.

5. Related Personalization Developments

   This section will contain information on the Liberty Alliance,
   Microsoft Passport, the W3C ([CC/PP], P3P, and Device Independence)

   Barbir, et al.       Expires December 2002               [Page 25]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   and other developments that are likely to affect the direction of
   services offered within the Framework for Service Personalization.

5.1 The Liberty Alliance and Microsoft Passport

   The Liberty Alliance and Microsoft Passport are somewhat similar
   initiatives. This generic discussion is intended only to address
   their relationship with the OPES FSP, and does not differentiate
   between them, although there are differences.

   These initiatives define specifications for online identification
   that can allow individuals to carry their identity from site to
   site. They propose a kind of "single sign-on" technology that can
   enable an end user to log on at one web site and then allow some
   elements of that log-in to be transferred to other participating web
   sites.

   These initiatives appear to be primarily focused on facilitating
   business-to-consumer transactions over the Internet, by simplifying
   the process of establishing an identity on the Internet. At this
   point, it is not clear whether they address the problem of defining
   and maintaining current information on the capabilities of the
   user's access device. This is a required part of personalization of
   content services within the OPES FSP.

   Editor's note: Need to place these initiatives more clearly in the
   framework taxonomy, and identify interfaces, etc.

6. Acknowledgments

   The majority of the definitions contained in this document have been
   obtained from the document entitled: "A Model for Open Pluggable
   Edge Services", by G. Tomlinson, et al. [O-MODEL]. This contribution
   is gratefully acknowledged.

   The authors wish to acknowledge the comments and suggestions
   contributed by the members of the FSP mailing list. These people
   include: Raffi Uddin, Wil Walkoe, Ram Dantu.




   Barbir, et al.       Expires December 2002               [Page 26]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization


7. References

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.
   [CALLOUT] Barbir et al, "Requirements for an OPES Service
      Personalization Callout Server, draft-barbir-opes-spcs-01.txt
      (work in progress) February, 2002.
   [O-MODEL]  Tomlinson, G., Chen, R. and M. Hofmann, "A Model for Open
      Pluggable Edge Services", draft-tomlinson-opes-model-00.txt (work
      in progress), July 2001.
   [RFC-2616] Fielding, R., et al., "Hypertext Transfer Protocol --
      HTTP/1.1", RFC 2616, June 1999.
   [RFC-3040]  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
      Replication and Caching Taxonomy", RFC 3040, January 2001.
   [ESFNEP]  A. Beck et al, "Example Services for Network Edge
      Proxies", draft-beck-opes-esfnep-01.txt (work in progress), June
      2001.
   [POLICY]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
      M., Quinn, B., Perry, J., Herzog, S., Huynh, A., Carlson, M. and
      S. Waldbusser, "Policy Terminology", draft-ietf-policy-
      terminology-03.txt (work in progress), April 2001.
   [C-MODEL]  Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model
      for Content Internetworking", draft-day-cdnp-model-06.txt (work
      in progress), June 2001.
   [CC/PP] G. Klyne, F. Raynolds, C. Woodrow, H. Ohto, "Composite
      Capabilities/Preferences Profiles (CC/PP): Structure and
      Vocabularies", March 15, 2001. http://www.w3.org/Mobile/CCPP/.
   [RFC-2295] K. Holtman and A. Mutz, "Transparent Content Negotiation
      in HTTP", RFC 2295, March 1998.
   [ESI] Tsimelzon, M., Weihl, B. and L. Jacobs, "ESI Language
      Specification 1.0", (M. Nottingham, ed.), 2001,
      http://www.esi.org/language_spec_1-0.htm.
   [P3P] Platform for Privacy Preferences (P3P1.0) Specification,
      http://www.w3.org/TR/2000/CR-P3P-20001215.

8. Authors' Addresses

   Abbie Barbir, Ph.D.
   Nortel Networks
   3500 Carling Avenue
   Nepean Ontario K2H 8E9 Canada
   Email: Abbieb@nortelnetworks.com

   Nicholas Bennett
   Nortel Networks
   3500 Carling Avenue
   Nepean Ontario K2H 8E9 Canada
   Email: nbennett@nortelnetworks.com


   Barbir, et al.       Expires December 2002               [Page 27]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization

   Reinaldo Penno
   Nortel Networks, Inc.
   2305 Mission College Boulevard
   Building SC9-B1240
   San Jose, CA 95134
   Email: rpenno@nortelnetworks.com

   Rama R. Menon
   Intel Corporation
   2111 NE 25th Avenue, M/S JF3-206
   Hillsboro, OR 97124
   Email: rama.r.menon@intel.com

   Hien-Thong Pham
   Alcatel Bell
   Francis Wellesplein 1
   B-2018 Antwerp
   BELGIUM
   Phone: 3-2408630
   Email: hien-thong.pham@alcatel.be

   Senthil Sengodan, Ph.D.
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803
   Tel: 781-993-3789
   Fax: 781-993-1907
   Email: senthil.sengodan@nokia.com

   Jayanth P. Mysore
   Network and Infrastructure Research Laboratory
   Motorola Labs
   1301 E. Algonquin Road
   Schaumburg, IL 60196
   Email: jayanth@labs.mot.com

   Editor:  (Please send comments to Editor)
   Paul Knight
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA  01821   USA
   Phone:  +1-978-288-6414
   Email:  paknight@nortelnetworks.com

   Barbir, et al.       Expires December 2002               [Page 28]


Internet-Draft    draft-barbir-opes-fsp-02.txt            June 2002
               A Framework for Service Personalization


9. Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.


   Barbir, et al.       Expires December 2002               [Page 29]