draft-jones-appsawg-webfinger-03.txt   draft-jones-appsawg-webfinger-04.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: October 9, 2012 Joseph Smarr Expires: November 4, 2012 Joseph Smarr
Google Google
April 9, 2012 May 4, 2012
WebFinger WebFinger
draft-jones-appsawg-webfinger-03.txt draft-jones-appsawg-webfinger-04.txt
Abstract Abstract
This specification defines the WebFinger protocol. WebFinger may be This specification defines the WebFinger protocol. WebFinger may be
used to discover information about people on the Internet, such as a used to discover information about people on the Internet, such as a
person's personal profile address, identity service, telephone person's personal profile address, identity service, telephone
number, or preferred avatar. WebFinger may also be used to learn number, or preferred avatar. WebFinger may also be used to learn
information about objects on the network, such as the amount of toner information about objects on the network, such as the amount of toner
in a printer or the physical location of a server. in a printer or the physical location of a server.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 October 9, 2012. This Internet-Draft will expire on November 4, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 28 skipping to change at page 2, line 28
4.1. Performing a WebFinger Query..............................8 4.1. Performing a WebFinger Query..............................8
4.2. The Web Host Metadata "resource" Parameter................9 4.2. The Web Host Metadata "resource" Parameter................9
4.3. The Web Host Metadata "rel" Parameter....................11 4.3. The Web Host Metadata "rel" Parameter....................11
5. The "acct" URI................................................12 5. The "acct" URI................................................12
5.1. Using the "acct" URI.....................................12 5.1. Using the "acct" URI.....................................12
5.2. Syntax of "acct" URI.....................................13 5.2. Syntax of "acct" URI.....................................13
6. The "acct" Link Relation......................................13 6. The "acct" Link Relation......................................13
6.1. Purpose for the "acct" Link Relation.....................13 6.1. Purpose for the "acct" Link Relation.....................13
6.2. Example Message Exchange Using the "acct" Link Relation..14 6.2. Example Message Exchange Using the "acct" Link Relation..14
7. Cross-Origin Resource Sharing (CORS)..........................15 7. Cross-Origin Resource Sharing (CORS)..........................15
8. Security Considerations.......................................15 8. Controlling Access to Information.............................15
9. IANA Considerations...........................................16 9. Security Considerations.......................................16
9.1. Registration of the "acct" URI scheme name...............16 10. IANA Considerations..........................................17
9.2. Registration of the "acct" Link Relation Type............16 10.1. Registration of the "acct" URI scheme name..............17
10. Acknowledgments..............................................17 10.2. Registration of the "acct" Link Relation Type...........17
11. References...................................................17 11. Acknowledgments..............................................18
11.1. Normative References....................................17 12. References...................................................18
11.2. Informative References..................................18 12.1. Normative References....................................18
Author's Addresses...............................................19 12.2. Informative References..................................19
Author's Addresses...............................................20
1. Introduction 1. Introduction
There is a utility found on UNIX systems called "finger" [14] that There is a utility found on UNIX systems called "finger" [14] that
allows a person to access information about another person. The allows a person to access information about another person. The
information being queried might be on a computer anywhere in the information being queried might be on a computer anywhere in the
world. The information returned via "finger" is simply a plain text world. The information returned via "finger" is simply a plain text
file that contains unstructured information provided by the queried file that contains unstructured information provided by the queried
user. user.
skipping to change at page 7, line 43 skipping to change at page 7, line 43
} }
At this point, the blog server knows that Carol's OpenID identifier At this point, the blog server knows that Carol's OpenID identifier
is https://openid.example.com/carol and could then proceed with the is https://openid.example.com/carol and could then proceed with the
login process as usual. login process as usual.
3.4. Retrieving Device Information 3.4. Retrieving Device Information
While the examples thus far have been focused on information about While the examples thus far have been focused on information about
humans, WebFinger does not limit queries to only those that use the humans, WebFinger does not limit queries to only those that use the
account URI scheme. Let's suppose there are devices on the network account URI scheme. Any URI scheme that contains domain information
like printers and you would like to check the current toner level for MAY be used with WebFinger. Let's suppose there are devices on the
a particular printer identified via the URI like network like printers and you would like to check the current toner
level for a particular printer identified via the URI like
device:p1.example.com. While the "device" URI scheme is not device:p1.example.com. While the "device" URI scheme is not
presently specified, we use it here for illustrative purposes. presently specified, we use it 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 /lrdd/?format=json&uri=device%3Ap1.example.com HTTP/1.1 GET /lrdd/?format=json&uri=device%3Ap1.example.com HTTP/1.1
Host: example.com Host: example.com
The link relations that are returned may be quite different than The link relations that are returned may be quite different than
skipping to change at page 9, line 32 skipping to change at page 9, line 35
4.2. The Web Host Metadata "resource" Parameter 4.2. The Web Host Metadata "resource" Parameter
In addition to the normal processing logic for processing host In addition to the normal processing logic for processing host
metadata information, WebFinger defines the "resource" parameter for metadata information, WebFinger defines the "resource" parameter for
querying for host metadata and returning all of the link relations querying for host metadata and returning all of the link relations
from LRDD and other resource-specific link templates in a single from LRDD and other resource-specific link templates in a single
query. This resource essentially pushes the work to the server to query. This resource essentially pushes the work to the server to
form a complete resource descriptor for the specified resource. form a complete resource descriptor for the specified resource.
Note that support for the "resource" parameter is optional, but WebFinger servers compliant with this specification MUST support for
strongly RECOMMENDED for improved performance. If a server does not the "resource" parameter as a means of improving performance and
implement the "resource" parameter, then the server's host metadata reducing client complexity. Note that an RFC 6415-compliant server
processing logic remains unchanged from RFC 6415. might not implement the "resource" parameter, though the server would
respond to queries from the client as described in RFC 6415. Thus,
WebFinger clients need to check the server response to ensure that
the "resource" parameter is supported as explained below.
To utilize the host-meta "resource" parameter, a WebFinger client To utilize the host-meta "resource" parameter, a WebFinger client
issues a request to /.well-known/host-meta or /.well-known/host- issues a request to /.well-known/host-meta or /.well-known/host-
meta.json as usual, but then appends a "resource" parameter as shown meta.json as usual, but then appends a "resource" parameter as shown
in this example: in this example:
GET /.well-known/host-meta.json?resource=\ GET /.well-known/host-meta.json?resource=\
acct%3Abob%40example.com HTTP/1.1 acct%3Abob%40example.com HTTP/1.1
Host: example.com Host: example.com
skipping to change at page 11, line 16 skipping to change at page 11, line 23
] ]
} }
4.3. The Web Host Metadata "rel" Parameter 4.3. The Web Host Metadata "rel" Parameter
WebFinger also defines the "rel" parameter for use when querying for WebFinger also defines the "rel" parameter for use when querying for
host metadata. It is used to return a subset of the information that host metadata. It is used to return a subset of the information that
would otherwise be returned without the "rel" parameter. When the would otherwise be returned without the "rel" parameter. When the
"rel" parameter is used, only the link relations that match the "rel" parameter is used, only the link relations that match the
space-separated list of link relations provided via "rel" are space-separated list of link relations provided via "rel" are
included in the list of links returned in resource descriptor. All included in the list of links returned in the resource descriptor.
other information normally present in a resource descriptor is All other information normally present in a resource descriptor is
present in the resource descriptor, even when "rel" is employed. present in the resource descriptor, even when "rel" is employed.
The purpose of the "rel" parameter is to return a subset of The purpose of the "rel" parameter is to return a subset of
resource's link relations. It is not intended to reduce the work resource's link relations. It is not intended to reduce the work
required of a server to produce a response. That said, use of the required of a server to produce a response. That said, use of the
parameter might reduce processing requirements on either the client parameter might reduce processing requirements on either the client
or server, and it might also reduce the bandwidth required to convey or server, and it might also reduce the bandwidth required to convey
the partial resource descriptor, especially if there are numerous the partial resource descriptor, especially if there are numerous
link relation values to convey for a given resource. link relation values to convey for a given resource.
skipping to change at page 15, line 25 skipping to change at page 15, line 32
WebFinger is most useful when it is accessible without restrictions WebFinger is most useful when it is accessible without restrictions
on the Internet, and that includes web browsers. Therefore, on the Internet, and that includes web browsers. Therefore,
WebFinger servers MUST support Cross-Origin Resource Sharing (CORS) WebFinger servers MUST support Cross-Origin Resource Sharing (CORS)
[7]. Specifically, all queries to /.well-known/host-meta, /.well- [7]. Specifically, all queries to /.well-known/host-meta, /.well-
known/host-meta.json, and to the LRDD URI must include the following known/host-meta.json, and to the LRDD URI must include the following
HTTP header in the response: HTTP header in the response:
Access-Control-Allow-Origin: * Access-Control-Allow-Origin: *
8. Security Considerations 8. Controlling Access to Information
As with all web resources, access to the Host Metadata resource and
the LRDD resource MAY require authentication. Further, failure to
provide required credentials MAY result in the server forbidding
access or providing a different response than had the client
authenticated with the server.
Likewise, a server MAY provide different responses to different
clients based on other factors, such as whether the client is inside
or outside a corporate network. As a concrete example, a query
performed on the internal corporate network might return link
relations to employee pictures whereas link relations for employee
pictures might not be provided to external entities.
Further, link relations provided in a WebFinger server response MAY
point to web resources that impose access restrictions. For example,
it is possible that the aforementioned corporate server may provide
both internal and external entities with URIs to employee pictures,
but further authentication MAY be required in order for the WebFinger
client to access those resources if the request comes from outside
the corporate network.
The decisions made with respect to what set of link relations a
WebFinger server provides to one client versus another and what
resources require further authentication, as well as the specific
authentication mechanisms employed, are outside the scope of this
document.
9. Security Considerations
All of the security considerations applicable to Web Host Metadata All of the security considerations applicable to Web Host Metadata
[9] and Cross-Origin Resource Sharing [7] are also applicable to this [9] and Cross-Origin Resource Sharing [7] are also applicable to this
specification. Of particular importance is the recommended use of specification. Of particular importance is the recommended use of
HTTPS to ensure that information is not modified during transit. HTTPS to ensure that information is not modified during transit.
Clients should verify that the certificate used on an HTTPS Clients should verify that the certificate used on an HTTPS
connection is valid. connection is valid.
When using HTTP to request an XRD document, WebFinger clients SHOULD When using HTTP to request an XRD document, WebFinger clients SHOULD
verify the XRD document's signature, if present, to ensure that the verify the XRD document's signature, if present, to ensure that the
XRD document has not been modified. WebFinger servers SHOULD include XRD document has not been modified. WebFinger servers SHOULD include
a signature for XRD documents. a signature for XRD documents.
Service providers and users should be aware that placing information Service providers and users should be aware that placing information
on the Internet accessible through WebFinger means that any user can on the Internet accessible through WebFinger means that any user can
access that information. While WebFinger can be an extremely useful access that information. While WebFinger can be an extremely useful
tool for allowing quick and easy access to one's avatar, blog, or tool for allowing quick and easy access to one's avatar, blog, or
other personal information, users should understand the risks, too. other personal information, users should understand the risks, too.
If one does not wish to share certain information with the world, do If one does not wish to share certain information with the world, do
not allow that information to be accessible through WebFinger. not allow that information to be freely accessible through WebFinger.
The aforementioned word of caution is perhaps worth emphasizing again The aforementioned word of caution is perhaps worth emphasizing again
with respect to dynamic information one might wish to share, such as with respect to dynamic information one might wish to share, such as
the current location of a user. WebFinger can be a powerful tool the current location of a user. WebFinger can be a powerful tool
used to assemble information about a person all in one place, but used to assemble information about a person all in one place, but
service providers and users should be mindful of the nature of that service providers and users should be mindful of the nature of that
information shared and the fact that it might be available for the information shared and the fact that it might be available for the
entire world to see. Sharing location information, for example, entire world to see. Sharing location information, for example,
would potentially put a person in danger from any individual who would potentially put a person in danger from any individual who
might seek to inflict harm on that person. might seek to inflict harm on that person.
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 a WebFinger server for information available via WebFinger, such as a WebFinger server for
use inside a corporate network, the network administrator must take use inside a corporate network, the network administrator must take
measures necessary to limit access from outside the network. measures necessary to limit access from outside the network. Using
standard methods for securing web resources, network administrators
do have the ability to control access to resources that might return
sensitive information. Further, WebFinger servers can be employed in
such a way as to require authentication and prevent disclosure of
information to unauthorized entities.
9. IANA Considerations 10. IANA Considerations
RFC Editor: Please replace QQQQ in the following two sub-sections RFC Editor: Please replace QQQQ in the following two sub-sections
with a reference to this RFC. with a reference to this RFC.
9.1. Registration of the "acct" URI scheme name 10.1. Registration of the "acct" URI scheme name
This specification requests IANA to register the "acct" URI scheme in This specification requests IANA to register the "acct" URI scheme in
the "Permanent URI Schemes" sub-registry in the "Uniform Resource the "Permanent URI Schemes" sub-registry in the "Uniform Resource
Identifier (URI) Schemes" IANA registry [17]. This registration Identifier (URI) Schemes" IANA registry [17]. This registration
follows the URI Scheme Registration Template detailed in Section 5.4 follows the URI Scheme Registration Template detailed in Section 5.4
of RFC 4395 [15]. of RFC 4395 [15].
URI scheme name: acct URI scheme name: acct
Status: Permanent Status: Permanent
skipping to change at page 16, line 50 skipping to change at page 17, line 43
Applications/protocols that use this URI scheme name: WebFinger Applications/protocols that use this URI scheme name: WebFinger
Security considerations: see Section 7 of RFC QQQQ Security considerations: see Section 7 of RFC QQQQ
Contact: Gonzalo Salgueiro <gsalguei@cisco.com> Contact: Gonzalo Salgueiro <gsalguei@cisco.com>
Author/Change controller: IETF <ietf@ietf.org> Author/Change controller: IETF <ietf@ietf.org>
References: See Section 10 of RFC QQQQ References: See Section 10 of RFC QQQQ
9.2. Registration of the "acct" Link Relation Type 10.2. Registration of the "acct" Link Relation Type
Relation Name: acct Relation Name: acct
Description: A link relation that refers to a user's WebFinger Description: A link relation that refers to a user's WebFinger
account identifier. account identifier.
Reference: RFC QQQQ Reference: RFC QQQQ
Notes: Notes:
Application Data: Application Data:
10. Acknowledgments 11. Acknowledgments
The authors would like to acknowledge Eran Hammer-Lahav, Blaine Cook, The authors would like to acknowledge Eran Hammer-Lahav, Blaine Cook,
Brad Fitzpatrick, Laurent-Walter Goix, and Joe Clarke for their Brad Fitzpatrick, Laurent-Walter Goix, and Joe Clarke for their
invaluable input. invaluable input.
11. References 12. References
11.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[3] Nottingham, M., "Web Linking", RFC 5988, October 2010. [3] Nottingham, M., "Web Linking", RFC 5988, October 2010.
skipping to change at page 18, line 19 skipping to change at page 19, line 11
[11] The Unicode Consortium. The Unicode Standard, Version 6.1.0, [11] The Unicode Consortium. The Unicode Standard, Version 6.1.0,
(Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1- (Mountain View, CA: The Unicode Consortium, 2012. ISBN 978-1-
936213-02-3) http://www.unicode.org/versions/Unicode6.1.0/. 936213-02-3) http://www.unicode.org/versions/Unicode6.1.0/.
[12] Klensin, J., "Internationalized Domain Names in Applications [12] Klensin, J., "Internationalized Domain Names in Applications
(IDNA): Protocol", RFC 5891, August 2010. (IDNA): Protocol", RFC 5891, August 2010.
[13] Duerst, M., "Internationalized Resource Identifiers (IRIs)", [13] Duerst, M., "Internationalized Resource Identifiers (IRIs)",
RFC 3987, January 2005. RFC 3987, January 2005.
11.2. Informative References 12.2. Informative References
[14] Zimmerman, D., "The Finger User Information Protocol", RFC [14] Zimmerman, D., "The Finger User Information Protocol", RFC
1288, December 1991. 1288, December 1991.
[15] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and [15] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 35, RFC 4395, Registration Procedures for New URI Schemes", BCP 35, RFC 4395,
February 2006. February 2006.
[16] Perreault, S., "vCard Format Specification", RFC 6350, August [16] Perreault, S., "vCard Format Specification", RFC 6350, August
2011. 2011.
skipping to change at page 20, line 8 skipping to change at page 21, line 8
IM: xmpp:gsalguei@cisco.com IM: xmpp:gsalguei@cisco.com
Joseph Smarr Joseph Smarr
Google Google
Email: jsmarr@google.com Email: jsmarr@google.com
Change Log (To Be Deleted Before Publication) Change Log (To Be Deleted Before Publication)
============================================= =============================================
-04 Draft
* Added text that makes the "resource" parameter required
* Added a new section 8 that discusses controlling access to information
* Added a little more to the security considerations section to briefly
cover what was more fully explained in the new section 8
-03 Draft -03 Draft
* Changed the name from Webfinger to WebFinger (common usage) * Changed the name from Webfinger to WebFinger (common usage)
* Added a new paragraph to Section 4.1 to remind readers that WebFinger * Added a new paragraph to Section 4.1 to remind readers that WebFinger
benefits from all of the existing HTTP caching functionality benefits from all of the existing HTTP caching functionality
* Added the "rel" parameter to allow filtering the results of a * Added the "rel" parameter to allow filtering the results of a
WebFinger query to include Links of the specified type(s) WebFinger query to include Links of the specified type(s)
 End of changes. 20 change blocks. 
32 lines changed or deleted 81 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/