Just to keep beating that dead horse some more, this demonstrates why
*how* to solve the issue is out of scope, but that there is an issue
MUST be in the spec. :-)
btw: that is a cool extension, but wait until you see ours! ;-)
-- Dick
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: [EMAIL PROTECTED] [mailto:general-
[EMAIL PROTECTED] On
Behalf Of Chris Drake
Sent: Thursday, October 19, 2006 9:35 AM
To: Dick Hardt
Cc: Digital Identity Exchange; [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general
DH> _______________________________________________
DH> general mailing list
DH> [EMAIL PROTECTED]
DH> http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
[EMAIL PROTECTED]
http://openid.net/mailman/listinfo/general
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
