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.

cloudviews.org now supports OpenID logins

Identity Management and all the technologies that are related to it are one of cloudviews’ core subjects. Supporting a highly adopted open Identity Platform as OpenID is mandatory for us. We will continue to test other technologies, like  Information Cards (higgins) but with OpenID, for exemple, I’m already able to login with my I-Name: =paulo.calcada.  Unfortunately,  the OpenID module for wordpress is only able to recognize my I-Name in its URI version: xri.net/=paulo.calcada. But at least until XRI 2.0 is not approved or redesigned, the XRI_2_URI is acceptable  :).

With this feature all our authors will also  have their accounts turned into a OpenID account. They will be able to login in other OpenID enabled sites with www.cloudviews.org/author/foo_bar.

We will discuss OpenID with more detail soon. You can start exploring it by yourself at the OpenID site,  or if you want more advanced stuff you can take a look into this Nat Sakimura’s excellent post: “Problems of HTTPS (&HTTP) based OpenID“.