Kim Cameron in his blog discusses an approach to integrate OpenID with Infocards. This basically adds phishing resistance to OpenID - where, once a user is redirected to the OpenID provider for authentication, he'll be using an Infocard for authentication. In other words - the OpenID provider will be acting as an Infocard Relying Party who accepts Infocards. In this case, personal Infocards can be used - where those need to be registered with the OpenID Provider, before hand. This approach will completely eliminate typing passwords always.
Kim Cameron's approach is very much different from what is proposed in this spec by Sxip Identity.This proposes a new term - 'OpenID Inforcard'. Please refer my previous post to see a demonstration on OpenID Infocards and this post to find the differences between normal Infocard and OpenID Infocard approaches.
Well, if we go by Kim Cameron's proposal, we need to modify the OpenID Provider in to an Infocard Relying party.But, what is the gain? We make the OpenID flow phishing resistance.Anyway, if that is the only benefit - do we have to (really) go ahead with it? There are many other approaches to make OpenID, phishing resistance without touching the current OpenID Provider implementation. One such approach is to use the SeatBelt plugin for Firefox. But, with this, are we asking 'too' much from the user, since we pass the responsibility of protecting from phishing, towards the user.Anyway - my final thoughts on this is, Kim's proposal will definitely will be a marketing plus for OpenID Providers, if they, themselves add the phishing resistance to OpenID flow using Infocards.
Going back to the OpenID Infocard proposal - I can't really understand the benefit. It's almost same as the normal Infocard approach, except the use of OpenIDToken inside the RequestedSecurityToken, instead of SAML. In this post Mike Jones lists the benefits of OpenID Infocards against 'normal' OpenID.
1. There’s no OpenID string to type when you use your OpenID
2. This is a phishing-resistant authentication method.
3. It lets you recognize and choose your OpenID visually, based on the card graphics supplied by the OpenID provider.
Yes - I agree with all, but is there a point of using OpenID Infocards[OpenIDToken supported] against Infocards[SAML supported]?
Tuesday, December 18, 2007
Integrating OpenID and Infocard
Subscribe to:
Post Comments (Atom)
2 comments:
I didn't mean to imply that using your InfoCard to log in to your openid provider was better than direct use of an "openid infocard" as proposed by sxip. I actually like their proposal a lot. But I also think Jan Rain's method is cool too, and works with any site at all.
I don't like the SeatBelt idea at all, as much as I empathize with the need for a quick and dirty solution. THe main new attack we are seeing is "Browser in the middle", and Seatbelt helps automate and legitimize that. Plus, it puts OpenID into a ghetto with respect to other stronger forms of authentication. Making everything part of a continuum with shared experience to me remains a top priority.
Best regards!
Kim
Thanks Kim for your valuable thoughts.
But, still I am trying to figure out the gain, by using an OpenIDToken in 'openid infocards' instead of SAML.
Any thoughts?
Thanks & regards.
- Prabath
Post a Comment