[OpenID] Trust + Security @ OpenID
Eddy Nigg (StartCom Ltd.)
eddy_nigg at startcom.org
Fri Jul 20 19:50:56 UTC 2007
Hi Stephan,
I hope we all agree that SMTP sucks! We all suffer from it really...But
because it's extremely popular, many different solutions are tried with
more or less success to overcome spam and phishing. SMTP was developed
in the 80s and nobody can blame the inventor of this protocol for not
seeing into the future.
XMPP however is aware of the threats and are openly working on
preventing spam: https://stpeter.im/?p=1989
Also XMPP tries to improve security aspects: https://www.xmpp.net/
Now in the real world and also in PKI the relying party is the one to be
protected. In PKI the concern is the relying party (end user) who need
assurances for doing X or Y on the Internet (including purchase,
socializing, commerce etc).
However in the OpenID world, the relying party is NOT the end user**
(having an account), but web sites. The web sites wishing to make use of
OpenID as an authentication form are the relying party. It's their sites
which get screwed and spamed. You say below:
"A bad OP can only do nasty things if user X chooses to use them."
But if you can be your own OP, than you are also the user and the OP! So
a bads user is also a bad OP! I don't want to rely on bad OPs. Therefore
there must be a mechanism which allows any sincere person/organization
to run their own OP, but prevent the bad guys from doing that. Proposals
have been posted to this list and thread.
** The end user obviously can also be a screwed by IDPs (by weak server
security, identity theft and simple fraud), but as you mentioned
correctly, this is the end users choice if he relies on a third party
identity provider (IDP).
Stephen Paul Weber wrote:
> I have to agree here. There are decentralized technologies that work
> : SMTP and XMPP being the most popular. An RP needs to be able to
> trust users, not OPs. The protocol proves that user X has chosen OP X
> and controls URI X. A bad OP can only do nasty things if user X
> chooses to use them. USERs can be nasty, but OPs serve a pretty basic
> function.
>
> On 7/8/07, *Brendan Taylor* <whateley at gmail.com
> <mailto:whateley at gmail.com>> wrote:
>
> On Sun, Jul 08, 2007 at 01:59:02AM +0300, Eddy Nigg (StartCom
> Ltd.) wrote:
> > like self-signed certificates. A relying party can choose to
> trust them
> > but nothing has been verified or guarantied in any form (not
> even the
> > integrity of the authentication process). For me as relying party
> > running a forum or web log, this is not really assuring...not to
> speak
> > about other potential login facilities.
>
> This is something I've never understood - why does an RP need to
> trust an
> OP? If this is about spam, then surely it makes more sense to
> determine
> trust per-user (and possibly blacklist OPs).
>
> I especially don't understand why the RP cares about "integrity of the
> authentication process". Surely it should be the user's
> responsibility
> to select an OP with the security they require.
>
> I think this is going in the wrong direction; I would be very
> disappointed if OpenID lost its decentralization, and I'm not sure why
> people think it needs to.
>
> _______________________________________________
> general mailing list
> general at openid.net <mailto:general at openid.net>
> http://openid.net/mailman/listinfo/general
> <http://openid.net/mailman/listinfo/general>
>
>
>
>
>
> --
> - Stephen Paul Weber, Amateur Writer
> <http://www.awriterz.org>
>
> MSN/GTalk/Jabber: singpolyma at gmail.com <mailto:singpolyma at gmail.com>
> ICQ/AIM: 103332966
> BLOG: http://singpolyma.net/
> ------------------------------------------------------------------------
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: startcom at startcom.org
Phone: +1.213.341.0390
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20070720/41c9ee43/attachment-0002.htm>
More information about the general
mailing list