draft-ietf-appsawg-webfinger-11.txt   draft-ietf-appsawg-webfinger-12.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 8, 2013 Joseph Smarr Expires: September 28, 2013 Joseph Smarr
Google Google
March 8, 2013 March 28, 2013
WebFinger WebFinger
draft-ietf-appsawg-webfinger-11.txt draft-ietf-appsawg-webfinger-12.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 8, 2013. This Internet-Draft will expire on September 28, 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 17
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......................8 4.1. Constructing a WebFinger Request URI......................9
4.2. Performing a WebFinger Query..............................9 4.2. Performing a WebFinger Query..............................9
4.3. The "rel" Parameter.......................................9 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.............................................11 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.......................................14 4.5. WebFinger and URIs.......................................15
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
9. IANA Considerations...........................................18 8.1. Transport-Related Issues.................................17
9.1. Well-Known URI...........................................18 8.2. User Privacy Considerations..............................17
9.2. JSON Resource Descriptor (JRD) Media Type................18 8.3. Abuse Potential..........................................18
10. Acknowledgments..............................................20 8.4. Information Reliability..................................18
11. References...................................................20 9. IANA Considerations...........................................19
11.1. Normative References....................................20 9.1. Well-Known URI...........................................19
11.2. Informative References..................................21 9.2. JSON Resource Descriptor (JRD) Media Type................19
Author's Addresses...............................................22 10. Acknowledgments..............................................21
11. References...................................................21
11.1. Normative References....................................21
11.2. Informative References..................................22
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]
using standard Hypertext Transfer Protocol (HTTP) [2] methods over a using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
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).
skipping to change at page 4, line 49 skipping to change at page 5, line 4
"href" : "http://blogs.example.com/bob/", "href" : "http://blogs.example.com/bob/",
"titles" : "titles" :
{ {
"en-us" : "The Magical World of Bob", "en-us" : "The Magical World of Bob",
"fr" : "Le Monde Magique de Bob" "fr" : "Le Monde Magique de Bob"
} }
}, },
{ {
"rel" : "http://webfinger.example/rel/businesscard", "rel" : "http://webfinger.example/rel/businesscard",
"href" : "https://www.example.com/~bob/bob.vcf" "href" : "https://www.example.com/~bob/bob.vcf"
} }
] ]
} }
Note the assumption made in the above example is that there is an
"acct" URI for the given "mailto" URI. This may not always be the
case.
The email client would take note of the link relation in the above The email client would take note of the link relation in the above
JRD that refers to Bob's blog. The blog's URI would then be JRD that refers to Bob's blog. The blog's URI would then be
presented to you so that you could then visit his blog. The email presented to you so that you could then visit his blog. The email
client might also note that Bob has published an avatar link relation client might also note that Bob has published an avatar link relation
and use that picture to represent Bob inside the email client. and use that picture to represent Bob inside the email client.
Lastly, the client might automatically retrieve the data located at Lastly, the client might automatically retrieve the data located at
the URI specified by the "businesscard" link relation (which might be the URI specified by the "businesscard" link relation (which might be
a vcard [16]) to update the information about Bob in its internal a vcard [16]) to update the information about Bob in its internal
address book. address book.
skipping to change at page 13, line 18 skipping to change at page 13, line 32
from any other object in the array; any requirement to include a from any other object in the array; any requirement to include a
given member in the link relation object refers only to that given member in the link relation object refers only to that
particular object. particular object.
4.4.4.1. rel 4.4.4.1. rel
The value of the "rel" member is a string that is either an absolute The value of the "rel" member is a string that is either an absolute
URI or a registered relation type [10] (see RFC 5988 [4]). The value URI or a registered relation type [10] (see RFC 5988 [4]). The value
of the "rel" member MUST contain exactly one URI or registered of the "rel" member MUST contain exactly one URI or registered
relation type. The URI or registered relation type identifies the relation type. The URI or registered relation type identifies the
type of the link relation. The other members of the object have type of the link relation.
meaning only once the type of link relation is understood. In some
instances, the link relation will have associated semantics enabling The other members of the object have meaning only once the type of
the client to query for other resources on the Internet. In other link relation is understood. In some instances, the link relation
instances, the link relation will have associated semantics enabling will have associated semantics enabling the client to query for other
the client to utilize the other members of the link relation object resources on the Internet. In other instances, the link relation
without fetching additional external resources. will have associated semantics enabling the client to utilize the
other members of the link relation object without fetching additional
external resources.
URI link relation type values are compared using the "Simple String
Comparison" algorithm of section 6.2.1 of RFC 3986 [6].
The "rel" member MUST be present in the link relation object. The "rel" member MUST be present in the link relation object.
4.4.4.2. type 4.4.4.2. type
The value of the "type" member is a string that indicates the media The value of the "type" member is a string that indicates the media
type [11] of the target resource (see RFC 6838 [12]). type [11] of the target resource (see RFC 6838 [12]).
The "type" member is OPTIONAL in the link relation object. The "type" member is OPTIONAL in the link relation object.
skipping to change at page 17, line 7 skipping to change at page 17, line 24
resource=acct%3Aalice%40example.com resource=acct%3Aalice%40example.com
The client can then follow the redirection, re-issuing the request to The client can then follow the redirection, re-issuing the request to
the URI provided in the Location header. Note that the server will the URI provided in the Location header. Note that the server will
include any required URI parameters in the Location header value, include any required URI parameters in the Location header value,
which could be different than the URI parameters the client which could be different than the URI parameters the client
originally used. originally used.
8. Security Considerations 8. Security Considerations
8.1. Transport-Related Issues
Since this specification utilizes Cross-Origin Resource Sharing Since this specification utilizes Cross-Origin Resource Sharing
(CORS) [9], all of the security considerations applicable to CORS are (CORS) [9], all of the security considerations applicable to CORS are
also applicable to this specification. also applicable to this specification.
The use of HTTPS is REQUIRED to ensure that information is not The use of HTTPS is REQUIRED to ensure that information is not
modified during transit. It should be appreciated that in modified during transit. It should be appreciated that in
environments where a web server is normally available, there exists environments where a web server is normally available, there exists
the possibility that a compromised network might have its WebFinger the possibility that a compromised network might have its WebFinger
resource operating on HTTPS replaced with one operating only over resource operating on HTTPS replaced with one operating only over
HTTP. As such, clients MUST NOT issue queries over a non-secure HTTP. As such, clients MUST NOT issue queries over a non-secure
connection. connection.
Clients MUST verify that the certificate used on an HTTPS connection Clients MUST verify that the certificate used on an HTTPS connection
is valid (as defined in [14]) and accept a response only if the is valid (as defined in [14]) and accept a response only if the
certificate is valid. certificate is valid.
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 information, users discovering one's avatar, blog, or other personal data, users should
should understand the risks, too. If one does not wish to share understand the risks, too. If one does not wish to share certain
certain information with the world, do not allow that information to information with the world, do not allow that information to be
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 Further, WebFinger MUST NOT be used to provide any personal data to
information to any party unless explicitly or implicitly authorized any party unless explicitly authorized by the person whose
by the person whose information is being shared. 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 The aforementioned word of caution is perhaps worth emphasizing again
with respect to information that might reveal a user's current with respect to information that might reveal a user's current
context (e.g., the user's location). The power of WebFinger comes context (e.g., the user's location). The power of WebFinger comes
from providing a single place where others can find pointers to from providing a single place where others can find pointers to
information about a person, but service providers and users should be information about a person, but service providers and users should be
mindful of the nature of that information shared and the fact that it mindful of the nature of that information shared and the fact that it
might be available for the entire world to see. Sharing location might be available for the entire world to see. Sharing location
information, for example, would potentially put a person in danger information, for example, would potentially put a person in danger
from any individual who might seek to inflict harm on that person. from any individual who might seek to inflict harm on that person.
skipping to change at page 18, line 7 skipping to change at page 18, line 30
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
disclosure of information to unauthorized entities. disclosure of information to unauthorized entities.
Finally, a WebFinger resource has no means of ensuring that 8.3. Abuse Potential
information provided by a user is accurate. Likewise, neither the
resource nor the client can be absolutely guaranteed that information Service providers should be mindful of the potential for abuse using
has not been manipulated either at the server or along the WebFinger.
communication path between the client and server. Use of HTTPS helps
to address some concerns with manipulation of information along the As one example, one might query a WebFinger server only to discover
communication path, but it clearly cannot address issues where the whether a given URI is valid or not. With such a query, the person
resource provided incorrect information, either due to being provided may deduce that an email identifier is valid, for example. Such an
false information or due to malicious behavior on the part of the approach could help spammers maintain a current list of known email
server administrator. As with any information service available on addresses and to discover new ones.
the Internet, users should be wary of information received from
untrusted sources. WebFinger could be used to associate a name or other personal data
with an email address, allowing spammers to craft more convincing
email messages. This might be of particular value in phishing
attempts.
8.4. Information Reliability
A WebFinger resource has no means of ensuring that information
provided by a user is accurate. Likewise, neither the resource nor
the client can be absolutely guaranteed that information has not been
manipulated either at the server or along the communication path
between the client and server. Use of HTTPS helps to address some
concerns with manipulation of information along the communication
path, but it clearly cannot address issues where the resource
provided incorrect information, either due to being provided false
information or due to malicious behavior on the part of the server
administrator. As with any information service available on the
Internet, users should be wary of information received from untrusted
sources.
9. IANA Considerations 9. IANA Considerations
9.1. Well-Known URI 9.1. Well-Known URI
This specification registers the "webfinger" well-known URI in the This specification registers the "webfinger" well-known URI in the
Well-Known URI Registry as defined by [3]. Well-Known URI Registry as defined by [3].
URI suffix: webfinger URI suffix: webfinger
Change controller: IETF Change controller: IETF
Specification document(s): RFC XXXX Specification document(s): RFC XXXX
Related information: The response representation returned by a Related information: The query to the WebFinger resource will
WebFinger resource will be a JSON Resource Descriptor (JRD) as include one or more parameters in the query string; see Section 4.1
described in Section 4.4 of RFC XXXX. of RFCXXXX. Resources at this location are able to return a JSON
Resource Descriptor (JRD) as described in Section 4.4 of RFCXXXX.
[RFC EDITOR: Please replace "XXXX" references in this section and the [RFC EDITOR: Please replace "XXXX" references in this section and the
following section with the number for this RFC.] following section with the number for this RFC.]
9.2. JSON Resource Descriptor (JRD) Media Type 9.2. JSON Resource Descriptor (JRD) Media Type
This specification registers the media type application/jrd+json for This specification registers the media type application/jrd+json for
use with WebFinger in accordance with media type registration use with WebFinger in accordance with media type registration
procedures defined in [12]. procedures defined in [12].
skipping to change at page 21, line 24 skipping to change at page 22, line 18
[10] IANA, "Link Relations", http://www.iana.org/assignments/link- [10] IANA, "Link Relations", http://www.iana.org/assignments/link-
relations/. relations/.
[11] IANA, "MIME Media Types", [11] IANA, "MIME Media Types",
http://www.iana.org/assignments/media-types/index.html. http://www.iana.org/assignments/media-types/index.html.
[12] Freed, N., Klensin, J., Hansen, T., "Media Type Specifications [12] Freed, N., Klensin, J., Hansen, T., "Media Type Specifications
and Registration Procedures", RFC 6838, January 2013. and Registration Procedures", RFC 6838, January 2013.
[13] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC [13] Phillips, A., Davis, M., "Tags for Identifying Languages", RFC
5646, January 2001. 5646, January 2009.
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[15] Klyne, G., Newman, C., "Date and Time on the Internet: [15] Klyne, G., Newman, C., "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, July 2002.
11.2. Informative References 11.2. Informative References
[16] Perreault, S., "vCard Format Specification", RFC 6350, August [16] Perreault, S., "vCard Format Specification", RFC 6350, August
2011. 2011.
 End of changes. 18 change blocks. 
46 lines changed or deleted 86 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/