idnits 2.17.1 draft-morris-geopriv-core-02.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 (June 2003) is 7619 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 J. Morris 3 Document: draft-morris-geopriv-core-02.txt Center for Democracy 4 Expires December 2003 and Technology 6 D. Mulligan 7 Samuelson Law, Technology, 8 and Public Policy Clinic 10 J. Cuellar 11 Siemens AG 13 June 2003 15 Core Privacy Protections for 16 Geopriv Location Object 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Copyright Notice 40 Copyright (C) The Internet Society (2003). All Rights Reserved. 42 Abstract 44 The working group has generally agreed that the Geopriv Location 45 Object MUST be able to contain a limited set of Privacy Rules. This 46 Internet-Draft suggests the set of Privacy Rules that the authors 47 believe should be includable in the Location Object. 49 Morris, Mulligan, Cuellar 1 50 Table of Contents 52 1. Overview and Notes on Revisions ................................2 53 2. Conventions used in this document ..............................3 54 3. Privacy Rules to be Includable in a Geopriv Location Object ....3 55 3.1. Widely Distributable Privacy Elements and Rules ...........3 56 3.2. LS-to-LS Privacy Elements and Rules .......................4 57 4. Additional Discussion of Proposed Privacy Elements and Rules ...6 58 5. Reasons to Include Privacy Rules in Location Object ............7 59 6. Additional Suggested Requirement for Location Object ...........8 60 7. Security Considerations ........................................8 61 8. Acknowledgements ...............................................9 62 9. References .....................................................9 63 10. Author's Addresses ............................................9 64 11. Full Copyright Statement ......................................9 66 1. Overview and Notes on Revisions 68 The authors believe that there exists working group consensus that 69 that the Geopriv Location Object (LO) MUST be able to contain a 70 limited set of Privacy Rules. This document suggests the set of 71 Privacy Rules that the authors believe should be includable in the 72 Location Object. 74 The threshold question of whether the LO should contain any Privacy 75 Rules was discussed at IETF-55 in Atlanta. A brief explanation as to 76 why a limited set of Privacy Rules should be includable in the LO is 77 set out in Section 5 below. 79 The -00 version of this document was discussed at IETF-55 in Atlanta. 80 The -01 version significantly reorganized the proposed rules, and was 81 discussed at IETF-56 in San Francisco. This -02 version refines the 82 Privacy Rules proposal based on in person and mailing list 83 discussion. The main changes from the -01 version are: 85 * the prior draft placed the proposed privacy elements into two 86 categories: "Human- AND Machine-Readable Privacy" (including 87 elements that can be distributed to any of the entities in a Geopriv 88 transaction) and "Machine-Readable Privacy Elements" (including 89 elements that can only be sent from one Location Server to another 90 Location Server). Concern was raised by the idea of "human readable" 91 elements, and these categories have been changed to respond to the 92 concerns raised. 94 * the prior draft proposed that rules could be made specific to 95 individuals (Element D, for example, "give my location to my mother 96 at any time, but give my location to my boss only at these certain 97 times), AND, separately, specific to presenters of a credential 99 Morris, Mulligan, Cuellar 2 100 (Element E, for example, "give my location to anyone who presents XYZ 101 credential). A concern was expressed about the difficultly of 102 establishing identity independent of a credential. In other words, 103 assuming the absence of a credential (which is permitted with Element 104 E), verifying an identity (as in Element D) would be very difficult. 105 To address this concern, the old Element D has been eliminated. The 106 old Element E has been modified to suggest that in designing the 107 Location Object, it is possible that a concept of "identity" may be 108 used merely as an index into a table of credentials, but such a use 109 of "identity" would not be a requirement for the Location Object. 111 2. Conventions used in this document 113 Terms with initial capitals (such as, for example, "Location Object," 114 "Privacy Rule," and "Viewer") have the same meaning as defined in the 115 Geopriv Requirements document, draft-ietf-geopriv-reqs-03.txt. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [1]. 121 3. Privacy Rules to be Includable in a Geopriv Location Object 123 This section details two groups of core elements of Privacy Rules 124 that should be expressible in the Geopriv Location Object. For each 125 of the core elements (designated as Elements A through L), a more 126 precisely stated "rule" is also provided, with Elements D through L 127 being stated in a permissions table as part of a single rule. 128 Section 4 below contains some additional substantive discussion of 129 these elements. 131 Note that some of the elements and rules discussed below are phrased 132 in terms of prohibitions ("do not disclose except to . . ."), but 133 could probably as effectively be phrased in terms of permissions 134 ("permitted to disclosed only to . . . "). 136 3.1. Widely Distributable Privacy Elements and Rules 138 This first group of privacy elements and resulting rules represent 139 the most basic Privacy Rules, and can be transmitted between and 140 among any of the entities in a Geopriv transaction. 142 Two different forms of this first group would be defined - a compact 143 form suitable for low bandwidth applications, and a more verbose 144 default form that could possibly be transmitted to the Viewer (i.e., 145 the final recipient of Location Information). This latter approach 146 would permit, for example, the return of a Location Object in 147 response to a HTTP request from a web browser. 149 Morris, Mulligan, Cuellar 3 150 The three privacy elements in this group are: 152 Element A: Requirement that external privacy rules be followed 154 Element B: Limitation on length of data retention 156 Element C: Limitation on any retransmission or further 157 disclosure 159 The following expresses these three broad elements in more precise 160 language: 162 Rule 1: Do not retransmit or further disclose my location 163 information except in full compliance with the 164 privacy rules located at [url/uri]. (Element A) 166 Rule 2: Do not retain my location information [past xyz 167 time+date OR longer than xyz duration]. (Element B) 169 Rule 3: Do not retransmit or further disclose my location 170 information. (Element C) 172 3.2. LS-to-LS Privacy Elements and Rules 174 The second group of Privacy Rules that can be contained in a LO is 175 intended for use in transmissions between Location Servers. 177 The authors believe that, taken together, Elements A - L would allow 178 the expression of a very high percentage of users' complete set of 179 Privacy Rules, and thus in many cases could obviate the need for 180 reference to any external set of Privacy Rules. 182 The privacy elements in this group are: 184 Element D: [deleted] 186 Element E: Permission to disclose only to someone presenting a 187 specified key (for instance, a shared key or the 188 private key corresponding to a particular public 189 key), or a special type of credential (an e-token to 190 be defined). 192 Element F: Requirement that the granularity/precision of 193 location information be reduced 195 Element G: The ability to provide additional Privacy Rules for 196 specific requestors or groups of requestors 198 Element H: The ability to define a time until which a permission 199 is valid 201 Morris, Mulligan, Cuellar 4 202 Element I: The ability to define a geographical area for which 203 the permission is valid ("if I am in area x then you 204 can tell y my location") 206 Element J: The ability to define a repeatable time window (such 207 as weekdays during office hours) during which a 208 permission is valid 210 Element K: The ability to require that express consent of the 211 Target/Rule Maker be obtained prior to disclosing 212 location 214 Element L: The ability to require that notice be provided to the 215 Target if location is provided 217 Elements E through L can be expressed in the form of a single 218 permissions table: 220 Rule 4: Do not retransmit or further disclose my location 221 information EXCEPT in accordance to the following 222 permissions table: 224 |Credent/Ident|Accuracy|Policy|Valid|LocRes|TimeRes|Consent|Notice| 225 | | | | | | | | | 226 | xyz1 [id1] | uvw1 | p1 | v1 | r1 | t1 | c1 | n1 | 227 | xyz2 [id2] | uvw2 | p2 | v2 | r2 | t2 | c2 | n2 | 228 | xyz3 [id3] | uvw3 | p3 | v3 | r3 | t3 | c3 | n3 | 229 | xyz4 [id4] | uvw4 | p4 | v4 | r4 | t4 | c4 | n4 | 231 where 233 xyz Credential: allows for wildcards and "no additional 234 credential required beyond [abc] identity" (Element E) 236 [id] A non-required possible identity label that can be used 237 to provide an index into the credential table (for 238 example, "here is my xyz credential, and you will locate 239 that credential indexed by [id] in your table") 241 uvw Accuracy: has one of the following values (Element F): 242 A = no granularity change required 243 B = 10 kilometer radius (or within lat/long quadrant) 244 C = 100 kilometer radius (or within larger quadrant) 245 D = local or municipal civil designation (e.g., city) 246 E = state or regional civil designation (e.g., state) 247 F = national designation (e.g., country) 248 G = time zone 250 p Policy: pointer to the privacy rules/policy that must be 251 followed for this specific Location Seeker (Element G) 253 Morris, Mulligan, Cuellar 5 254 v Validity: this permission is valid until time v (Element 255 H) 257 r Location Restriction: r represents a region where this 258 permission applies (for instance, if I am in Munich, 259 then it is OK to pass this information) (Element I) 261 t Time Restriction: this permission is only valid within 262 the recurring time window t (for instance, only during 263 working hours may my boss obtain my location) (Element 264 J) 266 c Consent Bit: ask me for permission in real time (and let 267 the Location Seeker abc wait until I tell you) (Element 268 K) 270 n Notification Bit: send me a notification if you send 271 this Location Information to Location Seeker abc 272 (Element L) 274 4. Additional Discussion of Proposed Privacy Elements and Rules 276 The following are additional comments and explanations of the above 277 privacy elements and rules: 279 a. Rules 1 - 3 should be expressible in both a compact form 280 and a form that would be intelligible to a human viewer. Rule 4 is 281 primarily intended to be read by Location Servers that have 282 sufficient intelligence to process the rules. When sending Location 283 Information to an ultimate Viewer, it is possible that the Geopriv 284 Location Object (LO) itself would need to contain human-readable 285 information (for example, if the LO is sent to a Viewer using SMTP or 286 HTTP). This approach is analogous to the full and compact versions 287 of privacy policies under P3P. 289 b. Element C and Rule 3 could possibly be omitted as a separate 290 flag or field, because a "do not distribute" instruction should be a 291 fundamental default for the Geopriv Location Object. Nevertheless, 292 there is value in having an express "do not redistribute" indicator, 293 especially to emphasize that instruction to an ultimate Viewer (who, 294 as discussed above, may well be a human receiving the LO essentially 295 directly). 297 c. To be clear, the proposal of making specific Privacy Rules 298 includable in a Location Object does NOT mean that all of the 299 proposed privacy rules would be transmitted in every Location Object 300 within a given location transaction. It is quite possible that a LO 301 at an early stage of a location transaction might carry full 302 specifics on Rules 1 - 4. But a later stage of the same location 303 transaction (say, from a Location Server to an ultimate Viewer) might 305 Morris, Mulligan, Cuellar 6 306 only carry Rules 1 - 3 (which would be the only rules directly 307 applicable to the Viewer). 309 5. Reasons to Include Privacy Rules in Location Object 311 It is not the purpose of this Internet-Draft to explain in full the 312 reasons why a limited set of Privacy Rules should be includable in 313 the Location Object. A brief discussion, however, may assist a 314 reader who is unfamiliar with past working group discussions on the 315 topic. 317 A critical question that faced the Geopriv working group was whether 318 the Location Object (LO) to be designed should include fields for 319 particular privacy-protecting rules, or instead should simply refer 320 to an external set of privacy rules. The three most plausible 321 answers to this question would be: 323 (1) "Entirely External" -- the LO should only contain a URI 324 reference to an external set of privacy rules that must be 325 followed by any recipient of the LO. 327 (2) "Limited Internal" -- the LO should contain a limited set 328 of rules that cover the great bulk of likely privacy 329 situations (as well as the ability to include a URI 330 reference to an external set of privacy rules if more 331 robust rules are needed, or external rule storage is 332 preferred). 334 (3) "Full Internal" -- the LO should be defined to be able to 335 contain a full, robust, and potentially complex set of 336 privacy rules. 338 The "Full Internal" option would yield the most complex LO, would be 339 the most complex to define and implement, and may not be consistent 340 with the goal of enabling the use of the Geopriv LO on constrained 341 devices or with limited bandwidth. 343 The "Entirely External" approach would be the quickest for the 344 working group to accomplish, and if fully implemented in the 345 marketplace this approach could give end users a great deal of 346 control and flexibility in the protection of Location Information. 347 Under this approach, however, privacy protection would heavily depend 348 on marketplace developments wholly external to the work of Geopriv, 349 and thus may not fulfill the mission of the working group as defined 350 by its charter. 352 Certain working group participants (including the authors here) 353 argued that the most effective way to ensure that users have some 354 privacy control is for the Location Object to be able to carry a 355 limited number of privacy rules. In discussions at IETF-55 in 356 Atlanta, the working group agreed to pursue the "Limited Internal" 358 Morris, Mulligan, Cuellar 7 359 approach, although the group did not determine the precise elements 360 to be included in a "Limited Internal" approach. It is to this 361 latter question that this document is addressed. 363 Note that the "Limited Internal" approach is effectively a superset 364 of the "Entirely External" approach, so that both of those models 365 could be implemented in appropriate situations even if the LO can 366 carry a larger set of rules. Thus, where a particular location 367 service application in fact offers users robust and effective means 368 to create and maintain an external set of privacy rules, that 369 application could simply transmit the URI/URL of those external rules 370 in the Location Object. But where an application lacks robust and 371 effective external rule servers, the "Limited Internal" approach 372 would allow a core set of rules to be carried with the LO. 374 6. Additional Suggested Requirement for Location Object 376 This section is retained here to avoid losing track of the proposal 377 made below (which could be incorporated in the definition of the LO). 379 The -00 version of this document proposed one element (the original 380 Element G described below) that was decided to be useful, but not 381 actually a "privacy rule." The apparent consensus was to instead 382 designate the proposed functionality simply as a feature to be 383 included in a final definition of a Geopriv Location Object. The 384 resulting proposal is that the LO should be able to contain the 385 following instruction: 387 Promptly transmit my location to [abc] individual or entity, 388 along with [xyz] instruction (where the contents of [xyz] are 389 NOT defined by Geopriv except for technical parameters such as 390 maximum size). 392 Although this proposal does not itself directly advance a privacy 393 objective, it would greatly facilitate the future development of 394 privacy protecting (and other) business models. It would also 395 promote the ability of a Target to bypass the location services 396 offered by a Location Generator (such as a wireless carrier) in favor 397 of location services offered by a competitive third party. 399 7. Security Considerations 401 Security is, of course, is a core goal of the Geopriv working group. 402 The questions addressed in this Internet-Draft -- what privacy rules 403 should be includable in the Geopriv Location Object -- have 404 significant security implications, most directly on the security of 405 the privacy rules themselves. The inappropriate disclosure of some 406 privacy rules could itself harm privacy, and thus a decision to 407 include some privacy rules in the Location Object could expose those 408 rules to a higher chance of security (and thus privacy) violation. 410 Morris, Mulligan, Cuellar 8 411 On the other hand, if including rules in the Location Object 412 increases the likelihood that those privacy rules would in fact be 413 known and followed, then the added security risk of transmitting 414 those rules may be outweighed by the added privacy protection 415 afforded. 417 8. Acknowledgements 419 We wish to thank Jon Peterson for his constructive criticism of the 420 proposals advanced in the prior version of this document. 422 9. References 424 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 425 Levels", BCP 14, RFC 2119, March 1997. 427 10. Author's Addresses 429 John B. Morris, Jr. 430 Director, Internet Standards, Technology & Policy Project 431 Center for Democracy and Technology 432 1634 I Street NW, Suite 1100 433 Washington, DC 20006 Email: jmorris@cdt.org 434 USA http://www.cdt.org 436 Deirdre K. Mulligan 437 Samuelson Law, Technology and Public Policy Clinic 438 Boalt Hall School of Law 439 University of California 440 Berkeley, CA 94720-7 Email: dmulligan@law.berkeley.edu 441 USA 443 Jorge R Cuellar 444 Siemens AG 445 Corporate Technology 446 CT IC 3 447 81730 Munich Email: Jorge.Cuellar@siemens.com 448 Germany 450 11. Full Copyright Statement 452 Copyright (C) The Internet Society (date). All Rights Reserved. 454 This document and translations of it may be copied and furnished to 455 others, and derivative works that comment on or otherwise explain it 456 or assist in its implementation may be prepared, copied, published 457 and distributed, in whole or in part, without restriction of any 458 kind, provided that the above copyright notice and this paragraph are 460 Morris, Mulligan, Cuellar 9 461 included on all such copies and derivative works. However, this 462 document itself may not be modified in any way, such as by removing 463 the copyright notice or references to the Internet Society or other 464 Internet organizations, except as needed for the purpose of 465 developing Internet standards in which case the procedures for 466 copyrights defined in the Internet Standards process must be 467 followed, or as required to translate it into languages other than 468 English. 470 The limited permissions granted above are perpetual and will not be 471 revoked by the Internet Society or its successors or assigns. 473 This document and the information contained herein is provided on an 474 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 475 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 476 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 477 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 478 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Morris, Mulligan, Cuellar 10