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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 RFC 6772

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


   A Document Format for Expressing Privacy Preferences for Location
                              Information
                      draft-ietf-geopriv-policy-02

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she 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




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

Internet-Draft               Geopriv Policy                    July 2004


   This document defines an authorization policy language for controling
   access to location information.  It extends the authorization
   framework of the common policy markup language towards
   location-specific access control needs.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Basic Data Model and Processing  . . . . . . . . . . . . . . .  6
   4.  Rule Transport . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1   HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2   SIP Message Body . . . . . . . . . . . . . . . . . . . . .  7
     4.3   Location Object  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Securing the Location Object . . . . . . . . . . . . . . . . .  9
   6.  Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1   Civil Location . . . . . . . . . . . . . . . . . . . . . . 10
     6.2   Geospatial Location  . . . . . . . . . . . . . . . . . . . 10
   7.  Actions  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Transformations  . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1   Set D (Distribute) Flag  . . . . . . . . . . . . . . . . . 13
     8.2   Set R (Retention) Time . . . . . . . . . . . . . . . . . . 13
     8.3   Keep Rule (RR) . . . . . . . . . . . . . . . . . . . . . . 13
     8.4   Provide Civil Location . . . . . . . . . . . . . . . . . . 13
     8.5   Provide Geospatial Location  . . . . . . . . . . . . . . . 14
     8.6   Provide Timezone Flag  . . . . . . . . . . . . . . . . . . 16
   9.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   10.   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 19
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 21
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 22
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 22
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 22
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
   A.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 27















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

Internet-Draft               Geopriv Policy                    July 2004


1.  Introduction

   Location information needs to be protected against unauthorized
   access to preserve the privacy of the owner of the location
   information.  Therefore a protocol-independent model for access to
   geographic information was defined.  The model includes a Location
   Generator (LG) that produces Location Information (LI), a Location
   Server (LS) that authorizes access to LI, a location recipient (LR)
   that requests and receives information, and a Rulemaker (RM) that
   provides policy rules to the LS which enforce access control policies
   on access to a target.

   Two policy namespaces have been defined.  The first basic rule set
   [I-D.peterson-geopriv-pres] can restrict how long the receiver can
   retain the information and it can prohibit any further distribution
   of the information.  It does not allow to customize information to
   specific receivers, for example.  This document describes an enhanced
   rule set that provides richer constraints on the distribution of the
   Location Objects (LOs).  We assume that a basic location
   object[I-D.peterson-geopriv-pres] can contain a reference to
   additional rule sets.

   We refer to any entity that uses the rules in this document to
   restrict the retention or distribution of information as a Rule
   Enforcer (RE).  The rule set allows the RE to enforce access
   restrictions on location data, including prohibiting any
   dissemination to particular individuals or during particular times.
   The RM can also stipulate that only certain parts of the location
   object are to be distributed to recipients or that the resolution of
   parts of the location object is limited.

   The sequence of operations can be described as follows.  The LS
   receives either a query for location information of a particular
   Target, via the using protocol.  The using protocol provides the
   identity of the requestor, either at the time of the query or
   subscription to the location information.  The authenticated identity
   of the LR, 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 merging algorithm described in
   [I-D.ietf-geopriv-common-policy].  The resulting rule is applied to
   the location data, yielding a possibly modified location object that
   is delivered to the location recipient.

   Note that the protocols used to query location information (between
   LS and LR), update policies at the LS and the protocol between the LG
   to LS and from LS to LR do not have to be the same.  This document
   does not mandate a specific protocol for any of them.



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

Internet-Draft               Geopriv Policy                    July 2004


   This document is part of extends the framework defined
   in[I-D.ietf-geopriv-common-policy].  That document provides an
   abstract authorization framework for expressing policy rules.  As
   specified there, each such rule consists of 'conditions', 'actions'
   and 'transformations'.  Conditions determine under which
   circumstances the LS is permitted to perform 'actions'.
   'Transformations' implement a mechanism to optionally modify
   information elements returned to the requestor (e.g., to reduce the
   granularity of location information).  The term 'transformation' is
   also known as 'provisional action'.

   The XML schema in Section 10 extends the XML based authorization
   framework (see [I-D.ietf-geopriv-common-policy]) by introducing new
   members of the 'condition' and 'transformation' substitution groups
   defined there.  To express civil location information, it makes use
   of the schema in Section 2.2.3 of [I-D.ietf-geopriv-pidf-lo] that
   defines the 'civilAddress' complex type.


































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

Internet-Draft               Geopriv 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 reuses the terminology of[RFC3693].  We subsequently
   refer to the terminology used in [RFC3693] as Geopriv.  This section
   assists in the alignment between the terminology defined in
   [I-D.ietf-geopriv-common-policy] and in this document.  This document
   uses the terms LS, LR and RM.

   PT - Presentity / Target: Geopriv uses the term Target to identify
      the object or person of which location information is required.

   RM - Rule Maker: The entity RM corresponds to the Geopriv Rulemaker.

   PS - (Authorization) Policy Server: The PS corresponds to the
      Location Server (LS) in the Geopriv terminology.

   WR - Watcher / Recipient: The WR represents the Location Recipient
      (LR) in the Geopriv terminology.

   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.

   The Geopriv policy markup language refers to the authorization
   language defined in this document.  The Common policy markup language
   refers to the authorization language described in
   [I-D.ietf-geopriv-common-policy].







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

Internet-Draft               Geopriv Policy                    July 2004


3.  Basic Data Model and Processing

   As the Geopriv policy markup language defined in Section 10 extends
   the Common policy markup language in
   [I-D.ietf-geopriv-common-policy], this document adopts the basic data
   model as introduced in Section 6 of [I-D.ietf-geopriv-common-policy].













































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

Internet-Draft               Geopriv Policy                    July 2004


4.  Rule Transport

   We make no assumption as to how rules are conveyed to entities within
   the network.  Purely as examples, we below describe a few plausible
   options.  None of the rule elements depend on the properties of how
   rule sets are conveyed to an LS or LR.  Mechanisms may allow partial
   updates of rule sets.  A partial update is an update which modifies
   only parts of the rule set in contrast to a full update.  To simplify
   such partial updates, each rule is labelled with an identifier (see
   [I-D.ietf-geopriv-common-policy]).

   Transaction semantics for policy rule updates are not required since
   'permit only' and 'additive permissions' properties have to be used.
   These properties also prevent inconsistency during concurrent query
   and update operations.

4.1  HTTP

   A rule set could be uploaded to the LS via an HTTP POST operation or
   more fully-featured WEBDAV [RFC2518].  Each rule could be modeled as
   a single 'file', with the rule identifier as a file name.  (Since
   multiple rules may have the LR identity in the condition part of the
   rule, the LR identity cannot be used.) One example of this approach
   includes XCAP[I-D.ietf-simple-xcap].

   The rule set can also be referenced from within a location object.
   The attribute 'ruleset-reference' specified in Section 2.2.2 of
   [I-D.peterson-geopriv-pres] contains an URI that indicates where a
   rule set related to this object can be found.  The URI MAY
   alternatively use the CID URI scheme in which case it MUST denote a
   MIME body carried with the Location Object by the using protocol.

4.2  SIP Message Body

   The rule set can be carried, as a separate MIME message body, in the
   SIP message that conveys location information from a LG (a SIP UAC)
   via an LS (a SIP proxy) to an LR (a SIP UAS).  The rule set would
   then govern the behavior expected of the LR.

4.3  Location Object

   The rule set can be carried in LOs in two ways: by reference and by
   value.  In either case the 'ruleset-reference' attribute inside the
   LO [I-D.peterson-geopriv-pres] points to the location of the rules.
   The LG or the LS can attach the rule set (or a pointer to it) to the
   location object.

   One of the transformations of the rule set is the removal of the rule



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

Internet-Draft               Geopriv Policy                    July 2004


   set described here before further transmission.  Only the whole rule
   set can be removed and not individual elements (for example, some
   conditions).  Before transmitting the rules to the LR, the rule set
   SHOULD be removed since the rule set might disclose prefences of the
   rule maker which entities to trust and to which other entities no
   trust is available.  Revealing this information might have negative
   implication for the RM itself.












































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

Internet-Draft               Geopriv Policy                    July 2004


5.  Securing the Location Object

   The Geopriv requirements draft [RFC3693] addresses the minimal
   security protection required for the LO: Mutual end-point
   authentication, data object integrity, data object confidentiality
   and replay protection.  As proposed in[I-D.ietf-geopriv-pidf-lo] S/
   MIME SHOULD be used.  Protection for the LO also includes an attached
   rule set.

   Protection is likely to be necessary against adversaries who
   eavesdrop on the communication between the LS and the LR or the LG
   and the LS, who tamper with the LO or who replay previously recorded
   LOs.  Securing the communication between RM and LS depends on the
   protocol which is used to perform the desired actions (e.g., https).
   The communication between the LG and the LS can also be secured using
   channel security.

   If the LO is integrity and confidentiality-protected then the
   receiving entity (LS or LR) has to be able to decrypt and to verify
   the LO.  Since the policy rules described in this document allow the
   modification of the LO (via granularity reduction or by setting
   flags), it is not possible to forward the LO without reapplying the
   cryptographic protection.  This is particularly true for the LS as it
   is not the final consumer of the LO.

   When the LS protects the LO for transmission to the LR (after
   successful authorization), then the authenticated identity can be
   used to select a security association to apply proper protection of
   the location object.  Securing the LO for multiple LRs is not
   provided.

   Instead of encrypting the LO, the LG could digitally sign the LO,
   offering integrity, but no confidentiality.  However, if the LS needs
   to perform modifications on the LO, then it would have to break the
   digital signature and may apply its own digital signature.

   Since the LO is generally distributed to more than one LR, the LG
   lacks the necessary information about the recipient and thus cannot
   usually apply confidentially protection.

   By default, the LS re-signs LOs if the signed LO has been modified
   according to the rule set.  If the LS receives an LO that it cannot
   decrypt, it discards it if and only if the rule requires modification
   of the content.

   It remains for further study whether there should be an action that
   discards an LO that is signed or encrypted and needs to be modified
   according to the matching rule set.



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

Internet-Draft               Geopriv Policy                    July 2004


6.  Conditions

   This section describes the location-specific conditions of a rule,
   namely the civil and geo-spatial location conditions.

6.1  Civil Location

   The <civil-loc-condition> element matches if the current location of
   the target matches all the values specified in the child elements of
   this element.  The <civil-loc-condition> is of the 'civilAddress'
   complex type defined in Section 2.2.3 of [I-D.ietf-geopriv-pidf-lo].
   It includes a number of fields, including the country (expressed as a
   two-letter ISO 3166 code), and the administrative units A1 through A6
   of[I-D.ietf-geopriv-dhcp-civil].  This designation offers
   street-level precision.

   If the civil location of the target is not known, rules that contain
   a civil location never match.  (This case may occur, for example, if
   location information has been removed by earlier transmitters of
   location information or if only the geospatial location is known.)

   If any of the elements <A1> through <A6> are specified, <country>
   MUST also be specified.  The schema does not enforce that the
   specification uniquely identifies a particular location.  For
   example, it would be possible to omit the region and match only on
   city name, so that any city sharing that name within a country would
   match.  This feature is primarily designed to deal with users that
   may not know the administrative divisions between country and city
   level.  For example, many users may not know the county for cities in
   the United States.

6.2  Geospatial Location

   Geospatial location conditions can be expressed by means of the
   <geospatial-loc-condition> element.  Such a condition makes the rule
   match if the Target is currently located within the trapezoid on the
   surface of the earth that is bounded by the values of longitude and
   latitude elements <longitude1>, <longitude2>, <latitude1>, and
   <latitude2>, regardless of the altitude value, if present; Figure 1
   shows this.  The northern boundary of this trapezoid is on the
   latitude given by the value of the <latitude1> element
   correspondingly, the southern boundary is given by the value of the
   <latitude2> element.  The western boundary of this trapezoid is on
   the longitude given by the value of the <longitude1> element, and its
   eastern boundary is on the longitude given by the value of the
   <longitude2> element.





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

Internet-Draft               Geopriv Policy                    July 2004


                             <latitude1>
                      _________________________
                     /                         \
                    /                           \
                   /    _________                \
     <longitude1> /    /         \                \<longitude2>
                 /    /  Target   \                \
                /    /             \                \
               /    /---------------\                \
              /                                       \
             /                                         \
            /                                           \
           /---------------------------------------------\
                           <latitude2>


           Figure 1: Example Trapezoids North of the Equator

   The Target knows where it is (shown as the inner trapezoid).  This
   trapezoid might be greater in size than the dimensions of the Target
   due to precision of the measuring device issues.  The rule is a match
   if the outer trapezoid completely encloses the inner trapezoid.





























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

Internet-Draft               Geopriv Policy                    July 2004


7.  Actions

   According to the common policy
   framework[I-D.ietf-geopriv-common-policy], actions and
   transformations included in a rule determine which operations the LS
   MUST execute after having received from a LR a location data access
   request that matches all conditions of this rule.  Transformations
   exclusively specify LS-side operations that lead to a modification of
   the location data items requested by the LR.  Actions, on the other
   hand, specify all remaining types of operations the LS is obliged to
   execute, i.e., all operations that are not of transformation type.
   This document does not define new, location-specific actions.







































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

Internet-Draft               Geopriv Policy                    July 2004


8.  Transformations

   In addition to the transformations below, the LS MAY translate, add
   or remove location information.  For example, they may add timezone
   information based on civil information.

   All transformations are privacy-safe, i.e., if a transformation is
   NULL (i.e., if the attribute is not present or empty in a policy
   rule), the LS removes the corresponding location information from the
   LO and leaves the LO flags undisturbed.

   Extensions to this document may define other transformations.

8.1  Set D (Distribute) Flag

   This transformation sets the D flag in the location object to either
   'true' or 'false'.  A value of 'true' means the recipient of the LO
   is allowed to further distribute it.  A value of 'false' prevents
   further distribution.

   The value NULL keeps the D flag in the LO as is.  The default value
   is 'false'.

8.2  Set R (Retention) Time

   The retention transformation sets the retention value in the location
   object to the current time plus the time provided in the element,
   measured in seconds.

   The value NULL keeps the retention time in the LO as is.  If the LO
   did not contain a value then the LS sets it to a configured default
   value.

8.3  Keep Rule (RR)

   If the Keep Rule (RR) flag is set, any extended rules included in the
   location object are kept.

8.4  Provide Civil Location

   The Provide Civil Location transformation restricts the civil
   location to one of six levels, from lowest to highest: null, country,
   region, city, building, full.  Each level includes all elements
   included by the lower levels.  The 'country' level includes only the
   <country> element; the 'region' level adds the <a1> element; the
   'city' level adds the <a2> and <a3> elements; the 'building' level
   and the 'full' level add further civil location data as shown below.




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

Internet-Draft               Geopriv Policy                    July 2004


   If this action is NULL, all civil information is removed from the LO.

   The values for this attribute are used in the following hiearchy:


                              Full
         {<Country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>,
           <PRD>, <POD>, <STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>,
                      <NAM>, <FLR>, <ZIP>}
                               |
                            Building
         {<Country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>,
         <PRD>, <POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>, <ZIP>}
                               |
                             City
                     {<Country>, <A1>, <A2>}
                               |
                             Region
                        {<Country>, <A1>}
                               |
                             Country
                           {<Country>}
                               |
                             'NULL'
                               {}



8.5  Provide Geospatial Location

   The Provide Geospatial Location transformation restricts the
   resolution of the geospatial location information to the number of
   bits provided, separately for longitude and latitude, and altitude
   (if present) .  The default value is zero.

   For purposes of this transformation, longitude and latitude are
   treated as a 34 bit fixed point value consisting of 9 bits of integer
   and 25 bits of fraction.  Altitude is treated as a fixed-point 22-bit
   integer part with a 8-bit fraction, measured in meters.  This
   corresponds to the representation in [RFC3825], but does not
   constrain the representation in the location object.

   Longitude, latitude and altitude are not to be conveyed in is 2s-
   complement form in the this text based protocol, but rather in
   decimal form for easier reading.  Conversation between the two forms
   is for resolution altering.  For example (as given in the appendix of
   [RFC3825], the civic address of the White House in Washington, DC
   (US) is:



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

Internet-Draft               Geopriv Policy                    July 2004


      White House

      1600 Pennsylvania Ave.  NW

      Washington, DC 20006

   which is equivalent to the coordinates (using the WGS84 datum):


      Latitude 38.89868 degrees North (or +38.89868 degrees)

      Using 2s complement, 34 bit fixed point, 25 bit fraction

      Latitude = 0x04dcc1fc8,

      Latitude = 0001001101110011000001111111001000


      Longitude 77.03723 degrees West (or -77.03723 degrees)

      Using 2s complement, 34 bit fixed point, 25 bit fraction

      Longitude = 0xf65ecf031,

      Longitude = 1101100101111011001111000000110001

   All three values above (each for latitude and for longitude) are
   equivalent (barring rounding).  Using 2 forms that are of the same
   representation (decimal, hex and 2s-complement binary), the size of
   the point a numbering pair represent is approximately 3.11mm by
   2.62mm.  When reducing the resolution of the 'point' one is
   conveying, reducing the length of the raw binary number increases the
   size of the point (to the point of not being a point, but a square
   with an upper and lower bound to all that is within this area).

   For example, if

   o  the resolution were reduced (here using the LaRes and LoRes values
      within the DHCP Option) to 22 (0x16 or 010110), for each - it
      would describe a geo-location area that is latitude 38.896816
      north to latitude 38.8985596 and extends from -77.0372314 degrees
      to -77.0371094 degrees longitude.  This is an area of
      approximately 143 square meters (10.5m x 13.6m).

   o  the resolution were reduced (here using the LaRes and LoRes values
      within the DHCP Option) to 18 (0x12 or 010010), for each - it
      would describe a geo-location area that is latitude 38.8984375
      north to latitude 38.9003906 and extends from -77.0390625 degrees



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

Internet-Draft               Geopriv Policy                    July 2004


      to -77.0371094 degrees longitude.  This is an area of
      approximately 36,600 square meters (169m x 217m).

   o  the resolution were reduced (here using the LaRes and LoRes values
      within the DHCP Option) to 5 (0x05 or 000101), for each - it would
      describe a geo-location area that is latitude 32 north of the
      equator to latitude 48 and extends from -64 degrees to -80 degrees
      longitude.  This is approximately an east-west boundary of a time
      zone, an area of approximately 700,000 square nm.

   All 3 examples above were from the same 3.11mm x 2.62mm point, merely
   with a reduced resolution.

   The altitude value was not adjusted in any example.  It is:

      Altitude 15 (meters is the unit) being precise for the White
      House.

   If the transformation value is NULL, all geospatial location
   information is removed from the LO.

8.6  Provide Timezone Flag

   The 'Provide Timezone' transformation indicates the inclusion or
   removal of timezone information of the target, i.e., the offset from
   UTC.  The value of 'false' causes timezone information to be excluded
   from the LO.

   If the transformation value is NULL, all timezone information is
   removed from the LO.





















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

Internet-Draft               Geopriv Policy                    July 2004


9.  Example

   The example of this section illustrates a rule set with a single
   rule.  The conditions given in this rule match to a location
   requestor named ted@example.com (provided as a SIP URI in our
   example).  The rule is valid for one year (2003-10-01 to 2004-10-01).
   Requests only match if the target is at his main office in a Siemens
   site in Munich.  This is specified by means of the content of the
   <civil-loc-condition> element.  The syntax of this content complies
   with the 'civilAddress' complex type defined in Section 2.2.3 of
   [I-D.ietf-geopriv-pidf-lo].  The <transformations> section indicates
   that all civil location information is provided to the location
   requestor.  The distribution flag is set to 'false' and the rules
   included in the LO are left unmodified.



   <?xml version="1.0" encoding="UTF-8"?>
   <common-policy:ruleset
     xmlns:geopriv-policy="urn:ietf:params:xml:ns:geopriv-policy"
     xmlns:common-policy="urn:ietf:params:xml:ns:common-policy"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
       "urn:ietf:params:xml:ns:geopriv-policy geopriv-policy01.xsd
        urn:ietf:params:xml:ns:common-policy  common-policy00.xsd">

     <common-policy:rule id="AA56i09">

       <common-policy:conditions>
         <common-policy:validity>
           <common-policy:from>2003-10-01T17:00:00+01:00
                  </common-policy:from>
           <common-policy:to>2004-10-01T00:00:00+01:00
                  </common-policy:to>
         </common-policy:validity>

         <geopriv-policy:civil-loc-condition>
           <country>DE</country>
           <A1>Bavaria</A1>
           <A3>Munich</A3>
           <A4>Perlach</A4>
           <A6>Otto-Hahn-Ring</A6>
           <HNO>6</HNO>
         </geopriv-policy:civil-loc-condition>
       </common-policy:conditions>

       <common-policy:actions> </common-policy:actions>




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

Internet-Draft               Geopriv Policy                    July 2004


       <common-policy:transformations>
         <geopriv-policy:civil-loc-transformation>full
                 </geopriv-policy:civil-loc-transformation>
         <geopriv-policy:set-distribution>false
                 </geopriv-policy:set-distribution>
         <geopriv-policy:keep-rules>true</geopriv-policy:keep-rules>
       </common-policy:transformations>

     </common-policy:rule>

   </common-policy:ruleset>


   In case of a policy consisting of more than one rule and a request
   for location information that let multiple rules match, there must be
   a procedure for combining the permissions contained in the matching
   rules.  This procedure is defined in
   [I-D.ietf-geopriv-common-policy], Section 10.

































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

Internet-Draft               Geopriv Policy                    July 2004


10.  XML Schema

   This section specifies an XML schema for the authorization policies
   described in the previous sections.  The Geopriv policy markup
   language introduced by this schema extends the common policy markup
   language (see [I-D.ietf-geopriv-common-policy]) by introducing new
   members of the 'condition' and 'transformation' substitution groups
   whose heads (namely the elements <condition> and <transformation>)
   are specified by the common policy schema (once again,
   see[I-D.ietf-geopriv-common-policy]).  This way, the Geopriv policy
   markup language specializes the common rules markup language towards
   location-based presence information.  To this end, the following
   schema imports the vocabulary of the common policy markup language.
   Furthermore, to express civil location information, it imports the
   'civilAddress' complex type as defined in section 2.2.3
   of[I-D.ietf-geopriv-pidf-lo].



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

     <xs:import namespace="urn:ietf:params:xml:ns:common-policy"
       schemaLocation="cp00.xsd"/>

     <xs:import
       namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
       schemaLocation="civilLoc.xsd"/>

     <!-- Geopriv conditions -->

     <xs:element name="civil-loc-condition" type="cl:civilAddress"
       substitutionGroup="cp:condition"/>

     <xs:element name="geospatial-loc-condition"
        substitutionGroup="cp:condition">
       <xs:complexType>
         <xs:all>
           <xs:element name="longitude1" type="xs:double"/>
           <xs:element name="longitude2" type="xs:double"/>
           <xs:element name="latitude1" type="xs:double"/>



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

Internet-Draft               Geopriv Policy                    July 2004


           <xs:element name="latitude2" type="xs:double"/>
          </xs:all>
       </xs:complexType>
     </xs:element>

     <!-- Geopriv transformations -->

     <xs:element name="civil-loc-transformation"
       substitutionGroup="cp:transformation">
       <xs:simpleType>
         <xs:restriction base="xs:string">
           <xs:enumeration value="full"/>
           <xs:enumeration value="building"/>
           <xs:enumeration value="city"/>
           <xs:enumeration value="region"/>
           <xs:enumeration value="country"/>
         </xs:restriction>
       </xs:simpleType>
     </xs:element>

     <xs:element name="set-retention" type="xs:integer"
       substitutionGroup="cp:transformation"/>
     <xs:element name="set-distribution" type="xs:boolean"
       substitutionGroup="cp:transformation"/>
     <xs:element name="keep-rules" type="xs:boolean"
       substitutionGroup="cp:transformation"/>
     <xs:element name="longitude-resolution" type="xs:integer"
       substitutionGroup="cp:transformation"/>
     <xs:element name="latitude-resolution" type="xs:integer"
       substitutionGroup="cp:transformation"/>
     <xs:element name="altitude-resolution" type="xs:integer"
       substitutionGroup="cp:transformation"/>
     <xs:element name="provide-timezone" type="xs:boolean"
       substitutionGroup="cp:transformation"/>

   </xs:schema>















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

Internet-Draft               Geopriv Policy                    July 2004


11.  Security Considerations

   This document aims to make it simple for users to prevent the
   unintended disclosure of private information to third parties.
   Security threats are described in [RFC3694] and are applicable to
   this draft as well.  Requirements are addressed in [RFC3693].
   Section 5 addresses issues of protecting the policy rules within the
   LO and location information itself.  Aspects of combining permissions
   in a privacy-safe fashion are illustrated in Section 8.










































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

Internet-Draft               Geopriv Policy                    July 2004


12.  References

12.1  Normative References

   [I-D.ietf-geopriv-common-policy]
              Schulzrinne, H., Morris, J., Tschofenig, H., Cuellar, J.,
              Polk, J. and J. Rosenberg, "A Document Format for
              Expressing Privacy Preferences",
              draft-ietf-geopriv-common-policy-01 (work in progress),
              July 2004.

   [I-D.ietf-geopriv-pidf-lo]
              Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", draft-ietf-geopriv-pidf-lo-01 (work in progress),
              February 2004.

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

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

   [RFC3694]  Danley, M., Mulligan, D., Morris, J. and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", RFC 3694,
              February 2004.

12.2  Informative References

   [I-D.ietf-geopriv-dhcp-civil]
              Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses",
              draft-ietf-geopriv-dhcp-civil-02 (work in progress), March
              2004.

   [I-D.ietf-simple-xcap]
              Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)",
              draft-ietf-simple-xcap-02 (work in progress), February
              2004, <reference.I-D.ietf-simple-xcap.xml>.

   [I-D.peterson-geopriv-pres]
              Peterson, J., "A Presence Architecture for the
              Distribution of Geopriv Location Objects",
              draft-peterson-geopriv-pres-00 (work in progress),
              February 2003.

   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
              Jensen, "HTTP Extensions for Distributed Authoring --



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

Internet-Draft               Geopriv Policy                    July 2004


              WEBDAV", RFC 2518, February 1999.

   [RFC3825]  Polk, J., Schnizlein, J. and M. Linsner, "Dynamic Host
              Configuration Protocol Option for Coordinate-based
              Location Configuration Information", RFC 3825, July 2004.


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


   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



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

Internet-Draft               Geopriv Policy                    July 2004


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

   EMail: jmpolk@cisco.com












































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

Internet-Draft               Geopriv Policy                    July 2004


Appendix A.  Contributors

   We would like to thank Christian Guenther for his help with the XML
   schema in this document.


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







































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

Internet-Draft               Geopriv 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 their time discussing a
   number of details with us.  They helped us to improve the quality of
   this document.





































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

Internet-Draft               Geopriv 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 27]


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