draft-jones-appsawg-webfinger-04.txt   draft-jones-appsawg-webfinger-05.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: November 4, 2012 Joseph Smarr Expires: November 21, 2012 Joseph Smarr
Google Google
May 4, 2012 May 21, 2012
WebFinger WebFinger
draft-jones-appsawg-webfinger-04.txt draft-jones-appsawg-webfinger-05.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 November 4, 2012. This Internet-Draft will expire on November 21, 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. Controlling Access to Information.............................15 8. Security Considerations.......................................15
9. Security Considerations.......................................16 9. IANA Considerations...........................................16
10. IANA Considerations..........................................17 9.1. Registration of the "acct" URI scheme name...............17
10.1. Registration of the "acct" URI scheme name..............17 9.2. Registration of the "acct" Link Relation Type............17
10.2. Registration of the "acct" Link Relation Type...........17 10. Acknowledgments..............................................18
11. Acknowledgments..............................................18 11. References...................................................18
12. References...................................................18 11.1. Normative References....................................18
12.1. Normative References....................................18 11.2. Informative References..................................19
12.2. Informative References..................................19
Author's Addresses...............................................20 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 9, line 40 skipping to change at page 9, line 40
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.
WebFinger servers compliant with this specification MUST support for WebFinger servers compliant with this specification MUST support for
the "resource" parameter as a means of improving performance and the "resource" parameter as a means of improving performance and
reducing client complexity. Note that an RFC 6415-compliant server reducing client complexity. Note that an RFC 6415-compliant server
might not implement the "resource" parameter, though the server would might not implement the "resource" parameter, though the server would
respond to queries from the client as described in RFC 6415. Thus, respond to queries from the client as described in RFC 6415. Thus,
WebFinger clients need to check the server response to ensure that WebFinger clients MUST check the server response to ensure that the
the "resource" parameter is supported as explained below. "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 10 skipping to change at page 11, line 10
{ {
"rel" : "hub", "rel" : "hub",
"href" : "http://example.com/another/hub" "href" : "http://example.com/another/hub"
}, },
{ {
"rel" : "author", "rel" : "author",
"href" : "http://example.com/john" "href" : "http://example.com/john"
}, },
{ {
"rel" : "author", "rel" : "author",
"template" : "http://example.com/author?\ "href" : "http://example.com/author?\
q=http%3A%2F%2Fexample.com%2Fxy" q=http%3A%2F%2Fexample.com%2Fxy"
} }
] ]
} }
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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
accounts, WebFinger clients MUST take steps to avoid loops wherein accounts, WebFinger clients MUST take steps to avoid loops wherein
two accounts, directly or indirectly, refer the client to each other. two accounts, directly or indirectly, refer the client to each other.
There are no limits on the number of "acct" link relations that might There are no limits on the number of "acct" link relations that might
be returned in a WebFinger query. be returned in a WebFinger query.
An "acct" link relation used within the context of a WebFinger query An "acct" link relation used within the context of a WebFinger query
for a user's account MUST NOT return "acct" link relations for for a user's account MUST NOT return "acct" link relations for
another individual. another individual.
The "acct" link relation also makes it possible to use the link
relation in HTML documents or in HTTP headers as described in the Web
Linking specification [3]. This would allow, by way of example, for
a user to advertise his or her account identifier in a blog, article,
or other content located on a server that is unrelated to his user
account. Since there may be multiple contributors to an article,
there may be more than one "acct" link relation in an HTML document
or in HTTP headers. It is RECOMMENDED that no more than one "acct"
link relation is advertised per author of a given web page, as a
client may otherwise not understand that the multiple link relations
are for the same person; references to other accounts should be done
from within a user's account, as described in the preceding
paragraphs.
6.2. Example Message Exchange Using the "acct" Link Relation 6.2. Example Message Exchange Using the "acct" Link Relation
Consider the following non-normative example. Consider the following non-normative example.
Suppose Alice receives an email from bob@example.net. While Bob's Suppose Alice receives an email from bob@example.net. While Bob's
email identifier might be in the example.net domain, he holds his email identifier might be in the example.net domain, he holds his
account with an "acct" URI in the example.com domain. His email account with an "acct" URI in the example.com domain. His email
provider may provide WebFinger services to enable redirecting Alice provider may provide WebFinger services to enable redirecting Alice
when she queries for acct:bob@example.net. when she queries for acct:bob@example.net.
skipping to change at page 15, line 26 skipping to change at page 15, line 14
Alice's WebFinger client could then perform queries against the URIs Alice's WebFinger client could then perform queries against the URIs
acct:bob@example.com and acct:bob@example.org in order to get the acct:bob@example.com and acct:bob@example.org in order to get the
information Alice is seeking. information Alice is seeking.
7. Cross-Origin Resource Sharing (CORS) 7. Cross-Origin Resource Sharing (CORS)
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] when serving content intended for public consumption.
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: *
Enterprise WebFinger servers that wish to restrict access to
information from external entities SHOULD use a more restrictive
Access-Control-Allow-Origin header and MAY exclude the header
entirely.
8. Controlling Access to Information 8. Controlling Access to Information
As with all web resources, access to the Host Metadata resource and As with all web resources, access to the Host Metadata resource and
the LRDD resource MAY require authentication. Further, failure to the LRDD resource MAY require authentication. Further, failure to
provide required credentials MAY result in the server forbidding provide required credentials MAY result in the server forbidding
access or providing a different response than had the client access or providing a different response than had the client
authenticated with the server. authenticated with the server.
Likewise, a server MAY provide different responses to different Likewise, a server MAY provide different responses to different
clients based on other factors, such as whether the client is inside clients based on other factors, such as whether the client is inside
skipping to change at page 16, line 24 skipping to change at page 16, line 16
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. Additionally, WebFinger servers
a signature for XRD documents. SHOULD include a signature for XRD documents served over HTTP.
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 freely 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
skipping to change at page 17, line 24 skipping to change at page 17, line 17
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
URI scheme syntax: see Section 4.1 of RFC QQQQ URI scheme syntax: see Section 5.2 of RFC QQQQ
URI scheme semantics: see Section 4.1 of RFC QQQQ URI scheme semantics: see Section 5 of RFC QQQQ
Encoding considerations: The "acct" URI scheme allows any character Encoding considerations: The "acct" URI scheme allows any character
from the Unicode character set encoded as a UTF-8 string that is from the Unicode character set encoded as a UTF-8 string that is
then percent-encoded as necessary to result in an internal then percent-encoded as necessary to result in an internal
representation in US-ASCII [10] representation in US-ASCII [10]
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
skipping to change at page 21, 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)
============================================= =============================================
-05 Draft
* Minor editorial corrections
* Removed last paragraph from Section 6.1
* Clarified use of CORS and how it may differ for enterprise use
-04 Draft -04 Draft
* Added text that makes the "resource" parameter required * Added text that makes the "resource" parameter required
* Added a new section 8 that discusses controlling access to information * Added a new section 8 that discusses controlling access to information
* Added a little more to the security considerations section to briefly * Added a little more to the security considerations section to briefly
cover what was more fully explained in the new section 8 cover what was more fully explained in the new section 8
-03 Draft -03 Draft
 End of changes. 14 change blocks. 
35 lines changed or deleted 34 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/