idnits 2.17.1 draft-ietf-appsawg-webfinger-05.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 28, 2012) is 4139 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) == Unused Reference: '13' is defined on line 751, but no explicit reference was found in the text ** 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 (~~), 3 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 28, 2013 Joseph Smarr 6 Google 7 November 28, 2012 9 WebFinger 10 draft-ietf-appsawg-webfinger-05.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 28, 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....................................................2 54 3. Overview.......................................................3 55 4. Example Use of WebFinger.......................................3 56 4.1. Locating a User's Blog....................................3 57 4.2. Identity Provider Discovery for OpenID Connect............5 58 4.3. Auto-Configuration of Email Clients.......................6 59 4.4. Retrieving Device Information.............................7 60 5. WebFinger Protocol.............................................8 61 5.1. Performing a WebFinger Query..............................8 62 5.2. The JSON Resource Descriptor (JRD) Document...............9 63 5.3. The "rel" Parameter.......................................9 64 5.4. WebFinger and URIs.......................................11 65 6. Cross-Origin Resource Sharing (CORS)..........................12 66 7. Access Control................................................12 67 8. Hosted WebFinger Services.....................................12 68 9. Security Considerations.......................................13 69 10. IANA Considerations..........................................14 70 11. Acknowledgments..............................................15 71 12. References...................................................15 72 12.1. Normative References....................................15 73 12.2. Informative References..................................16 74 Author's Addresses...............................................17 76 1. Introduction 78 WebFinger is used to discover information about people or other 79 entities on the Internet using standard HTTP [2] methods. The 80 WebFinger server returns a structured document that contains link 81 relations, properties, and/or other information that is suitable for 82 automated processing. For a person, the kinds of information that 83 might be shared via WebFinger include a personal profile address, 84 identity service, telephone number, or preferred avatar. For other 85 entities on the Internet, the server might return documents 86 containing link relations that allow a client to discover the amount 87 of toner in a printer or the physical location of a server. 89 Information returned via WebFinger might be for direct human 90 consumption (e.g., looking up someone's phone number), or it might be 91 used by systems to help carry out some operation (e.g., facilitate 92 logging into a web site by determining a user's identity service). 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [1]. 100 WebFinger makes heavy use of "Link Relations". Briefly, a Link 101 Relation is an attribute and value pair used on the Internet wherein 102 the attribute identifies the type of link to which the associated 103 value refers. In Hypertext Transfer Protocol (HTTP) and Web Linking 104 [4], the attribute is a "rel" and the value is an "href". WebFinger 105 also uses the "rel" attribute, where the "rel" value is either a 106 single IANA-registered link relation type [12] or a URI [6]. 108 3. Overview 110 WebFinger enables the discovery of information about users, devices, 111 and other entities that are associated with a host. Discovery 112 involves a single HTTP GET request to the well-known [3] "webfinger" 113 resource at the target host and receiving back a JavaScript Object 114 Notation (JSON) [5] Resource Descriptor (JRD) document [11] 115 containing link relations. The request MUST include the URI or IRI 116 [7] for the entity for which information is sought as a parameter 117 named "resource". 119 Use of WebFinger is illustrated in the examples in Section 4, then 120 described more formally in Section 5. 122 4. Example Use of WebFinger 124 This non-normative section shows a few sample uses of WebFinger. 126 4.1. Locating a User's Blog 128 Assume you receive an email from Bob and he refers to something he 129 posted on his blog, but you do not know where Bob's blog is located. 130 It would be simple to discover the address of Bob's blog if he makes 131 that information available via WebFinger. 133 Assume your email client can discover the blog for you. After 134 receiving the message from Bob (bob@example.com), you instruct your 135 email client to perform a WebFinger query. It does so by issuing the 136 following HTTPS query to example.com: 138 GET /.well-known/webfinger? 139 resource=acct%3Abob%40example.com HTTP/1.1 140 Host: example.com 142 The server might then respond with a message like this: 144 HTTP/1.1 200 OK 145 Access-Control-Allow-Origin: * 146 Content-Type: application/json; charset=UTF-8 148 { 149 "expires" : "2012-11-16T19:41:35Z", 150 "subject" : "acct:bob@example.com", 151 "aliases" : 152 [ 153 "http://www.example.com/~bob/" 154 ], 155 "properties" : 156 { 157 "http://example.com/rel/role/" : "employee" 158 }, 159 "links" : 160 [ 161 { 162 "rel" : "http://webfinger.net/rel/avatar", 163 "type" : "image/jpeg", 164 "href" : "http://www.example.com/~bob/bob.jpg" 165 }, 166 { 167 "rel" : "http://webfinger.net/rel/profile-page", 168 "href" : "http://www.example.com/~bob/" 169 }, 170 { 171 "rel" : "blog", 172 "type" : "text/html", 173 "href" : "http://blogs.example.com/bob/", 174 "titles" : 175 { 176 "en-us" : "The Magical World of Bob", 177 "fr" : "Le monde magique de Bob" 178 } 179 }, 180 { 181 "rel" : "vcard", 182 "href" : "http://www.example.com/~bob/bob.vcf" 183 } 184 ] 185 } 187 The email client would take note of the "blog" link relation in the 188 above JRD document that refers to Bob's blog. This URL would then be 189 presented to you so that you could then visit his blog. The email 190 client might also note that Bob has published an avatar link relation 191 and use that picture to represent Bob inside the email client. 192 Lastly, the client might consider the vcard [14] link relation in 193 order to update contact information for Bob. 195 In the above example, an "acct" URI [8] is used in the query, though 196 any valid alias for the user might also be used. An alias is a URI 197 that is different from the "subject" URI that identifies the same 198 entity. In the above example, there is one "http" alias returned, 199 though there might have been more than one. Had the "http:" URI 200 shown as an alias been used to query for information about Bob, the 201 query would have appeared as: 203 GET /.well-known/webfinger? 204 resource=http%3A%2F%2Fwww.example.com%2F~bob%2F HTTP/1.1 205 Host: example.com 207 The response would have been substantially the same, with the subject 208 and alias information changed as necessary. Other information, such 209 as the expiration time might also change, but the set of link 210 relations and properties would be the same with either response. 212 4.2. Identity Provider Discovery for OpenID Connect 214 Suppose Carol wishes to authenticate with a web site she visits using 215 OpenID Connect [16]. She would provide the web site with her OpenID 216 Connect identifier, say carol@example.com. The visited web site 217 would perform a WebFinger query looking for the OpenID Connect 218 Provider. Since the site is interested in only one particular link 219 relation, the server might utilize the "rel" parameter as described 220 in section 5.3: 222 GET /.well-known/webfinger? 223 resource=acct%3Acarol%40example.com& 224 rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer 225 HTTP/1.1 226 Host: example.com 228 The server might respond with a JSON Resource Descriptor document 229 like this: 231 { 232 "expires" : "2012-11-16T19:41:35Z", 233 "subject" : "acct:carol@example.com", 234 "aliases" : 235 [ 236 "http://www.example.com/~carol/" 237 ], 238 "properties" : 239 { 240 "http://example.com/rel/role/" : "employee" 241 }, 242 "links" : 243 [ 244 { 245 "rel" : "http://openid.net/specs/connect/1.0/issuer", 246 "href" : "https://openid.example.com/" 248 } 249 ] 250 } 252 Since the "rel" parameter only filters the link relations returned by 253 the server, other elements of the response, including any aliases or 254 properties, would be returned. Also, since support for the "rel" 255 parameter is optional, the client must not assume the "links" array 256 will contain only the requested link relation. 258 4.3. Auto-Configuration of Email Clients 260 WebFinger could be used to auto-provision an email client with basic 261 configuration data. Suppose that sue@example.com wants to configure 262 her email client. Her email client might issue the following query: 264 GET /.well-known/webfinger? 265 resource=mailto%3Asue%40example.com HTTP/1.1 266 Host: example.com 268 The response from the server would contain entries for the various 269 protocols, transport options, and security options. If there are 270 multiple options, the server might return a link relation that for 271 each of the valid options and the client or Sue might select which 272 option to choose. Since JRD documents list link relations in a 273 specific order, then the most-preferred choices could be presented 274 first. Consider this response: 276 { 277 "subject" : "mailto:sue@example.com", 278 "links" : 279 [ 280 { 281 "rel" : "http://example.net/rel/smtp-server", 282 "properties" : 283 { 284 "host" : "smtp.example.com", 285 "port" : "587", 286 "login-required" : "yes", 287 "transport" : "starttls" 288 } 289 }, 290 { 291 "rel" : "http://example.net/rel/imap-server", 292 "properties" : 293 { 294 "host" : "imap.example.com", 295 "port" : "993", 296 "transport" : "ssl" 298 } 299 } 300 ] 301 } 303 In this example, you can see that the WebFinger server advertises an 304 SMTP service and an IMAP service. In this example, the "href" 305 entries associated with the link relation are absent. This is valid 306 when there is no external reference that needs to be made. 308 4.4. Retrieving Device Information 310 As another example, suppose there are printers on the network and you 311 would like to check the current toner level for a particular printer 312 identified via the URI device:p1.example.com. While the "device" URI 313 scheme is not presently specified, we use it here for illustrative 314 purposes. 316 Following the procedures similar to those above, a query may be 317 issued to get link relations specific to this URI like this: 319 GET /.well-known/webfinger?resource= 320 device%3Ap1.example.com HTTP/1.1 321 Host: example.com 323 The link relations that are returned for a device may be quite 324 different than those for user accounts. Perhaps we may see a 325 response like this: 327 HTTP/1.1 200 OK 328 Access-Control-Allow-Origin: * 329 Content-Type: application/json; charset=UTF-8 331 { 332 "subject" : "device:p1.example.com", 333 "links" : 334 [ 335 { 336 "rel" : "http://example.com/rel/tipsi", 337 "href" : "http://192.168.1.5/npap/" 338 } 339 ] 340 } 342 While this example is fictitious, you can imagine that perhaps the 343 Transport Independent, Printer/System Interface [15] may be enhanced 344 with a web interface that allows a device that understands the TIP/SI 345 web interface specification to query the printer for toner levels. 347 5. WebFinger Protocol 349 WebFinger is a simple HTTP-based web service that utilizes the JSON 350 Resource Descriptor (JRD) document format and the Cross-Origin 351 Resource Sharing (CORS) [10] specification. 353 This specification defines URI parameters that are passed from the 354 client to the server when issuing a request. These parameters, 355 "resource" and "rel", and the parameter values are included in the 356 "query" component of the URI (see Section 3.4 of RFC 3986). To 357 construct the "query" component, the client performs the following 358 steps. First, each parameter value is percent-encoded as per Section 359 2.1 of RFC 3986. Next, the client constructs a string to be placed 360 in the query component by concatenating the name of the first 361 parameter together with an equal sign ("=") and the percent-encoded 362 parameter value. For any subsequent parameters, the client appends 363 an ampersand ("&") to the string, the name of the next parameter, an 364 equal sign, and percent-encoded parameter value. The client MUST NOT 365 insert any spaces while constructing the string. The order in which 366 the client places each parameter and its corresponding parameter 367 value is unspecified. 369 5.1. Performing a WebFinger Query 371 WebFinger clients issue queries to the well-known resource /.well- 372 known/webfinger. All queries MUST include the "resource" parameter 373 exactly once and set to the value of the URI for which information is 374 being sought. If the "resource" parameter is absent or malformed, 375 the WebFinger server MUST return a 400 status code. 377 Clients MUST first attempt a query the server using HTTPS and utilize 378 HTTP only if an HTTPS connection cannot be established. If the HTTPS 379 server has an invalid certificate or returns an HTTP status code 380 indicating some error, including a 4xx or 5xx, the client MUST NOT 381 use HTTP in attempt to complete the discovery. 383 WebFinger servers MUST return JRD documents as the default 384 representation for the resource. A client MAY include the "Accept" 385 header to indicate a desired representation, though no other 386 representation is defined in this specification. For the JRD 387 document, the media type is "application/json" [5]. 389 If the client queries the WebFinger server and provides a URI for 390 which the server has no information, the server MUST return a 404 391 status code. 393 WebFinger servers can include cache validators in a response to 394 enable conditional requests by clients and/or expiration times as per 395 RFC 2616 section 13. 397 5.2. The JSON Resource Descriptor (JRD) Document 399 The JSON Resource Descriptor (JRD) document is formally described in 400 Appendix A of [11]. There is a RECOMMENDED order of JRD elements. 401 Further, WebFinger requires some elements and some are optional. The 402 following list indicates the preferred order and comments on the 403 presence or absence of elements: 405 o "expires" (element) is optional 406 o "subject" (element) is required and MUST be the value of the 407 "resource" parameter 408 o "aliases" (array) is optional and absence or an empty array 409 are semantically the same 410 o "properties" (array) is optional and absence or an empty 411 array are semantically the same 412 o "links" (array) is optional and absence or an empty array are 413 semantically the same 415 Array elements within the "links" array are presented by the server 416 in order of preference. 418 The "links" array is comprised of several elements. As above, the 419 following list indicates the preferred order or elements within a 420 "links" array element and comments on the presence or absence of 421 elements within the array: 423 o "rel" (element) is required 424 o "type" (element) is optional 425 o "href" (element) is optional 426 o "template" (element) is forbidden 427 o "titles" (array) is optional and absence or an empty array 428 are semantically the same 429 o "properties" (array) is optional and absence or an empty 430 array are semantically the same 432 Clients MUST ignore any unknown or forbidden elements received in the 433 JRD document. 435 5.3. The "rel" Parameter 437 WebFinger defines the "rel" parameter to request only a subset of the 438 information that would otherwise be returned without the "rel" 439 parameter. When the "rel" parameter is used, only the link relations 440 that match the link relations provided via "rel" are included in the 441 array of links returned in the JSON Resource Descriptor document. 442 All other information normally present in a resource descriptor is 443 present in the resource descriptor, even when "rel" is employed. 445 The "rel" parameter MAY be transmitted to the server multiple times 446 in order to request multiple types of link relations. 448 The purpose of the "rel" parameter is to return a subset of 449 resource's link relations. Use of the parameter might reduce 450 processing requirements on either the client or server, and it might 451 also reduce the bandwidth required to convey the partial resource 452 descriptor, especially if there are numerous link relation values to 453 convey for a given resource. 455 Support for the "rel" parameter is OPTIONAL, but RECOMMENDED on the 456 server. Should the server not support the "rel" parameter, it MUST 457 ignore it and process the request as if any "rel" parameter values 458 were not present. 460 The following example presents the same example as found in section 461 4.1, but uses the "rel" parameter in order to select two link 462 relations: 464 GET /.well-known/webfinger? 465 resource=acct%3Abob%40example.com& 466 rel=http%3A%2F%2Fwebfinger.net%2Frel%2Fprofile-page& 467 rel=vcard HTTP/1.1 468 Host: example.com 470 In this example, the client requests the link relations of type 471 "http://webfinger.net/rel/profile-page" and "vcard". The server then 472 responds with a message like this: 474 HTTP/1.1 200 OK 475 Access-Control-Allow-Origin: * 476 Content-Type: application/json; charset=UTF-8 478 { 479 "expires" : "2012-11-16T19:41:35Z", 480 "subject" : "acct:bob@example.com", 481 "aliases" : 482 [ 483 "http://www.example.com/~bob/" 484 ], 485 "properties" : 486 { 487 "http://example.com/rel/role/" : "employee" 488 }, 489 "links" : 490 [ 491 { 492 "rel" : "http://webfinger.net/rel/profile-page", 493 "href" : "http://www.example.com/~bob/" 495 }, 496 { 497 "rel" : "vcard", 498 "href" : "http://www.example.com/~bob/bob.vcf" 499 } 500 ] 501 } 503 As you can see, the server returned only the link relations requested 504 by the client, but also included the other parts of the JSON resource 505 Descriptor document. 507 In the event that a client requests links for link relations that are 508 not defined for the specified resource, a resource descriptor MUST be 509 returned. In the returned JRD, the "links" array MAY be absent, 510 empty, or contain only links that did match a provided "rel" value. 511 The server MUST NOT return a 404 status code when a particular link 512 relation specified via "rel" is not defined for the resource, as a 513 404 status code is reserved for indicating that the resource itself 514 (e.g., either /.well-known/webfinger or the resource indicated via 515 the "resource" parameter) does not exist. 517 5.4. WebFinger and URIs 519 WebFinger requests can include a parameter specifying the URI of an 520 account, device, or other entity. WebFinger is agnostic regarding 521 the scheme of such a URI: it could be an "acct" URI [7], an "http" or 522 "https" URI, a "mailto" URI, or some other scheme. 524 For resources associated with a user account at a host, use of the 525 "acct" URI scheme is RECOMMENDED, since it explicitly identifies an 526 account accessible via WebFinger. Further, the "acct" URI scheme is 527 not associated with other protocols as, by way of example, the 528 "mailto" URI scheme is associated with email. Since not every host 529 offers email service, using the "mailto" URI scheme [9] is not ideal 530 for identifying user accounts on all hosts. That said, use of the 531 "mailto" URI scheme would be ideal for use with WebFinger to discover 532 mail server configuration information for a user. 534 A host MAY utilize one or more URIs that serve as aliases for the 535 user's account, such as URIs that use the "http" URI scheme [2]. A 536 WebFinger server MUST return substantially the same response to both 537 an "acct" URI and any alias URI for the account, including the same 538 set of link relations and properties. The only elements in the 539 response that MAY be different include "subject", "expires", and 540 "aliases". In addition, the server SHOULD include the entire list 541 aliases for the user's account in the JRD returned when querying the 542 LRDD resource or when utilizing the "resource" parameter. 544 6. Cross-Origin Resource Sharing (CORS) 546 WebFinger might not be useable by code running in web browsers due to 547 "Same-Origin" policies. Therefore, WebFinger servers MUST support 548 Cross-Origin Resource Sharing (CORS) [10] and SHOULD do so by 549 including the following HTTP header in responses: 551 Access-Control-Allow-Origin: * 553 Enterprise WebFinger servers that wish to restrict access to 554 information from external entities MAY use a more restrictive Access- 555 Control-Allow-Origin header. 557 7. Access Control 559 As with all web resources, access to the /.well-known/webfinger 560 resource MAY require authentication. Further, failure to provide 561 required credentials MAY result in the server forbidding access or 562 providing a different response than had the client authenticated with 563 the server. 565 Likewise, a server MAY provide different responses to different 566 clients based on other factors, such as whether the client is inside 567 or outside a corporate network. As a concrete example, a query 568 performed on the internal corporate network might return link 569 relations to employee pictures, whereas link relations for employee 570 pictures might not be provided to external entities. 572 Further, link relations provided in a WebFinger server response MAY 573 point to web resources that impose access restrictions. For example, 574 the aforementioned corporate server may provide both internal and 575 external entities with URIs to employee pictures, but further 576 authentication might be required in order for the client to access 577 the picture resources if the request comes from outside the corporate 578 network. 580 The decisions made with respect to what set of link relations a 581 WebFinger server provides to one client versus another and what 582 resources require further authentication, as well as the specific 583 authentication mechanisms employed, are outside the scope of this 584 document. 586 8. Hosted WebFinger Services 588 As with most services provided on the Internet, it is possible for a 589 domain owner to utilize "hosted" WebFinger services. By way of 590 example, a domain owner might control most aspects of their domain, 591 but use a third-party hosting service for email. In the case of 592 email, mail servers for a domain are identified by MX records. An MX 593 record points to the mail server to which mail for the domain should 594 be delivered. It does not matter to the sending mail server whether 595 those MX records point to a server in the destination domain or a 596 different domain. 598 Likewise, a domain owner might utilize the services of a third party 599 to provide WebFinger services on behalf of its users. Just as a 600 domain owner was required to insert MX records into DNS to allow for 601 hosted email serves, the domain owner is required to redirect HTTP(S) 602 queries to its domain to allow for hosted WebFinger services. 604 When a query is issued to /.well-known/webfinger, the web server MUST 605 return a 301, 302, or 307 response status code that includes a 606 Location header pointing to the location of the hosted WebFinger 607 service URL. The WebFinger service URL does not need to point to 608 /.well-known/* on the hosting service provider server. WebFinger 609 clients MUST follow all 301, 302, or 307 redirection requests. 611 As an example, assume that example.com's WebFinger services are 612 hosted by example.net. Suppose a client issues a query for 613 acct:alice@example.com like this: 615 GET /.well-known/webfinger? 616 resource=acct%3Aalice%40example.com HTTP/1.1 617 Host: example.com 619 The server might respond with this: 621 HTTP/1.1 307 Temporary Redirect 622 Location: http://wf.example.net/example.com/webfinger? 623 resource=acct%3Aalice%40example.com HTTP/1.1 625 The client MUST follow the redirection, re-issuing the request to the 626 URL provided in the Location header. 628 9. Security Considerations 630 All of the security considerations applicable to Web Host Metadata 631 [11] and Cross-Origin Resource Sharing [10] are also applicable to 632 this specification. Of particular importance is the recommended use 633 of HTTPS to ensure that information is not modified during transit. 634 Clients MUST verify that the certificate used on an HTTPS connection 635 is valid. 637 Service providers and users should be aware that placing information 638 on the Internet accessible through WebFinger means that any user can 639 access that information. While WebFinger can be an extremely useful 640 tool for allowing quick and easy access to one's avatar, blog, or 641 other personal information, users should understand the risks, too. 643 If one does not wish to share certain information with the world, do 644 not allow that information to be freely accessible through WebFinger 645 and do not use any service supporting WebFinger. Further, WebFinger 646 servers MUST NOT be used to provide any personal information to any 647 party unless explicitly or implicitly authorized by the person whose 648 information is being shared. Implicit authorization can be determined 649 by the user's voluntary utilization of a service as defined by that 650 service's relevant terms of use or published privacy policy. 652 The aforementioned word of caution is perhaps worth emphasizing again 653 with respect to dynamic information one might wish to share, such as 654 the current location of a user. WebFinger can be a powerful tool 655 used to assemble information about a person all in one place, but 656 service providers and users should be mindful of the nature of that 657 information shared and the fact that it might be available for the 658 entire world to see. Sharing location information, for example, 659 would potentially put a person in danger from any individual who 660 might seek to inflict harm on that person. 662 The easy access to user information via WebFinger was a design goal 663 of the protocol, not a limitation. If one wishes to limit access to 664 information available via WebFinger, such as a WebFinger server for 665 use inside a corporate network, the network administrator must take 666 measures necessary to limit access from outside the network. Using 667 standard methods for securing web resources, network administrators 668 do have the ability to control access to resources that might return 669 sensitive information. Further, WebFinger servers can be employed in 670 such a way as to require authentication and prevent disclosure of 671 information to unauthorized entities. 673 Finally, a WebFinger server has no means of ensuring that information 674 provided by a user is accurate. Likewise, neither the server nor the 675 client can be absolutely guaranteed that information has not been 676 manipulated either at the server or along the communication path 677 between the client and server. Use of HTTPS helps to address some 678 concerns with manipulation of information along the communication 679 path, but it clearly cannot address issues where the server provided 680 incorrect information, either due to being provided false information 681 or due to malicious behavior on the part of the server administrator. 682 As with any information service available on the Internet, users 683 should wary of information received from untrusted sources. 685 10. IANA Considerations 687 This specification registers the "webfinger" well-known URI in the 688 Well-Known URI Registry as defined by [3]. 690 URI suffix: webfinger 691 Change controller: IETF 693 Specification document(s): RFC QQQ 695 Related information: The JSON Resource Descriptor (JRD) documents 696 obtained via the WebFinger web service are described in RFC 6415 697 Appendix A and RFC QQQ. 699 [RFC EDITOR: Please replace "QQQ" references in this section with the 700 number for this RFC.] 702 11. Acknowledgments 704 The authors would like to acknowledge Eran Hammer-Lahav, Blaine Cook, 705 Brad Fitzpatrick, Laurent-Walter Goix, Joe Clarke, Michael B. Jones, 706 and Peter Saint-Andre for their invaluable input. 708 12. References 710 12.1. Normative References 712 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 713 Levels", BCP 14, RFC 2119, March 1997. 715 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 716 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 717 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 719 [3] Nottingham, M., Hammer-Lahav, E., "Defining Well-Known Uniform 720 Resource Identifiers (URIs)", RFC 5785, April 2010. 722 [4] Nottingham, M., "Web Linking", RFC 5988, October 2010. 724 [5] Crockford, D., "The application/json Media Type for 725 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 727 [6] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform 728 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 729 January 2005. 731 [7] Duerst, M., "Internationalized Resource Identifiers (IRIs)", 732 RFC 3987, January 2005. 734 [8] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg- 735 acct-uri-01, October 2012. 737 [9] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI 738 Scheme", RFC 6068, October 2010. 740 [10] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS 741 http://www.w3.org/TR/cors/, July 2010. 743 [11] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415, 744 October 2011. 746 12.2. Informative References 748 [12] IANA, "Link Relations", http://www.iana.org/assignments/link- 749 relations/. 751 [13] Zimmerman, D., "The Finger User Information Protocol", RFC 752 1288, December 1991. 754 [14] Perreault, S., "vCard Format Specification", RFC 6350, August 755 2011. 757 [15] "Transport Independent, Printer/System Interface", IEEE Std 758 1284.1-1997, 1997. 760 [16] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., 761 Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", June 762 2012, http://openid.net/specs/openid-connect-messages-1_0.html. 764 Author's Addresses 766 Paul E. Jones 767 Cisco Systems, Inc. 768 7025 Kit Creek Rd. 769 Research Triangle Park, NC 27709 770 USA 772 Phone: +1 919 476 2048 773 Email: paulej@packetizer.com 774 IM: xmpp:paulej@packetizer.com 776 Gonzalo Salgueiro 777 Cisco Systems, Inc. 778 7025 Kit Creek Rd. 779 Research Triangle Park, NC 27709 780 USA 782 Phone: +1 919 392 3266 783 Email: gsalguei@cisco.com 784 IM: xmpp:gsalguei@cisco.com 786 Joseph Smarr 787 Google 789 Email: jsmarr@google.com