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]?