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

Introducing BrowserID: A better way to sign in

identity.mozilla.com

Post reply on HN
Print view View original

91–100 of 188 posts

Re: Introducing BrowserID: A better way to sign in

#91

Post by icebraining »

huhtenberg wrote: post #83
bct wrote: post #65

Earlier quoted context omitted.

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

Read through your link, and here's just an observation - > BrowserID is a decentralized identity system BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization , is it? Practically speaking. (edit) Added practically speaking ... and ease up on that downvoting, d…

Uh, GMail users are a minority. Besides, the system is decentralized - the fact that most people can choose the same server is not a problem of the system.

Besides, the fact is that most websites already use email, so BrowserID is not any worse than the status quo.

Re: Introducing BrowserID: A better way to sign in

#92

Post by huhtenberg »

JoshTriplett wrote: post #87
huhtenberg wrote: post #83

Earlier quoted context omitted.

Read through your link, and here's just an observation - > BrowserID is a decentralized identity system BrowserID effectively links identity an email service provider, and while I realize that not everyone shares their emails with Google, a vast majority of people still does. That's not that much of decentralization , is it? Practically speaking. (edit) Added practically speaking ... and ease up on that downvoting, d…

"decentralization" doesn't mean "forced decentralization". Anyone can register a domain name and have their own email at that domain, so anyone can create an identity. And ignoring the transitional bits in BrowserID, eventually that identity gets controlled entirely by the public/private keys in the user's browser. Or, in other words: if you don't trust Google, don't use gmail; that someone else chooses to do so does…

Sure, I understand that of course. I am just saying that practically speaking this property is not going to matter much in the world where everyone and their dog is on GMail. It is certainly nice to have though.

Re: Introducing BrowserID: A better way to sign in

#93

Post by bct »

JoshTriplett wrote: post #90
bct wrote: post #65

Earlier quoted context omitted.

Ignifero described what happens when your browser or email provider don't support BrowserID. When your browser and email provider both support BrowserID: 1. You log into e.g. gmail. 2. Your browser generates a keypair and sends the public key to gmail. 3. Gmail signs your public key and sends your browser a certificate saying "this key is owned by whoever@gmail.com". 4. You click "sign in" on some site (e.g. Hacker N…

Why would you want your email provider to support BrowserID? I'd consider it invasive for my email provider to do anything different to interfere with the email verification process for another site.

I don't follow you, what's invasive/interfering about it? You & your browser can decide whether any of the steps of this process actually happen.

Re: Introducing BrowserID: A better way to sign in

#94

Post by swaits »

ora600 wrote: post #23

What I'd really want to see is public-key authentication for website. Let me upload my public key when I create an account on a website, and let the browser interact with my ssh-agent to authenticate.

Will you and the website owner each verify the key fingerprints? What I'm getting at is it's a hard problem to solve, because users want it to be quick and easy. But that often works against the stated goal of security.

Re: Introducing BrowserID: A better way to sign in

#95

Post by JoshTriplett »

shockie wrote: post #5

What's the advantage over openid?

OpenID fundamentally argued that you should trust a third-party authentication service. Not too long ago, Mozilla tried implementing OpenID directly in the browser so you didn't have to trust any third party, but that represented an afterthought in the OpenID ecosystem.

BrowserID, on the other hand, fundamentally uses distributed identity via public/private key crypto, and only involves a (single) third-party service as a crutch to allow browsers without native BrowserID support to handle BrowserID, so that sites can adopt this immediately rather than waiting for browser support.

Re: Introducing BrowserID: A better way to sign in

#97

Post by joeyespo »

SeoxyS wrote: post #52

They seriously need to work on their communication skills. It took me a good 15min to figure out what this thing actually does. And I'm still not sure I got it right. OpenID failed because it was too complicated for mere mortals. This, I fear, may be too confusing. At least form the way it's presented. After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basica…

Wow, I had exactly the opposite experience. Tons of thoughts popped into mind as I watched.

If my brain had a replay button, it would say:

* Ok, what if I have multiple accounts? Ahh, nice.

* Hmm it would be cool if it worked like LastPass, where you get great security and only one password to remem... ha, nice, it's very similar!

* Email verification? ....yep, check.

* Can you lock the browser so that nobody can just use your browser to sign in? (No direct answer, but I assume so. Or will be this way soon.)

* Open source? Great.

I didn't really expect any technical answers. But they did mention the blog and there's got to be some good posts coming soon. Subscribed.

Re: Introducing BrowserID: A better way to sign in

#98

Post by JoshTriplett »

riffraff wrote: post #80
ignifero wrote: post #75

Earlier quoted context omitted.

- No need to register your application with browserid.org - No need to use an oauth library (just 1 GET request) - Oauth provides access to user data on the provider, while browserID provides no data. Less anxiety for the users. - No request_token/access_token pairs - In the future, the user will (hopefully) be able to change his default browserid and as a developer you just don't care.

thanks, I thought you meant it was easier _as an end user_ and could not see why.

The implementation using browserid.org, to an end user, will not get any easier or harder than OAuth or any other third-party service. On the other hand, a browser-based implementation could simply bring up a browser notification saying "Authenticate to example.org using your email address?", to which you could click "yes".

Re: Introducing BrowserID: A better way to sign in

#100

Post by JoshTriplett »

stickfigure wrote: post #58
51Cards wrote: post #47

Earlier quoted context omitted.

It's not that simple. They authenticate against your Account at Browser ID. I would assume you can go into Browser ID and add / remove email addresses from your account which makes it even easier when you change your email. Now you don't have to visit 20 different sites to update them.

Is there some sort of account ID other than an email address? It looks like the email is all that gets sent to the website (although I didn't read deeply enough to be sure). If you change (add new, remove old) your email address at browserid.org then revisit a site you authenticated to before, what happens?

Indeed. Ideally, the site would end up with the user's public key, and optionally their email address; they should use the former as the primary key in their database, and the latter as an easily-changed property.
Post reply on HN