[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4745

GEOPRIV                                                   H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: January 17, 2005                                      J. Morris
                                                                     CDT
                                                           H. Tschofenig
                                                              J. Cuellar
                                                                 Siemens
                                                                 J. Polk
                                                                   Cisco
                                                            J. Rosenberg
                                                             DynamicSoft
                                                           July 19, 2004


          A Document Format for Expressing Privacy Preferences
                draft-ietf-geopriv-common-policy-01.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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.

   This Internet-Draft will expire on January 17, 2005.

Copyright Notice

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

Abstract

   This document defines a framework for authorization policies



Schulzrinne, et al.     Expires January 17, 2005                [Page 1]

Internet-Draft               Common Policy                     July 2004


   controling access to application specific data.  This framework
   combines common location- and SIP-presence-specific authorization
   aspects.  An XML schema specifies the language in which common policy
   rules are represented.  The common policy framework can be extended
   to other application domains.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   Modes of Operation . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Passive Request-Response - PS as Server (Responder)  . . .   6
     3.2  Active Request-Response - PS as Client (Initiator) . . . .   6
     3.3  Event Notification . . . . . . . . . . . . . . . . . . . .   6
   4.   Goals and Assumptions  . . . . . . . . . . . . . . . . . . .   8
   5.   Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.   Basic Data Model and Processing  . . . . . . . . . . . . . .  11
     6.1  Identification of Rules  . . . . . . . . . . . . . . . . .  12
     6.2  Extensions . . . . . . . . . . . . . . . . . . . . . . . .  12
   7.   Conditions . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1  Identity . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.2  Sphere . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.3  Validity . . . . . . . . . . . . . . . . . . . . . . . . .  15
   8.   Actions  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   9.   Transformations  . . . . . . . . . . . . . . . . . . . . . .  17
   10.  Procedure for Combining Permissions  . . . . . . . . . . . .  18
     10.1   Introduction . . . . . . . . . . . . . . . . . . . . . .  18
     10.2   Algorithm  . . . . . . . . . . . . . . . . . . . . . . .  18
     10.3   Example  . . . . . . . . . . . . . . . . . . . . . . . .  19
   11.  Meta Policies  . . . . . . . . . . . . . . . . . . . . . . .  22
   12.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . .  23
   13.  XML Schema Definition  . . . . . . . . . . . . . . . . . . .  24
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  27
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  28
     15.1   Common Policy Namespace Registration . . . . . . . . . .  28
     15.2   Common Policy Schema Registration  . . . . . . . . . . .  28
   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  29
   16.1   Normative References . . . . . . . . . . . . . . . . . . .  29
   16.2   Informative References . . . . . . . . . . . . . . . . . .  29
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  29
   A.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  31
   B.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  32
   C.   Enhancements to the Combining Permissions Algorithm  . . . .  33
     C.1  Introduction . . . . . . . . . . . . . . . . . . . . . . .  33
     C.2  Algorithms . . . . . . . . . . . . . . . . . . . . . . . .  36
     C.3  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  37
        Intellectual Property and Copyright Statements . . . . . . .  40




Schulzrinne, et al.     Expires January 17, 2005                [Page 2]

Internet-Draft               Common Policy                     July 2004


1.  Introduction

   This document defines a framework for creating authorization policies
   for access to application specific data.  This framework is the
   result of combining the common aspects of single authorization
   systems that more specifically control access to presence and
   location information and that previously had been developed
   separately.  The benefit of combining these two authorization systems
   is two-fold.  First, it allows to build a system which enhances the
   value of presences with location information in a natural way and
   reuses the same underlying authorization mechanism.  Second, it
   encourages a more generic authorization framework with mechanisms for
   extensibility.  The applicability of the framework specified in this
   document is not limited to policies controling access to presence and
   location information data, but can be extended to other applications
   domains.

   The general framework defined in this document is intended to be
   accompanied and enhanced by application-specific policies specified
   elsewhere.  Using the 'Location-specific Policy' and the
   'Presence-specific Policy' documents [both are currently under
   development - references to be included here], figureFigure 1
   illustrates the relationship between the 'Common Policy' framework
   defined in this document and application-specific enhancements of
   this framework.

                           +-----------------+
                           |                 |
                           |     Common      |
                           |     Policy      |
                           |                 |
                           +---+---------+---+
                              /|\       /|\
                               |         |
      +-------------------+    |         |    +-------------------+
      |                   |    | enhance |    |                   |
      | Location-specific |    |         |    | Presence-specific |
      |      Policy       |----+         +----|      Policy       |
      |                   |                   |                   |
      +-------------------+                   +-------------------+


                  Figure 1: Common Policy Enhancements

   This document starts with an introduction to the terminology
   inSection 2, an illustration of basic modes of operation inSection 3,
   a description of goals (see Section 4) and non-goals (see Section 5)
   of the authorization policy framework, followed by the data model in



Schulzrinne, et al.     Expires January 17, 2005                [Page 3]

Internet-Draft               Common Policy                     July 2004


   Section 6.  The structure of a rule, namely conditions, actions and
   transformations, are described in Section 7, in Section 8 and in
   Section 9.  The procedure for combining permissions is explained in
   Section 10 and used when more than one rule fires.  An example is
   provided in Section 12.  The XML schema will be discussed in Section
   13.  IANA considerations in Section 15 follow security considerations
   Section 14.












































Schulzrinne, et al.     Expires January 17, 2005                [Page 4]

Internet-Draft               Common Policy                     July 2004


2.  Terminology

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

   This document introduces the following terms:

   PT - Presentity / Target: The PT is the entity about whom information
      has been requested.

   RM - Rule Maker: RM is an entity which creates the authorization
      rules which restrict access to data items.

   PS - (Authorization) Policy Server: This entity has access to both
      the authorization policies and to the data items.  In
      location-specific applications, the entity PS is labeled as
      location server (LS).

   WR - Watcher / Recipient: This entity requests access to data items
      of the PT.  An access operation might be either be a read, write
      or any other operation.  In case of access to location information
      it might be a read operation.

   An 'authorization policy' is given by a 'rule set'.  A 'rule set'
   contains an unordered list of 'rules'.  A 'rule' has a 'conditions',
   an 'actions' and a 'transformations' part.

   The term 'permission' indicates the action and transformation
   components of a 'rule'.

   The terms 'authorization policy', 'policy' and 'rule set' are used
   interchangeable.

   The terms 'authorization policy rule', 'policy rule' and 'rule' are
   used interchangeable.

   The term 'using protocol' is defined in[RFC3693].  It refers to the
   protocol which is used to request access to and to return privacy
   sensitive data items.











Schulzrinne, et al.     Expires January 17, 2005                [Page 5]

Internet-Draft               Common Policy                     July 2004


3.  Modes of Operation

   The abstract sequence of operations can roughly be described as
   follows.  The PS receives a query for data items for a particular PT,
   via the using protocol.  The using protocol provides the identity of
   the requestor (or more precisely the authentication protocol), either
   at the time of the query or at the subscription time.  The
   authenticated identity of the WR, together with other information
   provided by the using protocol or generally available to the server,
   is then used for searching through the rule set.  All matching rules
   are combined according to a permission combining algorithm described
   in Section 10.  The result is returned to the WR, possibly modified
   by transformation policies.

   A single PS may authorize access to data items in more than one mode.
   Rather than having different rule sets for different modes all three
   modes are supported with a one rule set schema.  Specific instances
   of the rule set can omit elements that are only applicable to the
   subscription model.  The three different modes are explained below.

3.1  Passive Request-Response - PS as Server (Responder)

   In a passive request-response scenario, the WR queries the PS for
   data items about the PT.  Examples of protocols following this mode
   of operation include HTTP, FTP, LDAP, finger or various RPC
   protocols, including Sun RPC, DCE, DCOM, Corba and SOAP.  The PS uses
   the ruleset to determine whether the WR is authorized to access the
   PTs information, refusing the request if necessary.  Furthermore, the
   PS might filter information by removing elements or by reducing the
   resolution of elements.

3.2  Active Request-Response - PS as Client (Initiator)

   Alternatively, the PS may contact the WR and convey data items.
   Examples include HTTP, SIP session setup (INVITE request), H.323
   session setup or SMTP.

3.3  Event Notification

   Event notification adds a subscription phase to the "PS as client"
   mode of operation.  A watcher or subscriber asks to be added to the
   notification list for a particular presentity or event.  When the
   presentity changes state or the event occurs, the PS sends a message
   to the WR containing the updated state.  (Presence is a special case
   of event notification; thus, we often use the term interchangeably.)

   In addition, the subscriber may itself add a filter to the
   subscription, limiting the rate or content of the notifications.  If



Schulzrinne, et al.     Expires January 17, 2005                [Page 6]

Internet-Draft               Common Policy                     July 2004


   an event, after filtering by the rulemaker-provided rules and by the
   subscriber-provided rules, only produces the same notification
   content that was sent previously, no event notification is sent.
















































Schulzrinne, et al.     Expires January 17, 2005                [Page 7]

Internet-Draft               Common Policy                     July 2004


4.  Goals and Assumptions

   Below, we summarize our design goals and constraints.

   Table representation: Each rule must be representable as a row in a
      relational database.  This design goal should allow efficient
      policy rule implementation by utilizing standard database
      optimization techniques.

   Permit only: Rules only provide permissions rather than denying them.
      Allowing both 'permit' and 'deny' actions would require some rule
      ordering which had implications on the update operations executed
      on these rules.  Additionally it would make distributed rule sets
      more complicated.  Hence, only 'permit' actions are allowed which
      result in more efficient rule processing.  This also implies that
      rule ordering is not important.  Consequently, to make a policy
      decision requires processing all policy rules.

   Additive permissions: A query for access to data items is matched
      against the rules in the rule database.  If several rules match,
      then the overall permissions granted to the WR are the union of
      those permissions.  A more detailed discussion is provided
      inSection 10.

   Upgradeable: It should be possible to add additional rules later,
      without breaking PSs that have not been upgraded.  Any such
      upgrades must not degrade privacy constraints, but PSs not yet
      upgraded may reveal less information than the rulemaker would have
      chosen.

   Versioning support: In addition to the previous goal, a RM should be
      able to determine which types of rules are supported by the PS.
      The mechanism used to determine the capability of a PS will be
      covered in future versions of the document.

   Protocol-independent: The rule set supports constraints on both
      notifications or queries as well as subscriptions for event-based
      systems such as presence systems.

   No false assurance: It appears more dangerous to give the user the
      impression that the system will prevent disclosure automatically,
      but fail to do so with a significant probability of operator error
      or misunderstanding, than to force the user to explicitly invoke
      simpler rules.  For example, rules based on weekday and
      time-of-day ranges seem particularly subject to misinterpretation
      and false assumptions on part of the RM.  (For example, a
      non-technical RM would probably assume that the rules are based on
      the timezone of his current location, which may not be known to



Schulzrinne, et al.     Expires January 17, 2005                [Page 8]

Internet-Draft               Common Policy                     July 2004


      other components of the system.)


















































Schulzrinne, et al.     Expires January 17, 2005                [Page 9]

Internet-Draft               Common Policy                     July 2004


5.  Non-Goals

   We explicitly decided that a number of possibly worthwhile
   capabilities are beyond the scope of this first version.  Future
   versions may include these capabilities, using the extension
   mechanism described in this document.  Non-goals include:

   No external references: Attributes within specific rules cannot refer
      to external rule sets, databases, directories or other network
      elements.  Any such external reference would make simple database
      implementation difficult and hence they are not supported in this
      version.

   No regular expression or wildcard matching: Conditions are matched on
      equality or 'greater-than'-style comparisons, not regular
      expressions, partial matches such as the SQL LIKE operator (e.g.,
      LIKE "%foo%") or glob-style matches ("*@example.com").  Most of
      these are better expressed as explicit elements.

   No all-except conditions: It is not possible to express exclusion
      conditions based on identities such as "everybody except Alice".
      However, this restriction does not prevent all forms of
      blacklisting.  It is still possible to express an authorization
      rule like 'I allow access to my location information for everyone
      of domain example.com except for John'.  See the example in
      Section 7.1 describing how exceptions can be made work.

   No repeat times: Repeat times are difficult to make work correctly,
      due to the different time zones that PT, WR, PS and RM may occupy.
      It appears that suggestions for including time intervals are often
      based on supporting work/non-work distinctions, which
      unfortunately are difficult to capture by time alone.



















Schulzrinne, et al.     Expires January 17, 2005               [Page 10]

Internet-Draft               Common Policy                     July 2004


6.  Basic Data Model and Processing

   A rule set (or synonymously, a policy) consists of zero or more
   rules.  The ordering of these rules is irrelevant.  The rule set can
   be stored at the PS and conveyed from RM to PS as a single document,
   in subsets or as individual rules.  A rule consists of three parts -
   conditions (seeSection 7), actions (see Section 8), and
   transformations (see Section 9).

   The conditions part is a set of expressions, each of which evaluates
   to either TRUE or FALSE, i.e.  each of which is equipped with a value
   of either TRUE or FALSE by the PS.  When a WR asks for information
   about a PT, the PS goes through each rule in the rule set.  For each
   rule, it evaluates the expressions in the conditions part.  If all of
   the expressions evaluate to TRUE, then the rule is applicable to this
   request.  Generally, each expression specifies a condition based on
   some variable that is associated with the context of the request.
   These variables can include the identity of the WR, the domain of the
   WR, the time of day, or even external variables, such as the
   temperature or the mood of the PT.

   Assuming that the rule is applicable to the request, the actions and
   transformations (commonly referred to as permissions) in the rule
   specify how the PS is supposed to handle this request.  If the
   request is to view the location of the PT, or to view its presence,
   the typical action is "permit", which allows the request to proceed.

   Assuming the action allows the request to proceed, the
   transformations part of the rule specifies how the information about
   the PT - their location information, their presence, etc.  - is
   modified before being presented to the WR.  These transformations are
   in the form of positive permissions.  That is, they always specify a
   piece of information which is allowed to be seen by the WR.  When a
   PS processes a request, it takes the transformations specified across
   all rules that match, and creates the union of them.  The means for
   computing this union depend on the data type - Integer, Boolean, Set,
   or the Undef data type - and are described in more detail in Section
   10.  The resulting union effectively represents a "mask" - it defines
   what information is exposed to the WR.  This mask is applied to the
   actual location or presence data for the PT, and the data which is
   permitted by the mask is shown to the WR.  If the WR request a subset
   of information only (such as city-level civil location data only,
   instead of the full civil location information), the information
   delivered to the WR SHOULD be the intersection of the permissions
   granted to the WR and the data requested by the WR.

   In accordance to this document, rules are encoded in XML.  To this
   end, Section 13 contains an XML schema defining the Common Policy



Schulzrinne, et al.     Expires January 17, 2005               [Page 11]

Internet-Draft               Common Policy                     July 2004


   Markup Language.  This, however, is purely an exchange format between
   RM and PS.  The format does not imply that the RM or the PS use this
   format internally, e.g., in matching a query with the policy rules.
   The rules are designed so that a PS may translate the rules into a
   relational database table, with each rule represented by one row in
   the database.  The database representation is by no means mandatory;
   we will use it as a convenient and widely-understood example of an
   internal representation.  The database model has the advantage that
   operations on rows have tightly defined meanings.  In addition, it
   appears plausible that larger-scale implementations will employ a
   backend database to store and query rules, as they can then benefit
   from existing optimized indexing, access control, scaling and
   integrity constraint mechanisms.  Smaller-scale implementations may
   well choose different implementations, e.g., a simple traversal of
   the set of rules.

6.1  Identification of Rules

   Each rule is equipped with a parameter that identifies the rule.
   This rule identifier is an opaque token chosen by the RM.  A RM MUST
   NOT use the same identifier for two rules that are available to the
   PS at the same time for a given PT.  The combination <PT identity, RM
   identity, rule identity> uniquely identifies a rule.

6.2  Extensions

   The authorization policy framework defined in this document is meant
   to be extensible towards specific application domains.  Such an
   extension is accomplished by defining conditions, actions and
   transformations that are specific to the desired application domain.
   Each extension MUST define its own namespace and indicate its version
   number.



















Schulzrinne, et al.     Expires January 17, 2005               [Page 12]

Internet-Draft               Common Policy                     July 2004


7.  Conditions

   The access to data items needs to be matched with the rule set stored
   at the PS.  Each instance of a request has different attributes
   (e.g., the identity of the requestor) which are used for
   authorization.  A rule in a rule set might have a number of
   conditions which need to be verified before executing the remaining
   parts of a rule (i.e., actions and transformations).  Details about
   rule matching are described inSection 10.  This document specifies
   only a few conditions (namely identity, sphere, and validity).  Other
   conditions are left for extensions of this document.

7.1  Identity

   The policy framework specified in this document supports the usage of
   authenticated identities as input to access authorization decision
   processes.  This framework, however, abstracts from the
   particularities of concrete authentication mechanisms employed by
   different using protocols and is therefore unable to specify
   explicitly the details of identity relevant information.  Documents
   that enhance this framework should describe how a particular using
   protocol is able to provide identity information in a meaningful way.

   Such an enhancement needs to map the identity used by the
   authentication protocol employed in the using protocol to an identity
   used in the authorization policy.  It is necessary to clearly define
   a mapping between the authenticated identity of the user (and the
   domain of the user) and the identities used in the authorization
   policies.  This mapping needs to consider the large number of
   possible identities used in various authentication protocols and also
   to consider identities in using protocols.  Furthermore, it is
   important to designate an identifier that denotes an 'anonymous
   user', i.e., a user that has not authenticated itself to the PS.  The
   authors suggest to treat anonymous users by omitting this attribute
   in the rule which causes a 'NULL' value to be created in the ruleset
   table of a relational database.  Any request for a data item (for a
   given PT) would match with respect to this attribute in a rule.
   Furthermore, pseudonyms need to be addressed as part of this mapping
   process.

   This specification provides an <identity> element which belongs to
   the group of condition elements.  It can have either the <id> or the
   <domain> element as child elements.  The <domain> element contains a
   list of <except> elements and allows to implement a simple blacklist
   mechanism.  The <except> element contains the identity without the
   domain part since it equals the domain of the <domain> element.  The
   following example illustrates conditions based on an identity.




Schulzrinne, et al.     Expires January 17, 2005               [Page 13]

Internet-Draft               Common Policy                     July 2004


   <identity>
     <id>jack@example.com</id>
   </identity>

   It is allowed to list more than one identity within a single rule as
   described in the following example.  If multiple identities are
   provided in a single rule than the rule matches if one of the listed
   identities in a rule matches the authenticated identity of the entity
   requesting access to a resource.  For the given example the rule
   matches if the entity requesting access to a resource is either
   alice@example.com or bob@example.com.


   <identity>
     <id>alice@example.com</id>
     <id>bob@example.com</id>
   </identity>

   The next example shows how exceptions are implemented.  A request
   MUST match the domain part and all three exceptions parts in an
   atomic fashion to be a successful match.


   <identity>
     <domain>example.com</domain>
     <except>joe</except>
     <except>tony</except>
     <except>mike</except>
   </identity>


7.2  Sphere

   The <sphere> element belongs to the group of condition elements.  It
   can be used to indicate a state (e.g., 'work', 'home', 'meeting',
   'travel') the PT is currently in.  A sphere condition matches only if
   the PT is currently in the state indicated.  The state may be
   conveyed by manual configuration or by some protocol.  For example,
   RPID [I-D.ietf-impp-cpim-pidf] provides the ability to inform the PS
   of its current sphere.  Switching from one sphere to another causes
   to switch between different modes of visibility.  As a result
   different subsets of rules might be applicable.  An example of a rule
   fragment is shown below:








Schulzrinne, et al.     Expires January 17, 2005               [Page 14]

Internet-Draft               Common Policy                     July 2004


     <rule id="f3g44r1">
       <conditions>
         <sphere>work</sphere>
         <identity>
           <id>andrew@example.com</id>
         </identity>
       </conditions>
     </rule>

     <rule id="y6y55r2">
       <conditions>
         <sphere>home</sphere>
         <identity>
           <id>allison@example.com</id>
         </identity>
       </conditions>
     </rule>

   The code snippet above illustrates that the rule with the entity
   andrew@example.com matches if the sphere is been set to 'work'.  In
   the second rule with the entity allison@example.com matches if the
   sphere is set to 'home'.

7.3  Validity

   The <validity> element is the third condition element specified in
   this document.  It expresses the rule validity period by two
   attributes, a starting and a ending time.  Times are expressed in XML
   dateTime format.  Expressing the lifetime of a rule implements a
   garbage collection mechanism.  A rule maker might not have always
   access to the PS to remove some rules which grant permissions.  Hence
   this mechanisms allows to remove or invalidate granted permissions
   automatically without further interaction between the rule maker and
   the PS.

   An example of a rule fragment is shown below:


   <validity>
     <from>2003-08-15T10:20:00.000-05:00</from>
     <to>2003-09-15T10:20:00.000-05:00</to>
   </validity>

   The <identity>, the <sphere> and the <validity> element MUST NOT
   appear more than one in the conditions part of a single rule.  The
   <id< element on the other hand may appear more than once as described
   in this section.




Schulzrinne, et al.     Expires January 17, 2005               [Page 15]

Internet-Draft               Common Policy                     July 2004


8.  Actions

   While conditions are the 'if'-part of rules, actions and
   transformations build the 'then'-part of them.  The actions and
   transformations parts of a rule determine which operations the PS
   MUST execute after having received from a WR a data access request
   that matches all conditions of this rule.  Actions and
   transformations only permit certain operations; there is no 'deny'
   functionality.  Transformations exclusively specify PS-side
   operations that lead to a modification of the data items requested by
   the WR.  Regarding location data items, for instance, a
   transformation could force the PS to lower the precision of the
   location information which is returned to the WR.

   Actions, on the other hand, specify all remaining types of operations
   the PS is obliged to execute, i.e., all operations that are not of
   transformation type.  This document does not define any actions.  The
   reader is referred to the corresponding extensions to see examples of
   such elements.
































Schulzrinne, et al.     Expires January 17, 2005               [Page 16]

Internet-Draft               Common Policy                     July 2004


9.  Transformations

   Two sub-parts follow the conditions part of a rule: transformations
   and actions.  As defined in Section 8, transformations specify
   operations that the PS MUST execute and that modify the result which
   is returned to the WR.  This functionality is particularly helpful in
   reducing the granularity of information provided to the WR, as for
   example required by location information.  This document does not
   define any transformations since they depend on the application
   domain.

   A simple transformation example is provided in Section 10.







































Schulzrinne, et al.     Expires January 17, 2005               [Page 17]

Internet-Draft               Common Policy                     July 2004


10.  Procedure for Combining Permissions

10.1  Introduction

   This section describes the mechanism to evaluate the final result of
   a rule evaluation.  The result is reflected in the action and
   transformation part of a rule.  This procedure is sometimes referred
   as conflict resolution.

   We use the following terminology (which in parts has already been
   introduced in previous sections): The term 'permission' stands for an
   action or a transformation.  The notion 'attribute' terms a
   condition, an action, or a transformation.  An attribute MUST specify
   its name.  An attribute MUST either be equipped with a value of a
   certain data type or it is not equipped with a value.  In the latter
   case the value of this attribute is undefined.  For example, the name
   of the <sphere> attribute discussed in Section 7 is 'sphere', its
   data type is 'string', and its value may be set to 'home'.  The
   values of attributes of the same name MUST all be of the same data
   type.  To evaluate a condition means to associate either TRUE or
   FALSE to the condition.  A rule matches if all conditions contained
   in the conditions part of a rule evaluate to TRUE.

   When the PS receives a request for access to privacy-sensitive data
   then it needs to be matched against a rule set.  The conditions part
   of each individual rule is evaluated and as a result one or more
   rules might match.  If only a single rule matches then the result is
   determined by executing the actions and the transformations part
   following the conditions part of a rule.  However, it can also be the
   case that two or more matching rules contain a permission of the same
   name (e.g., two rules contain a permission named 'precision of
   geospatial location information'), but do not specify the same value
   for that permission (e.g., the two rule might specify values of '10
   km' and '200 km', respectively, for the permission named 'precision
   of geospatial location information').  This section describes the
   procedure for combining permissions in such cases.  The values of
   attributes MUST be of either Boolean, Integer, Set or undefined.  The
   value is undefined if no value is given for a particular attribute.
   Attributes with values of data type Integer can also be used for
   enumerations.  For example, you can enumerate different levels of
   civil location information precision (e.g., level 0 "country, city,
   street" vs.  level 1 "country, city") by associating integers to
   these levels.

10.2  Algorithm

   This section describes the algorithm in a more formal fashion.




Schulzrinne, et al.     Expires January 17, 2005               [Page 18]

Internet-Draft               Common Policy                     July 2004


   The combining rules are simple and depend on the data types of the
   values of permissions: Let P be a policy.  Let M be the subset of P
   consisting of rules r in P that match with respect to a given
   request.  Let n be a name of a permission contained in a rule r in M,
   and let M(n) be the subset of M consisting of rules r in M that have
   a permission of name n.  For each rule r in M(n), let v(r,n) and
   d(r,n) be the value and the data type, respectively, of the attribute
   of r with name n.  Finally, let V(n) be the combined value of all the
   permissions values v(r,n), r in M(n).  The combining rules that lead
   to the resulting value V(n) are the following:

   CR 1: If d(r,n)=Boolean or d(r,n)=Undefined for all r in M(n),  then
   V(n) is given as follows: If there is a r in M(n) with v(r,n)=TRUE,
      then V(n)=TRUE.  Otherwise, V(n)=FALSE.

   CR 2: If d(r,n)=Integer or d(r,n)=Undefined for all r in M(n),  then
   V(n) is given as follows: If v(r,n)=undefined for all r in M(n), then
      V(n) is not specified by this specification.  Otherwise,
      V(n)=max{v(r,n) | r in M(n)}.

   CR 3: If d(r,n)=Set or d(r,n)=Undefined for all r in M(n),  then V(n)
   is given as follows: V(n)=union of all v(r,n), the union to be
      computed over all r in M(n) with v(r,n)!=undefined.


10.3  Example

   In the following example we illustrate the process of combining
   permissions.  We will consider three conditions for our purpose,
   namely those of name identity, sphere, and validity.  For editorial
   reasons the rule set in this example is represented in a table.
   Furthermore, the domain part of the identity of the WR is omitted.
   For actions we use two permissions with names X and Y.  The values of
   X and Y are of data types Boolean and Integer, respectively.
   Permission X might, for example, represent the <confirmation> action.
   For transformations we use the attribute with the name Z whose value
   can be set either to '+'(or 1), 'o' (or 2) or '-' (or 3).  Permission
   Z allows us to show the granularity reduction whereby a value of '+'
   shows the corresponding information unrestricted and '-' shows
   nothing.  This permission might be related to location information or
   other presence attributes like mood.  Internally we use the data type
   Integer for computing the permission of this attribute.









Schulzrinne, et al.     Expires January 17, 2005               [Page 19]

Internet-Draft               Common Policy                     July 2004


   Conditions                       Actions/Transformations
   +--------------------------------+---------------------+
   | Id  WR-ID    sphere  from  to  |  X       Y     Z    |
   +--------------------------------+---------------------+
   |  1   bob      home    A1    A2 |  TRUE    10    o    |
   |  2   alice    work    A1    A2 |  FALSE   5     +    |
   |  3   bob      work    A1    A2 |  TRUE    3     -    |
   |  4   tom      work    A1    A2 |  TRUE    5     +    |
   |  5   bob      work    A1    A3 |  undef   12    o    |
   |  6   bob      work    B1    B2 |  FALSE   10    -    |
   +--------------------------------+---------------------+

   Again for editorial reasons, we use the following abbreviations for
   the two <validity> attributes 'from' and 'to':


   A1=2003-12-24T17:00:00+01:00
   A2=2003-12-24T21:00:00+01:00
   A3=2003-12-24T23:30:00+01:00
   B1=2003-12-22T17:00:00+01:00
   B2=2003-12-23T17:00:00+01:00

   The entity 'bob' acts as a WR and requests data items.  The policy P
   consists of the six rules shown in the table and identified by the
   values 1 to 6 in the 'Id' column.  The PS receives the query at
   2003-12-24T17:15:00+01:00.  The value of the attribute with name
   'sphere' indicating the state the PT is currently in is set to
   'work'.

   Rule 1 does not match since the sphere condition does not match.
   Rule 2 does not match as the identity of the WR (here 'alice') does
   not equal 'bob'.  Rule 3 matches since all conditions evaluate to
   TRUE.  Rule 4 does not match as the identity of the WR (here 'tom')
   does not equal 'bob'.  Rule 5 matches.  Rule 6 does not match since
   the rule is not valid anymore.  Therefore, the set M of matching
   rules consists of the rules 3 and 5.  These two rules are used to
   compute the combined permission V(X), V(Y), and V(Z) for each of the
   permissions X, Y, and Z:


     Actions/Transformations
   +-----------------------+
   |  X       Y      Z     |
   +-----------------------+
   |  TRUE     3     -     |
   |  undef   12     o     |
   +-----------------------+




Schulzrinne, et al.     Expires January 17, 2005               [Page 20]

Internet-Draft               Common Policy                     July 2004


   The results of the permission combining algorithm is shown below.
   The combined value V(X) regarding the permission with name X equals
   TRUE according to the first combining rule listed above.  The maximum
   of 3 and 12 is 12, so that V(Y)=12.  For the attribute Z in this
   example the maximum between 'o' and '-' (i.e., between 2 and 3) is
   '-'.


     Actions/Transformations
   +-----------------------+
   |  X       Y      Z     |
   +-----------------------+
   |  TRUE    12     -     |
   +-----------------------+

   Documents that extend the authorization policy framework defined here
   by introducing application specific actions and transformation MUST
   NOT define permissions whose values are of data type other than
   Boolean, Integer, Set, and Undef.  Furthermore, permissions and the
   meaning of their values MUST be defined in such a way that the usage
   of the combining rules CR 1, CR2, and CR 3 always preserves or
   increases the level of privacy protection for the PT.  In other
   words, the definition of new permissions MUST respect the way in
   which CR 1, CR 2, and CF 3 have been formulated in order to guarantee
   an appropriate level of privacy protection.

   Explicitly, it is not allowed to introduce a new permission whose
   value is of data type ...

      ...  Boolean and the PS-side operation corresponding to the
      permission value TRUE has a lower privacy protection level than
      that operation that corresponds to the value FALSE.

      ...  Integer and for any two permission values v1 and v2, v1 > v2,
      the PS-side operation corresponding to the value v1 has a lower
      privacy protection level than that operation that corresponds to
      the value v2.

      ...  Set and for any two permission values s1 and s2, the PS-side
      operation corresponding to the union of s1 and s2 has a lower
      privacy protection level than those operations that correspond to
      s1 or s2.









Schulzrinne, et al.     Expires January 17, 2005               [Page 21]

Internet-Draft               Common Policy                     July 2004


11.  Meta Policies

   Meta policies authorize a rulemaker to insert, update or delete a
   particular rule or an entire rule set.  Some authorization policies
   are required to prevent unauthorized modification of rule sets.  Meta
   policies are outside the scope of this document.

   A simple implementation could restrict access to the rule set only to
   the PT but more sophisticated mechanisms could be useful.  As an
   example of such policies one could think of parents configuring the
   policies for their children.








































Schulzrinne, et al.     Expires January 17, 2005               [Page 22]

Internet-Draft               Common Policy                     July 2004


12.  Example

   This section gives a basic example of an XML document valid with
   respect to the XML schema defined in Section 13.  Semantically richer
   examples can be found in documents which extend this schema with
   application domain specific data (e.g., location or presence
   information).


   <?xml version="1.0" encoding="UTF-8"?>
   <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">

     <rule id="f3g44r1">

       <conditions>
         <identity>
           <uri>bob@example.com</uri>
         </identity>
         <validity>
           <from>2003-12-24T17:00:00+01:00</from>
           <to>2003-12-24T19:00:00+01:00</to>
         </validity>
       </conditions>

       <actions></actions>

     </rule>

   </ruleset>






















Schulzrinne, et al.     Expires January 17, 2005               [Page 23]

Internet-Draft               Common Policy                     July 2004


13.  XML Schema Definition

   This section provides the XML schema definition for the common policy
   markup language described in this document.


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:common-policy"
     xmlns:cp="urn:ietf:params:xml:ns:common-policy"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

     <xs:element name="ruleset">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="rule" type="cp:ruleType"
             minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

     <xs:complexType name="ruleType">
       <xs:sequence>
         <xs:element name="conditions" minOccurs="0">
           <xs:complexType>
             <xs:sequence>
               <xs:element ref="cp:condition"
                 minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
         <xs:element name="actions" minOccurs="0">
           <xs:complexType>
             <xs:sequence>
               <xs:element ref="cp:action"
                 minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>
         <xs:element name="transformations" minOccurs="0">
           <xs:complexType>
             <xs:sequence>
               <xs:element ref="cp:transformation"
                 minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:complexType>



Schulzrinne, et al.     Expires January 17, 2005               [Page 24]

Internet-Draft               Common Policy                     July 2004


         </xs:element>
       </xs:sequence>
       <xs:attribute name="id" type="xs:string" use="required"/>
     </xs:complexType>

     <xs:element name="condition" abstract="true"/>
     <xs:element name="action" abstract="true"/>
     <xs:element name="transformation" abstract="true"/>

     <xs:element name="validity" substitutionGroup="cp:condition">
       <xs:complexType>
         <xs:all>
           <xs:element name="from" type="xs:dateTime"/>
           <xs:element name="to" type="xs:dateTime"/>
         </xs:all>
       </xs:complexType>
     </xs:element>

     <xs:element name="sphere" type="xs:string"
       substitutionGroup="cp:condition"/>

     <xs:element name="identity" substitutionGroup="cp:condition">
       <xs:complexType>
         <xs:choice>
           <xs:element name="id" type="xs:string"
              maxOccurs="unbounded"/>
           <xs:sequence>
             <xs:element name="domain" type="xs:string"/>
             <xs:sequence minOccurs="0">
               <xs:element name="except" type="xs:string"
                 maxOccurs="unbounded"/>
             </xs:sequence>
           </xs:sequence>
         </xs:choice>
       </xs:complexType>
     </xs:element>

   </xs:schema>

   Although the XML schema does not require detailed explanations the
   following issues are worth mentioning: Each of the <conditions>,
   <actions>, and <transformations> (plural!) elements consists of zero
   or more child elements that belong to the substitution groups
   'condition', 'action', and 'transformation', respectively.  The
   respective heads of these substitution groups are the elements
   <condition>, <action>, and <transformation> (singular!).  These
   elements cannot be used directly in an instance document since they
   are labeled as abstract.



Schulzrinne, et al.     Expires January 17, 2005               [Page 25]

Internet-Draft               Common Policy                     July 2004


   XML schemas that extend this common policy schema by introducing new
   conditions, actions, and transformations MUST declare to which of
   these three substitution group the respective attribute belongs.
   These new attribute elements can then be used as immediate child
   elements of the <conditions>, <actions>, and <transformations>
   elements, depending on to which substitution group they belong.













































Schulzrinne, et al.     Expires January 17, 2005               [Page 26]

Internet-Draft               Common Policy                     July 2004


14.  Security Considerations

   This document describes a framework for authorization policy rules.
   This framework is intended to be enhanced elsewhere towards
   application domain specific data.  Security considerations are to a
   great extent application data dependent, and therefore need to be
   covered by documents that extend the framework defined in this
   specification.  However, new action and transformation permissions
   along with their allowed values must be defined in a way so that the
   usage of the permissions combining rules of Section 10 does not lower
   the level of privacy protection.  See Section 10 for more details on
   this privacy issue.







































Schulzrinne, et al.     Expires January 17, 2005               [Page 27]

Internet-Draft               Common Policy                     July 2004


15.  IANA Considerations

   This section registers a new XML namespace and a new XML schema with
   IANA.

15.1  Common Policy Namespace Registration

   URI: urn:ietf:params:xml:ns:common-policy

   Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne
      (hgs+geopriv@cs.columbia.edu).

   XML:

   BEGIN
   <?xml version="1.0"?>
   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
     "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
   <html xmlns="http://www.w3.org/1999/xhtml">
   <head>
     <meta http-equiv="content-type"
           content="text/html;charset=iso-8859-1"/>
     <title>Common Policy Namespace</title>
   </head>
   <body>
     <h1>Namespace for Common Authorization Policies</h1>
     <h2>urn:ietf:params:xml:ns:common-policy</h2>
     <p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
   </body>
   </html>
   END


15.2  Common Policy Schema Registration

   URI: Please assign.

   Registrant Contact: IETF Geopriv Working Group, Henning Schulzrinne
      (hgs+geopriv@cs.columbia.edu).

   XML: The XML schema to be registered is contained in Section 13.  Its
      first line is

   <?xml version="1.0" encoding="UTF-8"?>

       and its last line is

   </xs:schema>



Schulzrinne, et al.     Expires January 17, 2005               [Page 28]

Internet-Draft               Common Policy                     July 2004


16.  References

16.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

16.2  Informative References

   [I-D.ietf-impp-cpim-pidf]
              Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W.
              and J. Peterson, "Presence Information Data Format
              (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress),
              May 2003, <reference.I-D.ietf-impp-cpim-pidf.xml>.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
              Polk, "Geopriv Requirements", RFC 3693, February 2004,
              <reference.RFC.3693.xml>.


Authors' Addresses

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   450 Computer Science Building
   New York, NY  10027
   USA

   Phone: +1 212 939 7042
   EMail: schulzrinne@cs.columbia.edu
   URI:   http://www.cs.columbia.edu/~hgs


   John B. Morris, Jr.
   Center for Democracy and Technology
   1634 I Street NW, Suite 1100
   Washington, DC  20006
   USA

   EMail: jmorris@cdt.org
   URI:   http://www.cdt.org









Schulzrinne, et al.     Expires January 17, 2005               [Page 29]

Internet-Draft               Common Policy                     July 2004


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com


   Jorge R. Cuellar
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Jorge.Cuellar@siemens.com


   James Polk
   Cisco
   2200 East President George Bush Turnpike
   Richardson, Texas  75082
   USA

   EMail: jmpolk@cisco.com


   Jonathan Rosenberg
   DynamicSoft
   600 Lanidex Plaza
   Parsippany, New York  07054
   USA

   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net















Schulzrinne, et al.     Expires January 17, 2005               [Page 30]

Internet-Draft               Common Policy                     July 2004


Appendix A.  Contributors

   We would like to thank Christian Guenther for his help with this
   document.


   Christian Guenther
   Siemens AG
   Corporate Technology
   81730 Munich
   Email: christian.guenther@siemens.com
   Germany







































Schulzrinne, et al.     Expires January 17, 2005               [Page 31]

Internet-Draft               Common Policy                     July 2004


Appendix B.  Acknowledgments

   This document is partially based on the discussions within the IETF
   GEOPRIV working group.  Discussions at the Geopriv Interim Meeting
   2003 in Washington, D.C., helped the working group to make progress
   on the authorization policies based on the discussions among the
   participants.

   We particularly want to thank Allison Mankin <mankin@psg.com>,
   Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
   <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
   Peterson <jon.peterson@neustar.biz> for discussing a number of
   details with us.  They helped us to improve the quality of this
   document.

   Furthermore, we would like to thank the IETF SIMPLE working group for
   their discussions of J.  Rosenberg's draft on XCAP authorization
   policies.  We thank Stefan Berg, Christian Schmidt, Markus Isomaki
   and Eva Maria Leppanen for their comments.
































Schulzrinne, et al.     Expires January 17, 2005               [Page 32]

Internet-Draft               Common Policy                     July 2004


Appendix C.  Enhancements to the Combining Permissions Algorithm

   This section contains text, which should replace the text in Section
   10, if approved by the Geopriv working group.  It aims to enhance the
   combining permissions algorithm to offer a better privacy protection
   and to fix technical problems with the current algorithm.

C.1  Introduction

   This section describes the mechanism that MUST be employed in order
   to determine the actions and transformations the PS has to employ
   when processing a request for privacy-sensitive data.  When a PS
   receives such a request, the PS MUST evaluate the set of rules
   applicable to the request.  According to this specification, a rule
   set consists of a set of rules each of which is composed of
   conditions, actions and transformations.

   First of all, the PS MUST determine the set of matching rules within
   the rule set.  To this end, the PS MUST evaluate the conditions part
   of each rule contained in the rule set.  To evaluate the conditions
   part of a rule means to associate either TRUE or FALSE to each
   condition contained in the conditions part of the rule.  A rule
   matches if all conditions contained in the conditions part of a rule
   evaluate to TRUE.

   Secondly, the PS MUST determine the actions and transformations it
   has to perform.  If the set of matching rules consists of a single
   rule only, then the PS MUST execute the actions and transformations
   as specified in that rule.  However, it can also be the case that two
   or more matching rules contain a permission of the same name (e.g.,
   two rules contain a permission named
   'location-information-precision'), but do not specify the same value
   for that permission (e.g., the two rules might specify values of '10
   km' and '200 km', respectively, for the permission named
   'location-information-precision').  This section describes the
   procedure for combining actions and transformations in such cases.
   The notion 'permission' is used herein as a generic term for 'action'
   and 'transformation'.

   In order to come to an executable procedure for combining
   permissions, each permission definition MUST specify the name and the
   data type of it.  Each permission MUST be either of data type
   'Boolean', 'Integer', or 'Set'.  In case of 'Boolean', the permission
   can have the values 'TRUE' or 'FALSE'.  In case of 'Integer', the
   permitted values of a permission of this type are the integer number
   values.  In case of 'Set', the definition of a permission of this
   type MUST also include the definition of the names and the elements
   of the sets that are permitted as values of such permissions.



Schulzrinne, et al.     Expires January 17, 2005               [Page 33]

Internet-Draft               Common Policy                     July 2004


   For example, a permission named 'civil location information' that is
   to specify different precision levels of civil location information
   could be realized by specifying that it is of data type 'Set' and
   that the set named 'level 1' consists of the elements 'country',
   'city', and 'street', while the set named 'level 2' has the elements
   'country' and 'city' only.

   The data type 'Integer' also allows for enumerations when defining
   permissions: For example, instead of using the 'Set' data type, you
   could also define the permission indicating different precision
   levels of civil location information by enumerating these levels
   (e.g., level A, level B, ...), associating integer values to the
   single enumeration values (e.g., 1, 2, ...), and specifying the
   meaning of these values (e.g., level A stands for "country, city,
   street", level B stands for "country, city", and so on).  This does
   not contradict the fact that permissions must be either of data type
   'Boolean', 'Integer', or 'Set', as you MUST associate integer values
   to the single enumeration values when defining permission by
   enumeration.

   Now, it is necessary to have a means of preserving the level of
   privacy-protection when combining two permissions.  The problem here
   is as follows: Assume, a first matching rule contains the permission
   named 'location-information-precision' of data type 'Integer' which
   has been equipped with the value 1 permitting the level of location
   information precision that consists of 'country', 'city' and 'street'
   data.  A second matching rule (which might have a different set of
   conditions when compared to the first rule, but is also matching just
   like the first) also comprises the permission named
   'location-information-precision', but this time specifying a value of
   2 admitting 'country' and 'city' level precision only.

   In favor of privacy protection, it is necessary to combine these two
   permissions to a rule that permits 'country' and 'city' level
   location information only.  Mathematically spoken and respecting the
   fact that the locatin-information-precision permission had been
   defined in this example in such a way that its values 1 and 2
   represent lower and higher levels of pricacy protection,
   respectively, it is necessary to combine these two permissions by
   calculating the maximum of its single values: combined value =
   maximum of single values = max{1,2} = 2 = 'country' and 'city' level
   of precision.

   However, the 'location-information-precision' permission could have
   been specified in another way as well: the value of 1 could have been
   made representing 'country' and 'city' only, while the value of 2
   could represent 'country', 'city' and 'street'.  Now, it were
   necessary to combine these two rules by calculating the minimum and



Schulzrinne, et al.     Expires January 17, 2005               [Page 34]

Internet-Draft               Common Policy                     July 2004


   not the maximum of the single value.  Similar problems occur also for
   the permission data types 'Boolean' and 'Set'.

   Computer programs responsible for combining permissions must
   therefore get indicated which algorithm is to be employed when
   combining a permission of a given name.  This is accomplished by the
   requirement that each permission definition has not only to specify
   its name and data type but also exactly one of the following six
   combining rules (CRs):

      CR-Boolean-Or

      CR-Boolean-And

      CR-Integer-Minimum

      CR-Integer-Maximum

      CR-Set-Intersection

      CR-Set-Union

   What these combining rules actually mean from the algorithmic
   perspective will be detailed in the next paragraph.  From the XML
   point of view, authors of XML policy languages that are to be
   integrated under the roof of the common policy framework MUST use the
   XML built-in element <appinfo> when defining new permissions in XML
   schemas and equip this element with one of the six character strings
   above representing one of the six possible combining rules.  This
   approach guarantees that each computer program that has access to the
   XML schema specifying a certain policy language within the common
   policy framework can apply the combining rule that is specified by
   the permission definition's child element <appinfo>.

   To give an example: A location information-specific XML policy
   language might define a permission named 'latitude-resolution' of
   data type 'Integer' which is to indicate the number of digits
   permitted to be sent to a certain set of receivers.  In order to
   fulfill the requirement discussed above, the XML schema defining that
   policy language should specify the 'latitude-resolution'
   transformation as follows:










Schulzrinne, et al.     Expires January 17, 2005               [Page 35]

Internet-Draft               Common Policy                     July 2004


     <xs:element name="latitude-resolution"
                 type="xs:integer"
                 substitutionGroup="cp:transformation">
         <xs:annotation>
             <xs:appinfo>
                 CR-Integer-Minimum
             </xs:appinfo>
         </xs:annotation>
     </xs:element>


C.2  Algorithms

   This section describes the algorithms for the six possible combining
   rules in a formal fashion.

   The combining rules are simple and depend on the data types of the
   values of permissions: Let P be a policy, i.e., a rule set.  Let M be
   the subset of P consisting of rules r in P that match with respect to
   a given request.  Let n be a name of a permission contained in a rule
   r in M, D(n) be the data type of the permissions of name n, and let
   M(n) be the subset of M consisting of rules r in M that have a
   permission of name n.  For each rule r in M(n), let v(r,n) be the
   value of the permission of name n contained in the rule r.  Finally,
   let CV(n) be the combined value of all the permissions values v(r,n),
   r in M(n).  The combining rules CR-Boolean-Or, CR-Boolean-And,
   CR-Integer-Minimum, CR-Integer-Maximum, CR-Set-Intersection and
   CR-Set-Union MUST be implemented as follows:

   CR-Boolean-Or: This CR is applicable only if D(n)=Boolean:
      CV(n)=Or{v(r,n) | r in M(n)}.  This means: CV(n)=TRUE if and only
      if there is a value v(r,n), r in M(n), with v(r,n)=TRUE.

   CR-Boolean-And: This CR is applicable only if D(n)=Boolean:
      CV(n)=And{v(r,n) | r in M(n)}.  This means: CV(n)=TRUE if and only
      if for all r in M(n): v(r,n)=TRUE.

   CR-Integer-Minimum: This CR is applicable only if D(n)=Integer:
      CV(n)=Minimum{v(r,n) | r in M(n)}.

   CR-Integer-Maximum: This CR is applicable only if D(n)=Integer:
      CV(n)=Maximum{v(r,n) | r in M(n)}.

   CR-Set-Intersection: This CR is applicable only if D(n)=Set:
      CV(n)=Intersection{v(r,n) | r in M(n)}.






Schulzrinne, et al.     Expires January 17, 2005               [Page 36]

Internet-Draft               Common Policy                     July 2004


   CR-Set-Union: This CR is applicable only if D(n)=Set:
      CV(n)=Union{v(r,n) | r in M(n)}.


C.3  Example

   In the following example we illustrate the process of combining
   permissions.  We will consider three conditions for our purpose,
   namely those of name identity, sphere, and validity.  For editorial
   reasons the rule set in this example is represented in a table.
   Furthermore, the domain part of the identity of the WR is omitted.
   For actions we use two permissions with names X and Y.  The values of
   X and Y are of data types Boolean and Integer, respectively.  The
   combining rules that must be employed when combining values of X and
   Y are CR-Boolean-Or and CR-Integer-Maximum, respectively.

   For transformations we use the permission with the name Z whose value
   can be set either to '-'(or 1), 'o' (or 2) or '+' (or 3).  Its
   combining rule is CR-Integer-Minimum.  Permission Z allows us to show
   the granularity reduction whereby a value of '+' shows the
   corresponding information unrestricted and '-' shows nothing.  This
   permission might be related to location information or other presence
   attributes like mood.  Internally we use the data type Integer for
   computing the permission of this attribute.


   Conditions                       Actions/Transformations
   +--------------------------------+---------------------+
   | Id  WR-ID    sphere  from  to  |  X       Y     Z    |
   +--------------------------------+---------------------+
   |  1   bob      home    A1    A2 |  TRUE    10    o    |
   |  2   alice    work    A1    A2 |  FALSE   5     +    |
   |  3   bob      work    A1    A2 |  TRUE    3     -    |
   |  4   tom      work    A1    A2 |  TRUE    5     +    |
   |  5   bob      work    A1    A3 |  undef   12    o    |
   |  6   bob      work    B1    B2 |  FALSE   10    -    |
   +--------------------------------+---------------------+

   Again for editorial reasons, we use the following abbreviations for
   values of the two <validity> attributes 'from' and 'to':


   A1=2003-12-24T17:00:00+01:00
   A2=2003-12-24T21:00:00+01:00
   A3=2003-12-24T23:30:00+01:00
   B1=2003-12-22T17:00:00+01:00
   B2=2003-12-23T17:00:00+01:00




Schulzrinne, et al.     Expires January 17, 2005               [Page 37]

Internet-Draft               Common Policy                     July 2004


   The entity 'bob' acts as a WR and requests data items.  The policy P
   consists of the six rules shown in the table and identified by the
   values 1 to 6 in the 'Id' column.  The PS receives the query at
   2003-12-24T17:15:00+01:00.  The value of the attribute with name
   'sphere' indicating the state the PT is currently in is set to
   'work'.

   Rule 1 does not match since the sphere condition does not match.
   Rule 2 does not match as the identity of the WR (here 'alice') does
   not equal 'bob'.  Rule 3 matches since all conditions evaluate to
   TRUE.  Rule 4 does not match as the identity of the WR (here 'tom')
   does not equal 'bob'.  Rule 5 matches.  Rule 6 does not match since
   the rule is not valid anymore.  Therefore, the set M of matching
   rules consists of the rules 3 and 5.  These two rules are used to
   compute the combined permission values CV(X), CV(Y), and CV(Z) for
   each of the permissions X, Y, and Z:


     Actions/Transformations/Combining Rules
   +-----------------------------------------------------------+
   |  X               Y                    Z                   |
   +-----------------------------------------------------------+
   |  TRUE             3                   - (1)               |
   |  undef           12                   o (2)               |
   |  CR-Boolean-Or   CR-Integer-Maximum   CR-Integer-Minimum  |
   +-----------------------------------------------------------+

   The results of the permission combining algorithms are shown below.
   The combined value CV(X) regarding the permission with name X equals
   TRUE according to its combining rule CR-Boolean-Or.  The maximum of 3
   and 12 is 12, so that CV(Y)=12.  For the attribute Z in this example,
   the minimum between '-' and 'o' (i.e., between 1 and 2) is '-'.


     Actions/Transformations
   +-----------------------+
   |  X       Y      Z     |
   +-----------------------+
   |  TRUE    12     - (1) |
   +-----------------------+

   Documents that extend the authorization policy framework defined here
   by introducing application specific actions and transformations MUST
   NOT define permissions whose values are of data type other than
   Boolean, Integer, and Set.  At least, the actual data type used in
   the permission definition MUST be representable by means of these
   three data types.  In such cases, the mapping between the data type
   used and one of the three standard data types Boolean, Integer, and



Schulzrinne, et al.     Expires January 17, 2005               [Page 38]

Internet-Draft               Common Policy                     July 2004


   Set MUST be given explicitly when using another permission data type
   (such as an enumeration data type or the data type that consists of
   the values '-', 'o' and '+' as illustrated above).

   Furthermore, permissions and the meaning of their values MUST be
   defined in such a way that the application of one of the six
   combining rules specified in this section actually preserves the
   level of privacy protection when determining combined values of
   single permission values contained in several matching rules.  For
   example, this requirement implies that permission values of data type
   'Integer' are ordered in such a way that either lower values
   correspond to lower privacy protection levels and higher values to
   higher levels, or vice versa.  However, the value 1 MUST NOT
   correspond to a medium level of privacy protection, 3 to a lower and
   2 to a higher, for instance, so that neither the application of
   CR-Integer-Minimum nor of CR-Integer-Maximum would result in
   reasonable, privacy-protecting combined value.


































Schulzrinne, et al.     Expires January 17, 2005               [Page 39]

Internet-Draft               Common Policy                     July 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Schulzrinne, et al.     Expires January 17, 2005               [Page 40]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/