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 May 22, 2005.

Copyright Notice

Copyright (C) The Internet Society (2004).

Abstract

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
2.  Terminology
3.  Basic Data Model and Processing
4.  Rule Transport
    4.1  HTTP
    4.2  SIP Message Body
5.  Securing the Location Object
6.  Conditions
    6.1  Civil Location Condition
    6.2  Geospatial Location Condition
        6.2.1  Altitude
        6.2.2  Polygon
7.  Actions
8.  Transformations
    8.1  Distribution Transformation
    8.2  Retention Transformation
    8.3  Keep Rules Transformation
    8.4  Timezone Transformation
    8.5  Civil Location Transformation
    8.6  Geospatial Location Transformation
9.  Example
    9.1  Rule Example with Civil Location Condition
    9.2  Rule Example with Geospatial Location Information
10.  XML Schema
11.  Security Considerations
12.  References
12.1  Normative References
12.2  Informative References
§  Authors' Addresses
A.  Contributors
B.  Acknowledgments
§  Intellectual Property and Copyright Statements

1. Introduction

Location information needs to be protected against unauthorized access to preserve the privacy of the owner of the location information. In [RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004., 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 authorization policy rules. An authorization policy is a set of rules that regulate an entity's activities with respect to privacy-sensitive information such as location information. The data object containing LI is referred to as Location Object (LO).

Two namespaces have been defined by means of which authorization policies governing access to LI can be formulated: first, the basic rule set defined in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004. 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. Second, this document describes an enhanced rule set that provides richer constraints on the distribution of LOs.

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 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]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.. The resulting rule is applied to the location data, yielding a possibly modified location object that is delivered to the location recipient.

The protocols used to query location information (between LS and LR), to update authorization policies at the LS and the protocol between LG and 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.

This document extends the framework defined in [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.. That document provides an abstract framework for expressing authorization 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' and 'transformations'. 'Transformations' implement a mechanism to regulate LSs' handling of LOs in terms of data retention as well as data and policy distribution, and to modify information elements returned to the requestor (e.g., to reduce the granularity of location information).

The XML schema in Section 10XML Schema extends the XML-based authorization framework (see [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.) by introducing new members of the 'condition' and 'transformation' substitution groups defined there. The schema does not define new types of 'actions'. To express civil location information, it makes use of that schema in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004. that defines the 'civilAddress' complex type.

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]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..

This document reuses the terminology of [RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004., e.g., the terms Location Server (LS) and Location Recipient (LR). We subsequently refer to the terminology used in [RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004. as Geopriv. This document and [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004. share the following terminology:

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.

authorization policy:

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.

permission:

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]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004.. 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, H., A Document Format for Expressing Privacy Preferences, October 2004..

3. Basic Data Model and Processing

As the Geopriv policy markup language defined in Section 10XML Schema extends the Common policy markup language in [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004., this document adopts the basic data model as introduced in Section 6 of [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004..

4. Rule Transport

The XML data format of the Geopriv LO is specified in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004.. The definition of the LO there allows the authorization policy associated to the LO to be carried in two different ways: by value or by reference. To make use of the first possibility, an authorization policy as specified by this document can be integrated directly into the XML representation of the LO. For the second alternative, the LO data format definition in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004. provides the optional 'ruleset-reference' element which contains an URI that indicates where a rule set related to the LO can be found.

One of the transformations of the rule set is the removal of the rule set described here before transmission. Only the whole rule set can be removed and not individual elements (for example, some conditions). Before transmitting the rules to the LR, unless explicitly permitted by the authorization policy, the rule set MUST be removed from the LO, since the rule set might disclose which entities the RM trusts (see Section 8Transformations).

Transaction semantics for authorization 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.

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]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.).

4.1 HTTP

A rule set could be uploaded to the LS using an HTTP POST or via WEBDAV [RFC2518]Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, HTTP Extensions for Distributed Authoring -- WEBDAV, February 1999.. Each rule could be modeled as a single file, with the rule identifier as a file name. One example of this approach is XCAP [I-D.ietf-simple-xcap]Rosenberg, J., The Extensible Markup Language (XML) Configuration Access Protocol (XCAP), November 2004., the XML Configuration Access Protocol. Since multiple rules may have the same LR identity in the condition part of the rule, the LR identity cannot be used as file name.

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.

5. Securing the Location Object

The Geopriv requirements document [RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004. 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]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004., 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 authorization 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.

6. Conditions

This section describes the location-specific conditions of a rule, namely the civil and geo-spatial location conditions. The XML elements and attributes quoted subsequently are defined by the Geopriv policy markup languge whose corresponding XML schema can be found in Section 10XML Schema.

6.1 Civil Location Condition

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 [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004.. 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]Schulzrinne, H., Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information, October 2004.. This designation offers street-level precision.

If the civil location of the target is not known, rules that contain a civil location condition 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 Condition

In addition to the civil location condition, this specification also allows to make authorization decisions based on the current geospatial location of the target. A rule matches if the current location of the Target is contained in a specific area.

6.2.1 Altitude

The altitude condition matches if the target altitude is defined and is between the minimum and maximum stated in the rule, in meters.

6.2.2 Polygon

The condition matches if the longitude and latitude values of the polygon, interpreted as x and y coordinates on a plane, enclose the current location of the target.

There are a number of algorithms for determining whether a point is inside a polygon. A common algorithm draws a ray from the test point to the right. The test point is inside if and only if the ray intersects the line segments making up the polygon an odd number of times.

The listed points, which constitute the polygon, MUST be listed as they appear in a clockwise direction all the way around the perimeter of the single plane shape. The final point MUST be a repeat of the first point listed to enclose the polygon.

7. Actions

According to the common policy framework [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004., 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 regulate the LS-side operations that directly influence the handling of location information. 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.

8. Transformations

The Geopriv policy markup language defines several elements by means of which Rulemakers can specify transformations. For example, these transformations regulate the LS-side behavior in terms of how long a LS is permitted to store a given LO, whether the LO may be distributed or not, and at which level of accuracy the LS is allowed to pass location information on.

All transformations defined in this section are privacy-safe in the sense that, if the evaluation of the authorization policy related to a given LO does not produce an explicit transformation instruction, the LS MUST execute the transformation in question at the highest level of privacy protection.

Extensions to this document may define other transformations.

8.1 Distribution Transformation

This transformation can be specified by means of the <distribution-transformation> element whose value is of boolean type. With respect to a given LO, a LS is allowed to distribute this LO, if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <distribution-transformation> element,

2)

at least one of the rules safisfying 1) matches, and

3)

the combined value of this permission is 'true' (see [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004. for the term 'combined value').

In all other cases, the LS MUST NOT distribute the LO in question. In particular, this also comprises the case of an authorization policy that does not contain a rule with a <distribution-transformation> element.

8.2 Retention Transformation

This transformation can be specified by means of the <retention-transformation> element whose value is of integer type. With respect to a given LO, a LS is allowed to retain this LO for at most t>0 seconds after reception of the LO, if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <retention-transformation> element,

2)

at least one of the rules satisfying 1) matches, and

3)

the combined value of this permission is t.

In all other cases, the LS MUST delete the LO immediately upon the LS-side completion of the service that makes use of the LO. In particular, this also comprises the case of an authorization policy that does not contain a rule with a <retention-transformation> element, and the case in which a matching rule contains this element but its combined value is less than or equal to 0.

8.3 Keep Rules Transformation

This transformation can be specified by means of the <keep-rules-transformation> element whose value is of boolean type. With respect to a given LO, a LS is allowed to keep all authorization policy rules in the LO when passing this LO on, if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <keep-rules-transformation> element,

2)

at least one of the rules satisfying 1) matches, and

3)

the combined value of this permission is 'true'.

In all other cases, the LS MUST remove all authorization policy rules from the LO. In case of rules stated explicitly ('by value') inside the LO, this means to completely remove the rules from the LO; in case of a pointer to an authorization policy rule ('by reference') inside the LO, this means to remove the pointer from the LO. See Section 4Rule Transport for the different ways of attaching authorization policy rules to LOs.

8.4 Timezone Transformation

This transformation can be specified by means of the <timezone-transformation> element whose value is of boolean type. With respect to a given LO, a LS is allowed to provide the timezone information corresponding to the LO, if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <timezone-transformation> element,

2)

at least one of the rules safisfying 1) matches, and

3)

the combined value of this permission is 'true'.

In all other cases, the LS MUST NOT provide timezone information. In particular, this also comprises the case of an authorization policy that does not contain a rule with a <timezone-transformation> element.

8.5 Civil Location Transformation

The civil location transformation can be specified by means of the <civil-loc-transformation> element to restrict the level of civil location information the LS is permitted to provide. From lowest to highest level, the names of these levels are: 'null', 'country', 'region', 'city', 'building', 'full'. Each level is given by a set of civil location data items such as <country> and <A1>, ..., <A6>, as defined in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004.. 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:

                           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
                            {}

With respect to a given LO, a LS is permitted to pass civil location information corresponding to the given LO on at the level l (l='country', 'region', 'city', 'building', or 'full'), if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <civil-loc-transformation> element,

2)

at least one of the rules satisfying 1) matches, and

3)

the combined value of this permission is the level l.

In all other cases, including the case in which no rule of the authorization policy related to the given LO contains a <civil-loc-transformation> element, the LS MUST remove all civil location information from the LO before passing it on, thereby providing the 'null' level of civil location information.

8.6 Geospatial Location Transformation

The geospatial location transformation can be specified by means of the <geospatial-loc-transformation> element to restrict the resolution of the geospatial location information to the value provided in the <latitude-resolution>, <longitude-resolution> and <altitude-resolution> child elements of the <geospatial-loc-transformation> element. The resolution is specified as a positive, non-zero decimal number r. If n is the nominal coordinate value, the rounded value is computed as

floor(n/r + 0.5) * r.

For example, if the latitude is n=38.89868 and r=0.01, the latitude value rendered to the recipient of the location object is 38.90. If the longitude is n=77.03723 and r=0.01, the longitude is rendered as 77.04. This computation also works for r that are not integer powers of 10 or r > 1. For example, to round longitude to timezone accuracy, one would use r=15 and obtain a value of 75 in this example.

With respect to a given LO and to the latitude coordinate of ellipsoidal geospatial location information, a LS is allowed to pass the latitude value corresponding to the given LO on at the resolution value r, if and only if all of the following preconditions are satisfied:

1)

the authorization policy related to the LO contains a rule with a <geospatial-loc-transformation> element that has a <latitude> element,

2)

at least one of the rules satisfying 1) matches, and

3)

the combined value of this permission is r.

In all other cases, the LS MUST remove the latitude value from the geospatial location information. Substituting in this paragraph 'latitude' by 'longitude' and 'altitude', respectively, yields the corresponding regulations for the longitude and altitude coordinate.

9. Example

This section gives two simple examples for authorization policy rules that make use of the civil and the geospatial location condition.

9.1 Rule Example with Civil Location Condition

This example illustrates a single rule that employs the civil location condition which matches if the current location of the Target is inside the area specified by the child elements of the <civil-loc-condition> element. The syntax of this content complies with the 'civilAddress' complex type defined in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004.. In this example, requests match only if the Target is at his main office in a Siemens site in Munich.

The rule is valid for one year as specified by the <validity> element. No actions are imposed on LSs. The <transformations> section indicates that LSs are allowed to distribute the LOs with authorization policy included, to provide timezone and the full set of civil location information, and to pass latitude and longitude values of geospatial location information on at quite a high level of resolution. Since the policy does not contain a rule with a <retention-transformation>, LSs have to delete LOs immediately upon service completion.

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

  <cp:rule id="AA56i09">

    <cp:conditions>

      <cp:validity>
        <cp:from>2004-11-01T00:00:00+01:00</cp:from>
        <cp:to>2005-11-01T00:00:00+01:00</cp:to>
      </cp:validity>

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

    <cp:actions></cp:actions>

    <cp:transformations>

      <gp:distribution-transformation>
        true
      </gp:distribution-transformation>

      <gp:keep-rules-transformation>
        true
      </gp:keep-rules-transformation>
      
      <gp:timezone-transformation>
        true
      </gp:timezone-transformation>
      
      <gp:civil-loc-transformation>full</gp:civil-loc-transformation>
      
      <gp:geospatial-loc-transformation>
        <gp:lat-resolution>0.00001</gp:lat-resolution>
        <gp:lon-resolution>0.00001</gp:lon-resolution>
      </gp:geospatial-loc-transformation>
       
    </cp:transformations>

  </cp:rule>

</cp:ruleset>

9.2 Rule Example with Geospatial Location Information

This example illustrates a rule that employs the geospatial location condition which matches if the current location of the Target is inside the area specified by the <point> child elements of the <polygon> element. The individual points of the polygon have to be interpreted as points of the WGS-84 coordinate reference system, as specified by the value of the 'crsName' attribute of the <polygon> element. This coordinate reference systems is also used by GPS. The given four points specify a quadrangle on the surface of the rotational ellipoid being part of the WGS-84 system, corresponding to a certain area in Washington, DC, USA.

The Target associated to this authorization policy must be located within that area in order to make the rule match.

The transformation part of the example rule allows LSs to distribute LO from which all authorization policy rules or pointers to them have been removed. LSs are permitted to retain LOs related to the Target in question for at most one hour. They are allowed to provide civil location information about the Target at city level of precision, and geospatial location information at a rather low level of resolution. The rule below specifies that LSs must not provide timezone information inside LOs as the <timezone-transformation> has been omitted.

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

  <cp:rule id="BB56A09">

    <cp:conditions>

      <cp:validity>
        <cp:from>2004-11-01T00:00:00+01:00</cp:from>
        <cp:to>2005-11-01T00:00:00+01:00</cp:to>
      </cp:validity>

      <gp:geospatial-loc-condition>
        <gp:polygon 
          crsName="urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84">
          <gp:point>
            <gp:lat>38.8986</gp:lat>
            <gp:lon>-77.03724</gp:lon>
          </gp:point>
          <gp:point>
            <gp:lat>38.8986</gp:lat>
            <gp:lon>-77.03722</gp:lon>
          </gp:point>
          <gp:point>
            <gp:lat>38.8987</gp:lat>
            <gp:lon>-77.03722</gp:lon>
          </gp:point>
          <gp:point>
            <gp:lat>38.8987</gp:lat>
            <gp:lon>-77.03724</gp:lon>
          </gp:point>           
        </gp:polygon>
     </gp:geospatial-loc-condition>
      
    </cp:conditions>

    <cp:transformations>

      <gp:distribution-transformation>
        true
      </gp:distribution-transformation>

      <gp:keep-rules-transformation>
        false
      </gp:keep-rules-transformation>
      
      <gp:retention-transformation>
        3600
      </gp:retention-transformation>   
      
      <gp:civil-loc-transformation>city</gp:civil-loc-transformation>
      
      <gp:geospatial-loc-transformation>
        <gp:lat-resolution>0.2</gp:lat-resolution>
        <gp:lon-resolution>0.1</gp:lon-resolution>
      </gp:geospatial-loc-transformation>   

    </cp:transformations>

  </cp:rule>

</cp:ruleset>

The next ruleset indicates that the Target has to be between 1500 and 4000 meters in order for this rule to match.

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

  <cp:rule id="BB56A19">

    <cp:conditions>

      <cp:validity>
        <cp:from>2004-11-01T00:00:00+01:00</cp:from>
        <cp:to>2005-11-01T00:00:00+01:00</cp:to>
      </cp:validity>
      
      <gp:geospatial-loc-condition>
         <gp:altitude>
             <cp:min>1500.0</cp:min>
             <cp:max>4000.0</cp:max>
         </gp:altitude>         
      </gp:geospatial-loc-condition>
      
    </cp:conditions>

    <cp:transformations>

      <gp:distribution-transformation>
        true
      </gp:distribution-transformation>

      <gp:keep-rules-transformation>
        false
      </gp:keep-rules-transformation>
      
      <gp:retention-transformation>
        3600
      </gp:retention-transformation>   
      
      <gp:civil-loc-transformation>city</gp:civil-loc-transformation>
      
      <gp:geospatial-loc-transformation>
        <gp:lat-resolution>0.3</gp:lat-resolution>
        <gp:lon-resolution>0.2</gp:lon-resolution>
      </gp:geospatial-loc-transformation>   

    </cp:transformations>

  </cp:rule>

</cp: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]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004., Section 10.

10. XML Schema

This section presents the XML schema that defines the Geopriv policy language 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]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.) 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]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.).

This way, the Geopriv policy markup language specializes the common rules markup language for location-based presence information. To this end, the following schema imports the vocabulary of the common policy markup language. Furthermore, to express civil location conditions, it imports the 'civilAddress' complex type as defined in [I-D.ietf-geopriv-pidf-lo]Peterson, J., A Presence-based GEOPRIV Location Object Format, September 2004..

<?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="cp02.xsd"/>

  <xs:import
    namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
    schemaLocation="civilloc03.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:choice>
        <xs:element name="polygon">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="point"
                minOccurs="3" maxOccurs="unbounded">
                <xs:complexType>
                  <xs:sequence>
                    <xs:element name="lat" type="xs:double"
                      minOccurs="1" maxOccurs="1" />
                    <xs:element name="lon" type="xs:double"
                      minOccurs="1" maxOccurs="1"/>
                    </xs:sequence>
                </xs:complexType>
              </xs:element>
            </xs:sequence>
            <xs:attribute name="crsName" type="xs:anyURI"/>
          </xs:complexType>
        </xs:element>
        <xs:element name="altitude">
          <xs:complexType>
            <xs:sequence>
                <xs:element name="min" type="xs:double"
                      minOccurs="1" maxOccurs="1" />
                <xs:element name="max" type="xs:double"
                      minOccurs="1" maxOccurs="1"/>
            </xs:sequence>
            </xs:complexType>
        </xs:element> 
        <xs:any namespace="##other" processContents="lax"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
      
  <!-- Geopriv transformations -->

  <xs:element name="distribution-transformation"
    type="xs:boolean" substitutionGroup="cp:transformation"/>
       
  <xs:element name="retention-transformation"
    type="xs:integer" substitutionGroup="cp:transformation"/>

  <xs:element name="keep-rules-transformation"
    type="xs:boolean" substitutionGroup="cp:transformation"/>

  <xs:element name="timezone-transformation"
    type="xs:boolean" substitutionGroup="cp:transformation"/>
       
  <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="geospatial-loc-transformation"
    substitutionGroup="cp:transformation">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="lat-resolution" type="xs:double"
          minOccurs="0" maxOccurs="1" />
        <xs:element name="lon-resolution" type="xs:double"
          minOccurs="0" maxOccurs="1"/>
        <xs:element name="alt-resolution" type="xs:double"
          minOccurs="0" maxOccurs="1"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>

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]Danley, M., Mulligan, D., Morris, J. and J. Peterson, Threat Analysis of the Geopriv Protocol, February 2004. and are applicable to this draft as well. Requirements are addressed in [RFC3693]Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J. Polk, Geopriv Requirements, February 2004.. Section 5Securing the Location Object addresses issues of protecting the policy rules within the LO and location information itself. Aspects of combining permissions in cases of multiple occurrence are treated in [I-D.ietf-geopriv-common-policy]Schulzrinne, H., A Document Format for Expressing Privacy Preferences, October 2004.). How the behavior of LSs can be regulated in terms of location object handling in a privacy-safe fashion is specified in Section 8Transformations.

12. References

12.1 Normative References

12.2 Informative References

Authors' Addresses

Appendix A. Contributors

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

Christian Guenther
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81730
Germany
      
EMail: christian.guenther@siemens.com

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.

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.