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

[Dick Hardt <[e-mail]>]

Hi Chris

One of the features of looking at the OpenID form and detecting  
openid_identifier field is that we can place some a graphical element  
on top of the form rather then making the user goto the chrome to  
login. Our UX testing has found that to be really useful.

Since the entrypoint is where the action is, all we needed was for  
RPs that wanted to use AJAX and check_imediate to have an action  
entry in the form that would work for browsers with JavaScript  
disabled, a good practice regardless.

-- Dick

On 19-Oct-06, at 1:52 AM, Chris Drake wrote:

>
>
> 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:-
> [e-mail]
>
> 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
> sensible?
>
> 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
> else?
>
> 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: [e-mail] [mailto:general-
>>>> [e-mail]] On
>>>> Behalf Of Chris Drake
>>>> Sent: Thursday, October 19, 2006 9:35 AM
>>>> To: Dick Hardt
>>>> Cc: Digital Identity Exchange; [e-mail]
>>>> 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
>>>>>> [e-mail]
>>>>>> http://openid.net/mailman/listinfo/general
>>>>>>
>>>>>>
>>>>
>>>> DH> _______________________________________________
>>>> DH> general mailing list
>>>> DH> [e-mail]
>>>> DH> http://openid.net/mailman/listinfo/general
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> general mailing list
>>>> [e-mail]
>>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>
>
>
>
>


_______________________________________________
dix mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dix