
Open ID Is A Nightmare - chanks
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
======
Groxx
So... the problem is that it's too easy to forget your OpenID / its login.

I propose that the main reason for this is because browsers (and password-
storing applications in general) have practically _zero_ support for OpenID.
It's all handled by hand. It's all in your head, and nowhere else.

Sorta reminds me of, oh... _browsers before password managers_. Far far more
people used only a couple username/password combinations, or stored their ones
in a text file somewhere. Now that managers are integrated, and secure
external ones exist, it's viable to actually be safer with your logins, and
many more people do so. And now I rely so heavily on my password manager, I
only know a couple key points-of-entry where its data is stored - the rest of
my passwords are all randomly generated.

OpenID is essentially the next step, and it's precisely the same end-user
problem. Imagine if browsers supported it natively via a profile-like system;
pick a profile, and every site you've associated with it is immediately logged
in for you. You'd be able to handle multiple people using your computer easily
- just enter a password to use that profile, and everything can be switched
for you. No need to launch that password manager for every site, you sign in
_once_ and everything is automatically connected from that point.

OpenID can be _significantly_ more user-friendly than username + password. It
just isn't there yet.

~~~
zaphar
I sort of think the problem is that many people have multiple OpenId
providers. It sort of reduces half the reason you want to use it. Originally
OpenId was a way to have one authentication for multiple services on the net.
However when you have a Google Account, A Facebook account, A Twitter
account... problems start happening. Which one did you use to login to this
service last time?

Part of the problem I think is that the providers don't act as consumers also.
If I originally had an open id somewhere then why can't I use it for facebook,
Google, Twitter, and whatever else. Each "Provider" that offers a service to
me which I want forces me to get yet another OpenId. At this point I think I
have rougly 4 different OpenId providers and with Google I have like 4
different id's. This gets unwieldy quick. The technology had promise but the
way it was rolled out and adopted by various folks caused it to suck a little.

Now I need an OpenId manager in my browser like I needed a password manager
before. How is this better?

~~~
jerf
"Now I need an OpenId manager in my browser like I needed a password manager
before. How is this better?"

What you really need is delegation. In a webpage, place in the <head>:

    
    
        <link rel="openid.server" href="openID server URL" />
        <link rel="openid.delegate" href="openID server" />
    

with appropriate values.

My OpenID is "ht​tp://jerf.org". I delegate that to AOL right now, but I can
change that to any provider transparently. (The ickiness of using AOL is
mitigated by the trivial way in which I can change it; which of the corporate
monstrosities auths me isn't very important, and of the various accounts I
have they were the first to be a provider.)

Having this implemented by your metaphorical grandmother is obviously a
problem.

Edit: And also, I'd observe that this solves _your_ personal OpenID problem.
It doesn't do a thing to solve the problem for a site trying to use OpenID,
such as the original article author, because telling everyone to delegate like
this is a boil-the-ocean solution in the context of cutting down support
calls.

~~~
jdavid
This will likely appeal to the identi.ca and diaspora crowd, but will not
appeal to the facebook crowd.

there are two problems with OpenID.

    
    
      #1 the UX has been killed by committee more than once. ( i should know I worked on it. )
      
      #2 OpenID does not offer value for one, let alone many OpenIDs.
    

Whether we like it or not. We need to get activitystrea.ms and the browser
vendors to probably make some collective bets on identity.

Password managers make some bets on input fields that use the password type to
manage login pairs, but I think we need to take this further.

I think we need to start having browsers connect cookies and openid redirect
flows to login pairs. I think we can observe openid login flows in the browser
and... remember them! I think we can link that to a browser profile, and I
think we can pair that to a cookie set. I think smart-identity-browsers can
suggest OpenIDs and make OpenID NASCAR obsolete, or at-least auto create a
popular field of buttons, rather than making that site specific.

This is probably not enough space to discuss in detail how I think the tech
can mature. but i think it's obvious that the future of the web is mobile, and
is identity based. these interfaces don't need to get a little bit simpler,
they need to get a lot simpler. they need to work on mobile phones.

a lot of the work i have done on OpenID comes to naught when you try to copy
that experience for mobile phones.

~~~
jerf
I find myself uncertain if you are actually replying to me, and if so, if you
understand what I mean by delegation. I thought more people knew about this,
but in the past few hours I continue to see a lot of comments that leads me to
believe this is not common knowledge and that not everybody understood what
delegation is.

When I give my open ID to a site (usually blogger.com to make a comment), I
actually type in "jerf.org" after the <http://> , with nothing else. I do not
have a provider set up, which I looked into but is a pain in the bum, and, as
it turns out, entirely unnecessary. Instead, the OpenID consumer hits the page
I gave (my domain's front page, as it turns out), finds those tags, redirects
to "whatever those tags say today", and then I log in that way. When I have
successfully logged in with the delegated service, then I have successfully
authenticated myself as "ht​tp://jerf.org". I say "whatever those tags say
today" because if I change those tags on that page to delegate to Google,
suddenly I can log in with Google, but I will still be authenticated as
"ht​tp://jerf.org". If AOL, my current delegate, decides to get out of the
OpenID business entirely, one minute with vim on my website allows me to move
it somewhere else, again, all along, I'm "ht​tp://jerf.org". This layer of
indirection solved all the problems I had with the idea.

I don't have "many" OpenIDs, the phrase of yours that led me to wonder if you
(and perhaps others) aren't following me here. I have one: ht​tp://jerf.org.
Of course like everybody else I can't even count the number of accounts I have
with various OpenID providers, but I don't care; ht​tp://jerf.org is my
OpenID, and will be until I no longer have the domain.

I also don't know why it would "appeal" to one of the crowds you listed, but
not others. The crowd it "appeals" to is the crowd that has control over a
website that includes the ability to set arbitrary tags into the heading of a
webpage, rather than a pre-canned HTML template that can't be touched.
Unfortunately, rather fewer people have websites with that amount of control
than I'd like.

~~~
lmz
"If AOL, my current delegate, decides to get out of the OpenID business
entirely, one minute with vim on my website allows me to move it somewhere
else, again, all along,"

I doubt that. "<http://jerf.org> is a string that you type into the OpenID box
("endpoint URL"?), not the ID itself. I use Google Apps and set my site up
using an X-XRDS-Location header so I can type in "<http://id.example.com> into
the box, but the identity the site gets is something like
"<http://example.com/openid?id=123456789>. This identity will probably change
if I switch to using AOL.

~~~
riobard
Not if the provider implements delegation properly. The identity string
returned should be <http://jerf.org> in this case.

The catch, however, is that many providers screw the identity up. For example
I set up a page at <http://foo.com> with necessary headers to delegate to my
Google Account. Using the OpenID support on App Engine, I get the federated
identity as <http://foo.com/openid?id=[SOME> RANDOM DIGITS] instead.

The idea of OpenID and delegation is awesome. In reality the millions
different implementations f __ked up the whole thing, not even to mention the
control and reliability issues.

~~~
riobard
Oh by the way, one more thing: if you supply <https://foo.com> instead of
<http://foo.com> to App Engine you'll get completely different identity back
as a result. This is just pure fun.

------
patio11
Having implemented it for a day job, there is no power on earth or under it
which can force me to ever put it in one of my products. OpenID doesn't really
have a handle on the problem it is solving and almost certainly pessimizes for
the metrics I most care about, like conversion rates, success with
signup/signin, customer support costs, and mental wellbeing among the
engineering team (i.e. me).

------
jrockway
The problem with OpenID is that everyone wants to be a provider, but nobody
wants to let me use it to log in. This means everyone has 10 different
OpenIDs, but only one place to log into. Very stupid.

~~~
david927
Not so much stupid as greedy. The user base is the juice. It's the most
important thing most big sites have, and farming that out to another provider
is giving it to them. No one wants to do that. Facebook is hardly going to
say, "Login with your Twitter account."

It was a nice idea, but the successor (and there will be a successor to
OpenID) will be more flexible and the sole provider. It's the only way it can
work.

~~~
rbanffy
> Facebook is hardly going to say, "Login with your Twitter account."

Not really. The value for Facebook is in the data stored on Facebook's
computers. Who provides credentials is not that important.

------
michaelchisari
This is one of the reasons your Open ID should have been formed like an email
address, ie, username@domain.ext

That way, sites can immediately tell the domain name of the provider, and the
user to verify, without having the extra selection step for the user. It's
also more familiar to users.

This is one of the reasons I decided to not go with OpenID as primary identity
authentication for Appleseed.

~~~
jomohke
OpenId does have this in the form of a URL as your identifier. If you had a
myopenid.com account, for example, you can login to your site using
'michaelchisari.myopenid.com'. That page will contain a metadata tag
specifying who your provider is (You could use any domain/page you control as
long as you add a metadata tag to it).

This is the default way that OpenID works -- The selection of providers is
purely a UI choice that has become popular by sites to hide users from URLs.

There's always still a box near the bottom that allows you to type in your URL
without picking a provider.

~~~
michaelchisari
True, however, michaelchisari.myopenid.com is not the same as
michaelchisari@myopenid.com, though, which I firmly believe if OpenID had
standardized on, what was lost in flexibility, would have been more than made
up through user adoption.

~~~
jomohke
Agreed. Though it would only work if email providers also became OpenID
providers (which admittedly would have been very possible), or else having two
things that look just like email addresses could cause similar confusion.

An advantage of URLs is that you have the choice of whether to give your email
address to the site. Myopenid.com will prompt you for whatever information the
site requests, and you can even choose which email address (if any) to provide
the site. Sites which use an email address for login currently require you to
remember which spam email address you gave them.

The indirection offered by URLs is quite powerful too: See jerf's comment:
<http://news.ycombinator.com/item?id=1916033>

------
mike463
As a user, I _HATE_ openid.

I use one unique username/password for each site I visit. My browser will
maintain this for the sites I'd like it to, and sites where security is
important, I type it in manually.

In my opinion, developers are being selfish. They want one of their coding
problems to go away (authentication and all it entails), at the expense of
their users.

With openid, I have to open two accounts. One on the site, and another
separate openid account to provide authentication. Problems? Well, it could be
one, or the other. Does the brower help me? NO. Does it make me feel more
secure? NO.

I used to contribute to stackoverflow, and then after having to deal with
openid all those times, I _STOPPED USING THE SITE_.

------
sams99
I agree, open id sucks. Or more specifically the billion different evolving
implementations of open id suck. Making your users feels stupid sucks and
having your business totally dependent on a third party sucks.

There is a lot of suck.

However, to balance things out, remembering 100 different passwords sucks.
Getting an email to 100 different users on 100 different MXs, without being
flagged as spam, sucks. Recovering an account when a primary email address
stops working, cause a user switched jobs, sucks. Having to change your
password every time you visit a site (cause you visit it twice a year), sucks.
I know: keypass, self hosted clipperz, passpack. They are all at best awkward.

So, at the end of the day, you are stuck making a decision that is sucky, no
matter what you choose.

When I built community tracker, I decided unique logins and valid emails are a
valid requirement, openid is a nice add-on. A year later hacks have been added
to the open-id code.. It is code I hate touching, with conditional edge cases,
and is super hard to test. I decided against RPX cause I dislike the idea of
adding one more business dependency. It just felt wrong. Honestly, I am not
convinced the headache was worth it. Users love to be able to click on the
google button and get access to the site.

When I am working on Stack Overflow, occasionally, I wish we had the "unique
valid email" and "unique login" requirements. The whole cookie based account
thing we have scares me (Jeff says it is what makes us better than all those
sites that use slimy tricks to get your email).

However, it is far from our biggest problem. It is very easy to create an
account, you can even answer a question without logging on using open id. The
amount of customer service emails we get with regards to merging accounts is
manageable. The majority of users, use the google button, and the google
button works. The merging / recovery process and overhead is annoying but, not
out-of-control annoying.

There are tweaks, we probably should not be rendering that scary URL Google
gives us. We should look at ways to cut down on support calls.

Overall, I agree, for a business that is selling stuff to its users, making
openid the only way for your customers to buy stuff may not a good idea.

However, for a business, that is trying to make the Internet a better place,
the dependency on openid and all the hacks that come with it, is tolerable.
And doing a little bit to stop users from adding, yet another password, to the
never ending pool of passwords has its appeal.

------
mechanical_fish
Seems like as good a time as any to ask, yet again:

Will I ever be able to use a simple username and password to log into a Stack
Exchange site?

Please?

------
mivok
It seems to me that the problem of multiple OpenID providers and people not
knowing which one they're using would be a lot less serious if all of these
companies that are OpenID providers actually accepted logins via OpenID
themselves instead of everyone paying lip service to the idea while trying to
be the one source of identity for everyone else. That way you could be using
the same ID for twitter/google/facebook etc. and when it says 'use your
google/twitter credentials to log in' then there is only one set of
credentials to use.

------
mcantor
I'm really surprised that this hasn't been solved by browser vendors yet.

You should be able to tell your browser about your OpenID account(s), so it
can keep you logged in constantly. "Hey! Your OpenID login has expired. Please
login again now, or hit 'Later' to see this prompt the next time you try to
access an account."

Then, when you go to a website that supports OpenID, your browser can tell it,
"Hey. Don't bother presenting us with a login prompt. Just check to see if you
have any accounts associated with these OpenIDs."

Of course, it can't be that simplistic, because the site needs to verify
authentication with _your provider_ , not your potentially devious browser.
But I feel like that is not a difficult problem to solve.

It's one-and-a-half steps. The first "half" step is "Logging in," because you
only have to do it once per browser session. The first real step is: "Go to
the site." Done.

~~~
wvenable
If you want to involve browser makers, why not eliminate the OpenID providers
entirely? If I can store my profile in my browser and allow/deny sending my
information on site-by-site basis we wouldn't need OpenID at all. And there
are already plenty of services to sync your browser information (logins,
bookmarks, history) to the cloud.

~~~
seanalltogether
Chrome should start doing this immediately, since they're one of the few
browser vendors that can easily tie a bunch of these services together.

------
xiongchiamiov
Of course, if people didn't have accounts with 10 different OpenID providers
in the first place, they wouldn't have to remember which one they used. It
seems like many big sites opted to become a provider rather than start
accepting logins from existing providers, for which I suppose I can't blame
them.

~~~
mivok
Why not blame the bigger sites? If they accepted logins from other OpenID
providers, then people would have a lot fewer possibilities to remember. I
honestly believe this is a big part of the problem with OpenID adoption
currently.

~~~
xentronium
The problem is that bigger sites don't want to depend on other openid
providers.

------
steven_h
I think that this isn't really a problem if you remember that your users will
forget which Open ID they used and if you allow them to use all their Open
IDs, bad things will happen.

When I implemented Open ID the last time I used their OpenID identifier and
then had their e-mail tied to that account, you had to have an e-mail so if
your OpenID didn't supply an e-mail then the web app asked for one. If you
tried to log in with a different OpenID and used the same e-mail, it would
tell you that you already have an account.

This doesn't solve the problem 100% but it helps, you just have to design your
applications assuming that you wil be the smartest person to use your
application.

------
terra_t
This is why I'm likely to use Facebook Connect. Sure, some people hate
Facebook (maybe I lose 20% of sign-ups) but giving people 30 million choices
causes them to freeze up (lose 80% of sign-ups)

~~~
nkohari
Or you could lose 0% of signups by asking for a username and password. (Well,
okay, there might be a small margin of people who refuse to sign up -- but if
they're _that_ picky, you probably don't want them as your customers anyway.)

~~~
albertzeyer
If it is some random site I am visiting where I have not been before, I will
much more likely login via Facebook Connect or OpenID than going through some
registering (where I usually have to figure out what types of passwords it
accepts, about a free username, and wait for an accept mail and all that
through a terribly annoying and slow guidance).

~~~
nkohari
I definitely agree that for some sites, the signup process is too entailed.
For me though, the barrier is usually identifying myself rather than having to
create a login. If the site has something compelling enough for me to identify
myself to it, then it's not that big of a leap to create a username and
password.

------
djacobs
This is the problem i-names are intended to solve.

An i-name is a short name that looks something like =name. So instead of your
OpenId URL, you can type in =name in _any OpenId form_ and it will log you in
as usual.

So instead of name.myopenid.com, I'm =name.

There are registrars who sell an i-names for relatively cheap. (There are also
free ones.) The i-name points to the broker's lookup service. In their
database, your i-name is associated with a unique number that you keep even if
you let your name expire.

That entry points to an XRDS document, and that document tells the login form
a number of things. Most importantly, it tells it your OpenId URL. It also
provides a series of forwarding addresses that look like this:

    
    
      =djacobs/(+blog)
      =djacobs/(+contact)
      =djacobs/(+twitter)
    

Et cetera.

My favorite is =djacobs/(+contact). It points to a page on my broker's site
with a contact form. This contact form knows my e-mail address, and people can
use it to e-mail me without finding that address out--like any other contact
form. More importantly, the form comes with useful spam-fighting settings,
options like "don't let anyone e-mail me without an i-name of their own".

I happen to think i-names are pretty cool and will tend to make everyone
settle on one ID. Maybe a good vocabulary will come out of the forwarding
syntax, and we can approach a loose Semantic Web using i-names instead of URLs
and triples.

Caveat: As of now this is painfully tedious to set up for the average user.
Eventually, though, people will see the merit in this approach, and more
competition in this market will drive a user-friendly setup.

For now, it's just for hackers.

~~~
nkohari
How is this in _any_ demonstrable way better than a username and password? I
can't even imagine trying to explain how to use this to my parents.

~~~
djacobs
Your mother doesn't _need_ to understand it. I gave the technical details
because this is _Hacker News_. Brokers need to make setup simpler, yes. But
even today, logging in is as simple as typing =djacobs.

~~~
nkohari
Or I could type nkohari and a password...

~~~
djacobs
Exactly. This eliminates 50% of the hassle. Maybe 75% of that if you consider
having a single name to type in on any site on the Internet.

~~~
nkohari
I don't understand how that's the case. You still need to authenticate with
your OpenID provider using -- you guessed it -- a username and password.

Or, you could allow your provider to put a persistent cookie on your machine,
and (as we've seen from the Firesheep news lately) making it that much more
likely your identity will be compromised. (Not to mention if someone steals
the cookie for your OpenID provider, the impact is potentially much larger.)

The i-name stuff is just DNS for OpenID providers. It adds another layer of
bullshit on top of layers of bullshit that don't need to be there in the first
place.

I carry the key to my car. When I want to get in, I press the button on the
fob or I open the door with the key. OpenID is like having to make a phone
call to someone, tell them I need to get into my car, so they can then press a
button that will open my car door. And hopefully they aren't on their
lunchbreak.

~~~
djacobs
If I had 60 cars scattered around the city, well, I'd want that phone service.

Security issues are not unique to i-names, and I think the abstraction layer
(removing a domain name from your login) is important and useful.

Disagree if you must.

------
joedaltonwallas
Why people are so frightend of storing the salt & hash of the user password?
May be I am mistaken but if the salt is unique for each hash it is almost
imposible to recover the original password. Of course you must use a well
proven encription library but it is trivial. Am I missing something?

~~~
moshezadka
Yes, you are missing one thing: if you are storing that file, a security
breach (several kinds of those) means an attacker can get that file. Are you
thinking this is not a problem? Think again!

* For "moderately" strong passwords (say, ones which need 10,000 attempts to get), getting at your encrypted files means the difference between you being able to throttle-and-disable a serial guesser and having the password hacked (bonus points if that was the password your user uses on other sites with the same usernames.) * An attacker can go over the file to find "extremely" easy password for _some user_. * A determined attacker can test hundreds of millions of passwords for a specific user, and _know when he succeeded_ , before you ever notice it. So unless your website has a "change password every year" policy, the attacker can breach even "moderately strong" passwords.

This is even before issues like "well proven encryption libraries" are still
broken, and if the one you used is broken, _your file is still out there_.

This doesn't mean that it cannot be done, with enough care -- but it _does_
mean that if you _avoid_ doing it, it's a big relief, and a big potential
crisis averted.

~~~
joedaltonwallas
please correct me if I'm wrong: you are not storing passwords, you are storing
hashes & salts. One different long random salt for each password.

In my database I store hashes obtained with Blowfish:

[http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-
stro...](http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-
password-hashing-for-dotnet-and-mono.ashx)

How many tries would you have to do to guess it? And for the other passwords
you have to start all over again.

------
indiejade
The spirit of the OpenID concept is a good one, though. I'm one of the people
who attended the first OpenID dev camp (before OpenID was adopted on a wide
scale) [http://openid.net/2008/01/14/the-first-openiddevcamp-was-
a-s...](http://openid.net/2008/01/14/the-first-openiddevcamp-was-a-success/)
and there was (and arguably still is) a need for something like it.

The main problem is that it complicated things when it originally set out to
simplify them. Power users are hesitant to consolidate all their user names
and passwords into the ultimate master key; from a security standpoint, better
to use separation of control _when_ users are also smart enough to use
different names/passwords across a variety of sites.

------
nikcub
Great post - but yet another example of a blog without a sidebar or header.
When I got to the point where you started talking about your own company I
scrolled up and down to find a blurb about it. You introduced your company
name assuming we know who they are and what they do.

This happens far too often, help us out by adding a box in the sidebar
something simple like:

Hi my name is _name_. I am the _position_ of _company_ , a _what we do_
service that was launched _whenever_. To find out more about us, visit our
_homepage_ or _signup here_

Even better, include a mugshot so we know who is talking to us. People like
faces, it's comforting :)

------
gibsonf1
We've set up openid+oauth with Google Apps Marketplace, and the solution there
is very elegant. Users from their google apps gmail interface can select an
app from "more" and get automatically logged in to our web app. (using
extended cl-openid for google app domains and cl-oauth)

------
ancymon
In my opinion author should first read OpenID specifications and implement
some "best practices" ([http://wiki.openid.net/w/page/12995223/Relying-Party-
Best-Pr...](http://wiki.openid.net/w/page/12995223/Relying-Party-Best-
Practices)). Doing so might have solve his "problems". I think to make user
"NOT to feel stupid" it's better to implement OpenID properly than quit it.

1\. The OpenID specification suggests that user should be able to associate
multiple identifiers with one account. That way if you store user's email
address, he can easily add new OpenID account even after he lost/forgot his
identifier.

2\. You can't expect that OpenID provider has enabled extensions which give
away user email. User can also decide not to provide his e-mail. If that's not
provided you can ask user to fill a registration form "manually".

And by the way, I think that remembering who is your OpenID provider is still
easier than remembering login and password.

~~~
robconery
It's a fair point - the problem is that if I'm going to ask for a
user/password for a master account then... WTF do I need OpenID for?

Also - in terms of reading the spec - we use JanRain/RPX so I let them worry
about that.

