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 j...@a.com to give
permission for servi...@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 <ja...@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
