draft-ietf-appsawg-webfinger-12.txt   draft-ietf-appsawg-webfinger-13.txt 
Network Working Group Paul E. Jones Network Working Group Paul E. Jones
Internet Draft Gonzalo Salgueiro Internet Draft Gonzalo Salgueiro
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: September 28, 2013 Joseph Smarr Expires: October 16, 2013 Joseph Smarr
Google Google
March 28, 2013 April 16, 2013
WebFinger WebFinger
draft-ietf-appsawg-webfinger-12.txt draft-ietf-appsawg-webfinger-13.txt
Abstract Abstract
This specification defines the WebFinger protocol, which can be used This specification defines the WebFinger protocol, which can be used
to discover information about people or other entities on the to discover information about people or other entities on the
Internet using standard HTTP methods. WebFinger discovers Internet using standard HTTP methods. WebFinger discovers
information for a URI that might not be usable as a locator information for a URI that might not be usable as a locator
otherwise, such as account or email URIs. otherwise, such as account or email URIs.
Status of this Memo Status of this Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 28, 2013. This Internet-Draft will expire on October 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Terminology....................................................3 2. Terminology....................................................3
3. Example Uses of WebFinger......................................3 3. Example Uses of WebFinger......................................3
3.1. Locating a User's Blog....................................3 3.1. Locating a User's Blog....................................3
3.2. Identity Provider Discovery for OpenID Connect............5 3.2. Identity Provider Discovery for OpenID Connect............5
3.3. Auto-Configuration of Email Clients.......................6 3.3. Auto-Configuration of Email Clients.......................6
3.4. Retrieving Device Information.............................7 3.4. Retrieving Device Information.............................7
4. WebFinger Protocol.............................................8 4. WebFinger Protocol.............................................8
4.1. Constructing a WebFinger Request URI......................9 4.1. Constructing the Query Component of the Request URI.......9
4.2. Performing a WebFinger Query..............................9 4.2. Performing a WebFinger Query..............................9
4.3. The "rel" Parameter......................................10 4.3. The "rel" Parameter......................................10
4.4. The JSON Resource Descriptor (JRD).......................11 4.4. The JSON Resource Descriptor (JRD).......................11
4.4.1. subject.............................................12 4.4.1. subject.............................................12
4.4.2. aliases.............................................12 4.4.2. aliases.............................................12
4.4.3. properties..........................................12 4.4.3. properties..........................................12
4.4.4. links...............................................12 4.4.4. links...............................................12
4.5. WebFinger and URIs.......................................15 4.5. WebFinger and URIs.......................................14
5. Cross-Origin Resource Sharing (CORS)..........................15 5. Cross-Origin Resource Sharing (CORS)..........................15
6. Access Control................................................15 6. Access Control................................................15
7. Hosted WebFinger Services.....................................16 7. Hosted WebFinger Services.....................................16
8. Security Considerations.......................................17 8. Security Considerations.......................................17
8.1. Transport-Related Issues.................................17 8.1. Transport-Related Issues.................................17
8.2. User Privacy Considerations..............................17 8.2. User Privacy Considerations..............................17
8.3. Abuse Potential..........................................18 8.3. Abuse Potential..........................................18
8.4. Information Reliability..................................18 8.4. Information Reliability..................................19
9. IANA Considerations...........................................19 9. IANA Considerations...........................................19
9.1. Well-Known URI...........................................19 9.1. Well-Known URI...........................................19
9.2. JSON Resource Descriptor (JRD) Media Type................19 9.2. JSON Resource Descriptor (JRD) Media Type................20
10. Acknowledgments..............................................21 10. Acknowledgments..............................................21
11. References...................................................21 11. References...................................................21
11.1. Normative References....................................21 11.1. Normative References....................................21
11.2. Informative References..................................22 11.2. Informative References..................................22
Author's Addresses...............................................23 Author's Addresses...............................................23
1. Introduction 1. Introduction
WebFinger is used to discover information about people or other WebFinger is used to discover information about people or other
entities on the Internet that are identified by a URI [6] or IRI [7] entities on the Internet that are identified by a URI [6] or IRI [7]
skipping to change at page 3, line 10 skipping to change at page 3, line 4
secure transport [14]. A WebFinger resource returns a JavaScript secure transport [14]. A WebFinger resource returns a JavaScript
Object Notation (JSON) [5] object describing the entity that is Object Notation (JSON) [5] object describing the entity that is
queried. The JSON object is referred to as the JSON Resource queried. The JSON object is referred to as the JSON Resource
Descriptor (JRD). Descriptor (JRD).
For a person, the kinds of information that might be discoverable via For a person, the kinds of information that might be discoverable via
WebFinger include a personal profile address, identity service, WebFinger include a personal profile address, identity service,
telephone number, or preferred avatar. For other entities on the telephone number, or preferred avatar. For other entities on the
Internet, a WebFinger resource might return JRDs containing link Internet, a WebFinger resource might return JRDs containing link
relations [10] that enable a client to discover, for example, the relations [10] that enable a client to discover, for example, the
amount of toner in a printer or the physical location of a server. that a printer can print in color on A4 paper, the physical location
of a server, or other static information.
Information returned via WebFinger might be for direct human Information returned via WebFinger might be for direct human
consumption (e.g., looking up someone's phone number), or it might be consumption (e.g., looking up someone's phone number), or it might be
used by systems to help carry out some operation (e.g., facilitate used by systems to help carry out some operation (e.g., facilitate
logging into a web site by determining a user's identity service). logging into a web site by determining a user's identity service).
The information is intended to be static in nature and, as such,
WebFinger is not intended to be used to return dynamic information
like the temperature of a CPU or the current toner level in a laser
printer.
The WebFinger protocol is designed to be used across many
applications. Applications that wish to utilize WebFinger will need
to specify properties, titles, and link relation types that are
appropriate for the application. Further, applications will need to
define the appropriate URI scheme to utilize for the query target.
Use of WebFinger is illustrated in the examples in Section 3 and Use of WebFinger is illustrated in the examples in Section 3 and
described more formally in Section 4. described more formally in Section 4.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
skipping to change at page 3, line 50 skipping to change at page 4, line 4
or a URI [6]. or a URI [6].
3. Example Uses of WebFinger 3. Example Uses of WebFinger
This non-normative section shows a few sample uses of WebFinger. This non-normative section shows a few sample uses of WebFinger.
3.1. Locating a User's Blog 3.1. Locating a User's Blog
Assume you receive an email from Bob and he refers to something he Assume you receive an email from Bob and he refers to something he
posted on his blog, but you do not know where Bob's blog is located. posted on his blog, but you do not know where Bob's blog is located.
It would be simple to discover the address of Bob's blog if he made It would be simple to discover the address of Bob's blog if he made
that information available via WebFinger. that information available via WebFinger.
Assume your email client can discover the blog for you. After Assume your email client can discover the blog for you. After
receiving the message from Bob (bob@example.com), your email client receiving the message from Bob (bob@example.com), your email client
performs a WebFinger query either automatically or at your command. performs a WebFinger query either automatically or at your command.
It does so by issuing the following HTTPS [14] query to example.com: (Please refer to Section 8.2 for user privacy considerations and
Section 8.3 for abuse considerations, particularly when considering
any kind of automated query feature.) It does so by issuing the
following HTTPS [14] query to example.com:
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=acct%3Abob%40example.com HTTP/1.1 resource=acct%3Abob%40example.com HTTP/1.1
Host: example.com Host: example.com
The server might then respond with a message like this: The server might then respond with a message like this:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Access-Control-Allow-Origin: * Access-Control-Allow-Origin: *
Content-Type: application/jrd+json Content-Type: application/jrd+json
skipping to change at page 7, line 44 skipping to change at page 7, line 39
In this example, you can see that the WebFinger resource In this example, you can see that the WebFinger resource
representation advertises an SMTP service and an IMAP service. In representation advertises an SMTP service and an IMAP service. In
this example, the "href" entries associated with the link relation this example, the "href" entries associated with the link relation
are absent. This is valid when there is no additional reference that are absent. This is valid when there is no additional reference that
needs to be made. needs to be made.
3.4. Retrieving Device Information 3.4. Retrieving Device Information
As another example, suppose there are printers on the network and you As another example, suppose there are printers on the network and you
would like to check the current toner level for a particular printer would like to check a particular printer identified by the URI
identified via the URI device:p1.example.com. While the "device" URI device:p1.example.com to see if it can print in color on A4 paper.
scheme is not presently specified, we use it here for illustrative While the "device" URI scheme is not presently specified, we use it
purposes. here for illustrative purposes.
Following the procedures similar to those above, a query may be Following the procedures similar to those above, a query may be
issued to get link relations specific to this URI like this: issued to get link relations specific to this URI like this:
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=device%3Ap1.example.com HTTP/1.1 resource=device%3Ap1.example.com HTTP/1.1
Host: p1.example.com Host: p1.example.com
The link relations that are returned for a device may be quite The link relations that are returned for a device may be quite
different than those for user accounts. Perhaps we may see a different than those for user accounts. Perhaps we may see a
skipping to change at page 8, line 31 skipping to change at page 8, line 23
{ {
"rel" : "http://webfinger.example/rel/tipsi", "rel" : "http://webfinger.example/rel/tipsi",
"href" : "http://192.168.1.5/npap/" "href" : "http://192.168.1.5/npap/"
} }
] ]
} }
While this example is fictitious, you can imagine that perhaps the While this example is fictitious, you can imagine that perhaps the
Transport Independent, Printer/System Interface [17] may be enhanced Transport Independent, Printer/System Interface [17] may be enhanced
with a web interface enabling a device that understands the TIP/SI with a web interface enabling a device that understands the TIP/SI
web interface specification to query the printer for toner levels. web interface specification to query for printer capabilities.
4. WebFinger Protocol 4. WebFinger Protocol
A WebFinger resource is a well-known URI [3] using the HTTPS scheme. The WebFinger protocol is used to request information about an entity
WebFinger resources MUST NOT be served with any other URI scheme identified by a query target (a URI). The client can optionally
(such as HTTP). specify one or more link relation types for which it would like to
receive information.
A WebFinger request is an HTTPS request to a WebFinger resource. A
WebFinger resource is a well-known URI [3] using the HTTPS scheme,
constructed along with the required query target and optional link
relation types. WebFinger resources MUST NOT be served with any
other URI scheme (such as HTTP).
A WebFinger resource is always given a query target, which is another A WebFinger resource is always given a query target, which is another
URI that identifies the entity whose information is sought. GET URI that identifies the entity whose information is sought. GET
requests to a WebFinger resource convey the query target in the requests to a WebFinger resource convey the query target in the
"resource" parameter in the WebFinger URI's query string; see Section "resource" parameter in the WebFinger URI's query string; see Section
4.1 for details. 4.1 for details.
The host to which a WebFinger query is issued is significant. If the
query target contains a "host" portion (Section 3.2.2 of RFC 3986),
then the host to which the WebFinger query is issued MUST be the same
as the "host" portion of the query target. If the query target does
not contain a "host" portion, then the client MAY choose a host to
which it directs the query based on local policy.
The path component of a WebFinger URI MUST be the well-known path
"/.well-known/webfinger". A WebFinger URI MUST contain a query
component that encodes the query target and optional link relation
types as specified in Section 4.1.
The WebFinger resource returns a JSON Resource Descriptor (JRD) as The WebFinger resource returns a JSON Resource Descriptor (JRD) as
the resource representation to convey information about an entity on the resource representation to convey information about an entity on
the Internet. Also, the Cross-Origin Resource Sharing (CORS) [9] the Internet. Also, the Cross-Origin Resource Sharing (CORS) [9]
specification is utilized to facilitate queries made via a web specification is utilized to facilitate queries made via a web
browser. browser.
4.1. Constructing a WebFinger Request URI 4.1. Constructing the Query Component of the Request URI
This specification defines parameters that can be passed from the A WebFinger URI MUST contain a query component (see Section 3.4 of
client to the WebFinger resource when issuing a request. These RFC 3986). The query component MUST contain a "resource" parameter
parameters, "resource" and "rel", and the parameter values are and MAY contain one or more "rel" parameters. The "resource"
included in the query component of the URI (see Section 3.4 of RFC parameter MUST contain the query target (URI) and the "rel"
3986). To construct the query component, the client performs the parameters MUST contain encoded link relation types according to the
following steps. First, each parameter value is percent-encoded, as encoding described in this section.
per Section 2.1 of RFC 3986. The encoding is done to conform to the
To construct the query component, the client performs the following
steps. First, each parameter value is percent-encoded, as per
Section 2.1 of RFC 3986. The encoding is done to conform to the
query production in Section 3.4 of that specification, with the query production in Section 3.4 of that specification, with the
addition that any instances of the "=" and "&" characters within the addition that any instances of the "=" and "&" characters within the
parameter values are also percent-encoded. Next, the client parameter values are also percent-encoded. Next, the client
constructs a string to be placed in the query component by constructs a string to be placed in the query component by
concatenating the name of the first parameter together with an equal concatenating the name of the first parameter together with an equal
sign ("=") and the percent-encoded parameter value. For any sign ("=") and the percent-encoded parameter value. For any
subsequent parameters, the client appends an ampersand ("&") to the subsequent parameters, the client appends an ampersand ("&") to the
string, the name of the next parameter, an equal sign, and the string, the name of the next parameter, an equal sign, and the
parameter value. The client MUST NOT insert any spaces while parameter value. The client MUST NOT insert any spaces while
constructing the string. The order in which the client places each constructing the string. The order in which the client places each
attribute-and-value pair within the query component does not matter attribute-and-value pair within the query component does not matter
in the interpretation of the query component. in the interpretation of the query component.
4.2. Performing a WebFinger Query 4.2. Performing a WebFinger Query
A WebFinger client issues a query to the well-known [3] resource A WebFinger client issues a query using the GET method to the well-
identified by the URI whose path component begins with "/.well- known [3] resource identified by the URI whose path component is
known/webfinger" and whose query component MUST include the "/.well-known/webfinger" and whose query component MUST include the
"resource" parameter exactly once and set to the value of the URI for "resource" parameter exactly once and set to the value of the URI for
which information is being sought. If the "resource" parameter is which information is being sought. If the "resource" parameter is
absent or malformed, the WebFinger resource MUST indicate that the absent or malformed, the WebFinger resource MUST indicate that the
request is bad as per Section 10.4.1 of RFC 2616 [2]. request is bad as per Section 10.4.1 of RFC 2616 [2].
A client MUST query the WebFinger resource using HTTPS only. If the A client MUST query the WebFinger resource using HTTPS only. If the
client determines that the resource has an invalid certificate, the client determines that the resource has an invalid certificate, the
resource returns a 4xx or 5xx status code, or the HTTPS connection resource returns a 4xx or 5xx status code, or the HTTPS connection
cannot be established for any reason, then the client MUST accept cannot be established for any reason, then the client MUST accept
that the WebFinger query has failed and MUST NOT attempt to reissue that the WebFinger query has failed and MUST NOT attempt to reissue
skipping to change at page 10, line 6 skipping to change at page 10, line 11
resource if the client requests no other supported format explicitly resource if the client requests no other supported format explicitly
via the HTTP "Accept" header. The client MAY include the "Accept" via the HTTP "Accept" header. The client MAY include the "Accept"
header to indicate a desired representation; representations other header to indicate a desired representation; representations other
than JRD might be defined in future specifications. The WebFinger than JRD might be defined in future specifications. The WebFinger
resource MUST silently ignore any requested representations that it resource MUST silently ignore any requested representations that it
does not understand and support. The media type used for the JSON does not understand and support. The media type used for the JSON
Resource Descriptor (JRD) is "application/jrd+json" (see Section Resource Descriptor (JRD) is "application/jrd+json" (see Section
9.2). 9.2).
A WebFinger resource MAY redirect the client; if it does, the A WebFinger resource MAY redirect the client; if it does, the
redirection MUST only be to an "https" URI. redirection MUST only be to an "https" URI and the client MUST
perform certificate validation again when redirected.
A WebFinger resource can include cache validators in a response to A WebFinger resource can include cache validators in a response to
enable conditional requests by the client and/or expiration times as enable conditional requests by the client and/or expiration times as
per Section 13 of RFC 2616. per Section 13 of RFC 2616.
A WebFinger client MAY utilize the HEAD method when querying a
WebFinger resource. Consequently, a WebFinger resource MUST support
the receipt of the HEAD method.
4.3. The "rel" Parameter 4.3. The "rel" Parameter
When issuing a request to a WebFinger resource, the client MAY When issuing a request to a WebFinger resource, the client MAY
utilize the "rel" parameter to request only a subset of the utilize the "rel" parameter to request only a subset of the
information that would otherwise be returned without the "rel" information that would otherwise be returned without the "rel"
parameter. When the "rel" parameter is used and accepted, only the parameter. When the "rel" parameter is used and accepted, only the
link relation types that match the link relation types provided via link relation types that match the link relation types provided via
the "rel" parameter are included in the array of links returned in the "rel" parameter are included in the array of links returned in
the JRD. If there are no matching link relation types defined for the JRD. If there are no matching link relation types defined for
the resource, the "links" array in the JRD will either be absent or the resource, the "links" array in the JRD will either be absent or
skipping to change at page 15, line 15 skipping to change at page 15, line 9
4.5. WebFinger and URIs 4.5. WebFinger and URIs
WebFinger requests include a "resource" parameter (see Section 4.1) WebFinger requests include a "resource" parameter (see Section 4.1)
specifying the URI of an account, device, or other entity. WebFinger specifying the URI of an account, device, or other entity. WebFinger
is neutral regarding the scheme of such a URI: it could be an "acct" is neutral regarding the scheme of such a URI: it could be an "acct"
URI [7], an "http" or "https" URI, a "mailto" URI [21], or some other URI [7], an "http" or "https" URI, a "mailto" URI [21], or some other
scheme. scheme.
To perform a WebFinger lookup on an account specific to the host To perform a WebFinger lookup on an account specific to the host
being queried, use of the "acct" URI scheme is recommended, since it being queried, use of the "acct" URI scheme is recommended, since it
explicitly identifies an account accessible via WebFinger. Further, explicitly identifies a generic user account that is not necessarily
the "acct" URI scheme is not associated with other protocols as, by bound to a specific protocol. Further, the "acct" URI scheme is not
way of example, the "mailto" URI scheme is associated with email. associated with other protocols as, by way of example, the "mailto"
Since not every host offers email service, using the "mailto" URI URI scheme is associated with email. Since not every host offers
scheme is not ideal for identifying user accounts on all hosts. That email service, using the "mailto" URI scheme is not ideal for
said, use of the "mailto" URI scheme would be ideal for use with identifying user accounts on all hosts. That said, use of the
WebFinger to discover mail server configuration information for a "mailto" URI scheme would be ideal for use with WebFinger to discover
user. mail server configuration information for a user.
5. Cross-Origin Resource Sharing (CORS) 5. Cross-Origin Resource Sharing (CORS)
WebFinger resources might not be accessible from a web browser due to WebFinger resources might not be accessible from a web browser due to
"Same-Origin" policies. The current best practice is to make "Same-Origin" policies. The current best practice is to make
resources available to browsers through Cross-Origin Resource Sharing resources available to browsers through Cross-Origin Resource Sharing
(CORS) [9], and servers MUST include the Access-Control-Allow-Origin (CORS) [9], and servers MUST include the Access-Control-Allow-Origin
HTTP header in responses. Servers SHOULD support the least HTTP header in responses. Servers SHOULD support the least
restrictive setting by allowing any domain access to the WebFinger restrictive setting by allowing any domain access to the WebFinger
resource: resource:
skipping to change at page 17, line 52 skipping to change at page 17, line 41
8.2. User Privacy Considerations 8.2. User Privacy Considerations
Service providers and users should be aware that placing information Service providers and users should be aware that placing information
on the Internet means that any user can access that information and on the Internet means that any user can access that information and
WebFinger can be used to make it even easier to discover that WebFinger can be used to make it even easier to discover that
information. While WebFinger can be an extremely useful tool for information. While WebFinger can be an extremely useful tool for
discovering one's avatar, blog, or other personal data, users should discovering one's avatar, blog, or other personal data, users should
understand the risks, too. If one does not wish to share certain understand the risks, too. If one does not wish to share certain
information with the world, do not allow that information to be information with the world, do not allow that information to be
freely accessible on the Internet or discoverable via WebFinger. freely accessible on the Internet or discoverable via WebFinger.
Further, WebFinger MUST NOT be used to provide any personal data to
any party unless explicitly authorized by the person whose
information is being shared. Publishing one's personal data within
an access-controlled or otherwise limited environment on the Internet
does not equate to providing implicit authorization of further
publication of that data via WebFinger.
The aforementioned word of caution is perhaps worth emphasizing again Systems or services that expose personal data via WebFinger MUST
with respect to information that might reveal a user's current provide an interface by which users can select which data elements
context (e.g., the user's location). The power of WebFinger comes are exposed through the WebFinger interface. For example, social
from providing a single place where others can find pointers to networking sites might allow users to mark certain data as "public"
information about a person, but service providers and users should be and then utilize that marking as a means of determining what
mindful of the nature of that information shared and the fact that it information to expose via WebFinger. The information published via
might be available for the entire world to see. Sharing location WebFinger would thus comprise only the information marked as public
information, for example, would potentially put a person in danger by the user. Further, the user has the ability to remove information
from any individual who might seek to inflict harm on that person. from publication via WebFinger by removing this marking.
WebFinger MUST NOT be used to provide any personal data to any party
unless explicitly authorized by the person whose information is being
shared. Publishing one's personal data within an access-controlled
or otherwise limited environment on the Internet does not equate to
providing implicit authorization of further publication of that data
via WebFinger.
The privacy and security concerns with publishing personal data via
WebFinger are worth emphasizing again with respect to personal data
that might reveal a user's current context (e.g., the user's
location). The power of WebFinger comes from providing a single
place where others can find pointers to information about a person,
but service providers and users should be mindful of the nature of
that information shared and the fact that it might be available for
the entire world to see. Sharing location information, for example,
would potentially put a person in danger from any individual who
might seek to inflict harm on that person.
Users should be aware of how easily personal data one might publish
can be used in unintended ways. In one study relevant to WebFinger-
like services, Balduzzi et al. [22] took a large set of leaked email
addresses and demonstrated a number of potential privacy concerns,
including the ability to cross-correlate the same user's accounts
over multiple social networks. The authors also describe potential
mitigation strategies.
The easy access to user information via WebFinger was a design goal The easy access to user information via WebFinger was a design goal
of the protocol, not a limitation. If one wishes to limit access to of the protocol, not a limitation. If one wishes to limit access to
information available via WebFinger, such as WebFinger resources for information available via WebFinger, such as WebFinger resources for
use inside a corporate network, the network administrator needs to use inside a corporate network, the network administrator needs to
take necessary measures to limit access from outside the network. take necessary measures to limit access from outside the network.
Using standard methods for securing web resources, network Using standard methods for securing web resources, network
administrators do have the ability to control access to resources administrators do have the ability to control access to resources
that might return sensitive information. Further, a server can be that might return sensitive information. Further, a server can be
employed in such a way as to require authentication and prevent employed in such a way as to require authentication and prevent
skipping to change at page 18, line 46 skipping to change at page 18, line 53
whether a given URI is valid or not. With such a query, the person whether a given URI is valid or not. With such a query, the person
may deduce that an email identifier is valid, for example. Such an may deduce that an email identifier is valid, for example. Such an
approach could help spammers maintain a current list of known email approach could help spammers maintain a current list of known email
addresses and to discover new ones. addresses and to discover new ones.
WebFinger could be used to associate a name or other personal data WebFinger could be used to associate a name or other personal data
with an email address, allowing spammers to craft more convincing with an email address, allowing spammers to craft more convincing
email messages. This might be of particular value in phishing email messages. This might be of particular value in phishing
attempts. attempts.
It is RECOMMENDED that implementers of WebFinger server software take
steps to mitigate abuse, including malicious over-use of the server
and harvesting of user information. Although there is no mechanism
that can guarantee that publicly-accessible WebFinger databases won't
be harvested, rate-limiting by IP address will prevent or at least
dramatically slow harvest by private individuals without access to
botnets or other distributed systems. The reason these mitigation
strategies are not mandatory is that the correct choice of mitigation
strategy (if any) depends greatly on the context. Implementers
should not construe this as meaning that they do not need to consider
whether to use a mitigation strategy, and, if so, what strategy to
use.
WebFinger client developers should also be aware of potential abuse
by spammers or those phishing for information about users. As an
example, suppose a mail client was configured to automatically
perform a WebFinger query as discussed in the example in Section 3.1.
If a spammer sent an email using a unique identifier in the 'From'
header, then when the WF query was performed the spammer would be
able to associate the request with a particular user's email address.
This would provide information to the spammer, including the user's
IP address, the fact the user just checked email, what kind of
WebFinger client the user utilized, and so on. For this reason, it
is strongly advised that clients not perform WebFinger queries unless
authorized by the user to do so.
8.4. Information Reliability 8.4. Information Reliability
A WebFinger resource has no means of ensuring that information A WebFinger resource has no means of ensuring that information
provided by a user is accurate. Likewise, neither the resource nor provided by a user is accurate. Likewise, neither the resource nor
the client can be absolutely guaranteed that information has not been the client can be absolutely guaranteed that information has not been
manipulated either at the server or along the communication path manipulated either at the server or along the communication path
between the client and server. Use of HTTPS helps to address some between the client and server. Use of HTTPS helps to address some
concerns with manipulation of information along the communication concerns with manipulation of information along the communication
path, but it clearly cannot address issues where the resource path, but it clearly cannot address issues where the resource
provided incorrect information, either due to being provided false provided incorrect information, either due to being provided false
skipping to change at page 23, line 5 skipping to change at page 23, line 20
[19] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415, [19] Hammer-Lahav, E. and Cook, B., "Web Host Metadata", RFC 6415,
October 2011. October 2011.
[20] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor [20] Hammer-Lahav, E. and W. Norris, "Extensible Resource Descriptor
(XRD) Version 1.0", http://docs.oasis- (XRD) Version 1.0", http://docs.oasis-
open.org/xri/xrd/v1.0/xrd-1.0.html. open.org/xri/xrd/v1.0/xrd-1.0.html.
[21] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI [21] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' URI
Scheme", RFC 6068, October 2010. Scheme", RFC 6068, October 2010.
[22] Balduzzi, Marco, et al., "Abusing social networks for automated
user profiling", Recent Advances in Intrusion Detection,
Springer Berlin Heidelberg, 2010,
https://www.eurecom.fr/en/publication/3042/download/rs-publi-
3042_1.pdf.
Author's Addresses Author's Addresses
Paul E. Jones Paul E. Jones
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Phone: +1 919 476 2048 Phone: +1 919 476 2048
Email: paulej@packetizer.com Email: paulej@packetizer.com
 End of changes. 26 change blocks. 
53 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/