draft-ietf-appsawg-webfinger-10.txt   draft-ietf-appsawg-webfinger-11.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: August 8, 2013 Joseph Smarr Expires: September 8, 2013 Joseph Smarr
Google Google
February 8, 2013 March 8, 2013
WebFinger WebFinger
draft-ietf-appsawg-webfinger-10.txt draft-ietf-appsawg-webfinger-11.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 August 8, 2013. This Internet-Draft will expire on September 8, 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 26 skipping to change at page 2, line 26
4. WebFinger Protocol.............................................8 4. WebFinger Protocol.............................................8
4.1. Constructing a WebFinger Request URI......................8 4.1. Constructing a WebFinger Request URI......................8
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.......................................9
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.............................................11
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.......................................14
5. Cross-Origin Resource Sharing (CORS)..........................14 5. Cross-Origin Resource Sharing (CORS)..........................15
6. Access Control................................................15 6. Access Control................................................15
7. Hosted WebFinger Services.....................................15 7. Hosted WebFinger Services.....................................16
8. Security Considerations.......................................16 8. Security Considerations.......................................17
9. IANA Considerations...........................................18 9. IANA Considerations...........................................18
9.1. Well-Known URI...........................................18 9.1. Well-Known URI...........................................18
9.2. JSON Resource Descriptor (JRD) Media Type................18 9.2. JSON Resource Descriptor (JRD) Media Type................18
10. Acknowledgments..............................................20 10. Acknowledgments..............................................20
11. References...................................................20 11. References...................................................20
11.1. Normative References....................................20 11.1. Normative References....................................20
11.2. Informative References..................................21 11.2. Informative References..................................21
Author's Addresses...............................................22 Author's Addresses...............................................22
1. Introduction 1. Introduction
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Suppose Carol wishes to authenticate with a web site she visits using Suppose Carol wishes to authenticate with a web site she visits using
OpenID Connect [18]. She would provide the web site with her OpenID OpenID Connect [18]. She would provide the web site with her OpenID
Connect identifier, say carol@example.com. The visited web site Connect identifier, say carol@example.com. The visited web site
would perform a WebFinger query looking for the OpenID Connect would perform a WebFinger query looking for the OpenID Connect
Provider. Since the site is interested in only one particular link Provider. Since the site is interested in only one particular link
relation, the WebFinger resource might utilize the "rel" parameter as relation, the WebFinger resource might utilize the "rel" parameter as
described in Section 4.3: described in Section 4.3:
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=acct%3Acarol%40example.com& resource=acct%3Acarol%40example.com&
rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
HTTP/1.1 HTTP/1.1
Host: example.com Host: example.com
The server might respond like this: The server might respond 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
{ {
"subject" : "acct:carol@example.com", "subject" : "acct:carol@example.com",
skipping to change at page 6, line 23 skipping to change at page 6, line 23
{ {
"rel" : "http://openid.net/specs/connect/1.0/issuer", "rel" : "http://openid.net/specs/connect/1.0/issuer",
"href" : "https://openid.example.com" "href" : "https://openid.example.com"
} }
] ]
} }
Since the "rel" parameter only serves to filter the link relations Since the "rel" parameter only serves to filter the link relations
returned by the resource, other name/value pairs in the response, returned by the resource, other name/value pairs in the response,
including any aliases or properties, would be returned. Also, since including any aliases or properties, would be returned. Also, since
support for the "rel" parameter is OPTIONAL, the client must not support for the "rel" parameter is not guaranteed, the client must
assume the "links" array will contain only the requested link not assume the "links" array will contain only the requested link
relation. relation.
3.3. Auto-Configuration of Email Clients 3.3. Auto-Configuration of Email Clients
WebFinger could be used to auto-provision an email client with basic WebFinger could be used to auto-provision an email client with basic
configuration data. Suppose that sue@example.com wants to configure configuration data. Suppose that sue@example.com wants to configure
her email client. Her email client might issue the following query: her email client. Her email client might issue the following query:
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=mailto%3Asue%40example.com HTTP/1.1 resource=mailto%3Asue%40example.com HTTP/1.1
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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 the printer for toner levels.
4. WebFinger Protocol 4. WebFinger Protocol
A WebFinger resource is a well-known URI [3] using the HTTPS scheme. A WebFinger resource is a well-known URI [3] using the HTTPS scheme.
WebFinger resources MUST NOT be served with any other URI scheme WebFinger resources MUST NOT be served with any other URI scheme
(such as HTTP). (such as HTTP).
GET requests to a WebFinger resource convey the URI to perform the A WebFinger resource is always given a query target, which is another
query upon in the URI's query string; see Section 4.1 for details. URI that identifies the entity whose information is sought. GET
requests to a WebFinger resource convey the query target in the
"resource" parameter in the WebFinger URI's query string; see Section
4.1 for details.
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 a WebFinger Request URI
This specification defines parameters that can be passed from the This specification defines parameters that can be passed from the
client to the WebFinger resource when issuing a request. These client to the WebFinger resource when issuing a request. These
parameters, "resource" and "rel", and the parameter values are parameters, "resource" and "rel", and the parameter values are
included in the query component of the URI (see Section 3.4 of RFC included in the query component of the URI (see Section 3.4 of RFC
3986). To construct the query component, the client performs the 3986). To construct the query component, the client performs the
following steps. First, each parameter value is percent-encoded, as following steps. First, each parameter value is percent-encoded, as
per Section 2.1 of RFC 3986, so that it conforms to the query per Section 2.1 of RFC 3986. The encoding is done to conform to the
production in Section 3.4 of that specification, and additionally any query production in Section 3.4 of that specification, with the
instances of the "=" and "&" characters are also percent-encoded. addition that any instances of the "=" and "&" characters within the
Next, the client constructs a string to be placed in the query parameter values are also percent-encoded. Next, the client
component by concatenating the name of the first parameter together constructs a string to be placed in the query component by
with an equal sign ("=") and the percent-encoded parameter value. concatenating the name of the first parameter together with an equal
For any subsequent parameters, the client appends an ampersand ("&") sign ("=") and the percent-encoded parameter value. For any
to the string, the name of the next parameter, an equal sign, and the subsequent parameters, the client appends an ampersand ("&") to 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 is unspecified. attribute-and-value pair within the query component does not matter
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 to the well-known [3] resource
identified by the URI whose path component begins with "/.well- identified by the URI whose path component begins with "/.well-
known/webfinger" and whose query component MUST include the 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].
skipping to change at page 9, line 27 skipping to change at page 9, line 32
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
the WebFinger request using HTTP over a non-secure connection. the WebFinger request using HTTP over a non-secure connection.
A WebFinger resource MUST return a JRD as the representation for the A WebFinger resource MUST return a JRD as the representation for the
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, though no other header to indicate a desired representation; representations other
representation than JRD is defined in this specification. The media than JRD might be defined in future specifications. The WebFinger
type used for the JSON Resource Descriptor (JRD) is resource MUST silently ignore any requested representations that it
"application/jrd+json" (see Section 9.2). does not understand and support. The media type used for the JSON
Resource Descriptor (JRD) is "application/jrd+json" (see Section
9.2).
A WebFinger resource MAY redirect the client, but MUST only redirect A WebFinger resource MAY redirect the client; if it does, the
the client to an HTTPS URI. redirection MUST only be to an "https" URI.
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.
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, only the link relations parameter. When the "rel" parameter is used and accepted, only the
that match the link relations provided via the "rel" parameter are link relation types that match the link relation types provided via
included in the array of links returned in the JRD. All other the "rel" parameter are included in the array of links returned in
information present in a resource descriptor remains present, even the JRD. If there are no matching link relation types defined for
when "rel" is employed. the resource, the "links" array in the JRD will either be absent or
empty. All other information present in a resource descriptor
remains present, even when "rel" is employed.
The "rel" parameter MAY be transmitted to the WebFinger resource The "rel" parameter MAY be included multiple times in order to
multiple times in order to request multiple types of link relations. request multiple link relation types.
The purpose of the "rel" parameter is to return a subset of "link The purpose of the "rel" parameter is to return a subset of "link
relation objects" (see Section 4.4.4) that would otherwise be relation objects" (see Section 4.4.4) that would otherwise be
returned in the resource descriptor. Use of the parameter might returned in the resource descriptor. Use of the parameter might
reduce processing requirements on either the client or server, and it reduce processing requirements on either the client or server, and it
might also reduce the bandwidth required to convey the partial might also reduce the bandwidth required to convey the partial
resource descriptor, especially if there are numerous link relation resource descriptor, especially if there are numerous link relation
values to convey for a given "resource" value. values to convey for a given "resource" value.
WebFinger resources SHOULD support the "rel" parameter. If the WebFinger resources SHOULD support the "rel" parameter. If the
skipping to change at page 11, line 13 skipping to change at page 11, line 23
"rel" : "http://webfinger.example/rel/businesscard", "rel" : "http://webfinger.example/rel/businesscard",
"href" : "http://www.example.com/~bob/bob.vcf" "href" : "http://www.example.com/~bob/bob.vcf"
} }
] ]
} }
As you can see in the response, the resource representation contains As you can see in the response, the resource representation contains
only the link relations requested by the client, but the other parts only the link relations requested by the client, but the other parts
of the JRD are still present. of the JRD are still present.
In the event that a client requests link relation types that are not
defined for the specified "resource", a resource descriptor MUST be
returned. In the returned JRD, the "links" array MAY be absent,
empty, or contain only links that did match a provided "rel" value.
4.4. The JSON Resource Descriptor (JRD) 4.4. The JSON Resource Descriptor (JRD)
The JSON Resource Descriptor (JRD), originally introduced in RFC 6415 The JSON Resource Descriptor (JRD), originally introduced in RFC 6415
[19] and based on the Extensible Resource Descriptor (XRD) format [19] and based on the Extensible Resource Descriptor (XRD) format
[20], is a JSON object that is comprised of the following name/value [20], is a JSON object that comprises the following name/value pairs:
pairs:
o subject o subject
o aliases o aliases
o properties o properties
o links o links
The member "subject" is a name/value pair whose value is a string, The member "subject" is a name/value pair whose value is a string,
"aliases" is an array of strings, "properties" is an object comprised "aliases" is an array of strings, "properties" is an object
of name/value pairs whose values are strings, and "links" is an array comprising name/value pairs whose values are strings, and "links" is
of objects that contain link relation information. an array of objects that contain link relation information.
When processing a JRD, the client MUST ignore any unknown member and When processing a JRD, the client MUST ignore any unknown member and
not treat the presence of an unknown member as an error. not treat the presence of an unknown member as an error.
Below, each of these members of the JRD is described in more detail. Below, each of these members of the JRD is described in more detail.
4.4.1. subject 4.4.1. subject
The value of the "subject" member is a URI that identifies the entity The value of the "subject" member is a URI that identifies the entity
that the JRD describes. that the JRD describes.
skipping to change at page 12, line 15 skipping to change at page 12, line 17
4.4.2. aliases 4.4.2. aliases
The "aliases" array is an array of zero or more URI strings that The "aliases" array is an array of zero or more URI strings that
identify the same entity as the "subject" URI. Each URI must be an identify the same entity as the "subject" URI. Each URI must be an
absolute URI. absolute URI.
The "aliases" array is OPTIONAL in the JRD. The "aliases" array is OPTIONAL in the JRD.
4.4.3. properties 4.4.3. properties
The "properties" object is comprised of zero or more name/value pairs The "properties" object comprises zero or more name/value pairs whose
whose names are absolute URIs and whose values are strings or null. names are absolute URIs and whose values are strings or null.
Properties are used to convey additional information about the Properties are used to convey additional information about the
subject of the JRD. As an example, consider this use of subject of the JRD. As an example, consider this use of
"properties": "properties":
"properties" : { "http://webfinger.example/ns/name" : "Bob Smith" } "properties" : { "http://webfinger.example/ns/name" : "Bob Smith" }
The "properties" member is OPTIONAL in the JRD. The "properties" member is OPTIONAL in the JRD.
4.4.4. links 4.4.4. links
skipping to change at page 13, line 40 skipping to change at page 13, line 44
4.4.4.3. href 4.4.4.3. href
The value of the "href" member is a string that contains a URI The value of the "href" member is a string that contains a URI
pointing to the target resource. pointing to the target resource.
The "href" member is OPTIONAL in the link relation object. The "href" member is OPTIONAL in the link relation object.
4.4.4.4. titles 4.4.4.4. titles
The "titles" object is comprised of zero or more name/value pairs The "titles" object comprises zero or more name/value pairs whose
whose name is a language tag [13] or the string "default". The name is a language tag [13] or the string "default". The string is
string is human-readable and describes the link relation. More than human-readable and describes the link relation. More than one title
one title for the link relation MAY be provided for the benefit of for the link relation MAY be provided for the benefit of users who
users who utilize the link relation and, if used, a language utilize the link relation and, if used, a language identifier SHOULD
identifier SHOULD be duly used as the name. If the language is be duly used as the name. If the language is unknown or unspecified,
unknown or unspecified, then the name is "default". then the name is "default".
A JRD SHOULD NOT include more than one title identified with the same A JRD SHOULD NOT include more than one title identified with the same
language tag (or "default") within the link relation object. Meaning language tag (or "default") within the link relation object. Meaning
is undefined if a link relation object includes more than one title is undefined if a link relation object includes more than one title
named with the same language tag (or "default"), though this MUST NOT named with the same language tag (or "default"), though this MUST NOT
be treated as an error. A client MAY select whichever title or be treated as an error. A client MAY select whichever title or
titles it wishes to utilize. titles it wishes to utilize.
Here is an example of the titles object: Here is an example of the titles object:
"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"
} }
The "titles" member is OPTIONAL in the link relation object. The "titles" member is OPTIONAL in the link relation object.
4.4.4.5. properties 4.4.4.5. properties
The "properties" object within the link relation object is comprised The "properties" object within the link relation object comprises
of zero or more name/value pairs whose names are absolute URIs and zero or more name/value pairs whose names are absolute URIs and whose
whose values are strings or null. Properties are used to convey values are strings or null. Properties are used to convey additional
additional information about the link relation. As an example, information about the link relation. As an example, consider this
consider this use of "properties": use of "properties":
"properties" : { "http://webfinger.example/mail/port" : "993" } "properties" : { "http://webfinger.example/mail/port" : "993" }
The "properties" member is OPTIONAL in the link relation object. The "properties" member is OPTIONAL in the link relation object.
4.5. WebFinger and URIs 4.5. WebFinger and URIs
WebFinger requests can include a "resource" parameter (see Section WebFinger requests include a "resource" parameter (see Section 4.1)
4.1) specifying the URI of an account, device, or other entity. specifying the URI of an account, device, or other entity. WebFinger
WebFinger is neutral regarding the scheme of such a URI: it could be is neutral regarding the scheme of such a URI: it could be an "acct"
an "acct" URI [7], an "http" or "https" URI, a "mailto" URI [21], or URI [7], an "http" or "https" URI, a "mailto" URI [21], or some other
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 an account accessible via WebFinger. Further,
the "acct" URI scheme is not associated with other protocols as, by the "acct" URI scheme is not associated with other protocols as, by
way of example, the "mailto" URI scheme is associated with email. way of example, the "mailto" URI scheme is associated with email.
Since not every host offers email service, using the "mailto" URI Since not every host offers email service, using the "mailto" URI
scheme is not ideal for identifying user accounts on all hosts. That scheme is not ideal for identifying user accounts on all hosts. That
said, use of the "mailto" URI scheme would be ideal for use with said, use of the "mailto" URI scheme would be ideal for use with
WebFinger to discover mail server configuration information for a WebFinger to discover mail server configuration information for a
user. user.
5. Cross-Origin Resource Sharing (CORS) 5. Cross-Origin Resource Sharing (CORS)
skipping to change at page 15, line 21 skipping to change at page 15, line 27
There are cases where defaulting to the least restrictive setting is There are cases where defaulting to the least restrictive setting is
not appropriate, for example a server on an intranet that provides not appropriate, for example a server on an intranet that provides
sensitive company information SHOULD NOT allow CORS requests from any sensitive company information SHOULD NOT allow CORS requests from any
domain, as that could allow leaking of that sensitive information. A domain, as that could allow leaking of that sensitive information. A
server that wishes to restrict access to information from external server that wishes to restrict access to information from external
entities SHOULD use a more restrictive Access-Control-Allow-Origin entities SHOULD use a more restrictive Access-Control-Allow-Origin
header. header.
6. Access Control 6. Access Control
As with all web resources, access to the WebFinger resource MAY As with all web resources, access to the WebFinger resource could
require authentication. Further, failure to provide required require authentication. Further, failure to provide required
credentials MAY result in the server forbidding access or providing a credentials might result in the server forbidding access or providing
different response than had the client authenticated with the server. a different response than had the client authenticated with the
server.
Likewise, a WebFinger resource MAY provide different responses to Likewise, a WebFinger resource MAY provide different responses to
different clients based on other factors, such as whether the client different clients based on other factors, such as whether the client
is inside or outside a corporate network. As a concrete example, a is inside or outside a corporate network. As a concrete example, a
query performed on the internal corporate network might return link query performed on the internal corporate network might return link
relations to employee pictures, whereas link relations for employee relations to employee pictures, whereas link relations for employee
pictures might not be provided to external entities. pictures might not be provided to external entities.
Further, link relations provided in a WebFinger resource Further, link relations provided in a WebFinger resource
representation MAY point to web resources that impose access representation might point to web resources that impose access
restrictions. For example, the aforementioned corporate server may restrictions. For example, the aforementioned corporate server may
provide both internal and external entities with URIs to employee provide both internal and external entities with URIs to employee
pictures, but further authentication might be required in order for pictures, but further authentication might be required in order for
the client to access the picture resources if the request comes from the client to access the picture resources if the request comes from
outside the corporate network. outside the corporate network.
The decisions made with respect to what set of link relations a The decisions made with respect to what set of link relations a
WebFinger resource provides to one client versus another and what WebFinger resource provides to one client versus another and what
resources require further authentication, as well as the specific resources require further authentication, as well as the specific
authentication mechanisms employed, are outside the scope of this authentication mechanisms employed, are outside the scope of this
skipping to change at page 16, line 36 skipping to change at page 16, line 43
GET /.well-known/webfinger? GET /.well-known/webfinger?
resource=acct%3Aalice%40example.com HTTP/1.1 resource=acct%3Aalice%40example.com HTTP/1.1
Host: example.com Host: example.com
The server might respond with this: The server might respond with this:
HTTP/1.1 307 Temporary Redirect HTTP/1.1 307 Temporary Redirect
Access-Control-Allow-Origin: * Access-Control-Allow-Origin: *
Location: https://wf.example.net/example.com/webfinger? Location: https://wf.example.net/example.com/webfinger?
resource=acct%3Aalice%40example.com HTTP/1.1 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
Since this specification utilizes Cross-Origin Resource Sharing Since this specification utilizes Cross-Origin Resource Sharing
skipping to change at page 20, line 49 skipping to change at page 21, line 9
Object Notation (JSON)", RFC 4627, July 2006. Object Notation (JSON)", RFC 4627, July 2006.
[6] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform [6] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[7] Duerst, M., "Internationalized Resource Identifiers (IRIs)", [7] Duerst, M., "Internationalized Resource Identifiers (IRIs)",
RFC 3987, January 2005. RFC 3987, January 2005.
[8] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg- [8] Saint-Andre, P., "The 'acct' URI Scheme", draft-ietf-appsawg-
acct-uri-02, December 2012. acct-uri-03, February 2013.
[9] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS [9] Van Kesteren, A., "Cross-Origin Resource Sharing", W3C CORS
http://www.w3.org/TR/cors/, July 2010. http://www.w3.org/TR/cors/, July 2010.
[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.
 End of changes. 28 change blocks. 
72 lines changed or deleted 76 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/