Internet Draft J. Cuellar Document: draft-cuellar-geopriv-lo-ml-01.txt C. Guenther Siemens AG Expires in six months June 2003 Geopriv Location Object Markup Language Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 (2003). All Rights Reserved. Abstract This draft presents and illustrates a foundational version of an markup language suitable for representing the Geopriv Location Object. This language is defined by means of an XML schema. In addition, we compile a list of open issues that the Geopriv Working Group must solve in order to allow for precise definitions of Location Object data formats. 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 RFC-2119 [2]. Cuellar, Guenther Expires - December 2003 1 Geopriv Location Object Markup Language June 2003 Table of Contents 1. Introduction...................................................2 2. Geopriv LO Markup Language.....................................3 2.1. Overview..................................................3 2.2. Schema Element Start Tag..................................4 2.3. LO Element................................................4 2.4. Target Element............................................5 2.5. Device Element............................................6 2.6. RM Element................................................8 2.7. LR Element................................................9 2.8. LR Credential Element....................................10 2.9. LR PoP Element...........................................11 2.10. Rule Element............................................12 2.11. Location Element........................................13 2.11.1. Latitude, Longitude, Altitude and Precision........15 2.11.2. Civil..............................................16 2.11.3. Time Zone..........................................17 2.11.4. Sighting Time......................................18 2.11.5. Motion and Direction Vectors.......................18 2.12. Time to Live Element....................................18 3. XML Schema Listing............................................18 4. XML LO Instance...............................................28 5. Note on Validation............................................31 6. References....................................................31 7. Author's Addresses............................................31 8. Full Copyright Statement......................................32 1. Introduction This draft aims at providing a foundation of a markup language suitable for representing all data fields of the Geopriv Location Object (LO) as required in [3]. We present and illustrate an XML schema defining such a markup language. Up to now, we have concentrated on the question of how to represent the required data by means of an XML language, only touching the security and privacy issues concerning the Location Object. Even at this early stage of developing a suitable Geopriv Location Object (LO) data format, it has become very clear that the Geopriv Working Group has to arrive at more explicit descriptions of the content of required data fields in order to allow for precise definitions of appropriate LO data formats. To give just one example, the Geopriv Working Group should explicitly determine which types of Location Recipient (LR) Credentials are to be supported. Therefore, we shall also utilize this draft to compile a list of general open issues that must be solved by the Geopriv Working Group in order to be able to complete its work successfully. These general open issues are entirely independent of a particular LO data format (such as XML Cuellar, Guenther Expires - December 2003 2 Geopriv Location Object Markup Language June 2003 in case of this draft), but their solution is simply a prerequisite to any sensible definition of such a data format. Additionally, we shall collect some open issues that are related to the definition of an XML LO. Based on the solutions of the general and XML related open issues, future versions of this draft will make the Location Object (LO) markup language introduced in this draft more precise in terms of representing identity, privacy policy and location information. We will investigate how security and privacy requirements on the Location Object can be satisfied by means of, for instance, the XML Signature and XML Encryption languages, the XML Access Control Markup Language (XACML) and the XML Key Management Specification (XKMS). In addition, we will make proposals how this XML LO can be bound to different Using Protocols. 2. Geopriv LO Markup Language 2.1. Overview The XML schema listed completely in chapter 3 specifies an XML language that allows for the following top-level XML elements: - LO (Location Object): comprises all of the subsequent elements, the only mandatory of which is the Target element while all other elements are optional. - Target: contains an identifier for the Target which can be of non- anonymous, anonymous or of indeterminate type. - Device: contains an identifier for the Device which can be a phone number, an IP address, or of anonymous or indeterminate type. - RM (Rule Maker): contains an identifier for the Rule Maker (RM) which can be of non-anonymous, anonymous or of indeterminate type. - LR (Location Recipient): contains an identifier for the LR which can be of non-anonymous, anonymous or of indeterminate type; can also provide the information whether this identifier is a single or multi cast identifier. - LR Credential (Location Recipient Credential): contains credentials of the Location Recipient. - LR PoP (Location Recipient Proof of Possession of Credential): contains the data that allows for verifying that the LR is in fact in possession of a certain credential. - Rule: contains an URI of an Applicable Rule, a Limited Rule or both. - Location: contains one or more Location Information child elements each of which can be composed of one or more Location Representation child elements and a Sighting Time element. Motion and Direction Vector as well as Precision and Confidence elements are also included here. Cuellar, Guenther Expires - December 2003 3 Geopriv Location Object Markup Language June 2003 - Time to Live: contains the point of time until when Location Information can be considered current. Subsequent paragraphs illustrate the corresponding LO markup language in greater detail. 2.2. Schema Element Start Tag As usual, the schema element start tag defines basic properties of the corresponding XML language (the line numbers are, of course, not part of the XML schema, but merely for easier referencing): 1: In line 4, the W3C schema language namespace ôhttp://www.w3.org/2001/ XMLSchema" is linked to the prefix ôxsö. In line 3, the prefix ôgploö, which stands for ôgeopriv LOö, is associated to the namespace ôurn:ietf:geopriv:lo:0.0.4ö. This URI also defines the target namespace of this schema (line 2). The value of the attribute ôversionö indicates a (up to now, fictive) version number of this schema and the corresponding XML language. 2.3. LO Element The LO element is the element of highest level within the LO markup language. It is defined as follows: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: Cuellar, Guenther Expires - December 2003 4 Geopriv Location Object Markup Language June 2003 Thus, each valid LocationObject element can be composed of the child elements ôTargetö (line 11), ..., and ôTimeToLiveö (line 19). The Target element is the only child element of the LocationObject element that is mandatory. Each other child element is optional and can occur at most once; the order of occurrence is arbitrary (xs:all, line 10). Open Issue 1 (general): Which of the required LO data fields listed in [3] shall be mandatory to the LO? 2.4. Target Element In line 11, the definition of the Target element is referenced to the one given below. In essence, the Target element has a child element TargetIdentity and a grandchild element TargetIdentifier whose content is of type ôxs:stringö, and which can be equipped with the optional attributes ôIdentifierTypeö and ôNameSpaceö. Permitted values of the IdentifierType attribute are ôNonAnonymousö, ôAnonymousö and ôAnyö. The latter attribute value might indicate an indeterminate or unknown or concealed type of Target identifier. 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: Cuellar, Guenther Expires - December 2003 5 Geopriv Location Object Markup Language June 2003 48: 49: 50: 51: 52: 53: 54: A simple instance of the Target element definition could look like as follows: ginefohcsT sennaH Line 52 defines the attribute NameSpace which is optional to the TargetIdentifier element, and whose value must be an URI. In conjunction with an IdentifierType attribute value ôAnonymousö, this attribute could be used to point to a set of identifiers from which the anonymous Target identifier, i.e. the content of the TargetIdentifier element, had been taken. Open Issue 2 (XML): Pointing to a set of identifiers by means of an URI - is this an appropriate mechanism for handling anonymous identifiers? Line 29 in combination with line 27 allows the TargetIdentifier element to be substituted by any other element defined within a namespace different from the namespace of this schema. The purpose of this mechanism is to support other identity providing data formats such as specified by the Liberty Alliance Project, for example. Open Issue 3 (general): Which identity providing data formats shall be supported by the Geopriv LO? 2.5. Device Element The definition of the Device element is quite similar to the definition of the Target element û of course with the exception that the IdentifierType attribute of the DeviceIdentifier element can have the values ôPhoneNumberö, ôIPAddressö, ôAnonymousö and ôAnyö: 55: 56: 57: Cuellar, Guenther Expires - December 2003 6 Geopriv Location Object Markup Language June 2003 58: 59: 60: 61: 62: 63: 64: 65: 66: 67: 68: 69: 70: 71: 72: 73: 74: 75: 76: 77: 78: 79: 80: 81: 82: 83: 84: 85: 86: 87: 88: An example of an Device element complying with this syntax is: 017167239870 Open Issue 4 (general): Which types of Devices and Device identifiers shall be supported by the LO? (phone numbers, IP addresses, anonymous ones and ...?) Cuellar, Guenther Expires - December 2003 7 Geopriv Location Object Markup Language June 2003 2.6. RM Element Up to now, the RM element is defined in a way that allows for representing a non-anonymous, anonymous or indeterminate RM identifier, similar to the Target element. This, of course, will not be sufficient in a final version of this markup language: additional features will have to be specified in order to be able to satisfy the privacy requirements on the LO. 89: 90: 91: 92: 93: 94: 95: 96: 97: 98: 99: 100: 101: 102: 103: 104: 105: 106: 107: 108: 109: 110: 111: 112: 113: 114: 115: 116: 117: 118: 119: 120: 121: An example of a RuleMaker element could be: Cuellar, Guenther Expires - December 2003 8 Geopriv Location Object Markup Language June 2003 Siemens AG 2.7. LR Element The LR element is the last of the identifier storing child elements of the Location Object element. Its definition is modeled on the syntax of the Target, Device and RM elements. Its LocationRecipientIdentifier grandchild element can be of type ôNonAnonymousö, ôAnonymousö and ôAnyö. The optional attribute ôCastTypeö of the LocationRecipientIdentifier element can indicate whether the identifier is a single or a multi cast identifier: 122: 123: 124: 125: 126: 127: 128: 129: 130: 131: 132: 133: 134: 135: 136: 137: 138: 139: 140: 141: 142: 143: 144: 145: 146: 147: 148: 149: 150: 151: Cuellar, Guenther Expires - December 2003 9 Geopriv Location Object Markup Language June 2003 152: 153: 154: 155: 156: 157: 158: 159: 160: 161: 162: Example: CT IC 3 Mobile Security Team Open Issue 5 (general): Which types of data sub-fields shall the LR data field support? (For example, data sub-fields for phone numbers or IP addresses of LRs?) 2.8. LR Credential Element Up to now, the Geopriv Working Group has not determined which types of Credentials are to be supported by the LR Credential data field. Thus, for now, we have specified in the definition of the LocationRecipientCredential element that credentials are of unspecific type ôxs:stringö (line 166-170). The element names ôPKIXCertificateö, ..., ôIDandSharedSecretö indicate some credential types that could be supported by the LR Credential data field. Line 165 (maxOccurs= öunboundedö) allows several credentials to be included in the LocationRecipientCredential element: 163: 164: 165: 166: 167: 168: 169: Cuellar, Guenther Expires - December 2003 10 Geopriv Location Object Markup Language June 2003 170: 171: 172: A vacuous example of a LocationRecipientCredential element: ... Open Issue 6 (general): Which credential types shall be supported by the LR Credential data field? 2.9. LR PoP Element The Geopriv Working Group should define explicitly the types of PoP (Proof of Possession of Credential) that shall be supported in the corresponding data field. The simplest way of providing such a PoP may be signing an appropriate statement on the result of a successfully executed challenge-response procedure. We indicate this possibility rudimentarily in the current definition of the LocationRecipientPoPofCredential element: 173: 174: 175: 176: 177: 178: 179: For adding an XML digital signature to the statement contained in line 176, the schema definition could be modified as follows: M01: M09: M10: ....... M11: M12: Cuellar, Guenther Expires - December 2003 11 Geopriv Location Object Markup Language June 2003 M13: M14: M15: M16: M17: M18: M19: ....... In line M04, the W3C XML Signature namespace is assigned to the prefix ôdsö. The place at which an XML validator can find the XML Signature language definitions is identified in line M09. Finally, line M15 makes a ds:Signature element mandatory. Open Issue 7 (general): Which types of LR PoP data fields shall be supported? (Signatures on Challenge-Response procedures? However, we also need ...?) 2.10. Rule Element As described in the Geopriv Requirements draft [3], the Rule Field of the LO ôMAY be a referral to an applicable Rule (for instance, an URI to a full Rule), or it MAY contain a Limited Rule, or bothö. In the current version of the LO markup language, this requirement is implemented as follows: 180: 181: 182: 183: 184: 185: 186: 187: 188: 191: 194: 195: 196: 197: 198: 199: 200: Cuellar, Guenther Expires - December 2003 12 Geopriv Location Object Markup Language June 2003 201: 202: 203: 204: 205: 206: 207: 208: A Rule element could therefore look like as follows: Dirk Kroeselberg has no permission to see my location. (And this is a Rule language that is in fact ôlimitedö ...) Open Issue 8 (general and XML): Geopriv must specify or adopt at least one Rule language. Furthermore, the mechanism of pointing to an applicable Rule must be described explicitly. In case of an XML LO data format, the XML Access Control Markup Language (XACML) seems to be a natural Rule language candidate - at least with respect to a full Rule language. - With regard to what exactly is a Limited Rule language supposed to be ôlimitedö? 2.11. Location Element The Location element carries the actual location information. It consists of an unbounded number of LocationInformation elements; the number of these elements can be zero (line 212). Each LocationInformation element allows for arbitrarily many LocationRepresentation child elements, and optional child elements ôSightingTimeö, ôMotionVectorö and ôDirectionVectorö (line 217-220). The LocationRepresentation elements can contain representations of location information that are of type ôLatLonAltö (Altitude is optional), ôCivilö, or ôTimeZoneö (lines 226-228), as well as of an type defined outside the namespace of the LO markup language (for instance, developed by OpenGIS), see line 229. In addition, the LocationRepresentation element has an optional child element ôConfidenceö (line 231), whose content is a decimal number between 0.0 and 100.0 indicating a level of reliability associated with a given Location Representation: 209: 210: 211: Cuellar, Guenther Expires - December 2003 13 Geopriv Location Object Markup Language June 2003 212: 213: 214: 215: 216: 217: 218: 219: 220: 221: 222: 223: 224: 225: 226: 227: 228: 229: 230: 231: 232: 233: The overall structure of an instance of the Location element can be seen from the following example, which uses the ôLatLonAltö, ôCivilö and ôTimeZoneö types of location representations: ..... ..... ..... ..... ..... ..... Cuellar, Guenther Expires - December 2003 14 Geopriv Location Object Markup Language June 2003 ...... ..... 2.11.1. Latitude, Longitude, Altitude and Precision Line 226 above points to the following definition of the ôLatLonAltö type of location representation: The LatLonAlt element consists of the mandatory Latitude and Longitude elements, an optional Altitude element and an optional Precision element: 234: 235: 236: 237: 238: 239: 240: 241: Real-world latitude and longitude representations come in (at least) three different styles: - Example: - 11— 13Æ 57ÆÆ: This means: degree, minute and second are represented separately by integers contained in certain intervals. We have introduced an equivalent XML representation which is abbreviated by DegIntMinIntSecInt. - Example: 48.1234—: This means: degree, minute and second are represented by one decimal number contained in a certain interval. We have specified an equivalent XML representation abbreviated by DegMinSecDec. - Example: - 19— 21.123Æ: This means: the degree is represented by an integer, while minute and second are represented by one decimal number. We have also introduced an equivalent XML representation which is abbreviated by DegIntMinSecDec. The optional Altitude element whose type is referenced in line 238 above consists of a positive or negative decimal number representing the altitude value with respect to a unit that must be indicated by the value of the attribute Unit. The permitted values of the Unit attribute are ôMeterö, ôKilometerö, ôFootö, ôYardö and ôMileö. Cuellar, Guenther Expires - December 2003 15 Geopriv Location Object Markup Language June 2003 The content of the optional element Precision (see line 239) is a positive decimal number indicating an area within which the Target is located. The Precision element has two mandatory attributes at its disposal: Area and Unit. The permitted values of the Area attribute are ôCircleö, ôSphereö, ôRectangleö and ôCuboidö indicating the shape of area, while the permitted values of the Unit attribute are as described above. In case the Altitude element is present, the semantics of a Precision element of the form 58.3, for instance, could be that the location of the Target is known to be contained in a sphere of 58.3 cubic meters around the position specified by means of the content of the Latitude, Longitude and Altitude elements. There are, of course, many other ways of indicating precision, which immediately leads to Open Issue 9 (general): Which types of precision indications shall be supported within the Location Field? Which is the exact semantics of these precision indications? Instead of listing the schema definitions illustrated in this paragraph, we give an example of a full LatLonAlt element: -48 8 23 11 34.4667 521.27 58.3 2.11.2. Civil There has been a long discussion within Geopriv on how the civil type of location representation should look like. Location domains such as ôstateö and ôdistrictö are not appropriate for all countries. Since we are not sure whether that discussion can be seen as finished, we include this problem in the list of open issues: Cuellar, Guenther Expires - December 2003 16 Geopriv Location Object Markup Language June 2003 Open Issue 10 (general): How exactly should civil location representations look like? In order to circumvent some of the problems, we have defined the civil type of location representation as follows: 242: 243: 244: 245: 246: 247: 248: 249: 250: 251: 252: 253: 254: 255: Thus, the Civil element introduced in line 227 above consists of an unbounded sequence of Domain elements, whose content is of type ôxs:stringö, and which are equipped with a mandatory but not explicitly specified attribute. The intention here is to allow for a type of civil location representation that is universal as far as possible: The Civil element Germany Bavaria Munich Leopoldstrasse 6 complies with its schema definition as well as ... ... ... does. 2.11.3. Time Zone Time zones are a further type of location representation supported by the schema definition: 256: 257: Cuellar, Guenther Expires - December 2003 17 Geopriv Location Object Markup Language June 2003 258: 259: 260: Therefore, -08:00, +11:36 and Z (standing for Zulu, i.e. Greenwich Mean Time) are valid content of TimeZone elements which have been introduced in line 228 above. 2.11.4. Sighting Time The W3C schema language specifications provide the data type ôxs:dateTimeö which is suitable for indicating when the location information was accurate. So 2003-07-14T20:12:34+01:00 is a valid SightingTime child element of the LocationInformation element. 2.11.5. Motion and Direction Vectors The MotionVector and DirectionVector elements are optional child elements of the LocationInformation element and are defined in lines 219 and 220 as follows: These definitions are nothing else than place holders since we have the following Open Issue 11 (general): How exactly shall the motion and direction vectors look like and what is their semantics? 2.12. Time to Live Element The data type ôxs:dateTimeö is also suitable for indicating until when location information can be considered current: 261: Example: 2003-07-14T20:17:34+01:00. 3. XML Schema Listing Cuellar, Guenther Expires - December 2003 18 Geopriv Location Object Markup Language June 2003 This section contains a complete listing of the XML schema that has been illustrated in previous sections. The next section provides a simple XML LO instance document that is valid with respect to this schema. Cuellar, Guenther Expires - December 2003 19 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 20 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 21 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 22 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 23 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 24 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 25 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 26 Geopriv Location Object Markup Language June 2003 Cuellar, Guenther Expires - December 2003 27 Geopriv Location Object Markup Language June 2003 4. XML LO Instance To give a preliminary impression of how an XML LO complying with the schema listed in section 3 could look like, this section provides Cuellar, Guenther Expires - December 2003 28 Geopriv Location Object Markup Language June 2003 such an XML instance document. It can be validated against this schema (see section 5). ginefohcsT sennaH 017167239870 Siemens AG CT IC 3 Mobile Security Team ... Challenge-Response executed successfully Cuellar, Guenther Expires - December 2003 29 Geopriv Location Object Markup Language June 2003 Dirk Kroeselberg has no permission to see my location. (Limited Rule Language needs to be defined.) -48 8 23 11 34.4667 521.27 58.3 95.0 Germany Bavaria Munich Leopoldstrasse 6 +01:00 2003-07-14T20:12:34+01:00 ... ... 2003-07-14T20:17:34+01:00 Cuellar, Guenther Expires - December 2003 30 Geopriv Location Object Markup Language June 2003 5. Note on Validation We have validated the XML LO listed in section 4 and other instance documents against the schema listed in section 3 using the XML Schema Validator (XSV) and the Apache XML projectÆs Xerces2-J parser. XSV and Xerces2-J are available at http://www.ltg.ed.ac.uk/~ht/xsv-status.html and http://xml.apache.org/xerces2-j/index.html, respectively. If you store the schema as ôgploml004.xsdö and the XML LO as (say) ôgploml004.xmlö in the same directory, then the commands xsv gploml004.xml gploml004.xsd and java dom.Writer ûv ûs gploml004.xml, respectively, should not produce any error messages. 6. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Cuellar, J., Morris, J.B., Mulligan D., Peterson, J., Polk, J., "Geopriv requirements", Internet Draft, draft-ietf-geopriv- reqs-03.txt, March 2003. 7. Author's Addresses Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich Email: jorge.cuellar@siemens.com Germany Christian Guenther Siemens AG Corporate Technology Cuellar, Guenther Expires - December 2003 31 Geopriv Location Object Markup Language June 2003 CT IC 3 81730 Munich Email: christian.guenther@siemens.com Germany 8. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. 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. Cuellar, Guenther Expires - December 2003 32