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

Peter Saint-Andre stpeter at stpeter.im
Fri Jan 22 14:22:20 UTC 2010


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 <stpeter at stpeter.im>
To: jeacott at 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/




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100122/b21be964/attachment.bin>


More information about the Standards mailing list