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

81–90 of 92 posts

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

#81

Post by alexchamberlain »

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

I would like to emphasise my disagreement with this comment and agreement with the other reply.

Authentication using HTTPS is the same theory as SSH public key authentication.

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

#82

Post by jaredhanson »

vthunder wrote: post #73
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.

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.

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

#83

Post by wmf »

badida wrote: post #71
gwillen wrote: post #34

Earlier quoted context omitted.

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.

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

#84

Post by jmathai »

StavrosK wrote: post #50
jmathai wrote: post #24

Earlier quoted context omitted.

BrowserID is super easy to implement. It's 8 lines of Javascript and about 8 lines of code on the backend to verify that a user owns an email address. I've implemented it on OpenPhoto and absolutely love it.

Can you give me an invite code? I'd love to try BrowserID out and openphoto looks interesting! My email is in my profile, if you need it.

Sent.

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

#86

Post by philikon »

wmf wrote: post #83
badida wrote: post #71

Earlier quoted context omitted.

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.

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

#87

Post by wmf »

philikon wrote: post #86
wmf wrote: post #83

Earlier quoted context omitted.

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

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.

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

#88

Post by Groxx »

thristian wrote: post #37
m_eiman wrote: post #33

Earlier quoted context omitted.

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…

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.

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

#89

Post by Groxx »

wmf wrote: post #87
philikon wrote: post #86

Earlier quoted context omitted.

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

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.

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

#90

Post by extension »

icebraining wrote: post #78
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.

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.

Post reply on HN