draft-ietf-appsawg-webfinger-01.txt   draft-ietf-appsawg-webfinger-02.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: April 19, 2013 Joseph Smarr Expires: April 22, 2013 Joseph Smarr
Google Google
October 19, 2012 October 22, 2012
WebFinger WebFinger
draft-ietf-appsawg-webfinger-01.txt draft-ietf-appsawg-webfinger-02.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 discover number, or preferred avatar. WebFinger may also be used to discover
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 April 19, 2013. This Internet-Draft will expire on April 22, 2013.
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 4, line 13 skipping to change at page 4, line 13
this connection consists of a context IRI, a link relation type, a this connection consists of a context IRI, a link relation type, a
target IRI, and optionally some target attributes, resulting in target IRI, and optionally some target attributes, resulting in
statements of the form "{context IRI} has a {relation type} resource statements of the form "{context IRI} has a {relation type} resource
at {target IRI}, which has {target attributes}". When used in the at {target IRI}, which has {target attributes}". When used in the
Link HTTP header, the context IRI is the IRI of the requested Link HTTP header, the context IRI is the IRI of the requested
resource, the relation type is the value of the "rel" parameter, the resource, the relation type is the value of the "rel" parameter, the
target IRI is URI-Reference contained in the Link header, and the target IRI is URI-Reference contained in the Link header, and the
target attributes are the parameters such as "hreflang", "media", target attributes are the parameters such as "hreflang", "media",
"title", "title*", "type", and any other link-extension parameters. "title", "title*", "type", and any other link-extension parameters.
Thus the framework for WebFinger consists of several building blocks: The framework for WebFinger consists of several building blocks:
1. To query the host, one requests a web host metadata document 1. To query the host, one requests a web host metadata document
located at the well-known URI /.well-known/host-meta or /.well- located at the well-known URI /.well-known/host-meta or /.well-
known/host-meta.json (referred to as the host-meta resources) at known/host-meta.json (referred to as the host-meta resources) at
the host. the host.
2. The web server at the host returns a JavaScript Object Notation 2. The web server at the host returns a JavaScript Object Notation
(JSON) [5] Resource Descriptor (JRD) or an Extensible Resource (JSON) [5] Resource Descriptor (JRD) or an Extensible Resource
Descriptor (XRD) [10] document, including a Link-based Resource Descriptor (XRD) [10] document, including a Link-based Resource
Descriptor Document (LRDD) link relation. Descriptor Document (LRDD) link relation.
3. To discover information about accounts, devices, or other entities 3. To discover information about accounts, devices, or other entities
skipping to change at page 10, line 36 skipping to change at page 10, line 36
5.2. The Web Host Metadata "resource" Parameter 5.2. The Web Host Metadata "resource" Parameter
In addition to the traditional processing logic for processing host In addition to the traditional 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
response. This parameter essentially pushes the work to the server response. This parameter essentially pushes the work to the server
to form a complete resource descriptor for the specified resource. to 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. 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 MUST check the server response to ensure that the WebFinger clients MUST check the server response to ensure that 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.json (RECOMMENDED) or issues a request to /.well-known/host-meta.json (RECOMMENDED) or
/.well-known/host-meta as usual, but then appends a "resource" /.well-known/host-meta as usual, but then appends a "resource"
parameter as shown in this example: parameter as shown in this example:
skipping to change at page 11, line 17 skipping to change at page 11, line 17
* Set the "Subject" returned in the response to the value of the * Set the "Subject" returned in the response to the value of the
"resource" parameter if the URI provided in the resource "resource" parameter if the URI provided in the resource
parameter is known to the server; and parameter is known to the server; and
* Collect and expand all resource-specific link relations, * Collect and expand all resource-specific link relations,
including those returned by querying for any LRDD link including those returned by querying for any LRDD link
relations, discard any host-wide link relations, and return a relations, discard any host-wide link relations, and return a
complete resource descriptor following the processing rules in complete resource descriptor following the processing rules in
Section 4.2 of RFC 6415; and Section 4.2 of RFC 6415; and
The WebFinger server MUST NOT issue HTTP queries for any link It is not the responsibility of the WebFinger server to verify, for
relations other than LRDD link relations. It is not the example, that a URI pointing to a person's avatar is a valid URI. If
responsibility of the WebFinger server to verify, for example, that a the WebFinger server needs to query an LRDD resource to collect
URI pointing to a person's avatar is a valid URI. When querying an additional resource-specific information, any errors (e.g., 500 or
LRDD resource to collect additional resource-specific information, 404) MUST be ignored by the server. When a request for an LRDD
any errors (e.g., 500 or 404) MUST be ignored by the server. When a fails, the server MUST NOT attempt to augment missing resource
request for an LRDD fails, the server MUST NOT attempt to augment information or return a "template" type link relation to a client
missing resource information or return a "template" type link that utilizes the "resource" parameter. Note that a WebFinger server
relation to a client that utilizes the "resource" parameter. might be implemented such that all LRDD resource-specific information
can be resolved without issuing HTTP requests. How a WebFinger
server collects and expands such resource-specific link relations is
an implementation matter.
The WebFinger client MUST verify support for the "resource" parameter The WebFinger client MUST verify support for the "resource" parameter
by checking the value of the Subject returned in the response. If by checking the value of the Subject returned in the response. If
the Subject matches the value of the "resource" parameter, then the the Subject matches the value of the "resource" parameter, then the
"resource" parameter is supported by the server. The Subject would "resource" parameter is supported by the server. The Subject would
be absent if the "resource" parameter is not supported. be absent if the "resource" parameter is not supported.
For illustrative purposes, the following is an example usage of the For illustrative purposes, the following is an example usage of the
"resource" parameter that aligns with the example in Section 1.1.1 of "resource" parameter that aligns with the example in Section 1.1.1 of
RFC 6415. The WebFinger client would issue this request: RFC 6415. The WebFinger client would issue this request:
 End of changes. 7 change blocks. 
16 lines changed or deleted 18 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/