Network Working Group Paul E. Jones Internet Draft Gonzalo Salgueiro Intended status: Standards Track Cisco Systems Expires: April 23, 2012 Joseph Smarr Google October 23, 2011 Webfinger draft-jones-appsawg-webfinger-00.txt Abstract This specification defines procedures for discovering information about people. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 23, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Jones, et al. Expires April 23, 2012 [Page 1] Internet-Draft Webfinger October 2011 Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Example Uses of Webfinger......................................3 3.1. Locating a User's Blog....................................3 3.2. Populating an Electronic Address Book.....................3 3.3. Simplifying the Login Process.............................4 4. The Webfinger Protocol.........................................4 4.1. The acct URI Scheme.......................................4 4.2. Performing a Webfinger Query..............................5 5. Support for the JSON Resource Descriptor (JRD).................6 6. Support for Cross-Origin Resource Sharing......................7 7. Security Considerations........................................7 8. IANA Considerations............................................7 9. Acknowledgments................................................8 10. References....................................................8 10.1. Normative References.....................................8 10.2. Informative References...................................9 Author's Addresses................................................9 1. Introduction There is a utility found on UNIX systems called "finger" [10] that allows a person to access information about another person. The information being queried might be on a computer anywhere in the world. The information returned via "finger" is simply a plain text file that contains unstructured information provided by the queried user. The "finger" protocol failed to be adopted by most users on the Internet primarily for two reasons. First, few users have an account on a system that supports the "finger" protocol. Even if one's email provider enabled the "finger" service, the information conveyed is substantially less rich and valuable than what might be conveyed on a personal homepage, blog, or social network site. Thus, there has been no motivation on the part of service providers to provide the service. Second, the information conveyed is entirely unstructured and not useful for automated processes. As such, there is little value to web programmers who might wish to use this information. Webfinger does not try to improve on the legacy "finger" by allowing users to provide rich content, at least not directly. Rather, Webfinger focuses on making information available to automated systems. What a user provides via the Webfinger protocol are references to the rich and valuable content. The references may be processed by automated systems and the referenced information utilized as appropriate for the content. This referenced content may include, but is certainly not limited to, a user's name, homepage, Jones, et al. Expires April 23, 2012 [Page 2] Internet-Draft Webfinger October 2011 blog, social network pages, contact information, authentication service, or demographic information. 2. 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 RFC 2119 [1]. 3. Example Uses of Webfinger In this section, we describe just a few sample use cases for Webfinger. This is by no means an exhaustive list. The list of potential use cases is virtually limitless since through Webfinger, a user can share any kind of machine-consumable information. 3.1. Locating a User's Blog Suppose you meet somebody at a party and they provide you with their email address. After the party, you decide to visit your new friend's blog to learn more about them. How do you find it? You could search for your friend's name on the Internet or on various social networking sites, but sometimes it is very hard to locate a person or information about a person with merely an email address or a name. Having an account profile established that supports Webfinger, though, your friend could provide a pointer to his or her blog. Thus, you could perform a search through a search engine, a social networking site, or through any Webfinger client and discover your friend's blog immediately. 3.2. Populating an Electronic Address Book Most people have an address book of some sort. It might be stored in a mobile phone, on the web, or as a part of an often used application like an email client. Populating the address book is often complicated, as one has to first collect the information and then manually enter the data as required for the particular address book software. This can be automated through the use of vCard [12], but the challenge for most users is finding those vCards. Again, Webfinger can help with this scenario. Within one's address book software, one could enter the user's email address and the software could automatically locate the target user's vCard file and populate the right fields accordingly. Since Webfinger is a web service and since contact information changes from time to time, an electronic address book might Jones, et al. Expires April 23, 2012 [Page 3] Internet-Draft Webfinger October 2011 automatically refresh stored information for users as changes are detected so that address book entries never stale. 3.3. Simplifying the Login Process We have all been frustrated with maintaining dozens or hundreds of passwords for the various web sites that we visit. To address that problem, technologies were developed to simplify the login process by allowing users to utilize a single identity provider that can verify user credentials and allow various web sites to trust that the user trying to access certain resources is, indeed, who he or she claims to be. A challenge that remains with some solutions, though, is locating the user's identity provider. Webfinger can help by advertising the location of the user's identity provider, thus allowing the service to perform a Webfinger query to discover that location and to significantly simplify and improve the overall login process. 4. The Webfinger Protocol Webfinger does not actually introduce a new protocol, per se. Rather, it builds upon the existing Web Host Metadata [8] and the Cross-Origin Resource Sharing [6] specifications. 4.1. The acct URI Scheme The Web Host Metadata specification [8] refers to resources that may be queried at a host. The protocol allows for any kind of resource to be queried, but it is necessary to define a specific type of resource in order to query information about a human user. For this purpose, we introduce the "acct" URI scheme. The "acct" URI scheme takes a familiar form in looking like an email address. However, it is not an email address. Rather, it is an account identifier. Quite often, and perhaps almost always, these two values will appear to be virtually identical and software may assume that if a user provides an email address to the system, the associated user account may be accessed using the "acct" URI scheme along with that email address. Users should never be required to provide a system with the "acct" URI scheme name prepended in input forms, but systems MUST accept the entry of the full URI if provided by the user. To ensure compatibility with email addresses, we define the Augmented Backus-Naur Form (ABNF) [4] such that it borrows the non-terminal definition of addr-spec from section 3.4.1 of RFC 5322 [5]. The formal syntax is for the "acct" URI scheme is: Jones, et al. Expires April 23, 2012 [Page 4] Internet-Draft Webfinger October 2011 acctURI = "acct:" addr-spec QUESTION: Do we want to restrict the acct: URI to only be user@domain and borrow the syntax from, say, the SIP spec? Or, do we want to reference addr-spec as we have it now? 4.2. Performing a Webfinger Query Given an identifier, a system may perform a Webfinger query to locate additional information related to the user that owns the identifier. If the "acct" URI scheme name is not prepended to the identifier, "acct:" must be prepended before attempting a query. So, given the identifier bob@example.com, the identifier must be converted to acct:bob@example.com to successfully issue a Webfinger request. With a proper URI in hand, a Webfinger client issues a request to the domain associated with the identifier. In our example, the domain is example.com. The initial query is made to /.well-known/host-meta as per [8]. For example: GET /.well-known/host-meta HTTP/1.1 Host: example.com The response will contain any number of link relations. All of the link relations MUST be ignored, except for the one named 'lrdd' (Link-based Resource Descriptor Documents). It is the LRDD link relation that is where clients issue requests for user accounts. Let us assume that the Extensible Resource Descriptor (XRD) [7] document returned from the server contained the following LRDD link relation: If a client prefers to utilize JavaScript Object Notation (JSON) and queries the /.well-known/host-meta.json resource, the following reply snippet might be returned to the client, for example: "link" : [ { "rel" : "lrdd", "type" : "application/json", "template" : "https://example.com/lrdd/?format=json&uri={uri}" } ] Jones, et al. Expires April 23, 2012 [Page 5] Internet-Draft Webfinger October 2011 Now knowing the URI template for the LRDD link relation, the Webfinger client issues a request to the resource specified in the template, replacing the template parameter with the target users "acct" URI. With consideration given to the XRD example above, the complete URI to use to query for the user's Webfinger information would be: https://example.com/lrdd/?uri=acct%3Abob%40example.com When performing this query, another XRD document will be returned. This document contains the link relations that are specific to the target user. Purely for illustrative purposes, consider the following document: acct:bob@example.com This document provides links to locations that include an avatar, a blog, a vCard, an identity provider, a public file share, and the user's profile page. Each of these link relations needs to be fully specified, but the definition of link relations is outside the scope of this document. What software does with this information is also outside the scope of this document. 5. Support for the JSON Resource Descriptor (JRD) The JRD representation uses the JSON format, elements and processing rules defined in RFC 4627 [3]. Servers that support Webfinger queries MUST support the JRD representation as defined in Appendix A of [8]. Jones, et al. Expires April 23, 2012 [Page 6] Internet-Draft Webfinger October 2011 6. Support for Cross-Origin Resource Sharing Webfinger is most useful when it is accessible without restrictions on the Internet, and that includes web browsers. Therefore, servers that support the Webfinger protocol MUST support Cross-Origin Resource Sharing (CORS) [6]. Specifically, all queries to /.well- known/host-meta and to the LRDD URI must include the following header in the Hypertext Transfer Protocol (HTTP) [2] response: Access-Control-Allow-Origin: * QUESTION: Do we want to require CORS? Do we want to make it a SHOULD? Or, do we want to say nothing about CORS? 7. Security Considerations All of the security considerations applicable to Web Host Metadata [8] and Cross-Origin Resource Sharing [6] are also applicable to this specification. Further, service providers and users should also be aware that placing information on the Internet accessible through Webfinger means that any user can access that information. While Webfinger can be an extremely useful tool for allowing quick and easy access to one's avatar, blog, or other personal information, users should understand the risks, too. If one does not wish to share certain information with the world, do not allow that information to be accessible through Webfinger. 8. IANA Considerations This specification requests IANA to register the "acct" URI scheme in the "Permanent URI Schemes" sub-registry in the "Uniform Resource Identifier (URI) Schemes" IANA registry [13]. This registration follows the URI Scheme Registration Template detailed in Section 5.4 of RFC 4395 [11]. URI scheme name: acct Status: Permanent URI scheme syntax: see Section 4.1 of RFC XXXX [This document] URI scheme semantics: see Section 4.1 of RFC XXXX [This document] Encoding considerations: The "acct" URI scheme is encoded in US- ASCII [9], with section 3.4.1 of RFC 5322 detailing the encoding of addr-spec Jones, et al. Expires April 23, 2012 [Page 7] Internet-Draft Webfinger October 2011 Applications/protocols that use this URI scheme name: Webfinger Security considerations: see Section 7 of RFC XXXX [This document] Contact: Gonzalo Salgueiro Author/Change controller: IETF References: See Section 10 of RFC XXXX [This document] 9. Acknowledgments The authors would like to acknowledge Eran Hammer-Lahav and Blaine Cook for their invaluable input. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [3] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [5] Resnick, P., "Internet Message Format", RFC 5322, October 2008. [6] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS http://www.w3.org/TR/cors/, July 2010. [7] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor (XRD) Version 1.0", . [8] Hammer-Lahav, E., Cook, B., "Web Host Metadata", draft-hammer- hostmeta-17, September 2011. [9] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4, 1986. Jones, et al. Expires April 23, 2012 [Page 8] Internet-Draft Webfinger October 2011 10.2. Informative References [10] Zimmerman, D., "The Finger User Information Protocol", RFC 1288, December 1991. [11] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006. [12] Perreault, S., "vCard Format Specification", RFC 6350, August 2011. [13] Internet Assigned Numbers Authority (IANA) Registry, "Uniform Resource Identifier (URI) Schemes", . Author's Addresses Paul E. Jones Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 476 2048 Email: paulej@packetizer.com IM: xmpp:paulej@packetizer.com Gonzalo Salgueiro Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Phone: +1 919 392 3266 Email: gsalguei@cisco.com IM: xmpp:gsalguei@cisco.com Joseph Smarr Google ADDRESS Phone: PHONE Email: jsmarr@google.com Jones, et al. Expires April 23, 2012 [Page 9]