[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.129c, available from
https://tools.ietf.org/tools/rfcmarkup/