<br><font size=2 face="sans-serif">I'd be interested to hear if people
think the ph-off plugin is useful or not.... If not why not? </font>
<br>
<br><font size=2 face="sans-serif">If people think it's useful then I will
happily extend it and make it more usable and I will put it into whatever
open source project would like to house it. </font>
<br>
<br><font size=2 face="sans-serif">I built it as a proof of concept that
it _could_ be done... Now the question of _should_ it be done :-)</font>
<br>
<br><font size=2 face="sans-serif">http://chile.ootao.com/phoff/</font>
<br>
<br>
<br><font size=2 face="sans-serif">Andy Dale<br>
ooTao, Inc.<br>
<br>
Phone: 877-213-7935<br>
Fax: 877-213-7935<br>
<br>
i-name: =Andy.Dale<br>
http://xri.net/=andy.dale<br>
<br>
***************************************************************************<br>
If you don't have an i-name yet use this link to visit one of our partners
and buy one:<br>
<br>
http://www.ezibroker.net/partners.html<br>
<br>
***************************************************************************<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Chris Drake <christopher@pobox.com></b>
</font>
<p><font size=1 face="sans-serif">10/18/2006 07:20 PM</font>
<table border>
<tr valign=top>
<td bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Digital Identity Exchange <dix@ietf.org></font></div></table>
<br>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Scott Kveton <scott@janrain.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">specs@openid.net, general@openid.net,
Mike Glover <mpg4@janrain.com>, Digital Identity Exchange <dix@ietf.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re[2]: [dix] Re: Gathering requirements
for in-browser OpenID support</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt>Hi Scott,<br>
<br>
All solutions for client-based MITM and phishing prevention can easily<br>
be built on top of OpenID 2.0 if we adopt the OpenIDHTTPAuth proposal.<br>
<br>
We can then leave these people to build their tools and protection<br>
howsoever they like, safe in the knowledge that when it's *done*,<br>
there will be a range of new plugins that will immediately work with<br>
all OpenID 2.0 enabled sites - and best of all - it does not have to<br>
hold up the OpenID 2.0 development in the meantime.<br>
<br>
The only thing we need to give to these tools is a way to get the<br>
login process started - that is - OpenIDHTTPAuth: the downloaded<br>
plugin needs to be able to get an entry point for the OpenID CGI code<br>
on the web site.<br>
<br>
-----------<br>
<br>
Here is a copy of my vote to include the above proposal, which<br>
contains more info abut it too:<br>
<br>
<br>
Hi,<br>
<br>
Why's this proposal "depreciated" ?<br>
( http://www.lifewiki.net/openid/OpenIDProposals )<br>
<br>
I'm casting my vote here:<br>
<br>
+1 to [PROPOSAL] bare response / bare request<br>
<br>
Besides the listed uses, it also allows IdPs to layer privacy and<br>
delegation easily on top of OpenID, as well as permitting cool future<br>
features (like letting a user change something at their IdP, and have<br>
that change be "pushed out" to all relevant RPs).<br>
<br>
This is a small and simple to implement "hook" which I believe
will be<br>
the dominating bit of OpenID protocol use in future.<br>
<br>
Alternatively - if we can standardize a way for the OpenIDHTTPAuth<br>
proposed extension to discover the RP's OpenID "entry point"
[so as to<br>
reliably eliminate the "optional" first step proposed here<br>
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good<br>
working alterative way to accommodate the "bare response" part
that we<br>
need.<br>
<br>
So...<br>
<br>
+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL<br>
that's somehow available to scripts, plugins,<br>
software agents that encounter OpenID login<br>
pages.<br>
<br>
Suggestion: (for OpenID-enabled login pages):-<br>
<br>
<link rel="openid.httpauth" href="http://my.rp.com/openid/blah.cgi"><br>
<br>
-----------<br>
<br>
<br>
Kind Regards,<br>
Chris Drake<br>
<br>
<br>
Thursday, October 19, 2006, 6:07:08 AM:<br>
<br>
>> It is vulnerable to a man in the middle attack - the RP, instead
of<br>
>> redirecting to the IdP redirects to itself or some other site
in<br>
>> cahoots, then proxies the conversation between the user and the
IdP<br>
>> thereby compromising the users (global) credentials as they pass
through.<br>
<br>
SK> Right, we've known about this for quite some time unfortunately
there hasn't<br>
SK> be a particularly easy solution to it and I classify this as one
of those<br>
SK> "The Internet Sucks" problems. I'm not saying we
shouldn't/couldn't do<br>
SK> anything about it I just think the right solution that mixes<br>
SK> ease-of-implementation and user need hasn't been found yet.<br>
<br>
>> There really needs to be user-agent support to avoid that - either<br>
>> something CardSpace like, or browser plugin that only ever presents
a<br>
>> pre-authenticated user.<br>
<br>
SK> I think we're headed in this direction. However, we have to
crawl before we<br>
SK> can walk. At least solving a big chunk of the use cases, getting
some<br>
SK> momentum behind the platform and solving a specific problem for
users<br>
SK> *today* is better than trying to build the perfect tool. We
can talk and<br>
SK> talk on these lists but we really don't know how users are going
to use this<br>
SK> stuff (or abuse it for that matter) until its out there and working
in the<br>
SK> wild.<br>
<br>
SK> I can't emphasize more the fact that with every passing day that
we don't<br>
SK> have OpenID v2.0 out the door, we're losing momentum from fixing
specific<br>
SK> user problems that are solved in the existing specification.<br>
<br>
SK> - Scott<br>
<br>
SK> _______________________________________________<br>
SK> general mailing list<br>
SK> general@openid.net<br>
SK> http://openid.net/mailman/listinfo/general<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
dix mailing list<br>
dix@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/dix<br>
</tt></font>
<br>