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

Jason Eacott jason at hardlight.com.au
Thu Jan 21 07:50:59 UTC 2010


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
> 



More information about the Standards mailing list