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

Jason jason at hardlight.com.au
Thu Jan 21 12:17:30 UTC 2010

Joe Hildebrand wrote:
> XEP-235 (OAuth)?

its only good if the component you are talking to directly supports it 
(and I'm aware of none that do).
what I'm suggesting is something that can make available any component 
service without any great effort by that components developers.

> 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

More information about the Standards mailing list