idnits 2.17.1
draft-jones-appsawg-webfinger-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 23, 2011) is 4568 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 4627 (ref. '3') (Obsoleted by RFC
7158, RFC 7159)
-- Possible downref: Non-RFC (?) normative reference: ref. '6'
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '9'
-- Obsolete informational reference (is this intentional?): RFC 4395 (ref.
'11') (Obsoleted by RFC 7595)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group Paul E. Jones
3 Internet Draft Gonzalo Salgueiro
4 Intended status: Standards Track Cisco Systems
5 Expires: April 23, 2012 Joseph Smarr
6 Google
7 October 23, 2011
9 Webfinger
10 draft-jones-appsawg-webfinger-00.txt
12 Abstract
14 This specification defines procedures for discovering information
15 about people.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on April 23, 2012.
34 Copyright Notice
36 Copyright (c) 2011 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction...................................................2
52 2. Terminology....................................................3
53 3. Example Uses of Webfinger......................................3
54 3.1. Locating a User's Blog....................................3
55 3.2. Populating an Electronic Address Book.....................3
56 3.3. Simplifying the Login Process.............................4
57 4. The Webfinger Protocol.........................................4
58 4.1. The acct URI Scheme.......................................4
59 4.2. Performing a Webfinger Query..............................5
60 5. Support for the JSON Resource Descriptor (JRD).................6
61 6. Support for Cross-Origin Resource Sharing......................7
62 7. Security Considerations........................................7
63 8. IANA Considerations............................................7
64 9. Acknowledgments................................................8
65 10. References....................................................8
66 10.1. Normative References.....................................8
67 10.2. Informative References...................................9
68 Author's Addresses................................................9
70 1. Introduction
72 There is a utility found on UNIX systems called "finger" [10] that
73 allows a person to access information about another person. The
74 information being queried might be on a computer anywhere in the
75 world. The information returned via "finger" is simply a plain text
76 file that contains unstructured information provided by the queried
77 user.
79 The "finger" protocol failed to be adopted by most users on the
80 Internet primarily for two reasons. First, few users have an account
81 on a system that supports the "finger" protocol. Even if one's email
82 provider enabled the "finger" service, the information conveyed is
83 substantially less rich and valuable than what might be conveyed on a
84 personal homepage, blog, or social network site. Thus, there has
85 been no motivation on the part of service providers to provide the
86 service. Second, the information conveyed is entirely unstructured
87 and not useful for automated processes. As such, there is little
88 value to web programmers who might wish to use this information.
90 Webfinger does not try to improve on the legacy "finger" by allowing
91 users to provide rich content, at least not directly. Rather,
92 Webfinger focuses on making information available to automated
93 systems. What a user provides via the Webfinger protocol are
94 references to the rich and valuable content. The references may be
95 processed by automated systems and the referenced information
96 utilized as appropriate for the content. This referenced content may
97 include, but is certainly not limited to, a user's name, homepage,
98 blog, social network pages, contact information, authentication
99 service, or demographic information.
101 2. Terminology
103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
105 document are to be interpreted as described in RFC 2119 [1].
107 3. Example Uses of Webfinger
109 In this section, we describe just a few sample use cases for
110 Webfinger. This is by no means an exhaustive list. The list of
111 potential use cases is virtually limitless since through Webfinger, a
112 user can share any kind of machine-consumable information.
114 3.1. Locating a User's Blog
116 Suppose you meet somebody at a party and they provide you with their
117 email address. After the party, you decide to visit your new
118 friend's blog to learn more about them. How do you find it? You
119 could search for your friend's name on the Internet or on various
120 social networking sites, but sometimes it is very hard to locate a
121 person or information about a person with merely an email address or
122 a name.
124 Having an account profile established that supports Webfinger,
125 though, your friend could provide a pointer to his or her blog.
126 Thus, you could perform a search through a search engine, a social
127 networking site, or through any Webfinger client and discover your
128 friend's blog immediately.
130 3.2. Populating an Electronic Address Book
132 Most people have an address book of some sort. It might be stored in
133 a mobile phone, on the web, or as a part of an often used application
134 like an email client. Populating the address book is often
135 complicated, as one has to first collect the information and then
136 manually enter the data as required for the particular address book
137 software. This can be automated through the use of vCard [12], but
138 the challenge for most users is finding those vCards.
140 Again, Webfinger can help with this scenario. Within one's address
141 book software, one could enter the user's email address and the
142 software could automatically locate the target user's vCard file and
143 populate the right fields accordingly.
145 Since Webfinger is a web service and since contact information
146 changes from time to time, an electronic address book might
147 automatically refresh stored information for users as changes are
148 detected so that address book entries never stale.
150 3.3. Simplifying the Login Process
152 We have all been frustrated with maintaining dozens or hundreds of
153 passwords for the various web sites that we visit. To address that
154 problem, technologies were developed to simplify the login process by
155 allowing users to utilize a single identity provider that can verify
156 user credentials and allow various web sites to trust that the user
157 trying to access certain resources is, indeed, who he or she claims
158 to be.
160 A challenge that remains with some solutions, though, is locating the
161 user's identity provider. Webfinger can help by advertising the
162 location of the user's identity provider, thus allowing the service
163 to perform a Webfinger query to discover that location and to
164 significantly simplify and improve the overall login process.
166 4. The Webfinger Protocol
168 Webfinger does not actually introduce a new protocol, per se.
169 Rather, it builds upon the existing Web Host Metadata [8] and the
170 Cross-Origin Resource Sharing [6] specifications.
172 4.1. The acct URI Scheme
174 The Web Host Metadata specification [8] refers to resources that may
175 be queried at a host. The protocol allows for any kind of resource
176 to be queried, but it is necessary to define a specific type of
177 resource in order to query information about a human user. For this
178 purpose, we introduce the "acct" URI scheme.
180 The "acct" URI scheme takes a familiar form in looking like an email
181 address. However, it is not an email address. Rather, it is an
182 account identifier. Quite often, and perhaps almost always, these
183 two values will appear to be virtually identical and software may
184 assume that if a user provides an email address to the system, the
185 associated user account may be accessed using the "acct" URI scheme
186 along with that email address. Users should never be required to
187 provide a system with the "acct" URI scheme name prepended in input
188 forms, but systems MUST accept the entry of the full URI if provided
189 by the user.
191 To ensure compatibility with email addresses, we define the Augmented
192 Backus-Naur Form (ABNF) [4] such that it borrows the non-terminal
193 definition of addr-spec from section 3.4.1 of RFC 5322 [5]. The
194 formal syntax is for the "acct" URI scheme is:
196 acctURI = "acct:" addr-spec
198 QUESTION: Do we want to restrict the acct: URI to only be user@domain
199 and borrow the syntax from, say, the SIP spec? Or, do we want to
200 reference addr-spec as we have it now?
202 4.2. Performing a Webfinger Query
204 Given an identifier, a system may perform a Webfinger query to locate
205 additional information related to the user that owns the identifier.
207 If the "acct" URI scheme name is not prepended to the identifier,
208 "acct:" must be prepended before attempting a query. So, given the
209 identifier bob@example.com, the identifier must be converted to
210 acct:bob@example.com to successfully issue a Webfinger request.
212 With a proper URI in hand, a Webfinger client issues a request to the
213 domain associated with the identifier. In our example, the domain is
214 example.com. The initial query is made to /.well-known/host-meta as
215 per [8]. For example:
217 GET /.well-known/host-meta HTTP/1.1
218 Host: example.com
220 The response will contain any number of link relations. All of the
221 link relations MUST be ignored, except for the one named 'lrdd'
222 (Link-based Resource Descriptor Documents). It is the LRDD link
223 relation that is where clients issue requests for user accounts.
225 Let us assume that the Extensible Resource Descriptor (XRD) [7]
226 document returned from the server contained the following LRDD link
227 relation:
229
233 If a client prefers to utilize JavaScript Object Notation (JSON) and
234 queries the /.well-known/host-meta.json resource, the following reply
235 snippet might be returned to the client, for example:
237 "link" :
238 [
239 {
240 "rel" : "lrdd",
241 "type" : "application/json",
242 "template" : "https://example.com/lrdd/?format=json&uri={uri}"
243 }
244 ]
246 Now knowing the URI template for the LRDD link relation, the
247 Webfinger client issues a request to the resource specified in the
248 template, replacing the template parameter with the target users
249 "acct" URI. With consideration given to the XRD example above, the
250 complete URI to use to query for the user's Webfinger information
251 would be:
253 https://example.com/lrdd/?uri=acct%3Abob%40example.com
255 When performing this query, another XRD document will be returned.
256 This document contains the link relations that are specific to the
257 target user.
259 Purely for illustrative purposes, consider the following document:
261
262
263 acct:bob@example.com
264
266
268
270
272
273
275
277 This document provides links to locations that include an avatar, a
278 blog, a vCard, an identity provider, a public file share, and the
279 user's profile page. Each of these link relations needs to be fully
280 specified, but the definition of link relations is outside the scope
281 of this document.
283 What software does with this information is also outside the scope of
284 this document.
286 5. Support for the JSON Resource Descriptor (JRD)
288 The JRD representation uses the JSON format, elements and processing
289 rules defined in RFC 4627 [3]. Servers that support Webfinger queries
290 MUST support the JRD representation as defined in Appendix A of [8].
292 6. Support for Cross-Origin Resource Sharing
294 Webfinger is most useful when it is accessible without restrictions
295 on the Internet, and that includes web browsers. Therefore, servers
296 that support the Webfinger protocol MUST support Cross-Origin
297 Resource Sharing (CORS) [6]. Specifically, all queries to /.well-
298 known/host-meta and to the LRDD URI must include the following header
299 in the Hypertext Transfer Protocol (HTTP) [2] response:
301 Access-Control-Allow-Origin: *
303 QUESTION: Do we want to require CORS? Do we want to make it a
304 SHOULD? Or, do we want to say nothing about CORS?
306 7. Security Considerations
308 All of the security considerations applicable to Web Host Metadata
309 [8] and Cross-Origin Resource Sharing [6] are also applicable to this
310 specification.
312 Further, service providers and users should also be aware that
313 placing information on the Internet accessible through Webfinger
314 means that any user can access that information. While Webfinger can
315 be an extremely useful tool for allowing quick and easy access to
316 one's avatar, blog, or other personal information, users should
317 understand the risks, too. If one does not wish to share certain
318 information with the world, do not allow that information to be
319 accessible through Webfinger.
321 8. IANA Considerations
323 This specification requests IANA to register the "acct" URI scheme in
324 the "Permanent URI Schemes" sub-registry in the "Uniform Resource
325 Identifier (URI) Schemes" IANA registry [13]. This registration
326 follows the URI Scheme Registration Template detailed in Section 5.4
327 of RFC 4395 [11].
329 URI scheme name: acct
331 Status: Permanent
333 URI scheme syntax: see Section 4.1 of RFC XXXX [This document]
335 URI scheme semantics: see Section 4.1 of RFC XXXX [This document]
337 Encoding considerations: The "acct" URI scheme is encoded in US-
338 ASCII [9], with section 3.4.1 of RFC 5322 detailing the encoding of
339 addr-spec
340 Applications/protocols that use this URI scheme name: Webfinger
342 Security considerations: see Section 7 of RFC XXXX [This document]
344 Contact: Gonzalo Salgueiro
346 Author/Change controller: IETF
348 References: See Section 10 of RFC XXXX [This document]
350 9. Acknowledgments
352 The authors would like to acknowledge Eran Hammer-Lahav and Blaine
353 Cook for their invaluable input.
355 10. References
357 10.1. Normative References
359 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
360 Levels", BCP 14, RFC 2119, March 1997.
362 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
363 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
364 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
366 [3] Crockford, D., "The application/json Media Type for
367 JavaScript Object Notation (JSON)", RFC 4627, July 2006.
369 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
370 Specifications: ABNF", STD 68, RFC 5234, January 2008.
372 [5] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
374 [6] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS
375 http://www.w3.org/TR/cors/, July 2010.
377 [7] Hammer-Lahav, E. and W. Norris, "Extensible Resource
378 Descriptor (XRD) Version 1.0",
379 .
381 [8] Hammer-Lahav, E., Cook, B., "Web Host Metadata", draft-hammer-
382 hostmeta-17, September 2011.
384 [9] American National Standards Institute, "Coded Character Set -
385 7-bit American Standard Code for Information Interchange", ANSI
386 X3.4, 1986.
388 10.2. Informative References
390 [10] Zimmerman, D., "The Finger User Information Protocol", RFC
391 1288, December 1991.
393 [11] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
394 Registration Procedures for New URI Schemes", BCP 35, RFC 4395,
395 February 2006.
397 [12] Perreault, S., "vCard Format Specification", RFC 6350, August
398 2011.
400 [13] Internet Assigned Numbers Authority (IANA) Registry, "Uniform
401 Resource Identifier (URI) Schemes",
402 .
404 Author's Addresses
406 Paul E. Jones
407 Cisco Systems, Inc.
408 7025 Kit Creek Rd.
409 Research Triangle Park, NC 27709
410 USA
412 Phone: +1 919 476 2048
413 Email: paulej@packetizer.com
414 IM: xmpp:paulej@packetizer.com
416 Gonzalo Salgueiro
417 Cisco Systems, Inc.
418 7025 Kit Creek Rd.
419 Research Triangle Park, NC 27709
420 USA
422 Phone: +1 919 392 3266
423 Email: gsalguei@cisco.com
424 IM: xmpp:gsalguei@cisco.com
426 Joseph Smarr
427 Google
428 ADDRESS
430 Phone: PHONE
431 Email: jsmarr@google.com