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 basically what this does:
* asymmetric crypto authentication in the backend.
* control over email address == authentication.
* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).
* falls back to regular email authentication we see every day.
I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?
Something like this already exists. Your browser can already identify itself with a certificate.
The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.
Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address?
On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent identity because they do not rely on third parties.
It's discontinued though unfortunately. Although there are still people out there making it work with newer versions of Firefox: https://grepular.com/FireGPG_on_Firefox_5
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.
My first ever programming project (I was 11) was basically this (edit: from a UI perspective, not under the hood), in PHP. I had no idea what I was doing, the architecture was questionable and at this point decentralization and OpenID were new and hot. It flopped horribly; it would have been a nightmare had it taken off, but it was fun.
My flow was basically this: website links to http://my-site/login?to=http://site.com/authenticate. User logs in against my MySQL database with an email I verified and a password. If successful, I generate a "ticket" number, my site makes an HTTP post to http://site.com/recevive with md5(ticket number + secret key) and the user's details, and then the user is redirected to http://site.com/authenticate?ticket=12345. Site.com verified the ticket using its API key and stuck it in its database. When the user hits site.com/authenticate, it looks it up by ticket number and has that person's details.
Obviously a terrible idea for a number of reasons (MD5, the race condition between the user and the ticket, and the reliance on my shared server being up) but my 11-year-old self thought it was pretty cool. Just thought I'd share.
that's a really cool project at 11 years old, both in terms of your idea and what you can actually accomplish! off topic, but when i was 11 i had a c64 and basic and couldn't dream of talking to another computer unless i saved my program to the tape drive and had my mom drive me to my friend's house to load it on his c64.
I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy.
Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.
I agree that email address != identity, but nothing would stop a site that uses BrowserID from allowing a user to change the email address that they use on that site.
It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
I understand the sentiment but simply because a solution doesn't cover all use cases (users must be able to change email addresses) doesn't mean it can't be usable. Also, we constantly use services were you cannot change your email address because that's how the system identifies you, so this dependency of email addresses isn't new at all.
(One work-around would be to use an disposable e-mail address service and redirect your emails as needed.)
What a weird double-standard. A feature of email (that you can have several, and you can change which one you use) is a failure, and a failure of Facebook (that it's one site, forever) is a feature?
We're all familiar with ways to migrate from one email address to another. If/when you leave Facebook/it disappears, how will you migrate your identity then?
In the literal sense that you are not your e-mail, yes email != identity.
In a practical "on the internet sense," your email really is your identity (maybe SSN or name would be a better description; you can change it, but to do so is catastrophically disruptive). After all if you can't be contacted you really can't be identified, and the universal way of contacting someone online is through email.
Now, you should definitely try and provide some redundancy (store multiple email addresses, long living sessions, whatever) and make your anonymous/unauthenticated/drive-by user experience stellar. But when push comes to shove if you can't send them a "forgot your username/password/open-id/samoflange" email, you've lost that user.
(anecdote: I've had the same primary email for >7 years)
OTOH, facebook id != identity, neither is twitter username. There will always be some id that you won't be able to change. But you are right that email is a bad choice, and i was surprised they give away the email address to developers. They should provide the browserid.org ID only.
This lets users sign in with an existing email address, so they don't need any new sevice or identifier to remember. It's decentralized; Mozilla has a service for web developers for convenience, but any site can implement the protocol itself instead (or use another provider). And it's designed to let browsers handle the login flow in the future, simplifying login and account creation for end-users.
I'm wondering if it's at all possible to integrate this with OpenID, and how this interacts with previous Mozilla Identity projects to make your identity a part of the browser chrome. It all seems rather tangential to their other efforts, rather than coherent with.
Am I the only one who kind of wishes we never went down this "let's fix authentication!" rabbit hole? It feels like we've just replaced one problem with another.
Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.
Say you're signed in to BrowserID already ... is there anything that would stop an attacker from being able to log you into some other BrowserID website without your knowledge or consent? With login reduced to two mouse clicks, it seems like a well-crafted webpage could log you in wherever it wanted. If that were the case, a CSRF-vulnerable BrowserID webpage could easily be exploited at a large scale.
BrowserID is a good first step, but ultimately as a website owner I'd much rather authenticate with Twitter/Facebook, since it makes it easier for me to figure out who the user is/ask them to share with friends.
Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication.
I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.
This looked great until I got to certification. At this point I think they've just re-invented X.509 and added browser/Javascript integration.
Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of [email protected], Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does.
This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.
How is this any different than current single signon systems, like Microsoft Live, Yahoo, Google, Facebook Connect.. I mean sure maybe this is open and anyone can run their own but lets not forget users dont care at all about that..
As a user, once your browser and email provider support it, it's single-click login (and signup), without any redirects.
As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".
So, it's basically a traditional single-sign on system? Is that right? Like, in the old days, I integrated one of my products with AOL. You could click a link and it would automatically sign you into my product using you AOL Screenname and Password (behind the scenes, AOL would verify that the screenname and password are correct and my app would create a new user in my database).
I hope that one of these services is on the user's side, so much that the ID isn't enough for, say, advertisers to track users over different sites. And how graceful is it for versions of IE that aren't 'recent'?
There seems to be an implied trade-off between a usable system and a distributed system. Most users and most developers at this point will go for usable.
But then, Google, Facebook and Twitter have reduced the friction for identifying all over the internet, so Mozilla is kind of arriving late to the party.
It's designed so that the browser can interact directly with the authentication protocol, saving steps for the user. This grew out of Mozilla Labs' "account manager" project, which had a protoype UI you can see here: http://hacks.mozilla.org/2010/04/account-manager-coming-to-f...
Thought that popped into my head. Instead of having separate passwords for different sites, now you are trusting your email provider to be absolutely secure (with that one ultra-secure password you are using, right?).
So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom.
The idea is that you would use this in situations where you currently would offer a "reset password via email" option - since this means you already treats control of the email address as identity.
This is just another web based open sign-in. Why did they tie this to email, of all things?
My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.
[+] [-] SeoxyS|14 years ago|reply
After reading the protocol spec, I have a somewhat better understanding of this. If I got this right, this is basically what this does:
* asymmetric crypto authentication in the backend.
* control over email address == authentication.
* allows a trusted third-party to authenticate the user. This could be a user or a web service (like browserid.org?).
* falls back to regular email authentication we see every day.
I'm still unclear how you can securely verify email ownership thru cryptographic means. Anybody care to explain it?
[+] [-] ora600|14 years ago|reply
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.
[+] [-] paulosman|14 years ago|reply
That's essentially what this is... with a verification service and web based UI to help bootstrap it.
[+] [-] wmf|14 years ago|reply
http://www.gnegg.ch/2008/05/why-is-nobody-using-ssl-client-c...
[+] [-] superuser2|14 years ago|reply
The interface is ugly and cumbersome for the non-technical (even in Firefox) and I don't think it's used very often, but I know that MIT issues certificates to students which identify them to all MIT's web applications, as well as third parties like the Apple and Dell student discount pages.
[+] [-] Astrohacker|14 years ago|reply
Email addresses are typically controlled by a third party, so it doesn't make much sense to me that they should be equated with identity. Would you equate your identity with your IRL work address?
On the other hand, private keys are held only by the person whose identity they represent. They are a better way to represent identity because they do not rely on third parties.
[+] [-] mike-cardwell|14 years ago|reply
It's discontinued though unfortunately. Although there are still people out there making it work with newer versions of Firefox: https://grepular.com/FireGPG_on_Firefox_5
[+] [-] groby_b|14 years ago|reply
[+] [-] swaits|14 years ago|reply
[+] [-] JanezStupar|14 years ago|reply
[+] [-] lucian1900|14 years ago|reply
[+] [-] superuser2|14 years ago|reply
My flow was basically this: website links to http://my-site/login?to=http://site.com/authenticate. User logs in against my MySQL database with an email I verified and a password. If successful, I generate a "ticket" number, my site makes an HTTP post to http://site.com/recevive with md5(ticket number + secret key) and the user's details, and then the user is redirected to http://site.com/authenticate?ticket=12345. Site.com verified the ticket using its API key and stuck it in its database. When the user hits site.com/authenticate, it looks it up by ticket number and has that person's details.
Obviously a terrible idea for a number of reasons (MD5, the race condition between the user and the ticket, and the reliance on my shared server being up) but my 11-year-old self thought it was pretty cool. Just thought I'd share.
[+] [-] rubyrescue|14 years ago|reply
[+] [-] stickfigure|14 years ago|reply
I should be able to change my email address (and/or email hosting provider) without changing my identity on a bazillion sites around the internet. Facebook got this right from the beginning. Google is sort-of getting this, although the chasm between Google Accounts and Google Apps Accounts makes this really messy.
Really this product should be called BrowserEmailAddress, not BrowserID. It doesn't serve identity.
[+] [-] paulosman|14 years ago|reply
It's very similar to the countless existing services that rely on email for identity... you'd just have to verify ownership of the new email address (usually through a confirmation email).
[+] [-] arkitaip|14 years ago|reply
(One work-around would be to use an disposable e-mail address service and redirect your emails as needed.)
[+] [-] bct|14 years ago|reply
What a weird double-standard. A feature of email (that you can have several, and you can change which one you use) is a failure, and a failure of Facebook (that it's one site, forever) is a feature?
We're all familiar with ways to migrate from one email address to another. If/when you leave Facebook/it disappears, how will you migrate your identity then?
[+] [-] kmontrose|14 years ago|reply
In a practical "on the internet sense," your email really is your identity (maybe SSN or name would be a better description; you can change it, but to do so is catastrophically disruptive). After all if you can't be contacted you really can't be identified, and the universal way of contacting someone online is through email.
Now, you should definitely try and provide some redundancy (store multiple email addresses, long living sessions, whatever) and make your anonymous/unauthenticated/drive-by user experience stellar. But when push comes to shove if you can't send them a "forgot your username/password/open-id/samoflange" email, you've lost that user.
(anecdote: I've had the same primary email for >7 years)
[+] [-] JoshTriplett|14 years ago|reply
[+] [-] nw|14 years ago|reply
[+] [-] ignifero|14 years ago|reply
[+] [-] sirn|14 years ago|reply
[+] [-] mbrubeck|14 years ago|reply
[+] [-] jdunck|14 years ago|reply
[+] [-] cgranade|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] namidark|14 years ago|reply
[+] [-] kpanghmc|14 years ago|reply
Now, instead of simply having to remember what username/password combination I used, I have to remember which (if any) OpenID provider I used, how much information about myself does said provider expose, and how to merge my accounts when I inevitably end up choosing the wrong provider and create a duplicate account on the site.
[+] [-] ams6110|14 years ago|reply
[+] [-] drfloob|14 years ago|reply
[+] [-] AlexeyMK|14 years ago|reply
Identity is cool, but Facebook is winning the 3rd party connect game right now because it offers websites syndication, which is more valuable than just authentication.
I'd love to see a BrowserID that can also grant permissions to Facebook, Twitter, etc.
[+] [-] rlpb|14 years ago|reply
Why not have a new way of using X.509 in the browser? I'm not talking about client side SSL certificates as they are at the moment. I mean that on login to your mail provider the browser will automatically generate a keypair and get a certificate either from your mail provider or from a third party which has verified that you own the email address in the traditional way. This certificate will contain a Subject of [email protected], Issuer of either CN=example.com or CN=trustedverifier.com. Then the browser can just present that certificate as normal to destination.com, and perhaps only on request (so the user can choose whether to "log in" or not). If the issuer matches my email address domain then destination.com will fetch the public certificate of example.com to verify. If the issuer matches trustedverifier.com then destination.com will already know whether it wants to trust it or not and have the public key if it does.
This does seem to be what the article describes, only the article has more optional elements and re-invents some of the cryptosystem rather than re-using X.509.
[+] [-] dendory|14 years ago|reply
[+] [-] bct|14 years ago|reply
As a site operator, you don't need to choose which company you're going to accept as an auth provider, or have a login page with lots of icons on it; you just have one button that says "Log in".
[+] [-] yarone|14 years ago|reply
[+] [-] bct|14 years ago|reply
[+] [-] tobylane|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] shockie|14 years ago|reply
[+] [-] bct|14 years ago|reply
Having in-browser support for this kind of thing seems like a plus, too.
[+] [-] rufibarbatus|14 years ago|reply
But then, Google, Facebook and Twitter have reduced the friction for identifying all over the internet, so Mozilla is kind of arriving late to the party.
[+] [-] bruceboughton|14 years ago|reply
[+] [-] mbrubeck|14 years ago|reply
[+] [-] bergie|14 years ago|reply
[+] [-] bergie|14 years ago|reply
[+] [-] flashmob|14 years ago|reply
Websites providing a disposable email address are mainstream - even hotmail allows you to create them these days.
[+] [-] newman314|14 years ago|reply
So if a BrowserID user were to ever get their email service compromised, it's keys to the kingdom.
IMO, I think this needs a rethink.
[+] [-] caf|14 years ago|reply
[+] [-] pornel|14 years ago|reply
Yes, because e-mailed password reminders are keys to my kingdom already.
[+] [-] NHQ|14 years ago|reply
My immediate thought was that a browser-based ID implementation would let you keep secure credential on the computer, saved by the browser, up to and including pics, profile, etc. In other words, take social credentials native.