How BrowserID differs from OpenID(identity.mozilla.com)
identity.mozilla.com
How BrowserID differs from OpenID
http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid
8 comments
I just finished implementing BrowserID in an application that I am building. It is quick and easy to use. Perhaps 20 minutes to get it to work. I used OpenID before. OpenID is annoying and difficult. I spent 3 full days working on it.
I'm really excited about BrowserID. I think for the end user it makes more sense than OpenId which was doomed from the start because it was too difficult to understand what it was.
If only people owned their email addresses then this would be a truly decentralized (eventually) and portable identity system. I do think emails are the best global handle for users that we have currently - we should treat it as such.
If only people owned their email addresses then this would be a truly decentralized (eventually) and portable identity system. I do think emails are the best global handle for users that we have currently - we should treat it as such.
I am too. My only concern is that it is still effectively a demo. Do we have any real commitment from Mozilla to keep it around?
I actually talked to Lloyd Hilaiel from Mozilla who worked on BrowserID and it's currently in alpha and they hope to move it to beta in a couple months. At that point they'd be committing to keeping it around.
The web needs this to be widely adopted. They've got some unique challenges to make it easy to integrate and easy to understand but I think they're on the right track.
The web needs this to be widely adopted. They've got some unique challenges to make it easy to integrate and easy to understand but I think they're on the right track.
OpenID kinda scares me, security wise. There's too many ways for developers to screw it up. Witness the ones who used Facebook names as unique user identifiers.
At least with email, provided by the email host, the string you get from them will be unique.
At least with email, provided by the email host, the string you get from them will be unique.
I do like their last point that the system is designed to be integrated directly into the browser. That avoids the issue of OpenID requiring that a popup be displayed to the user from their OpenID provider, which was a significant usability problem.
Having the browser handle the authentication makes for a much more seamless experience.
Having the browser handle the authentication makes for a much more seamless experience.
If you have browser support, the browser could log you in to your OpenID provider so there'd be no popup.
The problem is that OpenID doesn't specify that part of it. I could have one that needs a key-fob token to authenticate there.
You can authenticate any way you want, so that's not a problem.
If NAT and firewalls weren't such PITA, browser could even act as an OpenID provider for itself (e.g. Opera Unite makes it possible).
The problem with OpenID is lack of discovery. AFAIK there is no way to advertise that website supports OpenID login and where it should be submitted, so browsers are unable to have integrated UI for it.
If NAT and firewalls weren't such PITA, browser could even act as an OpenID provider for itself (e.g. Opera Unite makes it possible).
The problem with OpenID is lack of discovery. AFAIK there is no way to advertise that website supports OpenID login and where it should be submitted, so browsers are unable to have integrated UI for it.
Since it isn't specified as part of the spec, browsers would potentially have a different implementation for each OpenID provider, so yeah, that's a problem.
Client<>Provider authentication method is not visible in the in OpenID protocol between Provider<>Consumer. Can you elaborate where the problem lies?
Why would different auth methods in browsers cause problems, when different provider's methods don't?
AFAIK client auth method is invisible and irrelevant, especially in the case where client and provider are the same thing (the browser).
In fact, in-browser OpenID (where browser is the provider) could skip client authentication completely and just say "yes" to every consumer (because browser knows and trusts its own identity).
Why would different auth methods in browsers cause problems, when different provider's methods don't?
AFAIK client auth method is invisible and irrelevant, especially in the case where client and provider are the same thing (the browser).
In fact, in-browser OpenID (where browser is the provider) could skip client authentication completely and just say "yes" to every consumer (because browser knows and trusts its own identity).
Realistically everyone is going to become compatible with whatever the browsers support.
I never understand why we keep drafting all sorts of identity mechanisms instead of using public key. It's easy to understand, very secure, and battle-field tested.
BrowserID is based on public key cryptography. It just provides a mechanism to (a) attach public keys to an identity (in this case an email address) and (b) enable easy, widespread adoption by websites and browsers.
Public-key crypto may be easy to understand and secure, but until now it's not had good browser integration, it's been hard for websites to manage, and there's been no adoption.
(For example, if you write your own public-key auth mechanism for a website, you need to program all the backup mechanisms in case the user loses their key due to browser failure, needs to recover their account because of a security problem, or whatever. BrowserID outsources that to email providers or secondary authorities.)
Check out the detailed protocol explanation:
https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol
Public-key crypto may be easy to understand and secure, but until now it's not had good browser integration, it's been hard for websites to manage, and there's been no adoption.
(For example, if you write your own public-key auth mechanism for a website, you need to program all the backup mechanisms in case the user loses their key due to browser failure, needs to recover their account because of a security problem, or whatever. BrowserID outsources that to email providers or secondary authorities.)
Check out the detailed protocol explanation:
https://wiki.mozilla.org/Labs/Identity/VerifiedEmailProtocol
I hope and pray a single sign-on system that doesn't depend on a specific third party catches on. Any system, OpenID, BrowserID, I don't care. It's about time we do away with the insecure and complicated system of one password per site.
BrowserID only depends on a third party if you have a browser that doesn't handle BrowserID natively.
One use case I still am hesitant about for email-as-username is the situation where a family shares an email address for a household. I know that ISPs like Comcast still just provide a main email address when they set up the account, and I expect many people don't bother to make more for the rest of the family.
With all the free email options available I doubt this would be a serious problem. I also know some sites are requiring unique email addresses in their DB now. I simply wonder how many users still do this and if it would negatively impact them.
With all the free email options available I doubt this would be a serious problem. I also know some sites are requiring unique email addresses in their DB now. I simply wonder how many users still do this and if it would negatively impact them.
[deleted]
Yet, another protocol from Mozilla? It has even less features and is way more complicated than the last abandoned attempt: https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager...
FAIL
Why would I want to use my email address as an identity? I already get more than enough spam.
Why would I want to use my email address as an identity? I already get more than enough spam.
Virtually every site does this already, this just makes it more constant, secure, and convenient.
A lot of experienced users out there tends to provide each service a different email address ([email protected], [email protected], etc.)
BrowserID breaks this.
BrowserID breaks this.
BrowserID allows multiple emails, and I've tested "[email protected]" and "[email protected]", and both work.
I guess it can't be 100% automated, but you don't want automated logins anyway.
I guess it can't be 100% automated, but you don't want automated logins anyway.
Speaking of such (which is a valid concern) I always use a nice feature from gmail which gives the ability to append +anything to your username. Mail will be forwarded to your inbox as usual where you can apply filtering to know whom as leaked your email. Hence you can use [email protected] while registering for foobar webapp.
This assumes that foobar webapp accepts + as a valid email local part character which is not always the case unfortunately (and against RFC) but that is another story.
Just sayin
This assumes that foobar webapp accepts + as a valid email local part character which is not always the case unfortunately (and against RFC) but that is another story.
Just sayin
Given that everyone knows about this feature, what's to stop spammers just stripping of the '+' portion?
Simple solution: give everyone address with "+suffix", and mark as junk any mail without it.
For stubborn services who don't accept "+" in email addresses use unique redirect aliases.
(Also, IIRC, Gmail ignores dots, i.e. "[email protected]" and "[email protected]" is the same address. Chose a canonical one with a dot somewhere, and filter the rest with exception for legimate senders.)
For stubborn services who don't accept "+" in email addresses use unique redirect aliases.
(Also, IIRC, Gmail ignores dots, i.e. "[email protected]" and "[email protected]" is the same address. Chose a canonical one with a dot somewhere, and filter the rest with exception for legimate senders.)
you can get the same effect with arbitrary dots.
e.g. [email protected] is the same as [email protected]
e.g. [email protected] is the same as [email protected]
Still, they can remove all dots from gmail addresses.
You can hide the + portion of a Gmail address behind redirects and forwards, if you feel so inclined. It's a lot of work, but it does let you use the "deliveredto" operator in Gmail to automatically sort and discard spam like that.