XEP-235 (OAuth)?
On 1/20/10 11:50 PM, "Jason Eacott" <ja...@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 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 >> -- Joe Hildebrand
