OpenID? Huh?

In a posting called “OpenID? Huh?“, Francis Shanahan, whose job it is to worry about high value financial transactions and strong assertions about molecular identity, wonders why OpenID is nothing more than a reinvention of the WS wheel.  

“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 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.”

Let me clarify what really happens.  Let's go back to step (2) above.  We know Francis by his blog URL – http://www.francisshanahan.com.  So if he was going to leave comments on my blog, he would most likely use his own blog URL as his OpenID.

Note that his blog URL isn't an identity server.  So in step (3), the consumer doesn't contact an identity server – it requests and gets Francis’ actual web page (or, at least, its header).  As explained in step (5), the header contains a “link” element telling the consumer who to trust as the identity provider for this page.

Now, in steps (5) through (10), the user is redirected to the identity server, enters his credentials, and picks up a coupon that he gives back to the consumer after another redirect.  Behind the scenes, the consumer then sends the coupon back to the identity provider (using a backchannel) to see if it is valid. (There is a potential optimization that can be used here involving exchange of a key – but it is only an optimization).

So let's think about this.  Where is the root of trust?  In conventional systems like PKI or SAML or Kerberos, the root of trust is the identity provider.  I trust the identity provider to say something about the subject.  How do I know I'm hearing from the legitimate identity provider?  I have some kind of cryptographic key.  The relevant key distribution has a cost – such as that involved in obtaining or issuing public key certificates, or registering with a Key Distribution Center.

But in OpenID, the root of trust is the OpenID URL itself.  What you see is what you get.  In the example above, I trust Francis’ web page since it represents his thinking and is under his control.  His web page delegates to his OpenID identity provider (OP) through the link mechanism in (5).  Because of that, I trust his identity provider to speak on behalf of his web page.  How do I know I am looking at his web page or talking to his identity provider?  By calling them up on DNS.

I'm delving into the details here because I think this is what gives OpenID its legs.  It is as strong, and as weak, as DNS.  In other words, it is great for transactions that won't attract criminal attack, and terrible for those that will.

This now brings us face to face with the essence of the metasystem idea.  We don't live in a one-size-fits-all world.  Identity involves different – and even contradictory – use cases.  Rather than some monolithic answer, we need a metasystem in which the cost (in complexity or money) of using identity is proportional to the value of the asset being protected.  OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages.  But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.

The way I see it, there is a spectrum with DNS-based technology at one end and hardware-backed crypto technology at the other.  If we can get this continuum structured into a metasystem, the dichotomy between RESTful and Web Services approaches can be changed from a religious war to simple selection of the right tool for the right task.  That's why I want to see OpenID as an integral part of a metasystem providing a common experience while respecting the economics of identity.

This having been said, Francis is right for asking whether we've “just re-invented the WS-* wheel all over again using redirects and a browser?”.  While I think it is known I'm a strong supporter of SAML as a step forward for identity, I've been an equally vocal advocate of separating communications protocol, trust, and token payloads.  OpenID has a different token payload and trust system than SAML, but if the three axes had been properly disentangled, you could imagine OpenID as a very simple SAML profile.  Because of the entanglement, that can't be the case.

WS-Federation (possibly misnamed…) doesn't have this problem.  It can carry any token, and use any trust framework.  OpenID would work inside the WS-Federation protocol patterns, and would be able to retain its payload and trust structure.  So could SAML for that matter.  So there is the “theoretical possibility” of merging all these things.  Will it happen?  Someone would have to pass out large quantities of pain killers, but there is a possible future in which, over time, they converge.