40 Something Geek!

Browser supported Single Sign on with Email Addresses

2011-07-24T05:20:00.000-07:00

In this post I would like to explore Single Sign on's with email addresses, with the support of the users browser. Browsers do not currently support Single Sign On. Recently Mozilla showcased their concept of BrowserID.

I am not comfortable with their use of asymmetric keys, because this requires the user to manage his own private/public keys. Indeed BrowserID will ease the process for the user, but he still needs a private key on every computer he uses. And this may include public computers at browsing centers etc.

So here, I will present a Single Sign on process, that will not require asymmetric keys. For the sake of this post we will call the users email provider "email.com". The site he wants to sign into "site.com", and "BSSO" for Browser Supported Single Sign On. This article will not get into the details of algorithm's etc, because each step described here can be carried out in many ways, and has already been implemented in some form or the other by other protocols. A good example is OpenID 2.0.

First, I will describe the process when the user is already signed into "email.com", and wants to sign into "site.com".

Case 1 - User signed into email.com

Step 1

The user browses to "site.com". "site.com" needs to indicate to the user's browser that it supports BSSO. This can be done in many ways. I will give one example here. On site.com's page it can include two elements. One element in the html head part like below

In the body part it can have an element with id "bsso_sign_in_button".

The rel="bsso_end_point" link element will indicate to the browser that this site supports BSSO and it should listen to the click event of the element with id="bsso_sign_in_button".

Step 2

When the user clicks the "Sign In" button for "site.com" the browser will make an authentication request to "email.com" on behalf of "site.com" with "site.com"s end point. This will need the user to have pre selected his prefered email address(s) in the browsers BSSO setup, if not the browser will show a popup asking the user to select his prefered email address. The browser may also have discovered "email.com"s end point during setup using webfinger.

Step 3

"email.com" returns a positive assertion of the user's email address. This is not a problem because the user is currently signed into "email.com". Also a private "association key" is included along with the assertion.

Steps (2) and (3) are transparent to the user. The browser makes a cross-domain ajax request to "email.com". This is possible because it is the browser making the request and not any javascript on "site.com"s page.

Step 4

The browser now directs the user to "site.com"s end point url with a http post request, with the assertion returned from "email.com" in the post body.

Step 5

"site.com" will now verify the assertion by sending the assertion along with the association directly to "email.com"s endpoint. "site.com" would have also followed the webfinger protocol to determine the end point. It is possible for "site.com" to request a time bound association with "email.com", so that Step 5 and 6 can be avoided in subsequent requests.

Step 6

"email.com" will respond with success or failure.

Case 2 - User Not signed into email.com

In the case where the user is not signed into "email.com", in Step 3 "email.com" will respond with a "user not signed in" response along with a sign in url that might have an encoded token in its query parameter. (The encoded token is for preventing phishing, I am not yet sure if this token is required or not as of now). The browser will pop up a window and listen to the popup's close event, and direct the user to the returned sign in url. After sign in "email.com" must "close" the popup via javascript. When the popup is closed the browser will continue with Step 2 again. In case the popup was closed without the user signing in, the browser will receive a "user not signed in" for the second time, in which case the browser has to query the user again.

Some Notes

This may look like a lot of steps, but the user only "see's" (1) and (4). Also (5) and (6) are not required after "site.com" and "email.com" have established an association.

Phishing is not possible, because there are no redirects from "site.com".

The user can sign in from anywhere, there is no need to have any private keys on the computer being used.

Unlike BrowserID "email.com" will be aware of the site's the user sign's into. I don't know how much of a problem this is. It's a debatable issue I guess.

Android App Development in Scheme

2010-10-25T03:38:00.000-07:00

You can now develop android apps in Scheme. I find this very exciting because you can develop in a simple functional manner. I have started a tutorial for this here.
http://androidscheme.blogspot.com

Fast Track Clojure

2010-09-28T04:26:00.000-07:00

Fast Track Clojure is a tutorial I am developing for learning the Clojure language. The objective of the tutorial is to get you developing in Clojure as soon as possible.

Clojure is a Lisp based language, and here I would like to quote Eric Raymond on why you should learn Lisp.

"Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot."

You can start with the tutorials here.
http://fasttrackclojure.blogspot.com/2010/09/lesson-1-hello-clojure.html

Released Eezee MVC

2010-07-01T03:14:00.000-07:00

I released Eezee MVC an Easy, Model, View, Controller framework for Google App Engine.
Features

Has a Controller Class that does routing, handling and rendering templates
Your controllers reside in the controllers folder, views (html Django templates) in views folder,
models in models folder
Allows Controller to recieve GET/POST parameters as function arguments.
Use's S Nakajima's excellant gdispatch router

URL: http://eezeemvc.appspot.com/
Project URL: http://code.google.com/p/eezeemvc

Federated Identity in your Browser

2009-06-23T23:40:00.000-07:00

In this post I am going to discuss the background information that will make a case for Federated Identity Management in Browsers. With the advent of new Browser capabilities, and leveraging the new technologies that will be adopted by Federated Identity specifications, I hope to show how Federated Identity Management can be achieved using Browsers.

Federation of Identity serves to enable portability of Identity information across otherwise autonomous security domains. In other words Federated Identity is about using a single Identity to sign into different web sites (over simplifying a bit here). This is not only about your "username" and "password" but also a about other information that identifies a person like, real name, address, nick name, email etc.

Examples of common Federated Identity usage are, using your Google or Yahoo Account to Log in to other sites like Blogger, Youtube etc. In this case the web site allows authentication via any "Provider" that follows a Federated Identity standard like OpenID eg. This is different from using your Facebook or Twitter Accounts to sign into third Party sites. In the latter case it is called Delegated Identity. In other words the web site you are signing into has delegated authentication to Facebook or Twitter.

The way Federated Identity Log ins work is that, when you visit a Site you are redirected to your Identity Provider, eg. Google. You Log in at your Provider, and also "allow" your provider to provide additional information (your name, email etc), and then you are redirected back to the web site. For one this method is prone to Phishing. If a user inadvertently visits a untrustworthy site, the site could redirect the user to a site that appears to look like the users provider and steal his user name and password.

Another problem is that when you visit a site that supports Federated Identity, you cannot log in to the site just by clicking a button. The site for various reasons will choose to support a selected list of providers from which you have to choose from, leading to what is called Nascarization.

Another problem is that of data portability. Let us say you have your identity, profile and social contacts at Google, and you want to change to Yahoo. There is no way to do that seamlessly as of now.

All this begs the question where is the best place to keep your identity information? With You! That's the obvious answer. And the closest that can get to "You" is your Browser. Unfortunately in the current state of affairs of Federated Identity, the browser only plays the role of via media or broker, between the Identity provider and the web site. If the Browser were to manage your identity you could solve all the three problems above in one fell swoop!

However there are two reasons why browsers do not play a greater role in Federated Identity Management.

There is no commonly accepted standard that will allow browser vendors to support this. This would require a specification to allow the browser, identity provider, web sites to speak a "common" language.
Another solution would have been to implement browser plug ins. This would still require the common standard but at least we do not have to wait for the browser vendors. But the problem here is developing plug ins for all types of browsers is not easy (at least up to now).

New browser developments like Jetpack from Mozilla Labs allows you to develop browser plug ins very easily using Javascript. Opera Unite is another effort to empower the browser. All browser vendors are moving in the direction of empowering the browser. What all this means that extending your browser to support a Federated Log in standard is going to be trivial.

So what we really need is a "Federated Identity Standard for Browsers". There must be a working group for this at one of the standards bodies like OpenID, Open Web, Kantara etc. I have not seen such a working group yet.

I intend to demonstrate how a simple Federated Identity standard can be implemented using Mozilla Jetpack, and some minor tweaks to existing Federated Identity provider and consumer software, in a future post of mine.

Opera Unite, will I really use it?

2009-06-16T01:28:00.000-07:00

Opera has released its new web server in a browser called Opera Unite. This is not a new idea, and the idea of running your own server, is I guess only appealing to geeks. Having said that, it does give the lay user an ability to run some basic services like picture sharing, chat etc from his own PC.

I can't see a killer application from among the ones they have available now. So we have to wait and see what applications developers will come up with.

Also we have to consider why people don't usually run web servers from their PC's. One reason is of cource bandwidth. If you are connected via ADSL or something like that this is a bad idea. You can do some limited stuff with a small group of friends. But nothing for public consumption.

The second problem is discovery. User's may just have temporary IP addresses. Opera solves this by being your proxy server that allows users to connect to your PC. That means you have to sign up for the Opera Unite service. The part I dont like is accepting their terms of service "By uploading Content to Opera’s site, you grant Opera an unrestricted, blah blah blah ....".

So I don't think this is going to replace my blogger, facebook, twitter etc etc accounts. But I can see where I could use it. For one, to delegate my OpenID. So my OpenID could be something like

http://home.mynickname.operaunite.com/openid.

Now before you run and download Opera I would say hang on. I haven't figured how to do the above my self yet. Its 45 mins since I have downloaded Opera. So its not like just editing your "index.html". Looks to me somebody has to do a "OpenID" Opera Unite Service. So my Opera unite OpenID is actually pointing to a Opera Unite Service by adding a "/openid". And he has to upload the service and Opera has to approve it! Or has anybody figured how to edit index.html yet?

But you see, there is potential here. If you have an application that stores your personal profile data and provides it to applications as and when required, we have the beginnings of data portability. But now the problem is to port your data from browser to browser instead of from web site to web site!

Update.

To set up your openid on your browser do the following. You cannot set it on your default home page. After downloading Opera Unite, Install the web server application by clicking on web server tab. Select a folder to be your web server root. eg C:\openid. Click on automatically create index.html file. Set Access control to public and save. Edit the index and add the following in the HEAD part. Change the href's accordingly to point to your provider.

<link rel="openid2.provider" href="http://www.myopenid.com/server"/>

<link rel="openid2.local_id" href="http://myname.myopenid.com"/>

Your OpenID is

http://home.mynickname.operaunite.com/webserver

About Email Addresses and OpenID

2009-06-08T00:51:00.000-07:00

Out of the hundreds of millions of OpenID's in the wild today, 99% of them are provided for by Yahoo, Google, MySpace and AOL.

Three of them are email providers and your OpenID is tied to your email address. ie Opening and account at one of them gives you an email address and an OpenID. You can also create a Google account with a non Google email address. Again the OpenID is tied to an email address. So when you are logging in with any of these OpenID's you are in effect logging in with an email account.

This is also true in the case of MySpace even though it is not an email provider. When you login with your MySpace ID you are really logging in with your email address! The MySpace OpenID is also tied to your login email address.

In other words 99% of the OpenID's in the wild are really email addresses masquerading as OpenID's!

Why the need for this masquerading? Because OpenID does not support Email addresses as OpenID's.

And why doesn't OpenID support Email addresses as OpenID's? Given the facts above I cant think of a reason. Can you?

Google Wave is Web 3.0

2009-05-31T21:07:00.000-07:00

If you search the web to find out what web 2.0 and 3.0 is, you will find them associated with social aspects. Things like web 2.0 is the "social web" etc. But really each version of the web is a technological leap.

Static Web - Web 1.0 was the static web were you had to change the page or reload the page to change its contents.
Dynamic Web - Web 2.0 was the dynamic web where you could change the content without changing your browser page. (Google Maps, Ajax Pages).
Real time Web - Web 3.0 is the real time web where the content of the page will change in real time as the "author(s)" changes it. Google Wave makes this possible.

Web 2.0, the dynamic web took off in 2004 with Google maps. That is when developers realized that you could change the contents of the page in place, paving the way for Ajax technologies, leading to the social web.

Web 3.0 as described above is a technological leap to the next level. What is interesting is that the very same people who brought about Web 2.0 with Google maps, the brothers, Lars and Jens Rasmussen are also the ones who are behind Google Wave, poised to bring about web 3.0!

Much has already been written about Google Wave, some even skeptical. But most of the articles seem to have missed the fundamental point what Google Wave is all about. What Google Wave has done is to combine the static, dynamic, real time aspects of the web into one composite object called the "Wave".

The Wave Object can be turned into anything the developer wants. It can be turned into a message, blog comment, blog, real time game, tweet, a wall, literally limited only to your imagination. That is why 4000 developers gave it a standing ovation when it was revealed at the Google IO conference. (Standing ovations are an extremely rare occurrence at developer conferences).

Imagine a chat messenger without its text box (where you type), which has only its display area. Now imagine that you can type right into the display area. While you are typing the person you are chatting with can see you typing in real time. Actually if it is a chat conference all the people can type in at the same time and all of them can seen it in real time. You can add, pics video's and other types of content into the display area. You can fork off private conversations. A robot can spell check while all this is happening. The possibilities are endless. And this is what a Google Wave is.

Actually Google Wave sits on top of the same protocol that Google Talk sits on. The Jabber protocol now called XMPP. Google added to this protocol and called it the Wave protocol. It is an Open protocol, anyone can implement this protocol. Google is not keeping anything proprietary here. I can already see an army of developers piling on to this technology and you will see a lot cool stuff coming out within months.

Web 3.0 is here!

About Google Wave and OpenID

2009-05-29T02:56:00.000-07:00

I have been looking at Google Wave all day, wow, very very interesting. I have a lot to say but I will make this short by sticking to a couple of points that relate to OpenID.

1) Wave servers are natural OpenID Providers.

The wave protocol sits on top of XMPP and provides for real time communication between users. It is decentralized using the DNS system. Yes this is like OpenID, but the clincher is that you can communicate with the user in real time, as soon as he logs in, and you can verify the user immediately.

2) Wave ID's are natural OpenID's

Wave ID's are really Jabber ID's, look like email addresses and have discovery inherant in the ID.

Eg. If you have a user with wave ID

user@domain.com/waveserver

An OpenID server on the same domain is a natural. The users Wave ID can be his OpenID or it can be

user@domain.com/openidserver

ie. either make the waveid and openid same with xrds discovery or let it be different but point to the openid endpoint.

Any way it really deosn't matter how we do it, what matters is how fast we do it. In the coming months we may see a lot of Wave servers popping up, and if we are ready with support for WaveID's in OpenID we can make a killing.

Other wise the world will move on without us, and this will be another missed opportunity for OpenID. (We already missed it with email addresses).

About Google, Yahoo, Facebook and OpenID

2009-05-21T04:10:00.000-07:00

Facebook's support for OpenID may have some worrying prospects for Google, Yahoo, Microsoft and other major email providers, who would like to be OpenID providers.

Even though everyone says Facebook is now an OpenID RP, I dont agree with that. What Facebook does is only grock the users browser login status, and logs the user in if he has delegated that provider to Facebook. It does not work in many cases and I am not impressed with their implementation, and have said as much in my earlier posts.

So what is it that is going to be of a concern for Google, Yahoo etc?

Whether by design or by accident, what really Facebook has done, is to become an OpenID discovery and delegation provider for all its users. ie. Facebook users can now point to their Openid provider and also indicate their prefered provider in case they have more than one. This is significant. Because the primary problem to be solved for OpenID is discovery and delegation, and Facebook does it for its users.

Now all Facebook has to do is "Switch On" OpenID for Facebook Connect and Voila! You have 250 million users ready with single sign on with Facebook Connect! Throw in 250 million verified email addresses for good measure. (I am not sure all these are verified, but I can say they did verify mine).

If major RP's are not already salivating at the prospects, then they will soon. And this is not really all that bad. If you don't mind Facebook being your centralized mechanism for OpenID discovery and if they are the closest you can get to one, then why not?

Now you know why Google, Yahoo etc need to be concerned. But there are other options. One is the OpenEmailID i have suggested in an earlier post, where the onus on discovery rests with the RP. An even better Option is the WebFinger protocol, where the onus on discovery lies with the email provider for email addresses as identities.

Whatever happens I think it is high time Google, Yahoo etc move ahead with providing discovery for their users.

The OpenID community must come to a concrete decision on which way they must go and go after their objective as fast as possible.

Facebook support for OpenID. Where?

2009-05-18T20:05:00.000-07:00

I am seeing tweets and blog posts about Facebook support for OpenID. I had already suggested in an earlier post that it is going to be a farce. And that is what it exactly is.

You see, I have always maintained that it is impossible for Web site's who base their user identity on email addresses to support OpenID in the current form. And let me list out the problems with the so called Facebook OpenId support.

You can't log in into Facebook with your OpenID unless you are already logged in to another OpenID provider. So if you fire up your browser and go straight to Facebook, sorry!

You cannot create a Facebook account with OpenID. You need to create your Facebook account with your email address, and then log in to your account, and then go to settings, and then link your OpenID account.

Ok, so I decided to link my Google Account. I found that I could not link to my Google Account without me handing over all my Google contacts! In other words Google log in was useless for me.

When I tried to log in with Yahoo and I got the famous Yahoo message "Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate."

And what I find most embarrassing is the so called "Openid evangelists" going "gaga" over this release. Maybe it is "Facebook" so they better say good things, no matter whatever they do.

Finally, light at the end of the tunnel, for OpenID

2009-05-08T09:16:00.000-07:00

In the last few days two new pieces of information come as great news for OpenID. One for the long term, and the other for the short term.

Mozilla Firefox's demonstration of a single sign on with OpenID is testimony to the fact that Browsers will eventually manage the users identity. It may take five years or more to happen.

What is interesting for OpenID is that Browsers will not support proprietary "Connect's". Unless of course the Connect vendor also happens to own the Browser. I am hearing of Twitter Connect and Google Connect. The only "Connect" that will be common to all browsers will be OpenID! I think vendors coming out with their own Connect's, are venturing into something really futile.

The short term good news for OpenID is the webfinger protocol being developed. This will allow for email discovery, paving the way for emails as OpenID's.

The onus on discovery lies with the email provider which is only natural, and that is the only way it can work. This won't work if non email providers were OP's. Atleast not as equals to the email providers. Non email providers can issue virtual email addresses if they like. But it is not the real thing and they will have to dish out the real email address via SREG or AX.

If Facebook had supported OpenID as an OP with SREG support earlier, me as an OpenID community member would have been hard pressed to support the webfinger protocol. Another way out would have been the centralized discovery mechanism which is not going to happen anytime soon, and Facebook would have been the de facto centralized mechanism until then!

To really make OpenID happen I always believed we need one of the biggies. Ebay or Amazon or someone like that, and these guys won't play without an email address. With the webfinger protocol for email addresses they will definitely come on board. So it becomes very important for the community to move the webfinger protocol fast.

We can now look forward to great times with OpenID!

A Case for OpenEmailID

2009-05-03T03:40:00.000-07:00

What if Email addresses were your OpenID's, ie. your OpenEmailID's?

1) As a user you don't have to learn anything new. You just continue to use your email addresses to log in anywhere like you almost always did.

2) Web sites can easily integrate OpenEmailID into their existing log in systems. eg. If Facebook were to implement OpenEmailID's there is really nothing much more it needs to do. If the authenticated OpenEmailID is an existing account thats the users account. If it does not exist it is a new account and Facebook can skip the email verification process, an obvious advantage.

Considering the above two points OpenEmailID's are really a no brainer.

Now let us see what is needed to implement this. Turns out we don't need anything more than what we already have!

If a web site requires email address Log in, chances are, 1 out 3 of its users, would be logging in with a Yahoo or Gmail account. These figures are based on email client statistics. I know you can argue this figure but it doesn't affect the overall argument.

When a web site detects a Yahoo or Gmail address it can not only get the user authenticated from that web site (via OpenID directed identity), it will also get a verified email address of the account. Google already supports this and Yahoo will be supporting this very soon.

In effect this is the Users OpenEmailID. So you already have it for one third of the cases. I expect AOL and Microsoft to support this in the near future. In effect this pretty much covers 80% of the email Users.

In the case of companies or individuals running their own email servers, they can very easily implement an OpenID 2.0 provider service on their domain. The software is available free as Open Source.

And that's not all. We don't even have to wait for Microsoft, AOL and the other companies. If a User does not have a Yahoo or Gmail account he can get an OpenEmailID for free from a number of Providers even now! He can create a Google account with his own Email address. He can create an OpenID account from one of the OpenID providers like myOpenID or MyVidoop. He can actually create an OpenEmailID at any provider who supports OpenID 2.0 and supplies a verified email address.

So if the user does not have a Yahoo or Google account a web site needs to ask if he has an account with any of the above providers. This has to be done once only, and the web site should save his account preference. And the web site should encourage the user to create an account at one of these sites.

All this can be done very easily, because there is nothing new to implement or invent here. It only requires some concerted effort from the open web community, providers and web sites.

We can very easily achieve the objective of a single sign on. One email one password. One OpenEmailID!

Facebook support for OpenID. Farce or Feign?

2009-04-28T01:22:00.000-07:00

You want a Facebook Account? No problem. Just sign up with your OpenID. Yes you will be able to do that in the near future.

So you type in your OpenID URL. (If you have a Google account you will have to type https://www.google.com/accounts/o8/id I presume.) Didn't you want to get notified in your email box every time there is some activity from your friends, or other interests? Great! Please get your email address verified as well.

Good now that we have a Facebook account with our OpenID we can sign in to our account, or Facebook connect, with it. Now wait a minute. I can sign in with either my OpenID or Email address it doesnt matter! So what are you going to choose? Your OpenID or Email address to sign in?

Now the above is for people who have an OpenID, people who are a small minority among a large majority of people who have not even heard of OpenID. The large majority are going to sign up with their email addresses anyway. They are not about to go get themselves an OpenID just to sign up to Facebook.

Is this a farce? Or is it a feigned right hook, before they land the knockout left hook to OpenID?

Once we have all the OpenID officionadoes and users signed up to facebook with their email addresses how about releasing email addresses with Facebook Connect? BAM! Every RP who requires an email address will adopt Facebook connect before adopting OpenID. Because OpenID has still a long way to go as far as OP SREG support goes. Your NASCAR buttons will become a single Facebook Connect button.

I had wanted Facebook to support OpenID as an OP with SREG Email support in an earlier post. These guys dont get it do they? They are virtually sitting on a Gold mine, If only they supported OpenID as an OP. Looks like they are going the Apple way back in the 80's.

The battle lines are drawn. It is Facebook Vs The Rest. We will see if history repeats itself!

OpenID Login Box user Interface released

2009-04-23T00:02:00.001-07:00

I have released an OpenID Login box user interface for OpenID. It has a single button, drop down list of OpenID or non OpenID providers, and popup authentication. You can customize the login box to your requirements. You can view and download it by going to the link below. License MIT, GPL.

http://openid.myofiz.com

A lesson from history for Facebook

2009-04-15T02:19:00.000-07:00

Back in the mid 80's Apple launched their now popular Apple Mac with the Mac OS. The Mac OS was the first GUI based OS on a personal computer. All Microsoft had was the rickety MSDOS. Microsoft was caught napping. It took Microsoft 10 years (windows 95) to come out with something equivalent to the Mac OS! Their earlier attempts, windows 3.0 and 3.1 being failures.

Working in favor of Microsoft was the fact that MSDOS was open, and could be used by any hardware vendor, while the Mac OS used the proprietary Apple hardware.

Apple had a choice to make. Open up Mac OS to all hardware vendors or stay proprietary. They chose to stay proprietary, keeping the price of a Mac higher than a equivalent PC. Apple could have really trashed Microsoft if they had opened up Mac OS to the hardware vendors back then.

By the late 80's Apple was inching closer to bankruptcy, while William Gates was laughing all the way to the bank!

Facebook is pretty much faced with the same situation as Apple back then, as far as their Facebook Connect is concerned. They can choose to Open it up by supporting OpenID or stay proprietary. Only this time they have a bunch of contenders to deal with instead of just Microsoft.

Of cource the circumstances for Facebook are different today. But the underlying strategic mistake made by Apple cannot be missed. I hope Facebook learns from the past, and chooses to support OpenID as an OP, before it is too late.

Need of the Hour for OpenID

2009-04-07T18:39:00.000-07:00

Its been 2 weeks now that I have been involved with using OpenID. It all began when I decided to try out OpenID with a small application. Thats when it hit me, that OpenID is not going to "happen" without a verified email address. You can read the rest of it in my last 4 posts. I really want this to happen.

The remarkable thing about OpenID is that it has all the major players (Google, Yahoo, Facebook etc etc) on their board. I havent seen anything like this happen to a standards body ever. (Correct me if I am wrong). Usually what happens to any web standard is that a rival standard will pop up, splitting the major players more or less equally among them. This is a testimony to the great work done by the pioneers of OpenID, though things have not yet panned out like they would have wished.

It is increasingly clear to me, that the solution involves a centralized distribution mechanism which I alluded to in my "Suggestions for OpenID 2.1". Something in the lines of "Personal Discovery Service".

This can be possible only if all the major players come to an agreement on this. OpenID is in a perfect position to make this happen. This is easier said than done though. All the major players have their own vested interests.

To begin with, the solution must only consider sharing of basic profile data. Bringing in other social data will only magnify the disagreements. And in any case as far as Openid is concerned its interests should only be in the basic profile.

If the major players cant come together on this, then the only way out will be to leave out the Openid Providers from the equation and go straight for the Relying Party's. This is not too difficult a problem to solve. Definitely some food for thought.

Accidentaly deleted some posts

2009-04-07T11:29:00.000-07:00

Sorry to those who commented on five of my posts, which i accidentaly deleted while changing labels. I managed to recover four of them. I will try to rewrite the one i could not recover.

I think blogger must remove 'Delete' from the drop down which along with Labels, publish etc. Or for delete they must reconfirm, because you cannot recover a deleted post. I was fortunate to have most of them in my mailbox.

About Facebook, MySpace and OpenID

2009-04-07T11:26:00.000-07:00

MySpace recently announced there support for OpenID. The idea here is that MySpace users will be able to log in to third party sites with their MySpace Id's. MySpace users needn't get too exited about it too soon.

Consider this. A MySpace user would like to log in to her favorite shopping site with her MySpace Account. The shopping site is unlikely to support MySpace Logins. The simple reason being that shopping sites need the email addresses of their authenticated users for various reasons (communicating orders, delivery, new stock etc etc). It doesnt make sence to the shopping site to authenticate using MySpace (An extra step) and then run the user through another email verification process. This will also be true for many other web sites that require their users to login.

However MySpace could have made the users email available to the shopping site (Ofcource with the users consent only) via a provision in the OpenID specifications called SREG. So then why didnt MySpace choose to support SREG?

This is not a problem for MySpace alone. When Facebook decides to support OpenID it will be faced with the same dilemma. It is really a frightening thought for social networking sites to hand over their users email address to a third party. For social networking sites keeping the users bound their network is of primary importance.

However an equally frightening possibility for social networking sites is to see their users start using Google accounts and Yahoo accounts to log in into third party sites! They could start loosing users in that case too.

The jury is out on what these guys should do.

But I am clear on what MySpace should have done. Facebook being the no 1 social networking site can wait this one out a bit more. However MySpace should really have capitalized on this opportunity. Supported SREG and tried to rope in third party sites to support MySpace logins, and tried to build a small advantage over Facebook on this account.

My 2 Cents to the OpenID Foundation

2009-04-07T11:21:00.000-07:00

After my last blog post about OpenID i spent some time on the OpenID forums to see what was going on. The impression I gathered was that there were some genuine efforts to recognize emails as valid OpenID's in the upcoming OpenID 2.1 specifications. Is it a case of too little too late? Time will tell.

The problem is that emails were never recognized as OpenID's right from the beginning. And that was the kiss of death for OpenID. It is beyond me, living in a world were practically every one uses an email address to log in almost anywhere, a group of well meaning intelligent people can completely miss its importance. Did they think the concept of a url as an identity could be showed down the whole worlds throat?

So I rolled up my sleeves and went to work on this one, and I posted my solution on the Openid forum. The jist of what I had to say was, "The user MUST be able to authenticate himself with OpenID using his email address if he so chooses to".

For those of you who are technically oriented you can see my solution suggested to OpenID foundation here.

As a side note myspace has come out with there own version of OpenID support, which is not compatible with the OpenID specification. Another example of vested interests tearing apart the concept of OpenID. I think myspace has really shot itself in its foot this time. They really should have supported directed identity in conformance to OpenID 2.0 and SREG 1.0. They are really on there way to "nospace".

The death of OpenID

2009-04-07T11:19:00.000-07:00

Or atleast the death of open id as we know it. There is an interesting battle on between the big players of the web, Google, Yahoo, Microsoft, Facebook and what I call the OpenID wannabees (OpenID service providers like myopenid.com, myid.net, verisign etc).

Lets say you have an email address, and you want to login into any site with it. If every site were to support logins via OpenID 2.0, you could do exactly that. You wouldnt need an OpenID in that case. All you need is your email address!

Let me show you how it is done with a live example. Go to the link below. Hit on the login button. See the Google Login page. Dont Login. Hit your back button twice and return to this page.
http://myfeeds.myofiz.com

On the Google page you can login with your google account. But thats not all. If you noticed, you can also create a Google Account if you dont have one, with your own email address, on that very same page. In effect anyone can login into this site with his own email address (which is verified by Google), which need not be a Google email address, it could be any other email address!

This is all done with OpenID 2.0 without the user ever knowing what his OpenID actually is. He only needs to know his email address. In other words your email address is your OpenID!

Now the site above was developed by me, and why dont I support login via OpenID? Because I want only people with verified email addresses to log in. With OpenID I am not guaranteed to get a verified email address, I get just an OpenID that does not mean anything for me.

Now is this the future of Logins into web site. You bet! If Facebook and yahoo are to support this, the same same way like Google, I think all web sites will adopt OpenID login. If they dont, slowly Google Account will become the defacto logging method for every site.

Now thats what the battle is all about. Web sites are not sure which way to go. And the big players are not sure either. That is why the hesitancy by Facebook, Yahoo and Microsoft.

In the end given the choice between logging in, with an OpenId or email address, I bet the users are going to use their email addresses. And indeed that will the the death of OpenID as we know it!

JX 0.3 beta released

2008-11-06T05:30:00.000-08:00

I have released JX 0.3 beta http://jx.myofiz.com/

It has a quick start tutorial, examples, download and documentation.

A Feed Viewer application developed using JX, jQuery Object oriented extension

2008-11-03T01:07:00.000-08:00

I have developed a example feed viewer application using JX. You have to read my previous posts if you havent. The complete application is done with just one config option to the viewport. You can see the demo here.

For the feed viewer application I had to make a few additions to the JX extension.

Added JX.Panel class which has a jxtype 'panel'. It requires two config objects title: and body:. In the demo the feed list and feed summary boxes are JX.Panels.

Also added some methods to JX.Component.
You can set config option scopeThis: true, and all the handler functions will be called in the this scope of the component.
Added function setLoadIndicator(imagepath, width, height) to component.

I overrode the jQuery trigger function for containers, so that custom events are propagated to all its children. eg. in the demo application the feed links triggers the custom event 'loadfeed' on the viewport, and the feed summary panel binds to the loadfeed event. var viewport is accessible everywhere in the config.

Look at the source code of feedreader.html to see how it is implemented.

You can download the latest jx.js here.

Viewport, Column Container and nested layouts

2008-10-31T04:29:00.000-07:00

I have added a viewport class and a column container class to JX. Please read my earlier posts if you havent.

The viewport takes over the document body element. So you can have only one viewport instance in your application. If you have content in your body element the viewport will hide it. So it is unobtrusive also. Clients with no javascript will see your content. Viewport extends JX.Container so lays out its components vertically.

The column container works similar to the container in my previous post except that it lays out its components horizontally. You can set fitWidth: true to one of its components and the component width will expand to the remaining width of the parent minus its sibling widths.

You can nest the containers within each other and create complex layouts. I will create a a border layout using the viewport and column container. The border layout will resize accordingly when you resize your browser. You can see the demo here.

Here is the code to create the border layout.


$(document).ready(function() {
    var viewport = new JX.Viewport({
        css: {padding: '0px', margin: '0px'},
        items: [{
            height: 50,
            css: {backgroundColor: '#aaaaaa', padding: '20px'},
            text: $('#north').text(),
            fitWidth: true
        },{
            jxtype: 'columncontainer',
            fitHeight: true,
            items: [{
                text: $('#east').text(),
                width: 150,
                css: {backgroundColor: '#cccccc', padding: '20px'},
                fitHeight: true
            },{
                text: $('#center').text(),
                fitWidth: true,
                css: {backgroundColor: '#eeeeee', padding: '20px', overflow: 'hidden'},
                fitHeight: true
            },{
                text: $('#west').text(),
                width: 150,
                css: {backgroundColor: '#cccccc', padding: '20px'},
                fitHeight: true
            }]
        },{
            height: 50,
            css: {backgroundColor: '#aaaaaa', padding: '20px'},
            text: $('#south').text(),
            fitWidth: true
        }]
    });
});

I have added a new jxtype 'columncontainer' for column containers. Other jxtypes i have added are 'container' and 'component'. You need not specify jxtype if you are creating the component with 'new'. Also default is component ('div').

You can download the latest JX source code here.

A jQuery Container Class

2008-10-30T05:44:00.000-07:00

Further to my previous post I have created a container class called JX.Container. The container lays out components vertically just like you would if you append. However it has a few extra features.
In the config options it has a 'items' config which is an array of components or component configs.
You can set 'fitWidth' to each component and the component expand to the width of the container. You have to also call doLayout() on the container, this is required because of 'fitWidth'.
We will use the container class to create a login box. Here is the code.


$(document).ready(function() {
    var loginbox = new JX.Container({
        width: 200,
        css:{
            background: 'lightcyan',
            border: '1px solid darkblue',
            padding: '20px',
            fontSize: '12px',
            fontFamily: 'Arial, Helvetica',
            fontWeight: 'bold',
            color: 'darkblue'
        },
        appendTo: document.body,
        items: [{
            text: 'Enter your User Name'
        },{
            jxtype: 'input',
            attr: {type: 'text'},
            fitWidth: true
        },{
            text: 'Enter your Password'
        },{
            jxtype: 'input',
            attr: {type: 'password'},
            fitWidth: true
        },{
            jxtype: 'input',
            attr: {type: 'button', value: 'Login'}
        }]
    });
    loginbox.doLayout();
});

Here you can see the demo.
You will need the jx.js file to use this container. You can download it here.
You can also set fitHeight: true to a component. What this does is that the component will take up the height of the container minus the height of the other items. So you you can set fitHeight to only one of the items. I will show fitHeight in another post. I intend to do a columncontainer and a viewport, and by nesting these containers you can create complex layouts.

Configurable jQuery Components

2008-10-29T03:25:00.000-07:00

I wanted to create jQuery components easily by passing in config options, that would also take in jQuery method parameters in the config option. You have to read my previous post to understand what is going on here. First I will show you how it works. In the code below I create a button object by passing config options to JX.Component.


$(document).ready(function() {
    var mybutton = new JX.Component({
        jxtype: 'div',
        text: 'Click Me',
        width: 100,
        css:{background: 'darkblue', color: 'lightblue', textAlign: 'center'},
        appendTo: document.body,
        click: function() {
            alert("You clicked a button with text: " + $(this).text());
        },
        hover: [
            function() {
                $(this).css({cursor: 'pointer', opacity: '0.5'})
            },
            function() {
                $(this).css({cursor: 'default', opacity: '1'})
            }
        ]
    });
});

You will notice that all config options except jxtype are actually jQuery method names whose values are the parameters to the jQuery method. jxtype tells the component what type of dom element to create. If you dont specify jxtype default is 'div'. Also note the the 'hover' config option takes in an array as its value. So where ever the corresponding jQuery method takes more than one argument you must use an array here.
Here is the code for the new JX.Component.


JX.Component = function() {
    if (JX.isObject(arguments[0])) {
        var config = arguments[0];
        config.jxtype = config.jxtype ? config.jxtype : 'div'; // default type is div
        JX.Component.superclass.init.call(this, document.createElement(config.jxtype));
        this.applyConfig(config);
    } else
        JX.Component.superclass.init.apply(this, arguments);
};

JX.extend(JX.Component, jQuery, {
    applyConfig: function(config) {
        for (var key in config) {
            var a = JX.isArray(config[key]) ? config[key] : [config[key]];
            eval('this.' + key + '.apply(this, a)');
        };
    },
    jxtype: function(jxtype) { 
        this._jxtype = jxtype;
    }
});

To make reusable components you can create a factory function like this.


function buttonFactory(config) {
 var buttonconfig = jQuery.extend({
        jxtype: 'div',
        width: 100,
        appendTo: document.body,
        click: function() {
            alert("You clicked a button with text: " + $(this).text());
        },
        hover: [
            function() {
                $(this).css({cursor: 'pointer', opacity: '0.5'})
            },
            function() {
                $(this).css({cursor: 'default', opacity: '1'})
            }
        ]
 }, config);
 return new JX.Component(buttonconfig);
};

$(document).ready(function() {
    var mybutton = buttonFactory({
        text: 'Click Me',
        css:{background: 'darkblue', color: 'lightblue', textAlign: 'center'},
    });
});

You can download the source code for JX here. License is MIT, GPL.

Extending jQuery the Object Oriented Way

2008-10-27T22:58:00.000-07:00

Though I have used quite a few Ajax libraries in the last couple of years, nothing has impressed me like jQuery. However jQuery is not object oriented in the traditional sence. You cannot instantiate a jQuery object like this

var myobject = new jQuery();

or extend jQuery like this.

extend(MyClass, jQuery);

So what if you could object orientify jQuery? Imagine all your classes/widgets as extensions of jQuery. You could call all the jQuery functions from within your own 'this' like

this.addClass('classname');
this.click(function() {alert('you clicked me')});

But then you cannot extend jQuery because it does not have a constructor! It is itself an object. But thats where javascript comes to your rescue. Javascript does not differentiate an object from a class. And the jQuery object has some features that will come as a help. It has a prototype object and though it does not have a constructor it does have an init method. Some of you are already figuring where I am headed. But before we go ahead we need a function that will do a proper object oriented extend. And I will also add a namespace and call it "JX" for jQuery Extend. Here is the code.

var JX = {
    extend: function(bc, sc, o) {
        var f = function() {};
        f.prototype = sc.prototype;
        bc.prototype = new f();
        bc.prototype.constructor = bc;
        bc.superclass = sc.prototype;
        for (var m in o)
            bc.prototype[m] = o[m];
    }
};

JX.extend() is a function that will take in three parameters, a baseclass constructor, a superclass constructor and an object of functions to override any superclass methods. Now let us use this method to create a new Class called JX.Component that will be a base class for all our widgets.

JX.Component = function() {
  JX.Component.superclass.init.apply(this, arguments);
};
JX.extend(JX.Component, jQuery, {});

The arguments passed can be any argument you pass into the jQuery $() function. Voila! You have a class that extends jQuery!

Now try this.

$(document).ready(function() {
    var mydiv = new JX.Component(document.createElement('div'));
    mydiv.text("Hello World").click(function(){alert("You Clicked Me!")});
    mydiv.appendTo(document.body);
);

Now let us get down to something more usefull. Let us extend JX.Component to make a button class.


JX.Button = function() {
    JX.Button.superclass.constructor.apply(this, arguments);
    this.initialize();
};
JX.extend(JX.Button, JX.Component, {
    initialize: function() {
        var component = this;
        this.hover(
            function() {
                component.css({cursor: 'pointer', opacity: '0.5'})
            },
            function() {
                component.css({cursor: 'default', opacity: '1'})
            }
        );
        this.click(function() {
            alert("You clicked a button with text: " +component.text());
        });
    }
});

Now try your button class with this code.


$(document).ready(function() {
    var mybutton = new JX.Button(document.createElement('div'))
        .text("Click Me")
        .css({background: 'darkblue', color: 'lightblue', textAlign: 'center', width: '100px'})
        .appendTo(document.body);
});

If you noticed the Button constructor called its "superclass.constructor". However JX.Component when it extends jQuery calls its "superclass.init". And thats the trick in extending jQuery.

First ever Printed book had Chinese hardware and Indian software and Open Source Licence!

2008-09-05T06:16:00.000-07:00

I was reading a book by Amartya Sen (Noble prize winner in Economics 1998) and found an interesting little fact I wasn't aware of, so I thought I must post it here. Let me quote from the book here.

"The first printed book in the world with a date (corresponding to 868 CE), which was a Chinese translation of a Sanskrit treatise, the so called 'Diamond Sutra', (Kumarajiva had translated it in 402 CE), carried the remarkable motivational explanation: 'for universal free distribution'".

And from the footnote.

"Kumarajiva was a half-Indian half-Kucian scholar who studied in India but had a leading position in the Institute of Foriegn Languages and literature in Xian, from 402 CE".

So here we have the first printed book in the world and the machinery it was printed on (the hardware) being Chinese, and the contents (software) attributable to original author and the translator of the book both being Indian.

Google's Chrome Strategy

2008-09-03T02:25:00.000-07:00

If you haven't yet downloaded the new Google Chrome browser, launched yesterday, you can download it here. It's worth it. This is what a browser really should be. However this post is not about workings of the browser. There are a lot of articles about this in the last couple of days. This post is about Google's strategy for knocking Microsoft out of the race.

Really why would Google want to create a new browser when we have atleast half a dozen competent browsers already. As a matter of fact Google pays to support Firefox and that agreement is valid through 2011. And the Google Chrome browser itself is based on the WebKit rendering engine which is already being used by Apple's Safari browser. So really no advantage there except for the fact that chrome runs each tab you open as a separate process.

So what does Chrome have that the other browsers don't? A javascript compiler. Thats right, other browsers have javascript interpreters, but Chrome's V8 is really a Javascript compiler, that compiles and runs the javascript code as machine code, which is much faster than interpreting.

Thats the key. Faster javascript, means that you can run larger applications on your browser. If you have seen Google docs, you already have a spreadsheet, editor, and presentation software running on the browser. If you have faster javascript you could have software on your browser that can compete with standalone applications like Microsoft Office etc.

Think about this, over the years I have been using less of standalone applications, and more of applications on the browser. I use my browser for email, editing, spreadsheet and presentation. The only other applications I use is when I want to watch a movie or listen to music on my computer. Even that can be moved to the browser.

So there are many days that the only application I need to run on my computer is a browser. And Google has understood this for years now. That all your applications will eventually move to the browser. So Google docs and all other google apps are a step towards that goal.

Imagine the scenario. All the applications you need, now run on your browser. Does it matter what operating system you have in that case? No. Does it matter if you have an operating system at all? No. Your browser itself could be the OS too! So boot up your browser and shut down your browser! Far fetched or not, I bet this is already sending shivers down Microsoft's Spine.

Three Rules for Successful Software Development

2008-09-01T06:07:00.000-07:00

In my years of software development I have been looking for that "holy grail" of software development methodology. There are many methodologies, Six Sigma, Agile, Extreme programming to mention a few. However these methodologies have concrete rules to be followed, and they seem to restrict the element of creativity in the process of development.

If you look at the successful software developed in recent years, especially the open source ones, none of them have been developed using the above methodologies. On the other hand they have evolved to what they are today over the years. It is in this context that I would like to set three rules for successful software development. Look at your software as an evolving organism.

1) Only software that can be partially usefull, when implemented partially, can succeed. You need your software to evolve into what your ultimate goal is. Start with a small release that you think will make it usefull for a small group of people or solves a small set of problems. Based on feedback let it evolve into the next stage, and so on until you have what you need.

2) Your software is never in sync with its current requirements. Because of the very nature of the evolutionary process, your software has adapted to the previous requirements, and is currently being adapted to the present requirements.

3) Finally Orgel's Rule, named after the evolutionary biologist Leslie Orgel. "Evolution is smarter than you are". Let your current users point out what is missing. Let them set your agenda. No one person or group of developers or analysts can point out what is missing better than your current users.

This blog was inspired by an excellant article called "In praise of evolvable systems" by Clay Shirkey.

Cross Browser Keyboard Handler

2007-03-14T23:01:00.000-07:00

If you ever thought of writing a javascript editor you will know what I am talking about. Thats right. I am writing a cross browser WYSIWIG In Place javascript editor! Well this post is not about the editor itself. I may do that some time in the future.

The first problem you have to solve is cross browser keystroke handling because almost every browser has some quirks. I needed a keystroke handler that really was cross browser. Running a search on net, i didnt find a complete solution though there were a lot of interesting partial solutions. So i had to put these together and come up with my own.

Here is an excellant article on keystroke detection http://www.quirksmode.org/js/keys.html

As you should know by now, all browsers report the keypress, keydown, keyup events. And each of these events should report the KeyCode and Charcode. Of cource it doesnt allways happen. Ideally for each key event the browser should report the Charcode (the ascii character pressed) and the KeyCode (actual key). So if you hit "a" the Charcode would be 95 and the keycode 65.

For the sake of this discussion let us separate key events into character events and non character events, you will see why soon. Character events occur when a printable character is pressed and non character event occurs when a non printable character (navigation keys, backspace, delete etc) is pressed.

My Ideal browser (there is none) would for character events give the charcode and 0 for keycode. For non character events it would give keycodes and charcode 0. Your keystroke handler would be simple to write.

Mozilla comes closest to this ideal but it also reports keycodes for character events, like in the case of character "a" above. Even then it would be easy to write the keyboard handler if all the browsers behaved the same.

Why do we need keycodes and charcodes? Why not just one CODE? Well for starters there is an overlap of character event codes and non character event codes in the range 33 to 47. Character "%" has the same charcode 37, as the keycode 37 of non character "left arrow".

There are a lot of inconsistencies between browsers as highlighted in the link I gave above. However to solve my problem i needed to find the consistencies between browsers rather than the inconsistencies. Fortunately there are some consistencies.

For the keypress event all the browsers are consistent when reporting character events. Either the charcode or keycode will give you the right character code. But the keypress event is useless for non character events. In fact IE does not even fire the keypress event for non characters.

However for keydown event all browsers are consistent when reporting non character event codes. They correctly give you the right keycode. Even Safari which reports keycodes greater than 64000 for navigation keys on keypress, reports correctly for keydown.

KeyUp also works more or less like keyDown. Except on IE I wasnt able to capture the backspace key on KeyUp. It is important to capture the backspace key because the browser would otherwise resort to its default behaviour and mimick the back button and get off your page completely!

Here is the code.



document.onkeydown = function(e) {handleKeys(e)}
document.onkeypress = function(e) {handleKeys(e)}
var nonChar = false;

function handleKeys(e) {
    var char;
    var evt = (e) ? e : window.event;       //IE reports window.event not arg
    if (evt.type == "keydown") {
        char = evt.keycode;
        if (char < 16 ||                    // non printables
            (char > 16 && char < 32) ||     // avoid shift
            (char > 32 && char < 41) ||     // navigation keys
            char == 46) {                   // Delete Key (Add to these if you need)
            handleNonChar(char);            // function to handle non Characters
            nonChar = true;
        } else
            nonChar = false;
    } else {                                // This is keypress
        if (nonChar) return;                // Already Handled on keydown
        char = (evt.charCode) ?
                   evt.charCode : evt.keyCode;
        if (char > 31 && char < 256)        // safari and opera
            handleChar(char);               //
    }
    if (e)                                  // Non IE
        Event.stop(evt);                    // Using prototype
    else if (evt.keyCode == 8)              // Catch IE backspace
        evt.returnValue = false;            // and stop it!
}