Home » Cool & Future Tech, Digital Identity

OpenID? Huh?

28 January 2007 One Comment

I don’t understand OpenID [LINK]. I’m sorry. I’ve tried to understand it but I just don’t get it.

The spec is confusing but thankfully Phil Windley has translated it into a diagram for us mere mortals [LINK].

The idea of OpenID is to provide "an open, decentralized, free framework for user-centric digital identity."
And here’s how the flow works (at least one of the scenarios).  Note I’ve taken Phil’s explanation and augmented it with my own understanding:

  1. User is presented with OpenID login form by the Consumer
  2. User responds with the URL that represents their OpenID (for example "FrancisShanahan.myIDServer.com"). Now the Consumer needs to determine if I actually "own" the URL I’ve specified.
  3. Consumer canonicalizes the OpenID URL and uses the canonical version to request (GET) a document from the Identity Server.
  4. Identity Server returns the HTML document named by the OpenID URL
  5. Consumer inspects the HTML document header for <link/> tags with the attribute rel set to openid.server and, optionally, openid.delegate. The Consumer uses the values in these tags to construct a URL with mode checkid_setup for the Identity Server and redirects the User Agent.  {fs: Said differently, the consumer directs the user to login at their ID server.}   This checkid_setup URL encodes, among other things, a URL to return to in case of success and one to return to in the case of failure or cancellation of the request
  6. The OpenID Server returns a login screen.
  7. User sends (POST) a login ID and password to OpenID Server. {fs: I assume you can authenticate how ever your OpenID server likes}
  8. OpenID Server returns a trust form asking the User if they want to trust Consumer (identified by URL) with their Identity
  9. User POSTs response to OpenID Server.
  10. User is redirected to either the success URL or the failure URL returned in (5) depending on the User response
  11. Consumer returns appropriate page to User depending on the action encoded in the URL in (10)

Ok, makes sense but there’s an obvious problem as Kim Cameron correctly points out in this post [LINK].

If you assume the Consumer is evil, they can take the openID URL from step 2 and instead of directing the user to that legitimate URL, they can substitute it with their own faker site. This site’ll look EXACTLY like the one the user’s expecting. The user unwittingly enters their credentials and the scenario continues as normal. The user’s never aware that they were phished.

Clearly there’s a piece missing that Kim claims can be provided by the Cardspace ID selector. By integrating OpenID with Cardspace you can avoid malicious redirections and phishing in the protocol. But then what’ve you actually achieved? You’ve just re-invented the WS-* wheel all over again using redirects and a browser? So what’s the point?

I don’t get it but this is dark mojo and I’m probably missing something somewhere.

One Comment »

  • Nic Ferrier said:

    It’s true, right now OpenID is able to be spoofed. Though most of the OpenID providers are taking steps to make that very difficult.

    But I have solved the problem entirely with my OpenID provider: http://prooveme.com

    It uses client certificates to identify OpenID users. There is no way a consumer or any other party can fool the SSL implementation except DNS poisoning and that’s an attack none of us can get round.

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.