GEOPRIV Working Group M. Thomson Internet-Draft Andrew Expires: April 14, 2006 J. Polk Cisco October 11, 2005 Using URIs for the PIDF-LO 'provided-by' element draft-thomson-geopriv-provided-by-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 14, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The "provided-by" element in PIDF-LO is a container designed to carry information about the source of location information. This document defines an XML structure that can be used within the "provided-by" element to convey basic information about the information provider in the form of a URI. Thomson & Polk Expires April 14, 2006 [Page 1] Internet-Draft provided-by URI October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. provided-by URI . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. URI Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 3. provided-by URI Schema . . . . . . . . . . . . . . . . . . . . 5 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Thomson & Polk Expires April 14, 2006 [Page 2] Internet-Draft provided-by URI October 2005 1. Introduction The PIDF-LO document [I-D.ietf-geopriv-pidf-lo] defines the "provided-by" element, which is to be used to identify the organization that provided the location information to the endsystem. The "provided-by" element is designed to either augment provider identity information contained in a digital signature, or provide some information in the absence of a signature. The "provided-by" element can also be used to identify an original provider in the case where information is made available by a third party. The PIDF-LO specification [I-D.ietf-geopriv-pidf-lo] includes a definition for a "provided-by" element, that is, for the National Emergency Number Association (NENA), which is North America specific. This document includes a lightweight definition that is more widely applicable. The URI form specified in this document provides a loose means of identifying the provider of location information to the endsystem. It is characterized as "loose" since it the information can only be used as a hint, see Section 5 for details. 1.1. Terminology 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 [RFC2119]. Thomson & Polk Expires April 14, 2006 [Page 3] Internet-Draft provided-by URI October 2005 2. provided-by URI This document defines "provided-by" content, the "uri" element, that can be used to convey URIs. A URI provides a very flexible means of conveying information. To that end, this document does not mandate specific processing for the "provided-by" element. A User Agent MAY interpret the "provided-by" element in any fashion it considers appropriate, which could simply be to ignore the field entirely. Where URIs are made available, a User Agent SHOULD only use any URI on explicit user direction. It is RECOMMENDED that, where applicable, any URI included in the "provided-by" element be accessible from the public internet without requiring authentication. There MAY be more than one "uri" element in a PIDF-LO so that multiple URIs can be present. It MAY also be used in combination with other "provided-by" content. 2.1. URI Usage URIs included in the "provided-by" element can be used for many purposes. The "type" attribute MAY be included to provide a hint to a User Agent about how a URI could be used if it isn't evident from the URI scheme. The following values are defined: contact: The URI can be used to contact the providing organization. This is similar to the "contact" element defined in PIDF [RFC3863]. It is RECOMMENDED that this field include a URI in a scheme that can be used for establishing a media session, such as sip, sips or tel. location: The URI references location information pertaining to the organization or the specific campus, which should be in the form of a PIDF-LO document. info: The URI references general information, which might include information on the privacy policy of the organization; an explanation of how location information is determined by the organization; or any other information. No guidance is provided on how URIs are used, however it is expected that a User Agent use default handling behavior for each scheme. For instance, an http URI might be passed to a web browser or a sips URI might be passed to a SIP UA. Thomson & Polk Expires April 14, 2006 [Page 4] Internet-Draft provided-by URI October 2005 3. provided-by URI Schema The following schema defines a "uri" element that can be used for "provided-by" URIs. Thomson & Polk Expires April 14, 2006 [Page 5] Internet-Draft provided-by URI October 2005 4. Example The following example demonstrates the inclusion of multiple URIs in the "provided-by" element. DE BayernOberbayern München Marienplatz8 80331 no http://www.example.com/info/pidf-lo/ sips:location@example.com mailto:location@example.com?subject=PIDF-LO Thomson & Polk Expires April 14, 2006 [Page 6] Internet-Draft provided-by URI October 2005 5. Security Considerations The information in the "provided-by" element does not provide any assurance that the entity referred to is actually the provider of the location information. Specifically, the contents of a "provided-by" element do not provide a cryptographic assertion of identity of any nature. Unless location information is digitally signed, it is very easy to provide fraudulent information within this field. For example, a PIDF-LO from "example.cracker.com" might include a URI to the well- known and trusted "example.com" web site. This attack could be used to trick users into thinking that the location information was provided by "example.com". When a PIDF-LO is not digitally signed by an authenticated and sufficiently authorized entity the following restrictions apply: o Users of the information MUST NOT represent any authentication information provided when dereferencing the URI as the provider of location information. o Users of this information MUST NOT use the information for any purpose beyond informational. It is RECOMMENDED that a User Agent observe these restrictions even when a digital signature is present. Thomson & Polk Expires April 14, 2006 [Page 7] Internet-Draft provided-by URI October 2005 6. IANA Considerations This document calls for IANA to register a new XML namespace, as per the guidelines in [RFC3688]. 6.1. URN sub-namespace registration for 'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' URI urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri Registrant Contact IETF, GEOPRIV working group Martin Thomson XML BEGIN GEOPRIV provided-by URI

URI element for the provided-by element in PIDF-LO

urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri

See RFCXXXX.

END Thomson & Polk Expires April 14, 2006 [Page 8] Internet-Draft provided-by URI October 2005 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-geopriv-pidf-lo] Peterson, J., "A Presence-based GEOPRIV Location Object Format", draft-ietf-geopriv-pidf-lo-03 (work in progress), September 2004. 7.2. Informative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. Thomson & Polk Expires April 14, 2006 [Page 9] Internet-Draft provided-by URI October 2005 Authors' Addresses Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ James M. Polk Cisco 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com Thomson & Polk Expires April 14, 2006 [Page 10] Internet-Draft provided-by URI October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thomson & Polk Expires April 14, 2006 [Page 11]