idnits 2.17.1 draft-morris-geopriv-core-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7861 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft John B. Morris, Jr. 3 Document: draft-morris-geopriv-core-00.txt Center for Democracy 4 Expires April 28, 2003 and Technology 6 D. Mulligan 7 Samuelson Law, Technology, 8 and Public Policy Clinic 10 J. Cuellar 11 Siemens AG 13 October 2002 14 Core Privacy Protections for 15 Geopriv Location Object 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2002). All Rights Reserved. 41 Abstract 43 In designing the requirements for the Geopriv Location Object (LO), a 44 key question for the working group is whether to include privacy- 45 protecting rules inside the LO itself, and if so, how many and what 46 rules should be contained in the LO. The Internet-Draft first 47 suggests that the LO should contain at least a limited set of privacy 48 rule fields, and second proposes a set of rules for inclusion in the 49 Location Object. 51 Morris, Mulligan, Cuellar 1 52 Table of Contents 54 1. Introduction and Overview....................................... 2 55 2. Conventions used in this document............................... 4 56 3. Core Privacy Elements for the "Limited Internal" Approach....... 4 57 4. Specific Articulation of Core Privacy Elements.................. 5 58 5. Possible Alternate Implementation of Proposed Rule 3............ 6 59 6. Additional Discussion of Proposed Privacy Elements and Rules.... 6 60 7. Draft Requirements Language for "Limited Internal" Approach..... 7 61 8. Security Considerations......................................... 8 62 9. Acknowledgements................................................ 9 63 10. References..................................................... 9 64 11. Author's Addresses............................................. 9 65 12. Full Copyright Statement....................................... 9 67 1. Introduction and Overview 69 A critical question facing the Geopriv working group is whether the 70 Location Object (LO) to be designed should include fields for 71 particular privacy-protecting rules, or instead should simply refer 72 to an external set of privacy rules. 74 There are at least four plausible answers to this question, labeled 75 somewhat arbitrarily as follows: 77 * "Entirely External" -- the LO should only contain a URI 78 reference to an external set of privacy rules that must be 79 followed by any recipient of the LO. 81 * "Bare Bones Internal" -- the LO should contain at most one or 82 two rules that specify, for example, that the Location 83 Information (LI) shall not be retained past xyz date (or 84 longer than xyz duration), along with a URI reference to an 85 external set of privacy rules that must be followed by any 86 recipient of the LO. 88 * "Limited Internal" -- the LO should contain a limited set of 89 rules (say, 4 to 7 rules) that cover the great bulk of likely 90 privacy situations (as well as the ability to include a URI 91 reference to an external set of privacy rules if more robust 92 rules are needed, or external rule storage is preferred). 94 * "Full Internal" -- the LO should be defined to be able to 95 contain a full, robust, and potentially complex set of 96 privacy rules. 98 Morris, Mulligan, Cuellar 2 99 The "Full Internal" option would yield the most complex LO, would be 100 the most complex to define and implement, and may not be consistent 101 with the goal of enabling the use of the Geopriv LO on constrained 102 devices or with limited bandwidth. 104 Some working group participants have expressed the view that the 105 "Entirely External" approach would be the quickest for the working 106 group to accomplish, and that if fully implemented in the marketplace 107 the approach could give end users a great deal of control and 108 flexibility in the protection of Location Information. 110 Other WG participants (including at least some of the authors here) 111 have argued that the most effective way to ensure that users have 112 some privacy control is for the LO to be able to carry a limited 113 number of privacy rules. 115 It is not the purpose of this Internet-Draft to attempt to advance 116 and defend a definitive answer to this critical question. Instead, 117 this I-D articulates one approach to the "Limited Internal" set of 118 privacy rules. By specifying one view of how the Limited Internal 119 set of rules might be expressed, the Internet-Draft hopes to allow 120 the WG to assess some detailed specifics of that option. 122 Note that the "Limited Internal" approach is effectively a superset 123 of the "Entirely External" and "Bare Bones Internal" approaches, so 124 that both of those models could be implemented in appropriate 125 situations even if the LO can carry a larger set of rules. Thus, 126 where a particular location service application in fact offers users 127 robust and effective means to create and maintain an external set of 128 privacy rules, that application could simply transmit the URI/URL of 129 those external rules in the Location Object. But where an 130 application lacks robust and effective external rule servers, the 131 "Limited Internal" approach would allow a core set of rules to be 132 carried with the LO. 134 Five separate things follow below. First, there is a brief and 135 broad-brush statement of the core privacy elements that we think 136 should be contained in a "Limited Internal" design of the Location 137 Object. Second, there is a more precise proposal on exactly how to 138 articulate and express these elements; significantly, this proposal 139 combines three of the elements into one "permissions table." Third, 140 there is an alternate proposal that adds a few additional elements to 141 the proposed permissions table, and thereby significantly enhances 142 the power of the LO privacy protections. Fourth, there are a few 143 additional comments about the proposals. Fifth and last is language 144 in the form of a Requirement that could be inserted into a 145 requirements document if the WG chooses the "Limited Internal" 146 approach. 148 Morris, Mulligan, Cuellar 3 149 2. Conventions used in this document 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [1]. 155 3. Core Privacy Elements for the "Limited Internal" Approach 157 The following are seven elements suggested to be included in a 158 "Limited Internal" approach to the Location Object. The first five 159 elements (A - E) describe specific possible privacy rules. The sixth 160 element (F) allows a reference to an external set of privacy rules if 161 the first five rules are insufficient in scope or complexity, or if 162 external rule storage is preferred in a given application. The final 163 element (G) would facilitate the development of third party location 164 and privacy-protecting services, and would permit a constrained 165 Device to direct a Location Sighter to send Location Information to a 166 specific destination with a specific instruction. 168 Note that most of the elements and rules discussed below are phrased 169 in terms of prohibitions ("do not disclose except to . . ."), but 170 could probably as effectively be phrased in terms of permissions 171 ("permitted to disclosed only to . . . "). 173 A. Limitation on length of data retention 175 B. Limitation on any retransmission or further disclosure 177 C. Permission to disclose only to specified individual/entity 179 D. Permission to disclose only to someone presenting a 180 specified key (for instance, a shared key or the private 181 key corresponding to a particular public key), or a special 182 type of credential (an e-token to be defined). 184 E. Requirement that location granularity/precision of location 185 information be reduced 187 F. Requirement that external privacy rules be followed 189 G. Instruction that location be transmitted to specified 190 external privacy or location service with specified 191 instruction. 193 Section 6 below contains some discussion of these elements (such as, 194 for example, a reason to articulate elements C and D separately). 196 Morris, Mulligan, Cuellar 4 197 4. Specific Articulation of Core Privacy Elements 199 The following attempts to express the above broad principles in more 200 precise language, combining three elements into a single "permissions 201 table": 203 Rule 1: (Element A) Do not retain my location information [past 204 xyz time+date OR longer than xyz duration]. 206 Rule 2: (Element B) Do not retransmit or further disclose my 207 location information. 209 Rule 3: (Elements C, D, E) Do not retransmit or further 210 disclose my location information EXCEPT to [abc] if he 211 presents [xyz] credential or key, and only at [uvw] 212 accuracy, where 214 [abc] allows for wildcards including "any" or "any@some- 215 specific-domain" 216 [xyz] allows for wildcards and "no additional credential 217 required beyond the [abc] identity" 218 [uvw] has one of the following values: 220 A = no granularity change required 221 B = 10 kilometer radius (or within lat/long quadrant) 222 C = 100 kilometer radius (or within larger quadrant) 223 D = local or municipal civil designation (e.g., city) 224 E = state or regional civil designation (e.g., state) 225 F = national designation (e.g., country) 226 G = time zone 228 These elements would appear in a permissions table: 230 | Location seeker | Credential | Accuracy | 231 | | | | 232 | [abc1] | [xyz1] | [uvw1] | 233 | [abc2] | [xyz2] | [uvw2] | 234 | [abc3] | [xyz3] | [uvw3] | 235 | [abc4] | [xyz4] | [uvw4] | 237 Rule 4: (Element F) Do not retransmit or further disclose my 238 location information except in full compliance with the 239 privacy rules located at [url/uri]. 241 Rule 5: (Element G) Promptly transmit my location to [abc] 242 individual or entity, along with [xyz] instruction 243 (where the contents of [xyz] are NOT defined by Geopriv 244 except for technical parameters such as maximum size). 246 Morris, Mulligan, Cuellar 5 247 5. Possible Alternate Implementation of Proposed Rule 3 249 The permissions table suggested in Rule 3 above could have some 250 additional values that would greatly increase the flexibility of the 251 LO rules, along the following lines: 253 |LocSeek|Credent|LocRes|TimeRes|Notif |Consent|Accuracy| Val |Policy 254 |[abc1] |[xyz1] | r1 | t1 | n1 | c1 | [uvw1] | tt1 | p1 255 |[abc2] |[xyz2] | r2 | t2 | n2 | c2 | [uvw2] | tt2 | p2 256 |[abc3] |[xyz3] | r3 | t3 | n3 | c3 | [uvw3] | tt3 | p3 257 |[abc4] |[xyz4] | r4 | t4 | n4 | c4 | [uvw4] | tt4 | p4 259 where 261 r is a Location Restriction: r represents a region where this 262 policy applies (for instance, if I am in Munich, then it is 263 OK to pass this information) 265 t is a Time Restriction (only during working hours may my boss 266 obtain my location) 268 n is a "notification bit": send me a notification if you send 269 this Location Information to Location Seeker abc 271 c is a "consent bit": ask me for permission in real time (and 272 let the Location Seeker abc wait until I tell you) 274 tt is a "valid-until" field: this permission is valid until time 275 tt 277 p is the pointer to the privacy rules/policy that the Location 278 Seeker has to obey for this specific [abc] Location Seeker 280 6. Additional Discussion of Proposed Privacy Elements and Rules 282 The following are additional comments and explanations of the above 283 privacy elements and rules: 285 a. At least Rules 1 and 2 should be expressible in both 286 machine-readable form as well as an optional human-readable form. 287 Rules 3 - 5 are primarily intended to be read by Location Servers 288 that have sufficient intelligence to process the rules. But when 289 sending Location Information to an Ultimate Location Recipient, it is 290 possible that the Geopriv Location Object (LO) itself would need to 291 contain some human-readable information (for example, if the LO is 292 sent to a ULR using SMTP or HTTP). This approach is analogous to the 293 full and compact versions of privacy policies under P3P. 295 Morris, Mulligan, Cuellar 6 296 b. Element B and Rule 2 could possibly be omitted as a separate 297 flag or field, because a "do not distribute" instruction should be a 298 fundamental default for the Geopriv Location Object. Nevertheless, 299 there is value in having an express "do not redistribute" indicator, 300 especially to emphasize that instruction to Ultimate Location 301 Recipients (who, as discussed above, may well be humans receiving the 302 LO essentially directly). 304 c. Elements C (disclose only to specified individual) and D 305 (disclose only to someone presenting a key or credential) could 306 theoretically be consolidated, because establishing the identity in C 307 would effectively be using some form of credential. The elements, 308 however, are expressed separately to emphasize that a Rule Maker 309 should be able to allow access to defined individuals or groups of 310 individuals, and ALSO to anonymous requestors who present a specified 311 key or credential. In the proposed Rules, those two elements are 312 consolidated into Rule 3, but the possibility of an anonymous-but- 313 credentialed Location Seeker is preserved. 315 d. Obviously, the alternate proposal for Rule 3 (suggested in 316 Section 5) is more complex, but it also would enable the Location 317 Object to be more robust. It would also be possible to include parts 318 of the alternate proposal without including all of the additional 319 fields suggested. 321 e. Element G and Rule 5 do not themselves directly advance a 322 privacy objective, but they would greatly facilitate the future 323 development of privacy protecting (and other) business models. They 324 would also promote the ability of a Target to bypass the location 325 services offered by an Location Sighter (such as a wireless carrier) 326 in favor of location services offered by a competitive third party. 328 f. To be clear, the proposal of a "Limited Internal" approach 329 does NOT mean that all of the proposed privacy rules would be 330 transmitted in every Location Object within a given location 331 transaction. It is quite possible that a LO at an early stage of a 332 location transaction (say, from a Location Sighter to a Location 333 Server) might carry full specifics on Rules 1 - 5. But a later stage 334 of the same location transaction (say, from the Location Server to an 335 Ultimate Location Recipient) might only carry Rules 1 and 2 (which 336 would be the only rules directly applicable to the ULR). 338 7. Draft Requirements Language for "Limited Internal" Approach 340 If the working group were to adopt the "Limited Internal" approach, 341 the following is a draft requirement that could be included in the 342 Geopriv Requirements document. The proposed elements are drawn 343 directly from those listed in Section 3 above: 345 Morris, Mulligan, Cuellar 7 346 Req. 1. (Limited Policy language) Geopriv MUST specify a limited 347 policy language capable of expressing a limited set of 348 privacy rules concerning location information. This policy 349 language MAY be an existing one, an adaptation of an 350 existing one or a new policy language. The Location Object 351 MUST include sufficient fields and data to express the 352 limited set of privacy rules. The limited set of rules MUST 353 include, at a minimum, the following elements: 355 A. Limitation on length of data retention 357 B. Limitation on any retransmission or further 358 disclosure 360 C. Permission to disclose only to specified 361 individual/entity 363 D. Permission to disclose only to someone presenting a 364 specified key (for instance, a shared key or the 365 private key corresponding to a particular public 366 key), or a special type of credential (an e-token 367 to be defined). 369 E. Requirement that location granularity/precision of 370 location information be reduced 372 F. Requirement that external privacy rules be followed 374 G. Instruction that location be transmitted to 375 specified external privacy or location service with 376 specified instruction. 378 8. Security Considerations 380 Security is, of course, is a core goal of the Geopriv working group. 381 The questions addressed in this Internet-Draft -- where privacy rules 382 should be stored and whether some or all of those rules should be 383 transmitted with the Location Object -- have significant security 384 implications, most directly on the security of the privacy rules 385 themselves. The inappropriate disclosure of some privacy rules could 386 itself harm privacy, and thus a decision to include some privacy 387 rules in the Location Object could expose those rules to a higher 388 chance of security (and thus privacy) violation. On the other hand, 389 if including rules in the Location Object increases the likelihood 390 that those privacy rules would in fact be known and followed, then 391 the added security risk of transmitting those rules may be outweighed 392 by the added privacy protection afforded. 394 Morris, Mulligan, Cuellar 8 395 9. Acknowledgements 397 We wish to thank Jon Peterson for his constructive criticism of the 398 proposals advanced in the document. 400 10. References 402 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 403 Levels", BCP 14, RFC 2119, March 1997. 405 11. Author's Addresses 407 John B. Morris, Jr. 408 Director, Internet Standards, Technology & Policy Project 409 Center for Democracy and Technology 410 1634 I Street NW, Suite 1100 411 Washington, DC 20006 Email: jmorris@cdt.org 412 USA http://www.cdt.org 414 Deirdre K. Mulligan 415 Samuelson Law, Technology and Public Policy Clinic 416 Boalt Hall School of Law 417 University of California 418 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 420 Jorge R Cuellar 421 Siemens AG 422 Corporate Technology 423 CT IC 3 424 81730 Munich Email: Jorge.Cuellar@mchp.siemens.de 425 Germany 427 12. Full Copyright Statement 429 Copyright (C) The Internet Society (date). All Rights Reserved. 431 This document and translations of it may be copied and furnished to 432 others, and derivative works that comment on or otherwise explain it 433 or assist in its implementation may be prepared, copied, published 434 and distributed, in whole or in part, without restriction of any 435 kind, provided that the above copyright notice and this paragraph are 436 included on all such copies and derivative works. However, this 437 document itself may not be modified in any way, such as by removing 438 the copyright notice or references to the Internet Society or other 439 Internet organizations, except as needed for the purpose of 440 developing Internet standards in which case the procedures for 441 copyrights defined in the Internet Standards process must be 442 followed, or as required to translate it into languages other than 443 English. 445 Morris, Mulligan, Cuellar 9 446 The limited permissions granted above are perpetual and will not be 447 revoked by the Internet Society or its successors or assigns. 449 This document and the information contained herein is provided on an 450 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 451 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 452 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 453 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 454 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 456 Morris, Mulligan, Cuellar 10