Belay Flows

Belay Flow Diagrams

v1: October 25, 2011


This document describes the basic flows in the various Belay operations. Currently, most of these are implemented in the Belay demo, though not always in the exact form shown here. (Multiple stations and kiosk mode are not implemented.) This is an early draft and work in progress.

1. Basic Setup
Any time a Belay enabled page starts, it includes an iframe from the trusted Belay domain (belay-belay.org in the example). That iframe in turn establishes communication with all other iframes from Belay. The current prototype uses an HTML5 shared web worker. On older browsers we can use various other mechanisms to get this shared communication entirely within the browser.
Note: When we talk about pages communicating with Belay, we mean communication, via the iframe to this shared communication substrate. Such communication never leaves the client. The Belay domain's web site never sees any communication after serving the initial javascript.

2. Station Registration

When the user first creates a station or logs in to their station provider, the station needs to register itself with Belay in the browser. The first time this registration requires confirmation, as the station will learn all of the user's new web accounts. Belay can remember this confirmation via local storage for the local browser.

.3. Instance Creation
When a web site has decided to create an account for the user (we call this an instance), then it advises Belay of its creation. Belay, in turn, tells the station about it. In this way, the web sites don't need to know the list of possible stations, nor make the user make a choice before creating an account.
The instance is represented by a BCAP URL - which is a URL that is unguessable. Typically it is a large random number, and the web site's server's database maps that number to the particular account objects in the database. A nice consequence of this is that the user of such a URL can't tamper with the identities of the objects involved as they could with URL parameters.

4. Launch

When the user clicks on an entry in the station, the station "launches" the account. This path involves invoking the BCAP (just an XHR request), and getting information for how to start the new page. This information includes both the URL for the basic HTML of the account page, and blob of JSON that contains the account specific information. (Typically, this consists of more BCAP URLs back to the web site's servers.)

5. Suggestions

It is much more common for users to navigate directly to the top level page of web site and expect to get back to their account. To facilitate this, Belay supports securely showing suggested accounts with a web site that the user already has. This must be done in a way to not reveal new web sites to the station that user is navigating too.
The station declares to Belay which sites it has entries for. If the user navigates to a Belay enabled site, if Belay was told about that site by the station, then Belay asks the station for suggestions.
Then, Belay shows the suggestions to the user (via the "butter bar"). If the user picks one, then Belay asks the station to launch it back into the same window. Notice that the web site doesn't learn what entries the user has for it.

.6. Multiple Stations

Because web sites aren't constrained to authenticate against a single user provider, the user can actually have multiple provders open at once. In this example, the user might sign in to a service that stores all web accounts in a vault for backup and disaster retrieval.
When first added, again, the user must be prompted for confirmation.
Later, when new accounts are created, both stations are told.


7. Kiosk Mode
When the user is using their station from a less trusted system, the station can use a Belay technique called "wrapping" to ensure that the launch URLs aren't sent directly to the less trusted system. These URLs point directly back to the station's web server, and can be short lived.
When launching, the station's call to the launch URL is proxied via the station's web site, which retains the valuable true launch URL.
At this point in the flow, the station server could inject additional security features such as asking for OTPs, or sending SMS messages on use.

8. Attributes
Web sites desiring more information about the user can provide the station, via the launch process, a URL where the station can send attribute information (such as name, e-mail, account info, etc.., including possible attestations). The user can then easily audit and control what information the web site receives via the station, where the user is already keeping track of it.
Although attributes are technically all optional, nothing stops the web site from providing only limited, or non-functional access until the user supplies what it needs. Belay facilities this because the station provides the web site, on launch with a BCAP for requesting the user approve access:
We believe that this form of attribute exchange enables a wide variety of methods for improving the user experience. For example, web sites could be marked with a profile, like "game", "blog", "social", "financial". These marks could be self-proclaimed and/or via reputation. Then stations could provide substantial help to users in picking the right set of information to disclose.
Comments