When one web application wants to allow another web application to perform some operation, some form of cross-application authorization must take place. This includes scenarios such as when a user wants a game to be able to post high scores on their web site, allow a site to track what music they listen to, supply profile data from an social account to another web site.
In the standard model of web APIs, based on cookies, operations are authenticated by the presence, from the browser, of the user's session cookie. But when one site is interacting with another, this cookie isn't present. The normal solution is to invent a cookie substitute: A token that enables one site to operate on another, on behalf of a given user of that other site. Typically these tokens are scoped to a limited set of functions.
In Belay an application can grant a BCAP URL that is bound to a specific handler, and to specific application data. Possession of this URL allows the holder to invoke the operation. The BCAP URL is similar to the token, but improves on it in several ways:
- It is very easy to bind the BCAP URL to a specific piece of data. Thus users can authorize specific access to specific data ("This folder of photos, and no others."). This is very difficult to do in current application-to-application authorization protocols due to the predefined nature of operation scopes.
- BCAP URLs can never be used with the wrong API, since the handler is bound to the URL. This makes for simpler server code that is more secure.
- BCAP URLs can be wrapped by an intermediate service, which can then control their use. This can be done transparently to the final client application.
- Client applications don't have to know a priori the providing sites of such services. The Belay system includes a mechanism for finding possible providers.
- Belay enables many forms of direct manipulation user experience, whether through drag-n-drop, cut-n-paste, or pop-up menus. These enable the user to both specify what they want to do, and authorize it implicitly with one UI action. Other authorization mechanisms require a intersticial approval page.
- The looser coupling of client and provider applications makes it easier to create and deploy new services, as well as evolve standard services, all with the same security.