draft-webfinger-auth-reverse-lookup.txtDescription: Text document
|
| From: | Blaine Cook |
| Subject: | [Social] Privacy-over-Webfinger Draft |
| Date: | Wed, 14 Jul 2010 02:34:17 +0100 |
Attached is a[n early] and long-promised draft of a relatively insecure but easy-to-implement approach to decentralized authorization using webfinger. Feedback is most welcome, especially in the lead-up to the Federated Social Web summit in Portland this weekend. For those concerned about security, don't despair, crypto can be layered on like maple syrup at a sugar shack. :-) b.
draft-webfinger-auth-reverse-lookup.txt
Description: Text document
| TOC |
|
This specification describes one potential flow for asynchronously establishing an authenticated link between two parties, relying only on Webfinger profiles. This approach forgoes public key cryptography, instead opting for an HTTP-based exchange of shared secrets.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on January 15, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Authors
2.
Introduction
3.
Terminology
4.
Overview
4.1.
Authorization Request
4.2.
Accessing Content
5.
Access Request
5.1.
Initiating the Access Request
5.1.1.
User Requests Access
5.1.2.
Client Sends Access Request
5.2.
Request Verification
5.2.1.
Authenticate Client
5.2.2.
Verify That Client is Authorized to Act On Behalf Of User
5.3.
Request Approval
5.4.
Access Notification
6.
Accessing Protected Content
6.1.
Subscription-based Content
6.2.
Requesting Content via HTTP
7.
Security Considerations
§
Author's Address
| TOC |
This specification was authored by Blaine Cook.
| TOC |
Consuming public data across web domains is trivial, and widely done. Consuming private data across domains, however, is extremely difficult. To date, only two modes of private data exchange have succeeded in the wild:
However, both approaches have significant constraints.
The former assumes that all "users" exist within the bounds of the site. Any users who do not have or want an account with the site are unable to participate in the exchange of private data. The latter is generally only useful for a single individual to move their own data (or data to which they already have access) from one context to another.
Neither of these scenarios address the sort of data exchange that is needed in order to precipitate a decentralized model of social networks on the web. Viable approaches exist using non-HTTP technologies, such as XMPP. This specification provides a mechanism for exchanging private data between individuals and services using HTTP alone.
| TOC |
- reader
- An entity (normally a human) interested in receiving content from the publisher.
- publisher
- An entity (normally a human) producing content for distribution.
- client
- Software comprised of an HTTP Server and Client, acting on behalf of the reader that will obtain and relay incoming content to the reader.
- content server
- An HTTP Server (with access to an HTTP Client) acting on behalf of the publisher that will publish content to authorized clients.
- reader's webfinger server
- A webfinger server that hosts the profile for the reader.
- publisher's webfinger server
- A webfinger server that hosts the profile for the publisher.
| TOC |
| TOC |
The reverse proxy approach to authentication using webfinger identities enables the client to asynchronously obtain permission to access protected content from the publisher.
A two-way channel is established by way of the content server and client mutually authenticating. Webfinger is used by the user to delegate authorization to their client, and enables the content server to provide a useful interface for the publisher to allow or deny the ability to access private data to the user.
Note that the process is identical conceptually to the approach used by virtually all web-based social networks to negotiate relationships, with the additional affordances to account for the establishment of relationships across domains.
+----------+
| User |
+----------+
|
(A) Request Data
|
V
+----------+
| | Request +-----------+
| Client |--- (B) -->| | (C) Verify B
| | | Content |
| | | Server | Check for +-------------+
| | | | Delegation | User's |
| | | |--- (D) --->| Webfinger |
| | | | | Server |
| | | | +-------------+
| | | | Ask for
| | | | Permission +-------------+
| | | |--- (E) --->| |
| | | | | Publisher |
| | Confirm | | Grants | |
| | Request | | Permission | |
| |<-- (G) ---| |<-- (F) ----| |
+----------+ +-----------+ +-------------+
| Figure 1 |
The process is described in Figure 1, and involves the following steps:
- (A)
- The User indicates to their Client that they would like to gain access to a resource owned by the Publisher as described in Section 5.1.1 (User Requests Access).
- (B)
- The Client makes a request to the Content Server for access to the resource owned by the Publisher as per Section 5.1.2 (Client Sends Access Request).
- (C)
- The Content Server must verify that the request in question actually originated from the Client. While the precise mechanics of this step are beyond the scope of this specification, possible approaches are detailed in Section 5.2 (Request Verification).
- (D)
- At this point, the request has been authenticated as originating from the Client. The next step is for the Publishing Server to verify that the Client is authorized to act on behalf of the User as per Section 5.2.2 (Verify That Client is Authorized to Act On Behalf Of User).
- (E)
- Having verified that both the request came from the Client, and that the Client is allowed to act on behalf of the User, the Content Server now forwards the request to the Publisher. The mechanics of this step are not standardised, but a number of best-practice possibilities exist and are described in Section 5.3 (Request Approval).
- (F)
- After an indeterminate time period, the Publisher will log into the Content Server and either approve or deny the request.
- (G)
- After the Publisher has approved or denied the request, the Content Server notifies the Client of the outcome. The description in Section 5.4 (Access Notification) is non-normative, but includes a useful description of the considerations that the Publising Server should take into account here.
| TOC |
Once a request has been authorized, protected content may be obtained through any viable mechanism. Normally, though, fresh content should be sent from the Publisher to the Client using PubSubHubbub, or via the Client fetching the content over HTTP. In both scenarios, the Client then passes on the obtained content to the User through the most suitable mechanism available.
In Figure 2, the content is delivered from the Publisher to the Content Server, and then directly to the Client.
+------------+ Content +-----------------+
| Publisher |-- (A) ---->| Content Server |
+------------+ +-----------------+
|
(B) Deliver
| Content
Display V
+------------+ Content +-----------------+
| User |<-- (C) ----| Client |
+------------+ +-----------------+
| Figure 2 |
Alternatively, as Figure 3 details, the process can also be completed using a more traditional HTTP request-response cycle.
+-----------+ Publish Content +----------------+ | Publisher |--- (A) ---------->| Content Server | +-----------+ +----------------+ ... Time Passes ... +-----------+ Fetch Content +----------------+ | Client |<-- (B) ---------->| Content Server | +-----------+ +----------------+ ... Time Passes ... +-----------+ View Content +----------------+ | User |<-- (C) ---------->| Client | +-----------+ +----------------+
| Figure 3 |
| TOC |
The initiation of an access request is the first step in establishing communication between two parties.
The approach described here does not imply anything about the nature of the relationship between the User and the Publisher except that the User is requesting access to some content to which the Publisher has the ability to grant access. This approach is often referred to as "asynchronous follow".
As such, the process described here ends with a one-way communication channel; that is, the User is signalling their desire to receive content from the Publisher. If a two-way channel is desired (i.e., the Publisher would also like to receive content from the User), all that is required is for the same process to be performed but with the roles reversed.
| TOC |
This section describes a mechansim to establish a relationship between the User and Publisher. For an overview of the process, see Section 4.1 (Authorization Request).
| TOC |
The mechanics of this step are beyond the scope of this document, and are better defined by the implementor to match the specific use-case and interface requirements.
The way that this step is normally implemented for subscription-basedis as follows:
In the event that the User already knows the URL of the content that they would like to obtain, the Client can send the Access Request directly to the Publisher (Section 5.1.2 (Client Sends Access Request)). Note that in the absence of a webfinger address for the Publisher, the richness of profile data that the Client will be able to display is limited to the data provided by the URL in question.
Deviation from the above examples will not impede interoperability. Please feel free to experiment; the most important aspect of this step is to provide users with the best experience possible.
| TOC |
The crux of this document is the inclusion of the identity of the requestor in the request for private data. Providing this information is done by including an HTTP From header in the Subscription Request, the value of which is the webfinger address of the requesting party. A minimal request is illustrated in Figure 4.
This is an example of the simplest possible HTTP request that includes the identity of the requestor.
GET /protected HTTP/1.1 Host: example.com From: address@hidden
| Figure 4 |
The specific aspects of the HTTP request used to request the Publisher's private data are out of scope for this specification. Users and Publishers (and by extension, their Client and Content Server) must agree on a security mechanism to ensure that the request may be associated with the User as per Section 5.2 (Request Verification).
| TOC |
| TOC |
The Content Server MUST verify that the HTTP request in question originated from the Client.
There are several possible ways to verify the authenticity of the request, including but not limited to:
- PubSubHubbub
- PubSubHubbub, which includes a mechanism for verifying the Client (Subscriber) based on a callback URL.
- SSL Client Certificates
- verifying either the Client is relatively easy, since domain-level certificates are common and inexpensive.
- Magic Signatures
- these may be obtained from the Client's host-meta document, and offer a simple mechanism for issuing, distributing, and signing host-level certificates.
This specification advocates using PubSubHubbub as the preferred method for subscription-based requests. PubSubHubbub involves verifying the callback URL as the mechanism. The primary alternative would be to use client SSL certificates where the certificate identifies the Client (normally issued Server certifiates can be used as Client certificates for this purpose).
| TOC |
Using the From address provided in Section 5.1.2 (Client Sends Access Request), the Content Server MUST fetch the User's Webfinger profile. The obtained profile is then searched for any Links with a rel value equal to "me" and a href whose domain is equal to the domain of the Client.
<?xml version='1.0' encoding='UTF-8'?> <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'> <Link rel='hub' href='' /> <Link rel='me' href='' /> </XRD>
| Figure 5 |
In Figure 5, the second link implies that the User has delegated access to subscriber.example.com. If the request that was verified in Section 5.2.1 (Authenticate Client) originated from subscriber.example.com, then the Content Server can trust that the request was made on behalf of the User.
If the request in Section 5.2.1 (Authenticate Client) was not made by any of the rel=me servers listed in the User's XRD, then the Content Server MUST reject the request since no valid demonstration of delegation has been made.
| TOC |
This is normally accomplished by the Content Server displaying an approval interface to the Publisher. The interface should include profile details obtained from the User's Webfinger profile, and details pertaining to the specific Client with which the User indends to receive the requested data.
| TOC |
If the publisher denies the request, the Publishing Server MAY notify the Client of the failed request. If the request is approved, the Content Server SHOULD notify the Client of the successful request.
If the access request was for a subscription-based feed, the notification MAY be delivered using the notification mechanism associated with that feed. Without a clear return address, it may be impossible to provide the Client and/or User with a notification. In this event, the Client SHOULD poll periodically to obtain the current status of the request.
| TOC |
| TOC |
Once a subscription-based authorization has been granted, the Content Server SHOULD send all updated content to which the User has access to the Client. The mechanism by which this happens is out of scope for this specification, but requires no additional work.
Clients SHOULD store a reference to the original webfinger address that was used to create the subscription, so that content updates can be associated with the individual that created them (in this case, the Publisher).
| TOC |
When requesting content via HTTP, the Client requests the content exactly as they would in Section 5.1.2 (Client Sends Access Request). If the User identified by the From address has been granted access to the resource, then a valid delegate Client SHOULD be allowed access to that data.
GET /protected HTTP/1.1 Host: example.com From: address@hidden
| Figure 6 |
The request in Figure 6 is insufficient, since the Client has not identified themselves. Refer to Section 5.2.1 (Authenticate Client) for details on how the Client should present host-level identification.
Assuming that the Client has in fact identified themselves properly, though, the Publisher SHOULD verify that the Client still has permission to act as a delegate for the User. Since checking the User's webfinger profile with each request is relatively expensive, and revokation is a relatively infrequent occurance, this SHOULD be done at some reasonable interval. Publishers SHOULD also provide a mechanism by which a User can force a re-check of the validity of the delegation configuration. How that might work is for another spec.
| TOC |
Plenty
| TOC |
| Blaine Cook | |
| BT | |
| Email: | address@hidden |
| URI: | acct:address@hidden |
| [Prev in Thread] | Current Thread | [Next in Thread] |