Tuesday, February 20, 2007

Digg and OpenID

Well, I knew it would eventually happen- a popular OpenID Digg article. I was curious, however, the form it would take. And now that Digg has thrown its support behind the initiative, the Web 2.0 community has taken notice. Here's the article I found:

Here are 5 reasons why I think OpenID Rocks:

1) 1 ring to rule them all - why wouldn’t you want the ability to have 1 sign-in across all blogs?

2) Bye-bye comment spam.

3) Verify who is actually making comments. Many fake Matt Cutts’, Jason Calacanis’ make comments and require verifying IPs or other time-consuming checks when prolific people do comment.

4) MyOpenID’s (inaptly-named) affiliate system is a nice tool for developers and large site owners.

5) De-centralized authentication leaves no single player holding all the cards.

Here are 6 reasons why OpenID sucks

1) It is (as yet) too complicated for average website owner to implement.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Now, there's a variety of misconceptions as well as informed points in this piece, but it represents the common perception of OpenID by a relatively "enlightened" Digg user. Similarly, the Digg comments always make for great reading. Here, a response to the above:
I'm getting sick of this FUD over OpenID. It has THE SAME "TRUST" AS EMAIL BASED AUTHENTICATION. The only differences are:

1. You can change your provider at any time but keep your same openID (a plus)
2. They can't send you anything (another plus).

YOU manage your authentication. They don't need to send you password resets etc. They don't have an email address to sell to a thrid party, or to spam you with their product "newsletters". OpenID is BETTER than email based account management.

The only true con is that you REQUIRE a website (1 page) to use one.


1) It is (as yet) too complicated for average website owner to implement.

Uh.. you paste a line of html into your index page.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

It's as secure as email as a login mechanism. If your webserver is compromised you lose. If you email server is compromised you lose. How is this any different?

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

Yes there is. You don't link to the fake Mark Cuban's provider in your page. It's as simple as that. What's to stop someone from making a fake email address claiming to be you?

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

This is called RTFM. Put "openid" into any search engine and there's your answer. If someone knows enough about OpenID to want one, they will be able to find out how to get one.

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

This has nothing to do with OpenID as a standard. Just the quality of the particular plugin you're looking at.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Your "security" on financial sites is only as secure as the email address you associate with it. Your online banking security is only as secure as your email account.

Just as with email, you can be your own provider. There is no requirement to EVER trust a third party.

The ONLY WAY to compromise an OpenID account is to either compromise the webserver hosting the link to the provider, or to compromise the provider. If your email server gets compromised its the SAME RESULT.
While I'm not going to sit here and detail the problems with both posts, it does represent the understanding and perception problem that OpenID currently has. I believe it only goes to further my assertion that OpenID is still not ready for the limelight. Digg's adoption of the standard is certainly a boon for the OpenID community, but it may lead to a new group of users which is blindly passionate about technology they do not fully understand. (See above)

I'm not posting this to disparage the Digg nor the OpenID communities, but I do believe that the OpenID guys owe it to their prospective users to discuss the pros and cons of the technology. (Some of which I described in my last post)

1 comment:

steve said...

In regards to the last reason that OpenID sucks right now:

The team I work with is developing a beta implementation of strong,
multi-factor authentication for OpenID,
TrustBearer OpenID.

We've been concentrating on simple user experience at this point,
and we are interested to learn what sort of features user will look
for in this type of implementation.

With our OpenID, you basically just set-up a strong authentication device
and then link the device to your OpenID URL.