To be successful as a decentralized, easy-to-use authentication system, BrowserID needs help from three different groups.
- Web sites (Relying Parties): need to let their users sign in with BrowserID
- Web browsers: need to implement the BrowserID
- Email providers: need to act as identity providers
But there's a chicken-and-egg problem here: none of these groups will support BrowserID unless it has a critical mass of users, but it can't get a critical mass of users without support from them all.
To solve this we've set up https://browserid.org, which hosts three services:
- a fallback identity provider
- a portable implementation of the
- a remote verification service
Together, these services enable web sites to offer BrowserID without web browsers needing to change or email providers needing to get involved.
All three of these services are temporary, and will become less relevant as BrowserID implementations mature. Eventually we will be able to remove them entirely, and at that point https://browserid.org won't feature at all in the BrowserID system.
Fallback identity provider
In BrowserID anyone can act as an identity provider, as long as relying parties are willing to trust their certificates. Usually, though, we expect the user's email provider to act as an identity provider for the emails it administers. This makes the user experience of BrowserID much better, because it means that users don't need a separate password, to go through a separate sign-up step, or to bring a new party into the picture. Instead, the user can leverage their existing relationship with the email provider.
In the past we've called these types of providers primary identity providers, although we've now deprecated that terminology.
But until enough web sites support BrowserID, email providers won't offer identity provisioning. So we've set up our own identity provider at https://browserid.org to bridge that gap, and enable web sites to sign users in using their existing email address, whether or not the email provider supports BrowserID. This provider will certify email addresses from any domain, using its own authentication flow and its own password. This is what we used to call a secondary identity provider, but we now call it a fallback identity provider.
Once an email provider supports BrowserID, its users won't need to use our provider any more any more.
Implementation of navigator.id in include.js
For BrowserID to work, the user's browser has to support the navigator.id APIs. Eventually we expect browsers to add native support for these APIs, but until then we've provided an implementation of them in include.js. Just by including this file, web sites can use the BrowserID APIs in all modern browsers.
Remote verification service
At https://browserid.org we host a remote verification service that web sites can use to verify assertions sent from users. This makes it simpler for web sites to integrate BrowserID, as it takes care of parsing the assertion and verifying signatures and certificates.
Eventually we expect verification to be done locally, on the web site's server. This is an important step, as it will make it impossible for identity providers to track users.