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: