User:Infinity Linden/OGP Client Side Capabilities
Capabilities are pre-authorized URLs a network host may give to a trusted peer to access a sensitive resource. The Open Grid Protocol (OGP) makes extensive use of capabilities in preference to authentication token to avoid the Confused Deputy Problem and to support the decoupling of deployment from design. Information about capabilities in OGP may be found in An Inquiry into the Nature and Causes of Web Capabilities and Section 2.3 of the OGP Foundations draft.
As traditionally defined and deployed, capabilities exist exclusively on "server" hosts (i.e. - a host with a routable IP address that provides a service.) Use cases have emerged demonstrating the utility of "client capabilities" where a capability exists on "client" host that may be behind a NATted firewall (i.e. - it doesn't have a routable IP address.) This document provides a narrative intended to describe the problem domain and offer some solutions.
Client Side Capabilities With HTTP
Figure 1 shows a very simple solution to the problem of exposing capabilities. It also shows the main use case for capabilities. In this flow, the client application wishes to expose a sensitive resource to the a server with which it has established a trust relationship, named "Server 1" in the illustration. The capability can then be used by Server 1 to access the client application or it can be given to Server 2 (which is what this diagram illustrates.)
So the sequence illustrated here is:
Step 1: The Client Application (on host client1.example.org) creates a capability to represent Resource 1. It begins accepting TCP connection requests itself (say on port 12001) over which it will speak HTTP. When a peer requests the capability, the client will respond with the resource (let's say the path component of the capability is "/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855".) The client gives the server the capability http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 by POSTing or PUTting it to Resource 2 on Server 1. (and yes, this should probably all go over HTTPS, but we'll talk about that later.)
Step 2: Server 1 decides it needs to defer access to Server 2, a trusted peer. It provides the client capability to Server 2, likely by POSTing or PUTting it to Resource 3.
Step 3: At some point in the future, the process implementing Resource 3 needs to access Resource 1, which it does simply by accessing the cap http://client1.example.org/c/3FF69C95-CCF3-4A1B-94C4-80202E85C855 .
Problems with Client Side Capabilities With HTTP
But there are two major deficiencies with this scheme: 1. NATted firewalls make it hard for the client to respond to inbound TCP connection requests and 2. What do you do if the client side capability expires?