RE: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport

["Recordon, David" <drecordon at verisign.com>]

Andy,

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.

 

--David

---

From: specs-bounces at openid.net [mailto:specs-bounces at openid.net] On Behalf Of andy.dale at ootao.com
Sent: Wednesday, October 18, 2006 11:44 PM
To: Digital Identity Exchange
Cc: Digital Identity Exchange; specs at openid.net; general at openid.net
Subject: Re: Re[2]: [dix] Re: Gathering requirements for in-browser OpenIDsupport

I'd be interested to hear if people 
think the ph-off plugin is useful or not.... If not why not? 

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. 

I built it as a proof of concept that it _could_ be done... Now the 
question of _should_ it be done :-) 

http://chile.ootao.com/phoff/ 


Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 
877-213-7935

i-name: 
=Andy.Dale
http://xri.net/=andy.dale

***************************************************************************
If 
you don't have an i-name yet use this link to visit one of our partners and buy 
one:

  
http://www.ezibroker.net/partners.html

***************************************************************************

Chris Drake <christopher at pobox.com>

10/18/2006 07:20 PM

Please respond to
Digital Identity Exchange <dix at ietf.org>

To	Scott Kveton <scott at janrain.com>
cc	specs at openid.net, general at openid.net, Mike Glover <mpg4 at janrain.com>, Digital Identity Exchange <dix at ietf.org>
Subject	Re[2]: [dix] Re: Gathering requirements for in-browser OpenID support

Hi Scott,

All solutions for client-based MITM and phishing 
prevention can easily
be built on top of OpenID 2.0 if we adopt the 
OpenIDHTTPAuth proposal.

We can then leave these people to build their 
tools and protection
howsoever they like, safe in the knowledge that when 
it's *done*,
there will be a range of new plugins that will immediately work 
with
all OpenID 2.0 enabled sites - and best of all - it does not have 
to
hold up the OpenID 2.0 development in the meantime.

The only thing 
we need to give to these tools is a way to get the
login process started - 
that is - OpenIDHTTPAuth: the downloaded
plugin needs to be able to get an 
entry point for the OpenID CGI code
on the web 
site.

-----------

Here is a copy of my vote to include the above 
proposal, which
contains more info abut it too:


Hi,

Why's 
this proposal "depreciated" ?
( 
http://www.lifewiki.net/openid/OpenIDProposals )

I'm casting my vote 
here:

+1 to [PROPOSAL] bare response / bare request

Besides the 
listed uses, it also allows IdPs to layer privacy and
delegation easily on 
top of OpenID, as well as permitting cool future
features (like letting a 
user change something at their IdP, and have
that change be "pushed out" to 
all relevant RPs).

This is a small and simple to implement "hook" which I 
believe will be
the dominating bit of OpenID protocol use in 
future.

Alternatively - if we can standardize a way for the 
OpenIDHTTPAuth
proposed extension to discover the RP's OpenID "entry point" 
[so as to
reliably eliminate the "optional" first step proposed 
here
http://www.lifewiki.net/openid/OpenIDHTTPAuth ] - this is a 
good
working alterative way to accommodate the "bare response" part that 
we
need.

So...

+1 to OpenIDHTTPAuth - on the proviso RP's 
publish an endpoint URL
              
        that's somehow available to scripts, 
plugins,
                  
    software agents that encounter OpenID login
    
                  
pages.

                  
    Suggestion: (for OpenID-enabled login 
pages):-

 <link rel="openid.httpauth" 
href="">

-----------


Kind 
Regards,
Chris Drake


Thursday, October 19, 2006, 6:07:08 
AM:

>> 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.

SK> Right, we've known about this for quite some time 
unfortunately there hasn't
SK> be a particularly easy solution to it and I 
classify this as one of those
SK> "The Internet Sucks" problems.  I'm 
not saying we shouldn't/couldn't do
SK> anything about it I just think the 
right solution that mixes
SK> 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.

SK> I think 
we're headed in this direction.  However, we have to crawl before 
we
SK> can walk.  At least solving a big chunk of the use cases, 
getting some
SK> momentum behind the platform and solving a specific 
problem for users
SK> *today* is better than trying to build the perfect 
tool.  We can talk and
SK> talk on these lists but we really don't 
know how users are going to use this
SK> stuff (or abuse it for that 
matter) until its out there and working in the
SK> wild.

SK> I 
can't emphasize more the fact that with every passing day that we 
don't
SK> have OpenID v2.0 out the door, we're losing momentum from fixing 
specific
SK> user problems that are solved in the existing 
specification.

SK> - Scott

SK> 
_______________________________________________
SK> general mailing 
list
SK> general at openid.net
SK> 
http://openid.net/mailman/listinfo/general




_______________________________________________
dix 
mailing 
list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix

_______________________________________________
dix mailing list
dix at ietf.org
https://www1.ietf.org/mailman/listinfo/dix