User Authorization

The most common way for web sites to establish a user relationship is to create an account with a password. We can liken this to a user walking into a store and handing the store an calling card with a password scribbled on the back. The problems with this approach are well known, primarily hinging on the fact that users will reuse poor passwords with numerous sites, reducing the user's security to the security of the weakest. (Only takes one storing the passwords in the clear to get hacked...)

An alternative method is "federated login", such as OpenID. Here, a web site essentially "outsources" account names and authentication to a 3rd party, the identity provider (IDP). To continue our analogy, this is like the user showing some form of identification, like a drivers license or passport to the store (so long as it is from a state or country that the store is willing to accept and validate). While the users probably uses an account name and password with the IDP, hopefully it is stronger, and not used with other accounts. The downsides here are that a) the web site must decide, a priori, which IDPs to accept, b) the user must divulge some account information to the web site, and c) the user cannot move their identity to another IDP, because all their web stie relationships are predicated on the particular one.

Belay takes a different approach: When the web site wants to create an account for the user, it simply creates an account credential (serving as both account name and password), and delivers it to the user's browser, which in turn stores it wherever the user has designated such credentials are to be stored. In our store analogy, the store hands you a curtesy card, and you place it in your wallet.

The Belay approach offers a much wider range of use than traditional accounts because they are so light weight:
  • A site could require some information, and then offer an account. This is like giving money to the museum, and then they give you a membership card that gets you in for a year without having to show any other ID.
  • A site could require certification, such as an IDP login, before issuing an account, and then periodically check to ensure it is still valid. This is like the library requiring to see your utility bill before issuing a library card.
  • A site can offer credentials for things less heavy weight than an account: A shared travel planning page, a shared photo album, a book club meeting room, etc.
  • A site is free to ask for or require additional information at times after the initial account creation. Current federated identity schemes require this information be asked for at the start. In contrast, a web site with Belay can start an account for a user, with no "approval page", and only later, after gaining the user's trust, ask for more.
The key to making the Belay approach work, is having a place where the credentials are stored (called the station), and ensuring that the user is minimally involved in having to manage these credentials. The Belay project has implemented a fully functional station, storing users' credentials in the cloud, keyed off the user's strongly authenticated Google+ or OpenID or e-mail accounts. We expect to have it deployed for experimental use Q2 2012.