

How BrowserID differs from OpenID - joeyespo
http://identity.mozilla.com/post/7669886219/how-browserid-differs-from-openid

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

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

~~~
sambeau
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?

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

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

~~~
wmf
If you have browser support, the browser could log you in to your OpenID
provider so there'd be no popup.

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

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

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

~~~
pornel
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).

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

~~~
capnrefsmmat
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>

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

~~~
JoshTriplett
BrowserID only depends on a third party if you have a browser that doesn't
handle BrowserID natively.

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

------
aaaaaaaaaaa
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...](https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest)

------
HedgeMage
FAIL

Why would I want to use my email address as an identity? I already get more
than enough spam.

~~~
wisty
Virtually every site does this already, this just makes it more constant,
secure, and convenient.

~~~
drdaeman
A lot of experienced users out there tends to provide each service a different
email address (username+servicename@example.org, servicename@bar.example.org,
etc.)

BrowserID breaks this.

~~~
wisty
BrowserID allows multiple emails, and I've tested "me@gmail.com" and
"me+test@gmail.com", and both work.

I guess it can't be 100% automated, but you don't want automated logins
anyway.

