Kind of. We're suggesting that people link to the javascript shim on Mozilla's servers, while we refine the API, but we hope to support self-hosting by autumn. The entire system is designed to transparently drop away as identity providers and user agents implement native support for the BrowserID protocol, but for now we're supplying a shim implementation for the browsers and are acting as a trusted third party for identity providers.
For how this plays out, imagine the following combinations of native support for the BrowserID protocol:
1) BROWSER AND IDENTITY PROVIDER: Mozilla's services are left completely out of the loop.
2) BROWSER ONLY: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user.
3) IDENTITY PROVIDER ONLY: Mozilla's shim and services step in to provide a surrogate implementation of the BrowserID protocol.
4) NEITHER: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user, and to provide a shimmed implementation of the BrowserID protocol.
Again, the protocol was designed to be distributed from the very start, so nothing is locking it down to using Mozilla's shim and services, but they're there for you if you want to use them.
Disclaimer: I do not currently work for Mozilla, but I will be joining the Identity team later this month.
If it depends on JavaScript, it's still the problem. Mozilla has the browser, why not implement it without JaveScript? There are already more authentication methods which don't require JavaScript.
Yeah, I hear you. Still, for Persona / BrowserID to be successful, it has to support users regardless of browser. Choosing JavaScript means that we can build a solution that works for the whole web.
You should still implement non-js solution in Mozilla immediately to demonstrate how it's going to work once accepted.
js-based auth doesn't work for the whole web. Even for other browsers you have to make a solution where everything server can get the e-mail address without javascript on the client.
And you should definitely explain protocol as simple as possible for everybody who implements it to understand what's going on and how your services can be replaced by something else. That is, if you're serious about having a real cross-browser solution.
For how this plays out, imagine the following combinations of native support for the BrowserID protocol:
1) BROWSER AND IDENTITY PROVIDER: Mozilla's services are left completely out of the loop.
2) BROWSER ONLY: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user.
3) IDENTITY PROVIDER ONLY: Mozilla's shim and services step in to provide a surrogate implementation of the BrowserID protocol.
4) NEITHER: Mozilla's services step in as a trusted third party to handle validating control over an identity and signing assertions for that user, and to provide a shimmed implementation of the BrowserID protocol.
Again, the protocol was designed to be distributed from the very start, so nothing is locking it down to using Mozilla's shim and services, but they're there for you if you want to use them.
Disclaimer: I do not currently work for Mozilla, but I will be joining the Identity team later this month.