Somehow didn't copy the list. -------- Original Message -------- Subject: Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions] Date: Fri, 22 Jan 2010 07:21:52 -0700 From: Peter Saint-Andre <stpe...@stpeter.im> To: jeac...@hardlight.com.au
On 1/21/10 10:16 PM, Jason Eacott wrote: > > > > Peter Saint-Andre wrote: >> On 1/21/10 6:08 PM, Jason Eacott wrote: >> >>> Oauth is all about impersonating other users, thats all it does! >> >> False. OAuth is about delegating access to protected resources so that >> another entity can have restricted authority to perform a given task >> (the canonical example is granting a printing service access to your >> online photos). OAuth is not about impersonation, it is about delegated >> authorization. Those two things are very different. >> >> Peter > > fair enough, > but in practice is there really much distinction? granting a printing > service access to photos, granting another service limited access to my > private xml data store, granting another service to create pubsub nodes > with me as the owner, etc. > The upshot of it all is that after authority is delegated, the > authorised proxy is allowed to act on the users behalf for whatever it > has been given permission to do. > For me I dont see the difference. If I show up at your bank with a Jason Eacott constume on, fake ID, etc., and withdraw all your funds, the bank thinks that you have completed a legitimate transaction. If I show up at your bank with a notarized letter signifying that I have power of attorney and you have explicitly authorized me with the bank to act on your behalf in limited ways, then if I transfer some funds to another account the bank won't think that you did it, they will think that I did it with authorization. I continue to think that impersonation and delegation are quite different relationships. > I didn't state categorically in this > last post that the proxy can only act in limited ways (if the user > offers only limited authority to the service), but I dont think it > changes the fact that at the end of the process a service is allowed to > act on behalf of a user (various oauth api's make this feel very much > like simply switching user hats - now I'm user x. do ...). It feels that way, but under the hood it's not, and from a security perspective it had better not be the same. > my point is that if xmpp embraced something like this then components > and external services could actually use things like the private xml > storage of any user that offered authority, but instead the only options > I know for such a service is to either reinvent xml data storage, deploy > as a client app, or convince its users to handover user credentials. Correct at present. What does XEP-0235 not give you? How does it need to be expanded? IMHO you are pointing to the fact that this model is not yet in code. > previous posts in this thread have said there are other options > available but I don't yet know what they are. We really have not worked on this problem much, as Pedro points out. So I'm sure there are very wide gaps here between what exists and what you feel you need (for what application, by the way?). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
