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]