[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Internet Draft                                       John B. Morris, Jr.
Document: draft-morris-geopriv-core-00.txt          Center for Democracy
Expires April 28, 2003                                    and Technology

                                                             D. Mulligan
                                              Samuelson Law, Technology,
                                                and Public Policy Clinic

                                                              J. Cuellar
                                                              Siemens AG

                                                            October 2002
                      Core Privacy Protections for
                        Geopriv Location Object


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

Copyright Notice

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

Abstract

   In designing the requirements for the Geopriv Location Object (LO), a
   key question for the working group is whether to include privacy-
   protecting rules inside the LO itself, and if so, how many and what
   rules should be contained in the LO.  The Internet-Draft first
   suggests that the LO should contain at least a limited set of privacy
   rule fields, and second proposes a set of rules for inclusion in the
   Location Object.

   Morris, Mulligan, Cuellar                                         1
                       Core Privacy Protections           October 2002



Table of Contents

   1. Introduction and Overview....................................... 2
   2. Conventions used in this document............................... 4
   3. Core Privacy Elements for the "Limited Internal" Approach....... 4
   4. Specific Articulation of Core Privacy Elements.................. 5
   5. Possible Alternate Implementation of Proposed Rule 3............ 6
   6. Additional Discussion of Proposed Privacy Elements and Rules.... 6
   7. Draft Requirements Language for "Limited Internal" Approach..... 7
   8. Security Considerations......................................... 8
   9. Acknowledgements................................................ 9
   10. References..................................................... 9
   11. Author's Addresses............................................. 9
   12. Full Copyright Statement....................................... 9




1. Introduction and Overview

   A critical question facing the Geopriv working group is whether the
   Location Object (LO) to be designed should include fields for
   particular privacy-protecting rules, or instead should simply refer
   to an external set of privacy rules.

   There are at least four plausible answers to this question, labeled
   somewhat arbitrarily as follows:

        * "Entirely External" -- the LO should only contain a URI
           reference to an external set of privacy rules that must be
           followed by any recipient of the LO.

        * "Bare Bones Internal" -- the LO should contain at most one or
           two rules that specify, for example, that the Location
           Information (LI) shall not be retained past xyz date (or
           longer than xyz duration), along with a URI reference to an
           external set of privacy rules that must be followed by any
           recipient of the LO.

        * "Limited Internal" -- the LO should contain a limited set of
           rules (say, 4 to 7 rules) that cover the great bulk of likely
           privacy situations (as well as the ability to include a URI
           reference to an external set of privacy rules if more robust
           rules are needed, or external rule storage is preferred).

        * "Full Internal" -- the LO should be defined to be able to
           contain a full, robust, and potentially complex set of
           privacy rules.




   Morris, Mulligan, Cuellar                                         2
                       Core Privacy Protections           October 2002

   The "Full Internal" option would yield the most complex LO, would be
   the most complex to define and implement, and may not be consistent
   with the goal of enabling the use of the Geopriv LO on constrained
   devices or with limited bandwidth.

   Some working group participants have expressed the view that the
   "Entirely External" approach would be the quickest for the working
   group to accomplish, and that if fully implemented in the marketplace
   the approach could give end users a great deal of control and
   flexibility in the protection of Location Information.

   Other WG participants (including at least some of the authors here)
   have argued that the most effective way to ensure that users have
   some privacy control is for the LO to be able to carry a limited
   number of privacy rules.

   It is not the purpose of this Internet-Draft to attempt to advance
   and defend a definitive answer to this critical question.  Instead,
   this I-D articulates one approach to the "Limited Internal" set of
   privacy rules.  By specifying one view of how the Limited Internal
   set of rules might be expressed, the Internet-Draft hopes to allow
   the WG to assess some detailed specifics of that option.

   Note that the "Limited Internal" approach is effectively a superset
   of the "Entirely External" and "Bare Bones Internal" approaches, so
   that both of those models could be implemented in appropriate
   situations even if the LO can carry a larger set of rules.  Thus,
   where a particular location service application in fact offers users
   robust and effective means to create and maintain an external set of
   privacy rules, that application could simply transmit the URI/URL of
   those external rules in the Location Object.  But where an
   application lacks robust and effective external rule servers, the
   "Limited Internal" approach would allow a core set of rules to be
   carried with the LO.

   Five separate things follow below.  First, there is a brief and
   broad-brush statement of the core privacy elements that we think
   should be contained in a "Limited Internal" design of the Location
   Object.  Second, there is a more precise proposal on exactly how to
   articulate and express these elements; significantly, this proposal
   combines three of the elements into one "permissions table."  Third,
   there is an alternate proposal that adds a few additional elements to
   the proposed permissions table, and thereby significantly enhances
   the power of the LO privacy protections.  Fourth, there are a few
   additional comments about the proposals.  Fifth and last is language
   in the form of a Requirement that could be inserted into a
   requirements document if the WG chooses the "Limited Internal"
   approach.






   Morris, Mulligan, Cuellar                                         3
                       Core Privacy Protections           October 2002

2. Conventions used in this document

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



3. Core Privacy Elements for the "Limited Internal" Approach

   The following are seven elements suggested to be included in a
   "Limited Internal" approach to the Location Object.  The first five
   elements (A - E) describe specific possible privacy rules.  The sixth
   element (F) allows a reference to an external set of privacy rules if
   the first five rules are insufficient in scope or complexity, or if
   external rule storage is preferred in a given application.  The final
   element (G) would facilitate the development of third party location
   and privacy-protecting services, and would permit a constrained
   Device to direct a Location Sighter to send Location Information to a
   specific destination with a specific instruction.

   Note that most of the elements and rules discussed below are phrased
   in terms of prohibitions ("do not disclose except to . . ."), but
   could probably as effectively be phrased in terms of permissions
   ("permitted to disclosed only to . . . ").

        A.  Limitation on length of data retention

        B.  Limitation on any retransmission or further disclosure

        C.  Permission to disclose only to specified individual/entity

        D.  Permission to disclose only to someone presenting a
            specified key (for instance, a shared key or the private
            key corresponding to a particular public key), or a special
            type of credential (an e-token to be defined).

        E.  Requirement that location granularity/precision of location
            information be reduced

        F.  Requirement that external privacy rules be followed

        G.  Instruction that location be transmitted to specified
            external privacy or location service with specified
            instruction.

   Section 6 below contains some discussion of these elements (such as,
   for example, a reason to articulate elements C and D separately).






   Morris, Mulligan, Cuellar                                         4
                       Core Privacy Protections           October 2002

4. Specific Articulation of Core Privacy Elements

   The following attempts to express the above broad principles in more
   precise language, combining three elements into a single "permissions
   table":

        Rule 1:  (Element A) Do not retain my location information [past
                 xyz time+date OR longer than xyz duration].

        Rule 2:  (Element B) Do not retransmit or further disclose my
                 location information.

        Rule 3:  (Elements C, D, E) Do not retransmit or further
                 disclose my location information EXCEPT to [abc] if he
                 presents [xyz] credential or key, and only at [uvw]
                 accuracy, where

          [abc] allows for wildcards including "any" or "any@some-
                specific-domain"
          [xyz] allows for wildcards and "no additional credential
                required beyond the [abc] identity"
          [uvw] has one of the following values:

                A = no granularity change required
                B = 10 kilometer radius (or within lat/long quadrant)
                C = 100 kilometer radius (or within larger quadrant)
                D = local or municipal civil designation (e.g., city)
                E = state or regional civil designation (e.g., state)
                F = national designation (e.g., country)
                G = time zone

          These elements would appear in a permissions table:

                | Location seeker | Credential | Accuracy |
                |                 |            |          |
                |  [abc1]         |  [xyz1]    |  [uvw1]  |
                |  [abc2]         |  [xyz2]    |  [uvw2]  |
                |  [abc3]         |  [xyz3]    |  [uvw3]  |
                |  [abc4]         |  [xyz4]    |  [uvw4]  |

        Rule 4:  (Element F) Do not retransmit or further disclose my
                 location information except in full compliance with the
                 privacy rules located at [url/uri].

        Rule 5:  (Element G) Promptly transmit my location to [abc]
                 individual or entity, along with [xyz] instruction
                 (where the contents of [xyz] are NOT defined by Geopriv
                 except for technical parameters such as maximum size).






   Morris, Mulligan, Cuellar                                         5
                       Core Privacy Protections           October 2002

5. Possible Alternate Implementation of Proposed Rule 3

   The permissions table suggested in Rule 3 above could have some
   additional values that would greatly increase the flexibility of the
   LO rules, along the following lines:

   |LocSeek|Credent|LocRes|TimeRes|Notif |Consent|Accuracy| Val |Policy
   |[abc1] |[xyz1] |  r1  |   t1  |  n1  |  c1   | [uvw1] | tt1 | p1
   |[abc2] |[xyz2] |  r2  |   t2  |  n2  |  c2   | [uvw2] | tt2 | p2
   |[abc3] |[xyz3] |  r3  |   t3  |  n3  |  c3   | [uvw3] | tt3 | p3
   |[abc4] |[xyz4] |  r4  |   t4  |  n4  |  c4   | [uvw4] | tt4 | p4

        where

        r is a Location Restriction:  r represents a region where this
             policy applies (for instance, if I am in Munich, then it is
             OK to pass this information)

        t is a Time Restriction (only during working hours may my boss
             obtain my location)

        n is a "notification bit": send me a notification if you send
             this Location Information to Location Seeker abc

        c is a "consent bit": ask me for permission in real time (and
             let the Location Seeker abc wait until I tell you)

        tt is a "valid-until" field: this permission is valid until time
             tt

        p is the pointer to the privacy rules/policy that the Location
             Seeker has to obey for this specific [abc] Location Seeker



6. Additional Discussion of Proposed Privacy Elements and Rules

   The following are additional comments and explanations of the above
   privacy elements and rules:

        a.  At least Rules 1 and 2 should be expressible in both
   machine-readable form as well as an optional human-readable form.
   Rules 3 - 5 are primarily intended to be read by Location Servers
   that have sufficient intelligence to process the rules.  But when
   sending Location Information to an Ultimate Location Recipient, it is
   possible that the Geopriv Location Object (LO) itself would need to
   contain some human-readable information (for example, if the LO is
   sent to a ULR using SMTP or HTTP).  This approach is analogous to the
   full and compact versions of privacy policies under P3P.





   Morris, Mulligan, Cuellar                                         6
                       Core Privacy Protections           October 2002

        b.  Element B and Rule 2 could possibly be omitted as a separate
   flag or field, because a "do not distribute" instruction should be a
   fundamental default for the Geopriv Location Object.  Nevertheless,
   there is value in having an express "do not redistribute" indicator,
   especially to emphasize that instruction to Ultimate Location
   Recipients (who, as discussed above, may well be humans receiving the
   LO essentially directly).

        c.  Elements C (disclose only to specified individual) and D
   (disclose only to someone presenting a key or credential) could
   theoretically be consolidated, because establishing the identity in C
   would effectively be using some form of credential.  The elements,
   however, are expressed separately to emphasize that a Rule Maker
   should be able to allow access to defined individuals or groups of
   individuals, and ALSO to anonymous requestors who present a specified
   key or credential.  In the proposed Rules, those two elements are
   consolidated into Rule 3, but the possibility of an anonymous-but-
   credentialed Location Seeker is preserved.

        d.  Obviously, the alternate proposal for Rule 3 (suggested in
   Section 5) is more complex, but it also would enable the Location
   Object to be more robust.  It would also be possible to include parts
   of the alternate proposal without including all of the additional
   fields suggested.

        e.  Element G and Rule 5 do not themselves directly advance a
   privacy objective, but they would greatly facilitate the future
   development of privacy protecting (and other) business models.  They
   would also promote the ability of a Target to bypass the location
   services offered by an Location Sighter (such as a wireless carrier)
   in favor of location services offered by a competitive third party.

        f.  To be clear, the proposal of a "Limited Internal" approach
   does NOT mean that all of the proposed privacy rules would be
   transmitted in every Location Object within a given location
   transaction.  It is quite possible that a LO at an early stage of a
   location transaction (say, from a Location Sighter to a Location
   Server) might carry full specifics on Rules 1 - 5.  But a later stage
   of the same location transaction (say, from the Location Server to an
   Ultimate Location Recipient) might only carry Rules 1 and 2 (which
   would be the only rules directly applicable to the ULR).



7. Draft Requirements Language for "Limited Internal" Approach

   If the working group were to adopt the "Limited Internal" approach,
   the following is a draft requirement that could be included in the
   Geopriv Requirements document.  The proposed elements are drawn
   directly from those listed in Section 3 above:




   Morris, Mulligan, Cuellar                                         7
                       Core Privacy Protections           October 2002

      Req. 1.  (Limited Policy language) Geopriv MUST specify a limited
            policy language capable of expressing a limited set of
            privacy rules concerning location information.  This policy
            language MAY be an existing one, an adaptation of an
            existing one or a new policy language.  The Location Object
            MUST include sufficient fields and data to express the
            limited set of privacy rules.  The limited set of rules MUST
            include, at a minimum, the following elements:

                A.  Limitation on length of data retention

                B.  Limitation on any retransmission or further
                    disclosure

                C.  Permission to disclose only to specified
                    individual/entity

                D.  Permission to disclose only to someone presenting a
                    specified key (for instance, a shared key or the
                    private key corresponding to a particular public
                    key), or a special type of credential (an e-token
                    to be defined).

                E.  Requirement that location granularity/precision of
                    location information be reduced

                F.  Requirement that external privacy rules be followed

                G.  Instruction that location be transmitted to
                    specified external privacy or location service with
                    specified instruction.



8. Security Considerations

   Security is, of course, is a core goal of the Geopriv working group.
   The questions addressed in this Internet-Draft -- where privacy rules
   should be stored and whether some or all of those rules should be
   transmitted with the Location Object -- have significant security
   implications, most directly on the security of the privacy rules
   themselves.  The inappropriate disclosure of some privacy rules could
   itself harm privacy, and thus a decision to include some privacy
   rules in the Location Object could expose those rules to a higher
   chance of security (and thus privacy) violation.  On the other hand,
   if including rules in the Location Object increases the likelihood
   that those privacy rules would in fact be known and followed, then
   the added security risk of transmitting those rules may be outweighed
   by the added privacy protection afforded.





   Morris, Mulligan, Cuellar                                         8
                       Core Privacy Protections           October 2002

9. Acknowledgements

   We wish to thank Jon Peterson for his constructive criticism of the
   proposals advanced in the document.


10. References

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
          Levels", BCP 14, RFC 2119, March 1997.


11. Author's Addresses

   John B. Morris, Jr.
   Director, Internet Standards, Technology & Policy Project
   Center for Democracy and Technology
   1634 I Street NW, Suite 1100
   Washington, DC 20006                         Email:  jmorris@cdt.org
   USA                                               http://www.cdt.org

   Deirdre K. Mulligan
   Samuelson Law, Technology and Public Policy Clinic
   Boalt Hall School of Law
   University of California
   Berkeley, CA 94720-7              Email:  dmulligan@law.berkeley.edu

   Jorge R Cuellar
   Siemens AG
   Corporate Technology
   CT IC 3
   81730 Munich                   Email:  Jorge.Cuellar@mchp.siemens.de
   Germany


12. Full Copyright Statement

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

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


   Morris, Mulligan, Cuellar                                         9
                       Core Privacy Protections           October 2002


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

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












































   Morris, Mulligan, Cuellar                                        10


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/