idnits 2.17.1 draft-ietf-appsawg-webfinger-03.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 (November 16, 2012) is 4178 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 5785 (ref. '3') (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 5988 (ref. '4') (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 4627 (ref. '5') (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-07) exists of draft-ietf-appsawg-acct-uri-01 -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: May 16, 2013 Joseph Smarr 6 Google 7 November 16, 2012 9 WebFinger 10 draft-ietf-appsawg-webfinger-03.txt 12 Abstract 14 This specification defines the WebFinger protocol, which can be used 15 to discover information about people or other entities on the 16 Internet using standard HTTP methods. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 16, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction...................................................2 53 2. Terminology....................................................3 54 3. Overview.......................................................3 55 4. Example Use of WebFinger.......................................3 56 4.1. Locating a User's Blog....................................4 57 4.2. Auto-Configuration of Email Clients.......................5 58 4.3. Retrieving Device Information.............................6 59 5. WebFinger Protocol.............................................7 60 5.1. Performing a WebFinger Query..............................7 61 5.2. The JSON Resource Descriptor (JRD) Document...............8 62 5.3. The "rel" Parameter.......................................8 63 5.4. WebFinger and URIs.......................................10 64 6. Cross-Origin Resource Sharing (CORS)..........................10 65 7. Controlling Access to Information.............................11 66 8. Hosted WebFinger Services.....................................11 67 9. Security Considerations.......................................12 68 10. IANA Considerations..........................................13 69 11. Acknowledgments..............................................14 70 12. References...................................................14 71 12.1. Normative References....................................14 72 12.2. Informative References..................................15 73 Author's Addresses...............................................16 75 1. Introduction 77 There is a utility found on UNIX systems called "finger" [12] that 78 allows a person to access information about another person or entity 79 that has a UNIX account. The information queried might be on the 80 same computer or a computer anywhere in the world. What is returned 81 via "finger" is a plain text file that contains unstructured 82 information provided by the queried user, stored in a file named 83 .plan in the user's home directory. 85 Like the finger command, WebFinger can be used to discover 86 information about people or other entities on the Internet. However, 87 unlike the legacy finger command, WebFinger uses standard HTTP [2] 88 methods and utilizes a structured document that contains link 89 relations that are suitable for automated processes. These link 90 relations point to information and might return properties related to 91 information a user or entity on the Internet wishes to share. For a 92 person, the kinds of information that might be shared include a 93 personal profile address, identity service, telephone number, or 94 preferred avatar. WebFinger may also be used to discover information 95 about other entities on the Internet, such as the amount of toner in 96 a printer or the physical location of a server. 98 Information returned via WebFinger might be for direct human 99 consumption (e.g., another user's phone number) or it might be used 100 by systems to help carry out some operation (e.g., facilitate logging 101 into a web site by determining a user's identity service). 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [1]. 109 WebFinger makes heavy use of "Link Relations". Briefly, a Link 110 Relation is an attribute and value pair used on the Internet wherein 111 the attribute identifies the type of link to which the associated 112 value refers. In Hypertext Transfer Protocol (HTTP) and Web Linking 113 [4], the attribute is a "rel" and the value is an "href". 115 3. Overview 117 WebFinger enables the discovery of information about users, devices, 118 and other entities that are associated with a host. Discovery 119 involves a single HTTP GET request to the well-known [3] "webfinger" 120 resource at the target host and receiving back a JavaScript Object 121 Notation (JSON) [5] Resource Descriptor (JRD) document [11] 122 containing link relations. The request MUST include the URI [6] or 123 IRI [7] for the entity for which information is sought as a parameter 124 named "resource". 126 Briefly, a link is a typed connection between two web resources that 127 are identified by Internationalized Resource Identifiers (IRIs); this 128 connection consists of a context IRI, a link relation type, a target 129 IRI, and optionally some target attributes, resulting in statements 130 of the form "{context IRI} has a {relation type} resource at {target 131 IRI}, which has {target attributes}". When used in the Link HTTP 132 header, the context IRI is the IRI of the requested resource, the 133 relation type is the value of the "rel" parameter, the target IRI is 134 URI-Reference contained in the Link header, and the target attributes 135 are the parameters such as "hreflang", "media", "title", "title*", 136 "type", and any other link-extension parameters. 138 Use of WebFinger is illustrated in the examples in Section 4, then 139 described more formally in Section 5. 141 4. Example Use of WebFinger 143 In this section, we show a few samples using WebFinger so you can see 144 what the protocol looks like. This is not an exhaustive list of 145 possible uses and the entire section should be considered non- 146 normative. 148 4.1. Locating a User's Blog 150 Assume you receive an email from Bob and he refers to something he 151 posted on his blog, but you do not know where Bob's blog is located. 152 It would be simple to discover the address of Bob's blog if he makes 153 that information available via WebFinger. 155 Let's assume your email client can discover the blog for you. After 156 receiving the message from Bob (bob@example.com), you instruct your 157 email client to perform a WebFinger query. It does so by issuing the 158 following HTTPS query to example.com: 160 GET /.well-known/webfinger? 161 resource=acct%3Abob%40example.com HTTP/1.1 162 Host: example.com 164 The server might then respond with a message like this: 166 HTTP/1.1 200 OK 167 Access-Control-Allow-Origin: * 168 Content-Type: application/json; charset=UTF-8 170 { 171 "expires" : "2012-11-16T19:41:35Z", 172 "subject" : "acct:bob@example.com", 173 "aliases" : 174 [ 175 "http://www.example.com/~bob/" 176 ], 177 "properties" : 178 { 179 "http://example.com/rel/role/" : "employee" 180 }, 181 "links" : 182 [ 183 { 184 "rel" : "http://webfinger.net/rel/avatar", 185 "type" : "image/jpeg", 186 "href" : "http://www.example.com/~bob/bob.jpg" 187 }, 188 { 189 "rel" : "http://webfinger.net/rel/profile-page", 190 "href" : "http://www.example.com/~bob/" 191 }, 192 { 193 "rel" : "http://packetizer.com/rel/blog", 194 "type" : "text/html", 195 "href" : "http://blogs.example.com/bob/", 196 "properties" : 198 { 199 "en-us" : "The Magical World of Bob", 200 "fr" : "Le monde magique de Bob" 201 } 202 }, 203 { 204 "rel" : "vcard", 205 "href" : "http://www.example.com/~bob/bob.vcf" 206 } 207 ] 208 } 210 The email client would take note of the 211 "http://packetizer.com/rel/blog" link relation in the above JRD 212 document that refers to Bob's blog. This URL would then be presented 213 to you so that you could then visit his blog. The email client might 214 also note that Bob has published an avatar link relation and use that 215 picture to represent Bob inside the email client. Lastly, the client 216 might consider the vcard [13] link relation in order to update 217 contact information for Bob. 219 In the above example, an "acct" URI [8] is used in the query, though 220 any valid alias for the user might also be used. Had the "http:" URI 221 shown as an alias been used to query for information about Bob, the 222 query would have appeared as: 224 GET /.well-known/webfinger? 225 resource=http%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1 226 Host: example.com 228 The response would have been substantially the same, with the subject 229 and alias information changed as necessary. Other information, such 230 as the expiration time might also change, but the set of link 231 relations and properties would be the same with either response. 233 4.2. Auto-Configuration of Email Clients 235 WebFinger could be used to auto-provision an email client with basic 236 configuration data. Suppose that sue@example.com wants to configure 237 her email client. Her email client might issue the following query: 239 GET /.well-known/webfinger? 240 resource=mailto%3Asue%40example.com HTTP/1.1 241 Host: example.com 243 The response from the server would contain entries for the various 244 protocols, transport options, and security options. If there are 245 multiple options, the server might return a link relation that for 246 each of the valid options and the client or Sue might select which 247 option to choose. Since JRD documents list link relations in a 248 specific order, then the most-preferred choices could be presented 249 first. Consider this response: 251 { 252 "subject" : "mailto:sue@example.com", 253 "links" : 254 [ 255 { 256 "rel" : "smtp-server", 257 "properties" : 258 { 259 "host" : "smtp.example.com", 260 "port" : "587", 261 "login-required" : "yes", 262 "transport" : "starttls" 263 } 264 }, 265 { 266 "rel" : "imap-server", 267 "properties" : 268 { 269 "host" : "imap.example.com", 270 "port" : "993", 271 "transport" : "ssl" 272 } 273 } 274 ] 275 } 277 In this example, you can see that the WebFinger server advertises an 278 SMTP service and an IMAP service. In this example, the "href" 279 entries associated with the link relation are absent. This is valid 280 when there is no external reference that needs to be made. 282 4.3. Retrieving Device Information 284 As another example, let's suppose there are printers on the network 285 and you would like to check the current toner level for a particular 286 printer identified via the URI device:p1.example.com. While the 287 "device" URI scheme is not presently specified, we use it here for 288 illustrative purposes. 290 Following the procedures similar to those above, a query may be 291 issued to get link relations specific to this URI like this: 293 GET /.well-known/webfinger?resource= 294 device%3Ap1.example.com HTTP/1.1 295 Host: example.com 297 The link relations that are returned for a device may be quite 298 different than those for user accounts. Perhaps we may see a 299 response like this: 301 HTTP/1.1 200 OK 302 Access-Control-Allow-Origin: * 303 Content-Type: application/json; charset=UTF-8 305 { 306 "subject" : "device:p1.example.com", 307 "links" : 308 [ 309 { 310 "rel" : "tipsi", 311 "href" : "http://192.168.1.5/npap/" 312 } 313 ] 314 } 316 While this example is fictitious, you can imagine that perhaps the 317 Transport Independent, Printer/System Interface [14] may be enhanced 318 with a web interface that allows a device that understands the TIP/SI 319 web interface specification to query the printer for toner levels. 321 5. WebFinger Protocol 323 WebFinger is a simple HTTP-based web service that utilizes the JSON 324 Resource Descriptor (JRD) document format and the Cross-Origin 325 Resource Sharing (CORS) [10] specification. 327 5.1. Performing a WebFinger Query 329 WebFinger clients issue queries to the well-known resource /.well- 330 known/webfinger. All queries MUST include the "resource" parameter 331 exactly once and set to the value of the URI for which information is 332 being sought. If the "resource" parameter is absent or malformed, 333 the WebFinger server MUST return a 400 status code. 335 Clients MUST first attempt a query the server using HTTPS and utilize 336 HTTP only if an HTTPS connection cannot be established. If the HTTPS 337 server has an invalid certificate or returns an HTTP status code 338 indicating some error, including a 4xx or 5xx, the client MUST NOT 339 use HTTP in attempt to complete the discovery. 341 WebFinger servers MUST return JRD documents as the default 342 representation for the resource. A client MAY include the "Accept" 343 header to indicate a desired format, though no other format is 344 defined in this specification. For the JRD document, the media type 345 is "application/json" [5]. 347 If the client queries the WebFinger server and provides a URI for 348 which the server has no information, the server MUST return a 404 349 status code. 351 WebFinger servers MAY include cache validators in a response to 352 enable conditional requests by clients and/or expiration times as per 353 RFC 2616 section 13. 355 5.2. The JSON Resource Descriptor (JRD) Document 357 The JSON Resource Descriptor (JRD) document is formally described in 358 Appendix A of [11]. There is a RECOMMENDED order of JRD elements. 359 Further, WebFinger requires some elements and some are optional. The 360 following list indicates the preferred order and comments on the 361 presence or absence: 363 o "expires" (element) is optional 364 o "subject" (element) is required and MUST be the value of the 365 "resource" parameter 366 o "aliases" (array) is optional and absence or an empty array 367 are semantically the same 368 o "properties" (array) is optional and absence or an empty 369 array are semantically the same 370 o "links" (array) is optional and absence or an empty array are 371 semantically the same 373 Any array elements within the "links" array are presented by the 374 server in order of preference. 376 The "links" array is comprised of several elements. As above, the 377 following list indicates the preferred order or elements within a 378 link array element and comments on the presence or absence: 380 o "rel" (element) is required 381 o "type" (element) is optional 382 o "href" (element) is optional 383 o "template" (element) is forbidden 384 o "titles" (array) is optional and absence or an empty array 385 are semantically the same 386 o "properties" (array) is optional and absence or an empty 387 array are semantically the same 389 5.3. The "rel" Parameter 391 WebFinger defines the "rel" parameter to request only a subset of the 392 information that would otherwise be returned without the "rel" 393 parameter. When the "rel" parameter is used, only the link relations 394 that match the link relations provided via "rel" are included in the 395 array of links returned in the JSON Resource Descriptor document. 397 All other information normally present in a resource descriptor is 398 present in the resource descriptor, even when "rel" is employed. 400 The "rel" parameter MAY be transmitted to the server multiple times 401 in order to request multiple types of link relations. 403 The purpose of the "rel" parameter is to return a subset of 404 resource's link relations. It is not intended to reduce the work 405 required of a server to produce a response. That said, use of the 406 parameter might reduce processing requirements on either the client 407 or server, and it might also reduce the bandwidth required to convey 408 the partial resource descriptor, especially if there are numerous 409 link relation values to convey for a given resource. 411 Support for the "rel" parameter is OPTIONAL, but RECOMMENDED on the 412 server. 414 For illustrative purposes, the following example presents the same 415 example as found in section 4.1, but uses the "rel" parameter in 416 order to select two link relations: 418 GET /.well-known/webfinger? 419 resource=acct%3Abob%40example.com 420 rel=http%3A%2F%2Fwebfinger.net%2Frel%2Fprofile-page& 421 rel=vcard HTTP/1.1 422 Host: example.com 424 The server might then respond with a message like this: 426 HTTP/1.1 200 OK 427 Access-Control-Allow-Origin: * 428 Content-Type: application/json; charset=UTF-8 430 { 431 "expires" : "2012-11-16T19:41:35Z", 432 "subject" : "acct:bob@example.com", 433 "aliases" : 434 [ 435 "http://www.example.com/~bob/" 436 ], 437 "properties" : 438 { 439 "http://example.com/rel/role/" : "employee" 440 }, 441 "links" : 442 [ 443 { 444 "rel" : "http://webfinger.net/rel/profile-page", 445 "href" : "http://www.example.com/~bob/" 447 }, 448 { 449 "rel" : "vcard", 450 "href" : "http://www.example.com/~bob/bob.vcf" 451 } 452 ] 453 } 455 In the event that a client requests links for link relations that are 456 not defined for the specified resource, a resource descriptor MUST be 457 returned. In the returned JRD, the "links" array MAY be absent, 458 empty, or contain only links that did match a provided "rel" value. 459 The server MUST NOT return a 404 status code when a particular link 460 relation specified via "rel" is not defined for the resource, as a 461 404 status code is reserved for indicating that the resource itself 462 (e.g., either /.well-known/webfinger or the resource indicated via 463 the "resource" parameter) does not exist. 465 5.4. WebFinger and URIs 467 WebFinger requests can include a parameter specifying the URI of an 468 account, device, or other entity. WebFinger is agnostic regarding 469 the scheme of such a URI: it could be an "acct" URI [7], an "http" or 470 "https" URI, a "mailto" URI, or some other scheme. 472 For resources associated with a user account at a host, use of the 473 "acct" URI scheme is RECOMMENDED, since it explicitly identifies an 474 account accessible via WebFinger. Further, the "acct" URI scheme is 475 not associated with other protocols as, by way of example, the 476 "mailto" URI scheme is associated with email. Since not every host 477 offers email service, using the "mailto" URI scheme [9] is not ideal 478 for identifying user accounts on all hosts. That said, use of the 479 "mailto" URI scheme would be ideal for use with WebFinger to discover 480 mail server configuration information for a user. 482 A host MAY utilize one or more URIs that serve as aliases for the 483 user's account, such as URIs that use the "http" URI scheme [2]. A 484 WebFinger server MUST return substantially the same response to both 485 an "acct" URI and any alias URI for the account, including the same 486 set of link relations and properties. The only elements in the 487 response that MAY be different include "subject", "expires", and 488 "aliases". In addition, the server SHOULD include the entire list 489 aliases for the user's account in the JRD returned when querying the 490 LRDD resource or when utilizing the "resource" parameter. 492 6. Cross-Origin Resource Sharing (CORS) 494 WebFinger is most useful when it is accessible without restrictions 495 on the Internet, including web browsers. Therefore, WebFinger 496 servers MUST support Cross-Origin Resource Sharing (CORS) [10] when 497 serving content intended for public consumption. Specifically, all 498 queries to /.well-known/webfinger MUST include the following HTTP 499 header in the response: 501 Access-Control-Allow-Origin: * 503 Enterprise WebFinger servers that wish to restrict access to 504 information from external entities SHOULD use a more restrictive 505 Access-Control-Allow-Origin header. 507 7. Controlling Access to Information 509 As with all web resources, access to the /.well-known/webfinger 510 resource MAY require authentication. Further, failure to provide 511 required credentials MAY result in the server forbidding access or 512 providing a different response than had the client authenticated with 513 the server. 515 Likewise, a server MAY provide different responses to different 516 clients based on other factors, such as whether the client is inside 517 or outside a corporate network. As a concrete example, a query 518 performed on the internal corporate network might return link 519 relations to employee pictures, whereas link relations for employee 520 pictures might not be provided to external entities. 522 Further, link relations provided in a WebFinger server response MAY 523 point to web resources that impose access restrictions. For example, 524 the aforementioned corporate server may provide both internal and 525 external entities with URIs to employee pictures, but further 526 authentication might be required in order for the client to access 527 the picture resources if the request comes from outside the corporate 528 network. 530 The decisions made with respect to what set of link relations a 531 WebFinger server provides to one client versus another and what 532 resources require further authentication, as well as the specific 533 authentication mechanisms employed, are outside the scope of this 534 document. 536 8. Hosted WebFinger Services 538 As with most services provided on the Internet, it is possible for a 539 domain owner to utilize "hosted" WebFinger services. By way of 540 example, a domain owner might control most aspects of their domain, 541 but use a third-party hosting service for email. In the case of 542 email, mail servers for a domain are identified by MX records. An MX 543 record points to the mail server to which mail for the domain should 544 be delivered. It does not matter to the sending mail server whether 545 those MX records point to a server in the destination domain or a 546 different domain. 548 Likewise, a domain owner might utilize the services of a third party 549 to provide WebFinger services on behalf of its users. Just as a 550 domain owner was required to insert MX records into DNS to allow for 551 hosted email serves, the domain owner is required to redirect HTTP(S) 552 queries to its domain to allow for hosted WebFinger services. 554 When a query is issued to /.well-known/webfinger, the target domain's 555 web server MUST return a 301, 302, or 307 response status code that 556 includes a Location header pointing to the location of the hosted 557 WebFinger service URL. The WebFinger service URL does not need to 558 point to /.well-known/* on the hosting service provider server. In 559 fact, it should not, as that location would be reserved for queries 560 relating to the service provider's domain. WebFinger clients MUST 561 follow all 301, 302, or 307 redirection requests. 563 As an example, let's assume that example.com's WebFinger services are 564 hosted by example.net. Suppose a client issues a query for 565 acct:alice@example.com like this: 567 GET /.well-known/webfinger? 568 resource=acct%3Aalice%40example.com HTTP/1.1 569 Host: example.com 571 The server might respond with this: 573 HTTP/1.1 307 Temporary Redirect 574 Location: http://wf.example.net/example.com/webfinger? 575 resource=acct%3Aalice%40example.com HTTP/1.1 577 The client MUST follow the redirection, re-issuing the request to the 578 URL provided in the Location header. 580 9. Security Considerations 582 All of the security considerations applicable to Web Host Metadata 583 [11] and Cross-Origin Resource Sharing [10] are also applicable to 584 this specification. Of particular importance is the recommended use 585 of HTTPS to ensure that information is not modified during transit. 586 Clients MUST verify that the certificate used on an HTTPS connection 587 is valid. 589 Service providers and users should be aware that placing information 590 on the Internet accessible through WebFinger means that any user can 591 access that information. While WebFinger can be an extremely useful 592 tool for allowing quick and easy access to one's avatar, blog, or 593 other personal information, users should understand the risks, too. 595 If one does not wish to share certain information with the world, do 596 not allow that information to be freely accessible through WebFinger 597 and do not use any service supporting WebFinger. Further, WebFinger 598 servers MUST NOT be used to provide any personal information to any 599 party unless explicitly or implicitly authorized by the person whose 600 information is being shared. Implicit authorization can be determined 601 by the user's voluntary utilization of a service as defined by that 602 service's relevant terms of use or published privacy policy. 604 The aforementioned word of caution is perhaps worth emphasizing again 605 with respect to dynamic information one might wish to share, such as 606 the current location of a user. WebFinger can be a powerful tool 607 used to assemble information about a person all in one place, but 608 service providers and users should be mindful of the nature of that 609 information shared and the fact that it might be available for the 610 entire world to see. Sharing location information, for example, 611 would potentially put a person in danger from any individual who 612 might seek to inflict harm on that person. 614 The easy access to user information via WebFinger was a design goal 615 of the protocol, not a limitation. If one wishes to limit access to 616 information available via WebFinger, such as a WebFinger server for 617 use inside a corporate network, the network administrator must take 618 measures necessary to limit access from outside the network. Using 619 standard methods for securing web resources, network administrators 620 do have the ability to control access to resources that might return 621 sensitive information. Further, WebFinger servers can be employed in 622 such a way as to require authentication and prevent disclosure of 623 information to unauthorized entities. 625 Finally, a WebFinger server has no means of ensuring that information 626 provided by a user is accurate. Likewise, neither the server nor the 627 client can be absolutely guaranteed that information has not been 628 manipulated either at the server or along the communication path 629 between the client and server. Use of HTTPS helps to address some 630 concerns with manipulation of information along the communication 631 path, but it clearly cannot address issues where the server provided 632 incorrect information, either due to being provided false information 633 or due to malicious behavior on the part of the server administrator. 634 As with any information service available on the Internet, users 635 should wary of information received from untrusted sources. 637 10. IANA Considerations 639 This specification registers the "webfinger" well-known URI in the 640 Well-Known URI Registry as defined by [3]. 642 URI suffix: webfinger 644 Change controller: IETF 646 Specification document(s): RFC QQQ 648 Related information: The JSON Resource Descriptor (JRD) documents 649 obtained via the WebFinger web service are described in RFC 6415 650 Appendix A and RFC QQQ. 652 [RFC EDITOR: Please replace "QQQ" references in this section with the 653 number for this RFC.] 655 11. Acknowledgments 657 The authors would like to acknowledge Eran Hammer-Lahav, Blaine Cook, 658 Brad Fitzpatrick, Laurent-Walter Goix, Joe Clarke, Mike Jones, and 659 Peter Saint-Andre for their invaluable input. 661 12. References 663 12.1. Normative References 665 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 666 Levels", BCP 14, RFC 2119, March 1997. 668 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 669 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 670 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 672 [3] Nottingham, M., Hammer-Lahav, E., "Defining Well-Known Uniform 673 Resource Identifiers (URIs)", RFC 5785, April 2010. 675 [4] Nottingham, M., "Web Linking", RFC 5988, October 2010. 677 [5] Crockford, D., "The application/json Media Type for 678 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 680 [6] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 681 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 682 January 2005. 684 [7] Duerst, M., "Internationalized Resource Identifiers (IRIs)", 685 RFC 3987, January 2005. 687 [8] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg- 688 acct-uri-01, October 2012. 690 [9] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI 691 Scheme", RFC 6068, October 2010. 693 [10] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS 694 http://www.w3.org/TR/cors/, July 2010. 696 [11] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415, 697 October 2011. 699 12.2. Informative References 701 [12] Zimmerman, D., "The Finger User Information Protocol", RFC 702 1288, December 1991. 704 [13] Perreault, S., "vCard Format Specification", RFC 6350, August 705 2011. 707 [14] "Transport Independent, Printer/System Interface", IEEE Std 708 1284.1-1997, 1997. 710 Author's Addresses 712 Paul E. Jones 713 Cisco Systems, Inc. 714 7025 Kit Creek Rd. 715 Research Triangle Park, NC 27709 716 USA 718 Phone: +1 919 476 2048 719 Email: paulej@packetizer.com 720 IM: xmpp:paulej@packetizer.com 722 Gonzalo Salgueiro 723 Cisco Systems, Inc. 724 7025 Kit Creek Rd. 725 Research Triangle Park, NC 27709 726 USA 728 Phone: +1 919 392 3266 729 Email: gsalguei@cisco.com 730 IM: xmpp:gsalguei@cisco.com 732 Joseph Smarr 733 Google 735 Email: jsmarr@google.com