-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. Perhaps someone would like to help this person. :)
- -------- Original Message -------- Subject: Re: [Standards] xmpp oauth query Date: Sun, 18 Oct 2009 08:56:52 +0900 From: Jason <[email protected]> Reply-To: [email protected], XMPP Standards <[email protected]> To: [email protected] References: <[email protected]> Thanks, it does clarify things a lot, but it means that each and every client/component must provide its own implementation for this, so it seems a real disincentive. I'm trying to accomplish the usual oauth usecase, ie give an entity permission to act on behalf of another for a range of services. I want my cake and eat it too :) I want to make use of all the existing xmpp infrastructure for user management, authorisation, roster management, pubsub etc, but I want to allow 3rd party entities access to some of this functionality. It seems such a waste to have to reimplement this stuff over and over. my actual 'users' will never log in directly to xmpp, they will always be 'proxied' via 3rd party services (the user implementations using actual xmpp accounts being a convenience for me). I am using xmpp principally as a transport, but I'm also trying to use it to naturally federate my app (although I'm not sure its really going to work), and to save me some work re user account management and pubsub services. it also provides me with a platform/language independent 2 way transport - there really arent many choices here - which I can use internally and externally. oauth lets 1 entity act on behalf of others for given services so it seemed a good fit. so my initial thought re oauth was that there should be a way to hook into an xmpp server provided service to appropriately process the stanza, but no such thing exists and I'm not sure it can?. My second thought was to create a component that would simply process the oauth request and forward the request as the new user (adding a short custom element describing the origin user) since this would work for all cases, would be easier to implement for all my services, and would work for all the existing xmpp provided services too. It would also allow any service to act on any others behalf I'm not sure components are actually allowed to do this though(?), because it seems as if they were then it would be easy to write xmpp spam bots. Also there are problems with this scheme allowing oauth proxies access to services they were never authorised for (ie endpoint services that didnt check the origin and user prefs/granted access would blindly accept the request). I hope this makes sense, what am I missing? Thanks Jason. > On 10/13/09 9:05 PM, Jason Eacott wrote: >> Hi All, > > Howdy. :) > >> I've been trying to understand oauth for xmpp and have a couple of >> questions, I hope someone can answer :) >> >> I'm a bit confused as to what exactly the producer consists of. >> For example, should an xmpp server accept the oauth stanza and >> subsequently forward the given request as the oauth alias? >> clear as mud I know, but I'm asking if I send a message containing >> the details: >> from=somejidA >> to=somejidB >> oauth alias=somejidC >> >> then should/could an xmpp server rewrite this as simply: >> from=somejidC >> to=somejidB >> >> if this isnt the way its supposed to work, then is it up to each >> component/client to implement its own oauth impl for every incoming stanza? >> sorry if the question seems dumb but I'm still unclear on how to code a >> component that reacts to a given subelement (ie oauth) >> and apply its outcome to the wrapping element. >> >> I hope someone can make my head less murky ;-) > > Hmm. :) > > First, what exactly are you trying to accomplish? Perhaps you could > describe your use case a bit more. > > The idea behind XEP-0235 (OAuth Over XMPP) is that the XMPP server isn't > really involved, and certainly not involved in rewriting stanzas. > Instead, an XMPP client would provide an access token when seeking to do > something like publish to a pubsub node or join a chatroom. The client > would not obtain the access token over XMPP and similarly the request > token would not be obtained over XMPP. Right now all we have defined is > a way to include an access token with a particular XMPP request. > > I hope that clarifies things a bit more. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrcvCcACgkQNL8k5A2w/vwfFQCg1NeAwlpwJZKqocVmDk67zoBp lRkAoLd5LtbLAWowdRXbdzRilXJJSHQv =JmDV -----END PGP SIGNATURE-----
