Network Working Group                                      Paul E. Jones
Internet Draft                                         Gonzalo Salgueiro
Intended status: Standards Track                           Cisco Systems
Expires: April 23, 2012                                     Joseph Smarr
                                                        October 23, 2011



   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

   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
   ( 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

   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",
   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, the identifier must be converted to 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  The initial query is made to /.well-known/host-meta as
   per [8].  For example:

     GET /.well-known/host-meta HTTP/1.1

   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

     <Link rel="lrdd"
           template="{uri}" />

   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" : "{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:

   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:

     <?xml version="1.0" encoding="UTF-8"?>
     <XRD xmlns="">
       <Link rel=""
       <Link rel="blog"
       <Link rel="vcard"
       <Link rel=""
       <Link rel="share" href=""/>
       <Link rel=""

   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

   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

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, 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

   [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

   Phone: +1 919 476 2048

   Gonzalo Salgueiro
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Research Triangle Park, NC 27709

   Phone: +1 919 392 3266

   Joseph Smarr

   Phone: PHONE

Jones, et al.           Expires April 23, 2012                  [Page 9]