Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla's BrowserID (single sign-on for the web) is live

github.com

Post reply on HN
Print view View original

71–80 of 92 posts

Re: Mozilla's BrowserID (single sign-on for the web) is live

#71

Post by badida »

gwillen wrote: post #34
philikon wrote: post #26

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 provid…

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.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#72

Post by MatthewPhillips »

lloydhilaiel wrote: post #69
MatthewPhillips wrote: post #56

>Include the BrowserID include.js library in your site by adding the following script tag to your pages tag https://browserid.org/include.js type="text/javascript"> 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.

Hi MatthewPhillips, That's just the license header that's not stripped. I agree, that's a bit draconian. lemme see if I can fix that for you. lloyd

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.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#73

Post by vthunder »

jaredhanson wrote: post #68

For anyone interested in using BrowserID authentication from a Node.js app, Passport (which I developed) has a BrowserID module: https://github.com/jaredhanson/passport-browserid Just drop in a few lines of code and you have single sign-on.

Very cool! I didn't know you'd added that.

Let us (the BrowserID team) know if you have any feedback on the experience.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#74

Post by dholbert »

philikon wrote: post #26

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 provid…

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

Re: Mozilla's BrowserID (single sign-on for the web) is live

#75

Post by laconian »

icebraining wrote: post #45
resnamen wrote: post #6

Earlier quoted context omitted.

It provides a canonical identifier for your account without compromising your identity to BrowserID-enabled services. The OpenID spec divulges who you are.

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.

The OpenID identifier can act as a relational key across services.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#76

Post by philikon »

zobzu wrote: post #64
philikon wrote: post #26

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 provid…

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!

Re: Mozilla's BrowserID (single sign-on for the web) is live

#77

Post by icebraining »

laconian wrote: post #75
icebraining wrote: post #45

Earlier quoted context omitted.

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.

The OpenID identifier can act as a relational key across services.

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

Re: Mozilla's BrowserID (single sign-on for the web) is live

#78

Post by icebraining »

extension wrote: post #53

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 ad…

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.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#79

Post by icebraining »

gcp wrote: post #49
dhx wrote: post #38

Why? 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…

Because you don't need to create an account on each and every site you visited (together with decoding a similar number of CAPTCHA's, etc)

And more importantly than decoding Captchas - with B-ID there's no need to verify the damn email each time you register.

Re: Mozilla's BrowserID (single sign-on for the web) is live

#80

Post by icebraining »

zobzu wrote: post #66
alexchamberlain wrote: post #52

Earlier quoted context omitted.

They are brilliant, but they need to be more accessible. Hmmmmm... maybe I should provide a patch for Chromium/Firefox.

i wouldnt say brillant the CA model is still a pita where you've to pay for certified authorities that are backed up by the vendors and then, those certified authorities still fail to secure themselves it certainly made a lot of sense but in reality its not that good

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.

Post reply on HN