Last month I commented on the pluses and minuses of OpenID’s rise in the identity/authentication space (see “OpenID’s growing pains”). I should note that, due to the open source nature of OpenID and the collegial development effort of many people from many different organizations, any disagreements about the direction the protocol/specification is taking are almost always very public (see the mailing list archives for some fascinating discussions).

When one company is developing a spec - such as Microsoft with CardSpace - or a relatively secretive organization is doing so, e.g., the Liberty Alliance, these same disputations may be occurring, but no one outside the organization can see them.

One major fault-line in OpenID is the transition from the 1.0 spec (which was, essentially, a way to combat comment-spam in blogs) to the full-blown identity service that’s embodied in the 2.0 spec. Many are attracted to the simplicity of 1.0 and put off by the complexity (since other protocols and methods need to be included, such as I-names, SAML and CardSpace) of the 2.x progression. The OpenID group has taken the stance – the only reasonable one, I think – that both must be recognized. That is, a relying party (RP - the site wishing to accept an OpenID assertion) must differentiate between the 1.x and 2.x specs and is at liberty to support both or only the simplified one, so long as it reports this to the user. It’s not ideal, but it does keep the spec from “forking”, which could happen if it was required that OpenID RPs only accept 2.x while the earlier spec was promulgated as, say “OpenID Lite”. That would mean two separate development paths, and that’s never a good thing.

I did notice one off-putting comment in a recent story about OpenD in that august U.K. publication, The Times. In a story about single sign-on (“Can't remember your password? Don't panic”) Sxip Identity’s Dick Hardt – one of the co-authors of the OpenID spec – told the Times reporter that OpenID’s “role was to provide the standard by which Web sites requiring authentication talked to one another, rather than to set security standards.”

This, unfortunately, goes to a deep division in the OpenID community. It raises the question that, without defined security mechanisms can any relying party actually rely on the trustworthiness of the OpenID provider invoked by a user? Phishing, man-in-the-middle attacks, hijacked OpenID provider sites – the full panoply of Internet malware is lurking, waiting for the unsuspecting user to divulge identity data. It is imperative that any specification for the exchange of identity data (e.g., CardSpace, Liberty Alliance, etc.) should include specific requirements for security. Without that security, OpenID might just as well revert to the 1.0 spec and remain a quaint way for blog authors to login to other blogging sites.

Dave Kearns is a consultant and editor of IdM, the Journal of Identity Management.