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:-
[EMAIL PROTECTED]
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: [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
