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