Mozilla aims to simplify account registration and authentication on the Web with a new technology called BrowserID. It is a decentralized authentication system allows the Web browser to manage the user's identity.

The system relies on asymmetric keys and ties the user's identity to their e-mail address rather than conventional usernames and passwords. The browser handles the authentication process for the user, enabling relatively secure single-click logins on websites that support the scheme.

The login flow is relatively straightforward. The user navigates to the website of their identity authority provider and logs in conventionally. The authority provider website calls a browser JavaScript API that generates a key pair. The browser sends the public key to the identity provider and gets back a signed identity certificate. The browser will then store the private key and certificate in its secure keyring.

When a website wants a user's identity, it calls a JavaScript function that will cause the browser to initiate the authentication process. The browser will prompt the user to determine which identity to use and whether to log in at all. If the user agrees, the browser will send the requesting website an identity certificate signed with the user's private key. The website then obtains the user's public key from the identity provider and uses it verify the authenticity of the provided identity information.

The authentication process is largely transparent to the end user. All you will have to do is click a user interface element in the browser to approve the login. BrowserID conceptually similar to OpenID in a lot of ways, but without the usability problems and some of the other pain points.

Of course, the authentication process described above makes several assumptions: the user's browser implements the relevant JavaScript APIs, the website that the user wants to sign into supports the service and handles the verification step on its own, and the user's e-mail host serves as an identity provider. That's obviously the ideal scenario, but the protocol supports some other variations on the authentication process that will simplify a few of the challenges.

If the user's e-mail host doesn't act as an identity authority, it's possible to use a trusted secondary identity authority that does the job. In the absence of native BrowserID support in the user's Web browser, it's also possible to use an implementation hosted on a website. It's also worth noting that the actual process of verifying the identity can be performed by a trusted third-party, thus vastly reducing the amount of effort involved for Web application developers to support BrowserID logins.

Mozilla has set up a website called BrowserID.org that supplies these services. This will make it possible to start testing and implementing BrowserID right away without having to wait for adoption by e-mail providers and other browser vendors.

The concept is pretty good, but there are still some unanswered questions. It's unclear if major e-mail hosts and browser vendors are going to be interested in supporting the system. The specifications are still being finalized, so the effort to encourage adoption is obviously still at a very early stage. It's also not entirely clear yet what steps e-mail hosts will have to take to support BrowserID. It's generally understood that they will have to host public keys and make them accesible in a standardized way, but how exactly that will work hasn't been specified yet.

Another question is how BrowserID authentication will be handled in native desktop and mobile client applications outside of the Web browser. Individual applications may need to operate as BrowserID user agents and have their own internal implementation of the protocol. The application would provide an embedded browser window in which the user would log into their identity authority account so that the app can get the keys.

That will get really complicated and sort of ugly, but the problem could eventually be solved better by having the underlying operating system itself implement BrowserID and store the keys in a central keyring. There could be platform-level APIs for developers that allow a third-party client application to log into Web services with identities from the system keyring. The process could be mediated by the operating system so that the user has the opportunity to select an account or deny the login. The mobile platform vendors could probably do it without much trouble, but it will likely take more time for this to be supported on the desktop.

You can get more information about the protocol by visiting BrowserID.org or Mozilla's new identity website.