W3C home > Mailing lists > Public > public-usable-authentication@w3.org > October 2006

Re[4]: [dix] Re: Gathering requirements for in-browser OpenID support

From: Chris Drake <christopher@pobox.com>
Date: Thu, 19 Oct 2006 18:52:01 +1000
Message-ID: <927247889.20061019185201@pobox.com>
To: Dick Hardt <dick@sxip.com>
CC: "Gabe Wachob" <gabe.wachob@amsoft.net>, "'Digital Identity Exchange'" <dix@ietf.org>, <general@openid.net>, <public-usable-authentication@w3.org>

Dick: Sounds like you've got a cool extension for OpenID.
Andy: We've seen and congratulate you on yours
Myself: I've got one as well
Here's a list with a dozen or more folks with similar:-

SO - technology that takes AWAY from the RP the opportunity to
initiate the OpenID login is a good way to safely prevent MITM
attacks - the only thing that remains is to nut out exactly how we
want to achieve this.

We need...
1. A way for a software agent to recognize an RP (and hence take the
   user to their real chosen IdP with chrome switched on etc)
2. A way for an IdP to initiate the login with the RP

How shall we all agree to handle this?  Who wants to write it up?
This seems like a simple tweak to the existing "OpenIDHTTPAuth"
extension, or even the "Bare Request" proposal.  I think we should
maybe unify all this into a single proposal - does that sounds

My proposal is:
RP's login page MUST contain
<link rel="openid.entry" href="https://my.rp.com/openid/entry.cgi">

This solves 1 & 2 since agents can tell immediately that this is an
OpenID 2.0 enabled page (without the overhead of fetching yadis
documents etc), and at the same time find out how to kick the login
process off.  For *me* - this is sufficient.  Dick? Andy? I'm guessing
you need something extra - maybe a flag so you know whether or not the
user is already logged in?, or whether the page currently displayed is
actually requesting that a new login takes place?, or perhaps some
info about which identity a user selected to be logged in with: you
guys know your own chrome ideas best - do you need this, or anything

Kind Regards,
Chris Drake

Friday, October 20, 2006, 2:45:23 AM, you wrote:

DH> Just to keep beating that dead horse some more, this demonstrates why
DH> *how* to solve the issue is out of scope, but that there is an issue
DH> MUST be in the spec. :-)

DH> btw: that is a cool extension, but wait until you see ours! ;-)

DH> -- Dick

DH> On 19-Oct-06, at 9:40 AM, Gabe Wachob wrote:

>> And not to beat a dead horse to a pulp, but the Ph-Off Firefox  
>> extension
>> from OOTao provides exactly this sort of trustable (based on SSL  
>> certs)
>> visual indicator that you are actually talking to your real OpenID
>> IDP. Its
>> obviously an early iteration, but it *is* there and performs the  
>> function
>> adequately.
>> http://chile.ootao.com/phoff/
>> 	-Gabe
>>> -----Original Message-----
>>> From: general-bounces@openid.net [mailto:general- 
>>> bounces@openid.net] On
>>> Behalf Of Chris Drake
>>> Sent: Thursday, October 19, 2006 9:35 AM
>>> To: Dick Hardt
>>> Cc: Digital Identity Exchange; general@openid.net
>>> Subject: Re[2]: [dix] Re: Gathering requirements for in-browser  
>>> OpenID
>>> support
>>> Hi Dick,
>>> I disagree - the RP is *responsible* for directing the user to the
>>> IdP;  This is the highest risk point of MITM attack.  OpenID MUST
>>> include something to "enable" a "safe redirect" or browser-chrome
>>> activation or whathaveyou.  Granted - chrome etc shouldn't be in the
>>> spec, but *enabling* it for the future MUST.
>>> Kind Regards,
>>> Chris Drake
>>> Thursday, October 19, 2006, 1:56:05 PM, you wrote:
>>> DH> The MITM attack vector resolution is out of scope of OpenID
>>> DH> Authentication as it is a ceremony between the user and the  
>>> IdP. The
>>> DH> user and IdP need to know they are talking directly to each  
>>> other.
>>> DH> -- Dick
>>> DH> On 18-Oct-06, at 1:07 PM, Scott Kveton wrote:
>>>>>> 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.
>>>>> Right, we've known about this for quite some time unfortunately
>>>>> there hasn't
>>>>> be a particularly easy solution to it and I classify this as one of
>>>>> those
>>>>> "The Internet Sucks" problems.  I'm not saying we shouldn't/
>>>>> couldn't do
>>>>> anything about it I just think the right solution that mixes
>>>>> 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.
>>>>> I think we're headed in this direction.  However, we have to crawl
>>>>> before we
>>>>> can walk.  At least solving a big chunk of the use cases,  
>>>>> getting some
>>>>> momentum behind the platform and solving a specific problem for
>>>>> users
>>>>> *today* is better than trying to build the perfect tool.  We can
>>>>> talk and
>>>>> talk on these lists but we really don't know how users are going to
>>>>> use this
>>>>> stuff (or abuse it for that matter) until its out there and working
>>>>> in the
>>>>> wild.
>>>>> I can't emphasize more the fact that with every passing day that we
>>>>> don't
>>>>> have OpenID v2.0 out the door, we're losing momentum from fixing
>>>>> specific
>>>>> user problems that are solved in the existing specification.
>>>>> - Scott
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> general@openid.net
>>>>> http://openid.net/mailman/listinfo/general
>>> DH> _______________________________________________
>>> DH> general mailing list
>>> DH> general@openid.net
>>> DH> http://openid.net/mailman/listinfo/general
>>> _______________________________________________
>>> general mailing list
>>> general@openid.net
>>> http://openid.net/mailman/listinfo/general
Received on Thursday, 19 October 2006 18:52:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:15 UTC