Hi Scott, All solutions for client-based MITM and phishing prevention can easily be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.
We can then leave these people to build their tools and protection howsoever they like, safe in the knowledge that when it's *done*, there will be a range of new plugins that will immediately work with all OpenID 2.0 enabled sites - and best of all - it does not have to hold up the OpenID 2.0 development in the meantime. The only thing we need to give to these tools is a way to get the login process started - that is - OpenIDHTTPAuth: the downloaded plugin needs to be able to get an entry point for the OpenID CGI code on the web site. ----------- Here is a copy of my vote to include the above proposal, which contains more info abut it too: Hi, Why's this proposal "depreciated" ? ( http://www.lifewiki.net/openid/OpenIDProposals ) I'm casting my vote here: +1 to [PROPOSAL] bare response / bare request Besides the listed uses, it also allows IdPs to layer privacy and delegation easily on top of OpenID, as well as permitting cool future features (like letting a user change something at their IdP, and have that change be "pushed out" to all relevant RPs). This is a small and simple to implement "hook" which I believe will be the dominating bit of OpenID protocol use in future. Alternatively - if we can standardize a way for the OpenIDHTTPAuth proposed extension to discover the RP's OpenID "entry point" [so as to reliably eliminate the "optional" first step proposed here http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good working alterative way to accommodate the "bare response" part that we need. So... +1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL that's somehow available to scripts, plugins, software agents that encounter OpenID login pages. Suggestion: (for OpenID-enabled login pages):- <link rel="openid.httpauth" href="http://my.rp.com/openid/blah.cgi"> ----------- Kind Regards, Chris Drake Thursday, October 19, 2006, 6:07:08 AM: >> It is vulnerable to a man in the middle attack - the RP, instead of >> redirecting to the IdP redirects to itself or some other site in >> cahoots, then proxies the conversation between the user and the IdP >> thereby compromising the users (global) credentials as they pass through. SK> Right, we've known about this for quite some time unfortunately there hasn't SK> be a particularly easy solution to it and I classify this as one of those SK> "The Internet Sucks" problems. I'm not saying we shouldn't/couldn't do SK> anything about it I just think the right solution that mixes SK> ease-of-implementation and user need hasn't been found yet. >> There really needs to be user-agent support to avoid that - either >> something CardSpace like, or browser plugin that only ever presents a >> pre-authenticated user. SK> I think we're headed in this direction. However, we have to crawl before we SK> can walk. At least solving a big chunk of the use cases, getting some SK> momentum behind the platform and solving a specific problem for users SK> *today* is better than trying to build the perfect tool. We can talk and SK> talk on these lists but we really don't know how users are going to use this SK> stuff (or abuse it for that matter) until its out there and working in the SK> wild. SK> I can't emphasize more the fact that with every passing day that we don't SK> have OpenID v2.0 out the door, we're losing momentum from fixing specific SK> user problems that are solved in the existing specification. SK> - Scott SK> _______________________________________________ SK> general mailing list SK> [EMAIL PROTECTED] SK> http://openid.net/mailman/listinfo/general _______________________________________________ specs mailing list firstname.lastname@example.org http://openid.net/mailman/listinfo/specs