Mike Graves and I will be speaking at RailsConf on Friday. I am looking forward to three fun filled days in the windy city.
I don't want to sound like I am a programmer or a seasoned developer. I am not! But I have always been a hacker -- dangerous enough to build functional prototypes but not quite at the level of building full fledged applications. Big fan of working prototypes where end users can experience the solution first hand rather than see it in powerpoint slides. As a product manager in my previous life, I preferred building working wire frame prototype than writing long and detailed PRDs or MRDs. I feel it is important to involve the end users early and often. And in many cases the end users are not expert programmers, product managers or QA testers. They cannot take the leap from a powerpoint slide to the real system that will be delivered on their desktops. I like to keep things simple, focus on the end goal and not get too wrapped up into the weeds before an idea is vetted out. I feel it is important to experiment with different approaches before settling on a long term road map. All this is easier said than done, especially when building a small working application is an effort measures in "weeks". That's where you do a reality check and start compromising. I was looking for a "week-end" solution to prototyping. And then I discovered Ruby on Rails a few months back...

Rails was just perfect was what I was looking for. Simple, clean and very easy to put together. With Rails, I can spend more time thinking about "what" I want in my application rather than "how" do I code it. I find it very refreshing to be able to attain the results with very few lines of code. "Less" is very much "more" in the Rails world. I attended Rails on Canada and was swept by the momentum. Met a lot of folks who were doing much more than prototypes. It became abundantly clear that this stuff has legs and is on its way to change the web development landscape is a big way. A lot of very smart and motivated folks are trying to build meaningful applications that in most cases are focused on solving a specific problem. Putting my identity hat on, I feel we need to make it easier for folks to enable their applications to start using a common identity framework and not follow the footsteps of adding more peals to your Identity necklace.

Mike and I will be talking about what is available to a Rails programmers to enable their applications to user OpenID. We realize that not everybody in the audience will be familiar with the background of some of the Identity initiatives. So we will introduce the topic and show you how an application can support OpenID. If you are going to be at RailsConf, I look forward to meeting you in person.

Here is a blurb that will probably appear in the conference program -

Come on, admit it. After you warm up and get ready to write you Rails application, you start by creating a user table with ID and password columns. Well, okay some of us use a plug-in or a generator. But do you realize that you are forcing your users to create yet another userid just for your application. And you are not following DRY!

In this talk we will present an easy way to enable your applications to support OpenID. It is an interoperable protocol that enables users to use their identity with your rails applications. Think of it as a Visa credit card - get once, use anywhere Visa is accepted. Millions of users will have an OpenID, and we will be using a OpenID plug-in to boot strap your rails applications. The plug-in is open-source, free and ready to use. We will build an app from scratch in the talk and tell you more about other goodies that will follow..

Posted by at 10:52 AM | Permalink | Comments (0)

I wrote about the Identity necklace and did get some comments about the post. From a user standpoint, it is clear that carrying different IDs around is an annoyance, but there seems to be wide variation in how willing people are in putting up the inconvenience. From an application standpoint, there is a significant difference between retrofitting an existing system to inter operate with other systems and designing systems from the ground up to co-exist with other applications and services. The former can be a much involved problem based on the complexity of the existing system. As for new applications in the early stages of their development, it is not too late to make interoperability as a "must have" design goal.

The obvious follow up to this discussion is about tools and technologies. What makes it even more challenging is to make design decisions in the early stages of an evolving ecosystem. It becomes important to follow and track the standards without compromising innovation and creativity. OpenID is a standard that can be the underlying principle of an open, extensible, and royalty-free identity system for the internet. Mike Graves has explained how getting and OpenID from the Verisign Personal Identity Provider can get you a glimpse of things to come.

Here is a story of a company that has shown tremendous agility and made a swift move away from the old way of doing things. I met Terrell and Fred at the IIW 2006 in Mountain View a few weeks back. They had skipped their finals to be at the conference. They have a neat idea to let people take control of their "Google Resume". They had an almost predictable starting point in how users would start using their service. Users are shown the familiar screen to sign-up, choose an username ... you know the routine! When you are done, add one more pearl to your Identity necklace! They have since revamped the service to support OpenID. Now I can use my OpenID to signup into their service. How refreshing!

Terrell and Fred built ClaimID with Ruby on Rails. They are not the only ones embracing Rails as a development platform. It is considered as one of the hottest technologies around and is gaining tremendous momentum. I have been following Rails for a while and will be speaking at RailsConf in Chicago this Friday.

Posted by at 04:55 PM | Permalink | Comments (1)

I often ask folks about the number of different user IDs and passwords they have for the various web sites they regularly visit. The answer is almost predictable -- more than 10 (always given with frown or an annoyed look). Some folks though sheepishly admit that while they have 10 different web sites they visit, they use the same password at all the sites. They also pull out their key ring and show me the 10+ loyalty card their grocery stores, pharmacy stores, gas stations gave them. Some are bitter about the hassle and the extra junk they need to carry with them. Some on the other hand don't mind the annoyance in carrying the cards around to be able to save cash on their next purchase!

While folks get discounts and real savings in the retail world, they are not saving any cash by using different usernames on the web. What surprises me is that most people take this in the stride and put up with the annoyance. The minor annoyance turns into a major hassle when the site policies change. Another common occurrence is when you forget the username or the password. The "remind me" button then becomes the most frequently used page on the web site. This multitude of usernames or credentials needed to access various web sites is a direct effect of how the web evolved in its early days. It was all about the particular site providing services to the users and there was not much incentive or need to think about the site as a part of the ecosystem. When you went to hotmail to get your free email, it was okay to sign up with a name that was available. But then came photo sharing sites, the bank(s), your utility companies, the baseball leagues web site, the on-line merchants who sold you books, clothes, electronics and pretty soon you had more logins than you care to remember. Sounds so web 1.0! Doesn't it? How long will users continue to get around with the shackles from the web 1.0 era ? Not for long would be my guess -- if there were a better alternative.

The explosion of the Web 2.0 world has exponentially increased the number of web sites. Increased is the sophistication of the services they provide and I notice a laser sharp focus in the definition of what the sites hope to provide. This has a direct impact on your userID necklace! What used to be 10-15 sites is quickly going to be
20+ different web sites you visit on a regular basis -- all with different policies, with different requirements for the length and content of your password.

Is there a solution here? This has been discussed before -- multiple times. Several solutions have been proposed, trialed and rejected. A solution that has a good chance of succeeding has to be simple -- simple enough for my grandmother to understand. In the past, some solutions have tried to do too much and that has not been well
received. It has to be light-weight and easy to implement so that developers are relieved of the tedium of the repetitive tasks they do today for every application they build. And last but not least, it needs to be open. I feel "open and simple wins".

Posted by at 04:16 PM | Permalink | Comments (1)

I'm happy to welcome my VeriSign colleage Kiran Dandekar to the Infrablog. Kiran's working with me on the team here that is building infrastructure and tools around open identity. He's become increasingly central on our team and visible in the community in building technical consensus and business momemtum around OpenID and our Personal Information Provider. We'll be adding a handful of team members to the Infrablog in the next few weeks.

Kiran's just your run-of-the-mill-MIT-PhD Boston Red Sox fan and family man. He previously did some cool stuff over at MicroStrategy before coming to VeriSign a couple years ago to help build our supply chain business.

Welcome Kiran!

Posted by Michael Graves at 03:52 PM | Permalink | Comments (0)