A lot of questions here revolve around how this is different from OpenID and single sign-on solutions like Google Accounts or Facebook Connect. Here's a rough list (may be incomplete or inaccurate by now; while I work for Mozilla, I'm not involved in this project):
* federated (like OpenID)
* open standard (like OpenID)
* no passwords / no typing / no memorizing (e.g. like FB Connect)
* possibility of browsers providing an integrated experience (technically possible with previous solutions, but no browser has done this so far -- in the case of OpenID for a very good reason IMHO)
* anonymity/choice of identities (like OpenID, definitely unlike e.g. FB Connect)
* no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)
Check out Dan and Ben giving a nice demo of the BrowserID user experience: http://www.youtube.com/watch?v=6x45Nt1fOMM. No passwords, no typing, and anonymity where desired.
If you're interested in the nitty gritty details, Lloyd explains the cryptographic assertions that actually let sites verify your identity: http://lloyd.io/how-browserid-works
"NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."
The documentation also says "NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."
> no passwords / no typing / no memorizing (e.g. like FB Connect)
FB Connect requires you to memorize your Facebook password. It also requires you to have a Facebook account. BrowserID requires neither an "account" or a password.
In earlier identity experiments at Mozilla, we tried. It never felt good as a user experience, in large part because OpenID was designed to not include the browser.
It seems like it would have been less work to modify OpenID (given that they revise it every few years anyway) than to invent a completely new protocol.
I'm curious how you would come to that conclusion.
The problem is, OpenID will still require you to remember your OpenID provider's URL. (You could also be with one of the half a dozen or so big identity providers, and then every site gets to implement the "Nascar sticker" style icon banners. Like, uh, I don't know, news.ycombinator.com for instance ;)).
On top of the OpenID URL, a lot of sites also want a way of contacting the user via email. So that's another bit of info that you're going to have to enter when you sign up for the first time. What's interesting is that your email address almost certainly identifies you already anyway.
So why not just use email addresses instead of the URL, and API calls instead of those hideous redirects to establish identity? It's not too hard to see how you would end up with "verified email" as a core identity concept, and that any of the mechanics described by OpenID aren't really useful.
If the browser can remember a BrowserID token, it could also remember an OpenID URL. If the browser can have chrome that triggers a BrowserID login, it could have chrome that triggers an OpenID (3.0) login and does all the redirects behind the scenes. I think with OpenID+OAuth the RP can get an email address.
There is no reason that your browser can remember a unique username and password for every site you wish, but not a single OpenID url. Or that it can fill in username and passwords across wildly-varying-markup sites, but not in the much-more-frequently-identical OpenID fields. At absolute worst, the OpenID experience can be 100% identical to the Username/Password experience, but no browser I've seen has even done this trivial implementation, much less a more seamless one.
> * no passwords / no typing / no memorizing (e.g. like FB Connect)
Technically there's 1 password (your BrowserID login password), not "no passwords". :)
(Though of course you can have multiple identities (email addresses) all associated with the same BrowserID account, so as you increase the number of identities, I suppose your passwords-per-identity approaches zero... ;) )
> no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)
Unfortunately that might be what prevents this or http://webid.info/ from getting traction. The big guys wouldn't like losing that data, and OpenID/OAuth already do the job well enough for them.
I'm pretty sure I understand how this works, but please correct me if I'm wrong.
As currently implemented, it appears that if the Primary Identity Authority or Secondary Identity Authority keys are compromised, then all accounts for which that authority is trusted are also compromised. This enables accounts to be compromised en masse, rather than individually. It would seem that by de-centralizing authentication, browserid centralizes security.
Ok, so revoke the compromised certificate. If you "trust" browserid.org and do assertion verification on your own servers, how are you notified of the compromise and key change? Conversely, if you offload assertion checking to browserid.org and they go down, will users really understand why they can't log in and your site is "broken"? You could use CRLs and OSCP, but now you have another thing to get wrong in individual sites' assertion verification implementations.
Another interesting side effect of PIA or SIA key compromise is that an attacker could now create accounts and impersonate users, not just access existing ones.
It would also appear that due to the omission of a nonce, assertions are vulnerable to replay within the validity window.
I think that authentication is broken, and commend attempts to fix it. I'm just not sure that all the added complexity of browserid really buys us anything, and instead enables new attacks that previously weren't feasible.
I think the intention is for the primary to be your email provider. So if they become compromised to that extent, then I wouldn't feel very safe about my email account in the first place. Pretty much all of my credentials everywhere depend on that.
Until secondaries go away, Mozilla seems like a very competent and trustworthy organization to have in charge of browserid.org, IMHO. Much better than even Google. It's great to see that even the branding on browserid.org is minimal.
My guess is that, concerning nonces and revocation, they didn't consider the current situation (OpenID, OAuth for login, etc.) any better. BrowserID doesn't seem to do away with the strong advice to run HTTPS for such sites.
I'm not seeing how BrowserID differs from the standard email verification sign up. I went through the sign up process (enter email, click link in verification email, enter password, sign in with password). I also read Mozilla's 'really short version' explaining browserid (https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol) and will give the longer version a shot.
Indeed; I believe it authenticates your browser (or perhaps only your browser session?) across all BrowserID-using sites, drastically cutting down on the number of times you'd have to type in a password.
Right, this is caving cowpaths. Most sites have this flow, so if we can lift that up into the Browser and your Primary identity provider, than you can stop doing this on each new website you visit.
At the moment the BrowserID team provides a Javascript shim but the goal is that it will be supported natively in the browsers. The shim if a fallback (which applies for all browsers atm).
Even if the API is supported natively in the browser, it's still a JavaScript API, so you still need to allow the website to run JavaScript so that it can call that native method.
I'd say the experience is quite easy, especially when using browserid.org/verify for verification.
My biggest criticism is the lack of a concretely defined spec for how the Verified Email Protocol works, if one wanted to implement it directly, rather than relying on browserid.org.
Based on the code in the repository, the protocol seems relatively straightforward. But, as it currently stands, it'd be difficult to implement it based on the paper spec alone.
Anyway, nice work on BrowserID. I'm excited to see where its headed.
Firefox already stores passwords in a local database and it wouldn't be that hard to automatically log users into sites.
The method they describe here requires every web site be changed and requires cross-domain JavaScript to be enabled such that browserid.org will know which websites you visit. You _could_ place include.js on your local domain to avoid this issue. However history has shown that sites will tend to just cross-domain link to googleapis or yahooapis.
Additionally, this is yet another web authentication method that should probably be handled at a lower level in the stack -- either the HTTP protocol, transport layer (TLS) or perhaps in the future, by using IPSec.
This is a more pragmatic approach than openid. Most users have a secondary email for logins anyway, and browserid makes switching a snap. I think it will catch on, mainly because there s nothing new for users to learn, and everyone has an email addr
I have Facebook, Google, and Blogger OpenIDs, and probably some others I have forgotten. Probably Yahoo and Flickr, maybe WordPress and maybe even LiveJournal. I really have no idea.
Facebook and Twitter are owned by companies and have a single point of failure. Many users won't use sites that only provide these as a login method for various reasons (they don't like social media, etc).
OpenID seems to be difficult for non-technical users to grasp. They don't understand what it is or the fact that they probably already have it. Even technical users can have issues (what OpenID login did I use, which of my multiple current Google accounts are being used, etc).
BrowserID is being advertised as the easier alternative for users and developers I think.
BrowserID is not Firefox specific. The JavaScript shim works across a number of browsers.
I had to create an account a couple of days ago because it was the only way to log in to openphoto.me. Are there any clear differences between BrowserID and OpenID?
OpenID requires the user to remember what sites they have accounts on that provide OpenID authentication, and requires them to remember their authentication information for those sites every time they want to log into an OpenID-using site.
In its current form, BrowserID requires the user to do the email-verification dance once for each email address they want to authenticate as, and from then on they can just pick it from a list instead of doing the dance yet again.
In its ideal form, once the BrowserID API is implemented directly in browsers and webmail systems (instead of the shim at browserid.org), the user doesn't need to remember anything: they click "sign in" on the web-page, the browser brings up its standard 'pick an email address to authenticate as' dialog (populated from all the webmail sites the user has logged into), the user selects one from the list, and off they go.
I don' really need a foo@browserid.org address to register there right? So I could actually get the same email address verified through multiple providers. How would the browser know which one I actually want to use?
The clearest difference in my mind is that BrowserID is much easier for a user to grasp. An email address is something users already associate with their identity.
As far as OpenPhoto, we're pushing BrowserID because we think it's a much better authentication system than something like Facebook Connect. It's open, distributed and secure. We do have FB Connect plugins for OpenPhoto but we believe that defaultly using BrowserID is the right thing to do.
What does BrowserID do that every existing OpenID provider cannot? The BrowserID FAQ says the architecture is "decentralized", but login relies on Mozilla's browserid.org server.
Mozilla's browserid.org server is used for two things, currently:
- validating the signed authentication token you get back from calling the authentication function. As user "decentralized" points out, this is just a convenience; your service can do this itself if you don't mind getting your hands dirty with crypto code.
- Serving the JS shim for user-agents that don't implement navigator.id.getVerifiedEmail() natively. Once browsers implement this function themselves, and webmail systems can tell the browser that the user owns a particular email address, this won't be needed either.
"NOTE: You may choose to validate assertions on your own server. While a bit more complicated you can reduce your dependencies on others. Refer to the specification and the source for the reference validator."
So while it's easier to use their server, it appears it is entirely possible to implement without it. Perhaps in a few weeks, we will see some good implementations. As I understand, the main advantage over OpenID is that instead of needing a <username>@<someopenidprovider> login, people can simply use an email address as their login. If all email providers supported OpenID, there would be little difference, but that has not happened (yet).
The goal is that others support the verification portion (hence it being decentralized). The browserid.org site is required today because others haven't implemented support on their backends.
The design of BrowserID is more aligned with real user behavior in the wild. An example is users remember an email instead of a URL. The API/Protocol for an implementing website is much easier, based on implementer feedback.
It provides a canonical identifier for your account without compromising your identity to BrowserID-enabled services. The OpenID spec divulges who you are.
How so? As far as I know, the only mandatory information is the OpenID identifier (the URL you need to input to authenticate). While more information can be exchanged, that's completely optional and up to the user. For example, MyOpenID always asks what "persona" - if any - you want to send when you authenticate.
BrowserID is no better: you need to input your email address.
So can the email address in BrowserID, or the username in the typical user/pass combination. If you don't want to be connected, use different IDs for different services. Nothing in OpenID prevents a person from having multiple identifiers; in fact, Gmail generates different identifiers for each domain you authenticate on: http://blog.stackoverflow.com/2009/04/googles-openids-are-un...
I'm working on a webapp that will be used by not-so-tech-savvy working people and this could be an interesting way to subscribe to the service without implementing generic openid (i think most of them wont understand it) or facebook/twitter etc.. login (it's a service for businessman). I must check if it's more difficult to implement than an all-internal email subscription and verification process.
Maybe I do not understand the system well enough, but isn't there too much room for fake accounts? The web site implementing BrowserID must trust the browser or the 3rd party validation service that the user really owns the specified email, right? Wouldn't it be super-easy for a hacker to simply return bogus values from navigator.id.getVerifiedEmail() when that gets implemented in browsers? (more specifically, what is the verification procedure of the "Primary Identity Authorities" and what stops a hacker to create a fake one?)
I am all for simple log-in procedures, but as a web site owner, I want to be really sure, the email at least exists to prevent a bit of spam or low-quality content.
As I understand it, the authentication token you get back from BrowserID is signed by the entity that verified that the email address is real; at the moment, only browserid.org is signing tokens, but presumably there'll be some scheme where you say "I have a token for foo@example.com, so I'll request the public key of example.com and validate the signature on this token".
I guess it's possible for somebody to set up a website that will sign absolutely any token anybody offers them, but (a) as a website operator, you can tell that the token "foo@example.com signed by example.com" is different from "foo@example.com signed by evil.com" and (b) you could always have a blacklist/whitelist of entities you trust to verify BrowserIDs.
It would be interesting for this to get some exposure from a large web-service. Being realistic, Facebook nor Google would be interested in replacing their own system. But I think it is an interesting idea which now is no longer just theory.
Well, Google wouldn't replace their login process because they are the BrowserID primary. If you have a gmail account, BrowserID expects you to be logged in with it, which essentially means you're logged in to Google. (They could add it for non-gmail Google accounts, I guess.)
But Facebook could benefit from this. Maybe not at this early stage, but the way you log into Facebook is using your email account. That's exactly the step BrowserID wants to make easier.
>Include the BrowserID include.js library in your site by adding the following script tag to your pages <head> tag <script src="https://browserid.org/include.js type="text/javascript"></script>
Not minified. Come on Mozilla, you did the same thing with the (rather large) Open Web Apps library. Minification is required. You are Mozilla, you should know this. YUI Compressor takes a few seconds at most.
Actually I went to the Documentation and clicked the link there, which actually takes you to the github source. Completely my bad, having a license header is not abnormal. I jumped the gun because the Open Web Apps shim wasn't minified for quite a while.
Why has this been developed? I would have like to have seen a way for clients to generated client-based SSL certificates and submitting them to a server for signing automatically. This would be little new technology and proven cryptographically.
The CAs don't need to play any part in client-cert based authentication. You just generate a cert locally and then copy the public key to the site when you register. Subsequent logins are performed by the server checking if you own the right private key that matches the public key used on registration.
It's like SSH, not HTTPS.
CAs are only useful to match a cert to a domain and/or known organization, or inside an organization to make sure the user has a cert signed by the org itself.
"You just generate a cert locally and then copy the public key to the site when you register."
But how do you know you're copying your key to the right site and not some fake? Answer is, of course, you don't, so you need something else. And it's not stronger than the weakest link..
Hmm.. so if my browser has integrated support, then any site I visit can add itself to my list of primarity authorities as evil-username@evil-domain. And I will be asked to choose one of these authorities to log in to other sites. And a rogue authority can impersonate me on the sites where I use it. Is this correct?
I can see a slight potential to trick the user into using a rogue authority. Imagine the evil email address is somehow tailored to a site the user is expected to log in to, in a way that makes it look like the "right" selection for that site, in the BrowserID dialog. I can't think of an explicit example right now, but when you allow untrusted parties to inject text into trusted dialogs, there are often many possibilities for trickery.
I'm not sure if "any site I visit can add itself to my list of primarity authorities as evil-username@evil-domain", but I do know that the login to the authority is done using Public Key authentication, which unlike passwords isn't subject to phishing. There's no risk in logging in to a rogue authority, since the key never actually leaves your machine.
I don't mean logging into an evil authority, I mean tricking the user into using an evil authority to log in to a relying party. There evidently is or will be a way for web sites to tell your browser that they can serve as a primary authority for some particular email address at their domain. When you visit the evil site, it would register some misleading email address, which your browser would then show in the list of identities whenever you log in to a relying party.
At best, we will still need some way of filtering out junk from the identity list.
I was hopeful about this protocol, but now I'm kind of disappointed. It uses email and is built into the browser, so why does it require JavaScript on the user side and a complicated verification server on the server side? I was a hoping for something simpler.
* federated (like OpenID)
* open standard (like OpenID)
* no passwords / no typing / no memorizing (e.g. like FB Connect)
* possibility of browsers providing an integrated experience (technically possible with previous solutions, but no browser has done this so far -- in the case of OpenID for a very good reason IMHO)
* anonymity/choice of identities (like OpenID, definitely unlike e.g. FB Connect)
* no exposure to identity provider (this is unlike any existing solutions; if you log into a site, your OpenID provide, Facebook, Google, etc. will know which site it was; not with BrowserID!)
Check out Dan and Ben giving a nice demo of the BrowserID user experience: http://www.youtube.com/watch?v=6x45Nt1fOMM. No passwords, no typing, and anonymity where desired.
If you're interested in the nitty gritty details, Lloyd explains the cryptographic assertions that actually let sites verify your identity: http://lloyd.io/how-browserid-works
(EDIT: format bullet points)