<br><font size=2 face="sans-serif"><br>
I'd be interested to hear if people think the ph-off plugin is useful or
not.... If not why not? </font><font size=3><br>
</font><font size=2 face="sans-serif"><br>
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><font size=3><br>
</font><font size=2 face="sans-serif"><br>
I built it as a proof of concept that it _could_ be done... Now the question
of _should_ it be done :-)</font><font size=3> <br>
</font><font size=2 face="sans-serif"><br>
http://chile.ootao.com/phoff/</font><font size=3> <br>
<br>
</font><font size=2 face="sans-serif"><br>
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>
 &nbsp;http://www.ezibroker.net/partners.html<br>
<br>
***************************************************************************</font><font size=3><br>
<br>
<br>
</font>
<table width=100%>
<tr valign=top>
<td width=27%><font size=1 face="sans-serif"><b>Chris Drake &lt;christopher@pobox.com&gt;</b>
</font>
<p><font size=1 face="sans-serif">10/18/2006 07:20 PM</font><font size=3>
</font>
<br><font size=2><br>
</font>
<table border=4 width=100%>
<tr valign=top>
<td width=100% bgcolor=white>
<div align=center><font size=1 face="sans-serif">Please respond to<br>
Digital Identity Exchange &lt;dix@ietf.org&gt;</font></div></table>
<br>
<p>
<td width=72%><font size=2><br>
</font>
<table width=100%>
<tr valign=top>
<td width=7%>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td width=92%><font size=1 face="sans-serif">Scott Kveton &lt;scott@janrain.com&gt;</font><font size=3>
</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 &lt;mpg4@janrain.com&gt;, Digital Identity Exchange &lt;dix@ietf.org&gt;</font><font size=3>
</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>
<br>
<br><font size=2><br>
</font>
<table width=100%>
<tr valign=top>
<td width=50%>
<td width=49%></table>
<br>
<br></table>
<br>
<br><font size=3><br>
<br>
</font><font size=2><tt><br>
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 &quot;depreciated&quot; ?<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 &quot;pushed out&quot; to all relevant RPs).<br>
<br>
This is a small and simple to implement &quot;hook&quot; 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 &quot;entry point&quot;
[so as to<br>
reliably eliminate the &quot;optional&quot; first step proposed here<br>
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a good<br>
working alterative way to accommodate the &quot;bare response&quot; part
that we<br>
need.<br>
<br>
So...<br>
<br>
+1 to OpenIDHTTPAuth - on the proviso RP's publish an endpoint URL<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;that's somehow available to scripts, plugins,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;software agents that encounter OpenID login<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;pages.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;Suggestion: (for OpenID-enabled login pages):-<br>
<br>
 &lt;link rel=&quot;openid.httpauth&quot; href=&quot;http://my.rp.com/openid/blah.cgi&quot;&gt;<br>
<br>
-----------<br>
<br>
<br>
Kind Regards,<br>
Chris Drake<br>
<br>
<br>
Thursday, October 19, 2006, 6:07:08 AM:<br>
<br>
&gt;&gt; It is vulnerable to a man in the middle attack - the RP, instead
of<br>
&gt;&gt; redirecting to the IdP redirects to itself or some other site
in<br>
&gt;&gt; cahoots, then proxies the conversation between the user and the
IdP<br>
&gt;&gt; thereby compromising the users (global) credentials as they pass
through.<br>
<br>
SK&gt; Right, we've known about this for quite some time unfortunately
there hasn't<br>
SK&gt; be a particularly easy solution to it and I classify this as one
of those<br>
SK&gt; &quot;The Internet Sucks&quot; problems. &nbsp;I'm not saying we
shouldn't/couldn't do<br>
SK&gt; anything about it I just think the right solution that mixes<br>
SK&gt; ease-of-implementation and user need hasn't been found yet.<br>
<br>
&gt;&gt; There really needs to be user-agent support to avoid that - either<br>
&gt;&gt; something CardSpace like, or browser plugin that only ever presents
a<br>
&gt;&gt; pre-authenticated user.<br>
<br>
SK&gt; I think we're headed in this direction. &nbsp;However, we have to
crawl before we<br>
SK&gt; can walk. &nbsp;At least solving a big chunk of the use cases, getting
some<br>
SK&gt; momentum behind the platform and solving a specific problem for
users<br>
SK&gt; *today* is better than trying to build the perfect tool. &nbsp;We
can talk and<br>
SK&gt; talk on these lists but we really don't know how users are going
to use this<br>
SK&gt; stuff (or abuse it for that matter) until its out there and working
in the<br>
SK&gt; wild.<br>
<br>
SK&gt; I can't emphasize more the fact that with every passing day that
we don't<br>
SK&gt; have OpenID v2.0 out the door, we're losing momentum from fixing
specific<br>
SK&gt; user problems that are solved in the existing specification.<br>
<br>
SK&gt; - Scott<br>
<br>
SK&gt; _______________________________________________<br>
SK&gt; general mailing list<br>
SK&gt; general@openid.net<br>
SK&gt; 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</tt></font><font size=3><br>
</font>