<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=546242918-19102006><FONT face=Arial
color=#0000ff size=2>Andy,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=546242918-19102006><FONT face=Arial
color=#0000ff size=2>I think it is incredibly useful in showing the technology
needed to help protect users with systems like this. I'd love to see it as
part of the Heraldry project, you are already a committer, assuming you'd
be willing to contribute it.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=546242918-19102006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=546242918-19102006><FONT face=Arial
color=#0000ff size=2>--David</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> specs-bounces@openid.net
[mailto:specs-bounces@openid.net] <B>On Behalf Of
</B>andy.dale@ootao.com<BR><B>Sent:</B> Wednesday, October 18, 2006 11:44
PM<BR><B>To:</B> Digital Identity Exchange<BR><B>Cc:</B> Digital Identity
Exchange; specs@openid.net; general@openid.net<BR><B>Subject:</B> Re: Re[2]:
[dix] Re: Gathering requirements for in-browser
OpenIDsupport<BR></FONT><BR></DIV>
<DIV></DIV><BR><FONT face=sans-serif size=2>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 face=sans-serif size=2>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 face=sans-serif
size=2>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 face=sans-serif
size=2>http://chile.ootao.com/phoff/</FONT> <BR><BR><BR><FONT face=sans-serif
size=2>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%">
<TBODY>
<TR vAlign=top>
<TD width="40%"><FONT face=sans-serif size=1><B>Chris Drake
<christopher@pobox.com></B> </FONT>
<P><FONT face=sans-serif size=1>10/18/2006 07:20 PM</FONT>
<TABLE border=1>
<TBODY>
<TR vAlign=top>
<TD bgColor=white>
<DIV align=center><FONT face=sans-serif size=1>Please respond
to<BR>Digital Identity Exchange
<dix@ietf.org></FONT></DIV></TR></TBODY></TABLE><BR></P>
<TD width="59%">
<TABLE width="100%">
<TBODY>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>To</FONT></DIV>
<TD><FONT face=sans-serif size=1>Scott Kveton
<scott@janrain.com></FONT>
<TR vAlign=top>
<TD>
<DIV align=right><FONT face=sans-serif size=1>cc</FONT></DIV>
<TD><FONT face=sans-serif size=1>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 face=sans-serif size=1>Subject</FONT></DIV>
<TD><FONT face=sans-serif size=1>Re[2]: [dix] Re: Gathering
requirements for in-browser OpenID support</FONT></TR></TBODY></TABLE><BR>
<TABLE>
<TBODY>
<TR vAlign=top>
<TD>
<TD></TR></TBODY></TABLE><BR></TR></TBODY></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></BODY></HTML>