4 ms·

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 l

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 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 http://lloyd.io/how-browserid-works (EDIT: format bullet points)

m_eiman 15y ago
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…
- thristian 15y ago
  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."
  - Groxx 15y ago
    Doesn't that make you the identity provider, who you must identify yourself to? That sounds pretty similar to running your own OpenID server.
- sandeepshetty 15y ago
  "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-BrowserID-on-Your-Site https://github.com/mozilla/browserid/wiki/How-to-Use-Browser...
gwillen 15y ago
Can you explain briefly what the good reason is for no browser to integrate OpenID?
- badida 15y ago
  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.
  - wmf 15y ago
    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.
    - philikon 15y ago
      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.
      - wmf 15y ago
        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.
MatthewPhillips 15y ago
> 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.
zobzu 15y ago
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
- philikon 15y ago
  Yes, I already spoke to the team and they're going to put up a FAQ. Thanks!
dholbert 15y ago
> * 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... ;) )
ranit8 15y ago
> 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/ 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-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid http://security.stackexchange.com/questions/5406/what-are-th...

m_eiman 15y ago

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…

thristian 15y ago
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."
- Groxx 15y ago
  Doesn't that make you the identity provider, who you must identify yourself to? That sounds pretty similar to running your own OpenID server.
sandeepshetty 15y ago
"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-BrowserID-on-Your-Site https://github.com/mozilla/browserid/wiki/How-to-Use-Browser...

gwillen 15y ago

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

badida 15y ago
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.
- wmf 15y ago
  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.
  - philikon 15y ago
    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.
    - wmf 15y ago
      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.

MatthewPhillips 15y ago

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

zobzu 15y ago

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

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

dholbert 15y ago

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

ranit8 15y ago

> 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/ 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-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid http://security.stackexchange.com/questions/5406/what-are-th...