[security] how secure is openid? advise pls..

[Balasubramanian G]

"buttons to popular providers" idea is nice... i am planning to use php
library by JanRain, Inc. i believe that there're a few more libraries
available for php.. wht's ur idea abt them.. which one's better than the
others??

Warm Regards
Balasubramanian
www.icreatesoftwares.co.cc, www.yourtanpura.co.cc, www.quizmasterpro.co.cc


On Tue, Feb 10, 2009 at 1:18 AM, Nate Klingenstein <ndk at internet2.edu>wrote:

> Balasubramanian,
> Unfortunately, the answer to both of your questions today is probably yes.
>
> However, the difficulties associated with discovery user interfaces(typing
> URL's doesn't work for most users, so buttons to popular providers is
> common), or the set of information required beyond authentication like
> specialized attributes or social data, restricts the set of OP's anyway for
> some applications.  Hopefully a real reputation system or trust fabric will
> emerge to help resolve the conflict you point out.  It's still only on the
> chalkboard at this point, though.
>
> One last point you might consider, which is a bit frank, is whether a user
> with an insecure OP is exposing your site or sensitive data to danger, or
> only themselves.  I'm a strong believer in protecting users from themselves,
> but if you're comfortable with users assuming the risks resulting from
> choosing a bad OP, and there is no risk to your site, maybe it's okay if you
> accept all comers.
>
> Take care,
> Nate.
>
>
> On 09 Feb 2009, at 19:38, Balasubramanian G wrote:
>
> That was a nice reply Nate.. So would it be of some help, if i restrict the
> users to sign in through some trusted OPs instead of any x y z?? But by
> doing this am I not breaking one of the rules of thumb in OpenID concept??
> That the users can authenticate themselves through any OP which if i
> restrict, would not be true in my website..
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20090210/3f64499a/attachment-0002.htm>