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.

Interoperatibily, Interoperatibily, and Interoperatibily

In my post, that’s a follow up of Reuven Cohen initial thoughts about UCI,  I’m  analysing the same point of view of this new Reuven Cohen’s post.

We already have a lot of technologies that could be used as a starting point to make this Cloud world a better place in the interoperability perspective. As Reuven  also said, Cisco is moving in this direction, but you cannot forget other examples, as the recent work done by Microsoft with its Azure and Geneva. In contrast to what they usually do, this time they could (in same aspect) be used as an example.   I’m following closely the work on the Geneva platforms, and Identity 2.0 platforms,  but Azure also has interesting architect decisions.

Why are we so afraid to move to the Cloud?

Every remembrance that I have from a usual visit to my bank in the nineties, when I had started managing my own (small) bank account, always begins with a large standing queue.  But, suddenly, everything changed, and my dark remembrances were transformed into an “easy as click” sensation.

This new “click experiences” didn’t  have an easy start as I now remember it. In the begining, I had the same doubts and fears as everyone had. To have private information on the Web, especially the one’s regarding financial situation,  accessible to everyone, was a “terrifying” sensation. This “terrifying” sensation was always in opposition to the excitement of having a powerful personal finance managing application, and more, an application that we could used everywhere and on every scenarios – being on vacation and have the possibility to pay a bill that we had forgotten; making a last hour stock action’s investment; make a bank transfer to a friend; etc.

Those scenarios were, in fact,  very exciting, but as I vividly remember, the fear from losing the control over this new powerful application, and consequently, lose the control of our personal finances was always evermore present.

And how did this end? How has this incremental fear stopped? The answer is obviously not simple, but definitely, it must be related with reputation and trust links, I’ve already talked about that in a previous post. In this example, the solid reputation that the banks had,  together with a large development in security technologies,  were fundamental to create the trust links and to allow a phenomenal development in the home banking applications field.

And now, why are we so afraid to move to the Cloud? Why don’t we let ourselves be embraced by the power of having all our applications on the Web, not only our personal finances’ application, but all of them? My simple answer is: We don’t know what is the Cloud, or even, what is the Cloud is made of.

We must first realise that the Cloud is a group of services providers, like our bank an its home bank application. We must realise that, and then wait to see how these new service providers will construct their reputation and  how that reputation will be able to enhance our trust feeling.

I can now say that we should consider home banking as pre-historical Cloud Computing and an example to follow.

PS:
We are in an era where the banks’ reputation is not what it was back then, although this is completely out of the scope of this post, I think that this is something that will change. It must. Without this thing called reputation we won’t have the trust that has made possible this pre-historical Cloud Computing…

AWS Management Console – power to the users

Amazon has recently introduced its management console to the EC2 platform. This is a major step forward and gives users real power and control over the EC2 infrastructure. This console not only provides the tools to manage all virtual EC2 instances, but also gives access to a large group of AMIs ( Amazon Machine Images) built by the AWS community.

Quote from the AWS site:

“…The AWS Management Console gives you a quick, global picture of your cloud computing environment so that you can see what resources you’re operating and conveniently manage those resources…”

Although this is a real step forward, this seems that Amazon guys still have a lot of problems to solve, the most relevants are the security of its access control infrastructure, and also the dependencies over the quality of users’ network (Internet Access).

CloudAve have also good points about this: http://www.cloudave.com/link/amazon-web-services-makes-it-easy-for-the-hackers-oops-users

AMD plans supercomputer with 1,000 GPUs

Quoting a news article from CustomPC:

«AMD’s president, Dirk Meyer, revealed the plans for the supercomputer, called the Fusion Render Cloud, at the Consumer Electronics Show (CES). The colossal machine will be powered by AMD Phenom II processors and 790 motherboard chipsets, along with over 1,000 Radeon HD 4870 GPUs.
The company claims that one purpose of the system is to ‘deliver video games, PC applications and other graphically-intensive applications through the Internet “cloud” to virtually any type of mobile device with a web browser.’ The idea is that the Fusion Render Cloud will do all the hard work, so all you need is a machine capable of playing back the results, saving battery life and the need for ever greater processing power.
AMD also says that the Fusion Render Cloud will ‘enable remote real-time rendering of film and visual effects graphics on an unprecedented scale.’ Meanwhile, game developers would be able to use the supercomputer to quickly develop games, and also ‘serve up virtual world games with unlimited photo-realistic detail.’
»

Although the concept is not new, this seems to be a interesting move from AMD. The main problem to be addressed and necessarily solved is latency (the time delay between the rendering on the supercomputer and presenting the image on the remote client), which depends mostly on external factors…