OpenID/OAuth – a step forward in the Interoperability field

As Reuven reported in the CloudForum Google Group, Google has released its OpenID/OAuth  implementation. This is a major step forward in the Interoperability field. This example is fundamental to show how it’s possible to add real “conversation” capabilities (or information exchange) among Cloud Computing Service providers.

As I’ve already said, instead of developing new tools or platforms, reusing old ones and trying to combine them is, in my perspective, the only way to achieve real Interoperability in the Cloud. Cloud Computing is something that must be a reality now, we must not be forced to wait for future or complex interoperability platforms.

The work that Google has released is very important and it will allow, for instance, that a user from Zoho Writer can use data from a Google Docs Spreadsheet and then make the result available in his Linkedin profile. This is a theoretical example, but it’s intended to demonstrate the power of these new tools.

In other perspective, with OpenID/OAuth (and also maybe using I-Card/Higgins) we’ll be able to deploy Identity Management platforms (authentication and authorization) in a federated way, but without the need to use closed solutions. These federated platforms are very common in academic institutions. Even though these federated IdP are usually built with open technologies, like the OASIS SAML specifications and Internet2 Shibboleth software, they lack real Interoperability capabilities. They have very inflexible IdP discovery mechanisms, and users’ attributes or users’ data sharing mechanisms. Despite all the excellent work that is continuously done by Shibboleth, and even with the recent introduction of SAML2.0, these problems are still unsolved. Using the OpenID/OAuth approach, the federated IdP will definitely obtain major benefits.

[updade 23/07/09]

This short post  has been discussed in the projectconcordia mailing list: (http://lists.projectconcordia.org/pipermail/community/2009-July/002007.html), and I think I should clarify some of my initial thoughts. First, this is not a “OpenID Vs SAML” text. I’ve worked with both in the past and I’m continuing develop this work in an integrated way. I’m responsible to manage and develop an SSO platform initially  designed to support  SAML  2.0, and I’m now updating this platform in order to support OpenID as well.

Another short note, when I was talking on  SAML 2.0 being only recently introduced, I was talking on the context of the Shibboleth stable versions.

Share/Save