Thursday, April 29, 2010

Appholes!

Jon Stewart is a communication genius - as evident by the title of this post borrowed from him. He some how mastered the art of hiding behind comedy shield and turn serious when he needs it to make his point. He has become the nations moral compass of sorts. But that is a different story.

I read Jobs' Thoughts on Flash where he describes Apple's reasons for banning popular Adobe's Flash technology from Apple products. All the while thinking to myself " you got to be kidding me!".

Where are all the MSFT bashers of mid 90s and early 2000s? Half the countries in the world would have dragged MSFT to their highest court if they ever did such thing. After all MSFT didn't ban NetScape browsers, it simply made its own the default.

Back then, MSFT made the same claim as Apple does today:

"Our motivation is simple – we want to provide the most advanced and innovative platform to our developers..."

 Why is there no outrage this time around in the tech world? Why the double standard?

Now, banning Flash is only one example, Apple's reaction to Gizmodo is also something that makes you wonder. Listen to Stewart version of it:


The Daily Show With Jon StewartMon - Thurs 11p / 10c
Appholes
www.thedailyshow.com
Daily Show Full EpisodesPolitical HumorTea Party

Wednesday, April 21, 2010

xAuth: Second Tier IDP Club

I learned today that the toolbar company Meebo today announced a proposed standard called xAuth to solve the so called NASCAR problem of OpenID.

The essence of the solution is to create a centralized database (xauth.org) where users preferred IDPs are listed. For example if you use Google Friend Connect then xauth.org DB saves that preference for you. Now the publishers/RP that you visit, make a call to xauth.org (upon your visit) and learn that you prefer to "login" using GFC and only show that logo to you instead of a dozen logos from FB, Tweeter, Yahoo, AOL, Google, Microsoft, VeriSign and whoever else who jumps on federated ID band wagon.

My initial reaction (emphasis on initial) is "Are you serious?" and "Is it opt-in or opt-out" (apparently it is opt-out).

Two comments:
1- Of course collecting all people's information in one central database make a lot of things easier/smoother or more efficient, but there is a reason we don't do it (at least not yet), regardless of how noble the initial intent maybe.

2- And this is important, identity provider business is one of those things that have a real network effect, that means by definition and nature, in the IDP business there can not be dozen winners, it is a winner take all type of a game (or maybe a few - two, three) winners at most. NASCAR problem exists because no one wants to admit that it will not be one of the winners. But time will take care of this. For now support for xAuth seems to have become an admission of membership to "Second Tier IDP Club". after all if you think you are going to be one the winners, why would you want to remove your logo from the NASCAR race?

Monday, April 19, 2010

Identity Assertion Framework Talk @ Stanford Presentation

Here is the presentation for my talk today @ Stanford.




You can download the presentation for eBay's Identity Assertion Framework now. The talk is today (April 19, 2010), here is more information on time and place.

I have promised to write a bit more about IAF to a few people and I intend to keep my promise.

Wednesday, April 7, 2010

10 Decisions a Relying Party should make.

Open and federated identity schemes such as OpenID, InfoCard, FBConnect, GFC or sometimes even SAML getting a lot of attention these days, with OpenID capturing the biggest mind share.

A lot has been written (and standardized) about Open Identity protocols, transport binding and token format, (things that are primary concerns of IDPs - IDentity Providers). However I feel less attention has been paid to changes that Relying Parties (RPs) have to make to their systems (user experience and design, identity and account structure, session management etc.), after all there is a big difference between provisioning your own identity and performing your own primary authentication, v.s. relying on some one else to do it for you.

Here is a list of 10 things (you know it had to be 10 !) that you need to think about and decide if you are planning to be a Relying Party:


1.    Decide which IDPs to accept: Not all IDP are created equal of course. 
2.       The design of the sign-in and registration page: in way that encourages the use of OpenID but not confuse users who do not use OpenID or do not know what it is.
3.   Covering the "Information gap": How to capture information you need and is not provided by user's IDP during initial session, also determining whether you can call IDP (thru back channel) and ask for more (or updated) information about a user.
4.   Privileges: Decide whether an OpenID user of your site has all the privileges of a local user or do they need to create a local account before they can perform certain activities.

5.       Covering the "trust gap": Do you need IDP to provide some level of assurance (or verification) of the attributes it is providing you. For example if IDP provides user's home address, do you need this address to be verified?
6.       Account Linking - decide whether you plan to become a true RP (i.e. no local account with local user name and password) or upon initial OpenID session, you plan to ask user to "register" with you site and create a local user name and password.
7.       Session Management:Do you plan to sync you local session with IDP session length (or shorter or longer?) regardless will you "force re-authentication" for certain activities?
8.       Profile Change Management: How do you plan to deal with users' who lose/forget their OpenID, is it important for you that a user 
9.       Account Cardinality: How many local account will you allow to be associated with one OpenID identifier, conversely, can an OpenID account be associated with multiple local accounts?
10.   Logout: Whenan OpenID user logs out of your site, are you planning to report that to IDP for federated logout?

And if you are looking for controversy, consider the issue of "reporting adverse behavior" i.e. if a RP experienced an adverse behavior from a user with OpenID, should the RP report it to the IDP? If you consider IDPs equivalent to robots then, it seems like the Three laws of Robotics says no, but if you think of IDP more like credit bureaus (or evolving to become more like identity bureaus) then the ChexSystem indicates otherwise....

Friday, April 2, 2010

Key to Scalability: Distributed System Development

Today I came across this nice presentation about Google internal architecture practices by Jeff Dean.plenty of valuable advice and common sense (the most uncommon of all senses). I just wanted to highlight one item that I feel is a bit under-appreciated - on page 20 when he talks about key attributes of distributed system, there is on bullet point that reads:

Development cycles largely decoupled
    – lots of benefits: small teams can work independently

On one hand this is so obvious! After all they are "distributed" systems, how can they have coupled life cycle, on the other hand in so many people complain about lack of productivity and agility in large "distributed" systems. When you look closer, you find out that they have fairly decoupled system initally, more or less get the boundaries right, however they coupled the life cycles of all applications and services together !!

This means the whole organization releases with one giant push, the whole system all together. Everyone has to be on the same page, over time this unified "beat"brings down the boundaries and soon "the distributed" system becomes a monolith.

I will write a few more entries about the basic principles that enable true distributed (and autonomous) application development.



By the way,   Here is eBay version of scalability advice (a bit dated but updating it is in my todo list) by Dan Pritchet.

eBay Social Shopping w/ Google Friend Connect

Today, with Jay Patel's post on Google Social Web Blog,  we released the alpha version of eBay Social Shopping gadget. It is a little cool Gadget that allows any sites (that is registered with Google Friend Connect), to surface eBay inventory and mix it with social functions such as recommendation to friend, rankings, sharing eBay activities (bid, buy, watch etc.) with friends etc.

You can read more about it by visiting ess.ebay.com and see our demos.