Comment by philikon | Hacker News Reader

Comment by philikon | Hacker News Reader

Parent Full thread

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

(EDIT: format bullet points)

no exposure to identity provider

That's not quite true, is it? The documentation says I need to verify the user's identity by calling e.g. browserid.org/verify…

"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."

- https://github.com/mozilla/browserid/wiki/How-to-Use-Browser...

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."

Doesn't that make you the identity provider, who you must identify yourself to? That sounds pretty similar to running your own OpenID server.

> 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.

Can you explain briefly what the good reason is for no browser to integrate OpenID?

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.

Thank God someone else sees it.

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... ;) )

this post should be on browserid.org i find it difficult to find what it does, how its different, etc.. well until your post that is

Yes, I already spoke to the team and they're going to put up a FAQ. Thanks!

> 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.

A comparison WebID/BrowserID can be found here: http://security.stackexchange.com/questions/5406/what-are-th...

Reply on news.ycombinator.com