[Security] client-to-client security :: Summary and todo's
Hannes.Tschofenig at gmx.net
Sat Aug 23 12:12:36 CDT 2008
Pavel Simerda wrote:
> On Sat, 23 Aug 2008 18:21:38 +0200
> Dirk Meyer <dmeyer at tzi.de> wrote:
>> Pavel Simerda wrote:
>>> On Sat, 23 Aug 2008 16:23:28 +0200
>>> Dirk Meyer <dmeyer at tzi.de> wrote:
>>>> Pedro Melo wrote:
>>>>> On Aug 23, 2008, at 2:12 PM, Dirk Meyer wrote:
>>>>>> IMHO OAuth is kind of stupid. I have to trust a server I do not
>>>>>> know. No, the point is that I can upload a certificate to my
>>>>>> XMPP server and the owner of that certificate (a bot, a client
>>>>>> I do not trust) can log in using SASL-EXTERNAL as me without
>>>>>> having the password.
>>>>> OAuth is not stupid. The server you do not trust is your own XMPP
>>>>> server. If you don't trust that, well, what are you doing
>>>>> connected to him?
>>>> Oops, sorry, I messed up OAuth and OpenID. My fault, ignore me.
>>> Neither OpenID seems stupid to me. "Stupid" is a word that only
>>> means you didn't bother to find more information. When one knows
>>> what's going on, he might use "insuitable for oure purpose
>> OK, "stupid" is a bad word. Maybe: good good idea lost. The propblem
>> is that OpenID provider do not trust each other (except for blogs
>> maybe). E.g. every Yahoo id is an OpenID ... great. But I need a Yahoo
>> id to log on into flickr because they do not trust my OpenID
>> server. We also plan to install OpenID here at the university for some
>> stuff but you must have an OpenID from the university because we do
>> not trust Yahoo. So instead to have one OpenID (good idea) you have
>> several (good idea lost). But that is my opinion.
> 1) I only use one and that is "pavlix.net"
> It is delegated to http://xmppid.net/pavlix[AT]pavlix.net ([AT] = @),
> that is verified through Jabber and that's it.
> 2) If a service requires a particular OpenID provieder for
> authentication, it's their problem, it doesn't fit the main OpenID use
> This is not a drawback of OpenID but it is a use of OpenID for private
> This would be like saying that Jabber is bad because we don't trust
> jabberfr.org and we won't talk to them unless they are given JIDs from
> If you don't trust decentralized URL-based authentication, this is
> OpenID's fault but your security policy.
I can understand why the Dirk's university does not want to trust every
identity provider for some specific type of services. There is an
authorization problem there and the university admin solved it in a
specific fashion (most likely identities are only created for students
of that university -- not for every random person on the Internet).
That's obviously not what the OpenID designers wanted since their use
cases are somewhat different...
In the context of the end-to-end security using XMPP discussion luckily
many of these things don't really matter.
You can obviously have cases where an end user does not trust a
particular identity provider, does not recognize the authenticated
identity as one that is familar to him/her, the authenticated identity
does not match to any of the identities in the white list etc. etc. and
hence the entire e2e security procedure fails. But that's fine.
The main question regarding this mechanism is just whether one would
want to trust a third party, in this case the identity provider. From
Dirk's previous responses I got the impression that he does not want to
trust any other party other than the two end points. This use case
obviously makes some assumptions but that's his use case.
The OpenID, the SAML, and the OAuth use cases are different.
More information about the Security