alavillipraveen's blog

I am sure several of you might have already heard about OAuth but for those who haven't here is a deck I presented at the XTech 2008 conference earlier this year in Dublin, Ireland. Hope it would help you understand various aspects of it.

just wanted to clarify a few things regarding the Vidoop ImageShield integration for AOL/AIM OpenID users:

• All Vidoop ImageShield Passwords are stored in AOL. No information about user is shared with Vidoop.
• The Vidoop ImageShield is used as a 1st factor login credential, unlike Verisign VIP Token, which is a 2nd factor login credential.
• At this time no image ads are used in the Vidoop ImageShield.

This is a followup to my earlier blog with the same title (Vidoop ImageShield for AOL OpenID Users ?). Yesterday we opened up our private beta as a public beta for all AOL/AIM users that use their AOL OpenID to login to any 3rd party websites that supports OpenID (Relying Parties). To try it out just go to any OpenID relying party site and login with your AOL OpenID (openid.aol.com/) . In the OpenID login page you will see an option to add a Vidoop ImageShield Password to your account.

Shamelessly copied the title from Eran's blog post on OAuth Summit - hope he doesn't mind. :-)

So the OAuth Summit finally happened yesterday at the Yahoo! campus in Santa Clara, CA. It was great meeting with a lot of other folks that have been working on OAuth for a while now from different companies and organizations.

With the increase in the usage of mashups and widget/gadgets providing more personalized services from different providers on different sites (ex. netvibes.com, iGoogle gadgets, Facebook applications, etc..), and asking users to enter their login credentials at different sites, it is very important for all Identity Providers to provide any possible ways to reduce the need for the users to enter their secure login credentials multiple times from multiple locations. This is where exactly OpenID helps in providing a simple and open protocol to exchange user identities across the boundaries.

But with OpenID gaining more and more popularity all across the web to allow users to use their single account (from their trusted 'OpenID Provider') at many sites (called 'Relying Parties'), and also with the way OpenID protocol works by making the Relying Parties redirect users to the user's OpenID provider, there are some very valid security concerns about malicious Relying Parties out there redirecting the users to potential phishing sites that could steal user's credentials. So it is very important for the OpenID Providers to make sure they provide good ways for their users to be able to login more securely and be able to detect Phishing sites from legitimate sites. This is where exactly the 'Vidoop ImageShield' (also called 'RecoginitionAUTH') comes in to play to provide strong login technology that helps in fighting against these malicious attacks.

A new ID Selector from Janrain has been launched today to help make OpenID usage easier for end users. So far there has been a lot of talk around how to address the usability issues with OpenID and of course there have been several browser plugins proposed and implemented (like Sxipper, Seatbelt, etc). But 'ID Selector' is the first one of it's kind - I call it's "one of it's kind" because it's not a browser tool bar. It's a simple DHTML widget that can be embedded into any Relying Party (RP) login page with as simple as adding 2 lines of code. Of course the concept is not new (even we at AOL have a small DHTML Login Widget that we use to embed login module on several AOL web properties, ex. http://music.aol.com) but using it to present different accounts that a user can sign in with, without confusing them about the underlying technologies is neat. I really like this idea and am hoping that this would make the sign in process consistent across all the web supporting OpenID protocol.

We launched a new version of OpenAuth yesterday, which now has support for a new login method (called 'clientLogin') for rich clients (standalone desktop clients, flash/AIR/Silverlight clients both standalone and browser embedded). I have blogged before why we need to provide login methods for client applications.

With the new OpenAIM 2.0 launch, we really had to open up our authentication for rich clients built by 3rd party developers so they can build really cool AIM clients with great user experience.

I want to congratulate our peers on the Yahoo! Authentication team for a job well done. As you might have already [url=http://developer.yahoo.net/blog/archives/2008/01/yahoo-openid-beta.html]read[/url] - they released their OpenID support as public beta yesterday. We got a sneak preview from Allen and Shreyas last week and we were quite impressed with the way they dealt with usability, security and user education. Their implementation and presentation is a very good start to set a baseline for all OpenID Providers. As I have mentioned several times before both internally and externally, our end users do not need to know what OpenID or SAML or OAuth are. What we need to educate them about is how they can now use their favorite ID from their favorite IDP and use it anywhere without worrying about the protocol details. I am looking forward for those days ahead and ready to do anything we can to make it a reality.

I am sure most of you have noticed the new GMail + AIM integration - if not you can read about it several blogs.

Two important Open API/SDKs from AOL/AIM made it possible:
- AIM provides an SDK (code name 'AIMcc') that allows you to make use of complete AIM functionality in your custom clients.
- AOL's OpenAuth APIs provide a way for doing direct authentications from trusted clients/proxies so they can obtain an authentication token that can be used to do things on behalf of the users.

There were some good discussions at IIW this week about direct login methods for clients in general and also about if OpenID should support such methods.

Keeping aside the phishing, untrusted clients issues and in general good principles we follow in the Identity world, here are the reasons why i think we need to provide 'direct' login methods (with redirects and UI):

- not all clients have access to a browser/browser control objects
- user exp is considered as broken when a client app opens an external browser window
- even though some clients could embed browser control objects with themselves, not all can do that (flash apps, mobile app, ...)