[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]

Joe Hildebrand joe.hildebrand at webex.com
Thu Jan 21 09:09:06 UTC 2010

XEP-235 (OAuth)?

On 1/20/10 11:50 PM, "Jason Eacott" <jason at hardlight.com.au> wrote:

> I dont think the answers are easy either.
> but something should be done.
> I've been thinking of something like this:
> imagine for a moment that we have some way for jidA at a.com to give
> permission for serviceA at service.com to spoof jidA's identity with
> specific permissions for any given service/role/domain/whatever.
> This permission might exist in the form of a token (I'm familiar with
> oauth so I'll use tokens for now.) stored in a special part of jidA's
> XML private storage (or similar).
> When a serviceA (or any jid) wants to do something as jidA it sends a
> message as usual with jidA in the from field.
> serviceA's server would know it was attempting to be issued as a foreign
> user and so wraps and forwards the message to JidA's server (including
> the real from address of serviceA).
> JidA's server verifies the actual from address and inspects the
> to-be-spoofed address and message contents against its local private
> store of jidA's permissions.
> If permission is granted the message is reissued from jidA's server. If
> not an exception is returned.
> jidA's server would also be responsible for routing any response back to
> the origin sender.
> this is far from ideal I know - it adds lots of network hops for a
> start, but at least most of the existing xmpp rules stay in tact (I
> think). It allows xmpp server operators to enable/disable this
> functionality for their users or components, and gives complete control
> over what services can do what as proxies to each user/service.
> I'm sure efficiencies could be manufactured to save on traffic, but in
> principle, how does this sound as a starting point for discussion?
> thanks
> Jason.
> Peter Saint-Andre wrote:
>> On 1/20/10 8:01 PM, Matthew Wild wrote:
>>> 2010/1/21 Jason Eacott <jason at hardlight.com.au>:
>>>> Matthew Wild wrote:
>>>> ...
>>>>> Downsides are that this requires server support, especially thinking
>>>>> of e.g. gmail.com here. Probably other things I'm missing too.
>>>> again this just makes me sure that XMPP as it stands is far too client
>>>> centric, and needs to become properly extensible from the serverside too.
>>>> there should be a way for server extensions to do what clients can.
>>>> (I know thats not what you were suggesting here, but it might make
>>>> implementing such things easier)
>>> I didn't want to divert the original thread before it even starts, but
>>> was curious - what do you mean by this? I don't see how XMPP can
>>> enforce Google to implement any extension. The issue here is that the
>>> predominant use case for decloaking is Jingle, and many Jingle users
>>> happen to be Google Talk users.
>>> If decloaking was done client-side then the user can simply switch to
>>> a better client that supports it, switching server is much harder
>>> work.
>>> I guess I just don't understand your "there should be a way for server
>>> extensions to do what clients can".
>> Back before we even developed Jingle, I had some similar thoughts. It
>> would be great if I could ask my server to call you (like a switchboard
>> operator in the olden days), but realistically sometimes the client does
>> know best (it's behind a firewall, it has certain network interfaces, it
>> has certain capabilities, etc.). I do think it's worth exploring how
>> much servers can do, because in many ways we've gotten away from the
>> philosophy of "simple clients, complex servers". Is that philosophy
>> really valid and sustainable? Should servers really do more, or should
>> they be XML routers in the middle? Should the network be smart or dumb?
>> These are large design questions and I don't think they have easy answers.
>> Peter

Joe Hildebrand

More information about the Standards mailing list