Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
Hi, On Fri, Jan 22, 2010 at 5:16 AM, Jason Eacott ja...@hardlight.com.au 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. 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. Yes, it is totally different. With impersonation you are the user, and the services cannot know the difference and therefore you can't limit what they can do as you. Impersonation is me using your login and password. Delegating access implies a different identification that has access to your data, and the service can use that different identification (and other data, like the oauth access token) to provide you with limited access. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
Pedro Melo wrote: Hi, On Fri, Jan 22, 2010 at 5:16 AM, Jason Eacott ja...@hardlight.com.au 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. 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. Yes, it is totally different. With impersonation you are the user, and the services cannot know the difference and therefore you can't limit what they can do as you. Impersonation is me using your login and password. Delegating access implies a different identification that has access to your data, and the service can use that different identification (and other data, like the oauth access token) to provide you with limited access. Bye, sure - and with an oauth like system the target always knows. I'll admit that in my original suggested approach that the target service would not know, but it was a first rough, aimed for discussion, and at trying to enable reuse of existing components without modification. So suggest workable amendments or a workable alternative. I sense more than a small amount of nastiness here, and I dont think its warranted. I know I'm not alone in thinking this particular issue is an important missing capability of xmpp, but if nobody's interested in the discussion then I'll drop it.
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
Hi, On Fri, Jan 22, 2010 at 8:23 AM, Jason Eacott ja...@hardlight.com.au wrote: I sense more than a small amount of nastiness here, and I dont think its warranted. I know I'm not alone in thinking this particular issue is an important missing capability of xmpp, but if nobody's interested in the discussion then I'll drop it. If my answer came off as nasty, it was not my intention. I do believe that the only sane way to have XMPP-based services grow in usefulness is if we get a way to access, in a controlled fashion, to user data (roster, private storage, PIP nodes, presence information). I think the OAuth model is something that would work for the get an access token-part. I'm not sure how much or how little we should standardize the way that the what can you do with it-part is done though. This is not a new problem, and I've been paying attention to a lot of proposals over the years. I do think that the usual mantra simple clients, complex servers is limiting our current growth in terms of features because the major XMPP services will not update their servers just because it has cool new features. Specifically, I don't see GTalk implementing some of the features that just to tick the XEP- box. So I think we should put a little bit more logic on the client side in future protocols. It would allow us to deploy more advanced functionality without having to way for servers. I think that servers should gain protocols that have multiple purposes, so reuse PubSub or even current MUC for future protocols. Even access to private data can be implemented in the client, acting as the proxy and validator for other entities requests. The drawback is that you need at least one resource with that capability online. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
On 1/22/10 1:23 AM, Jason Eacott wrote: I sense more than a small amount of nastiness here, and I dont think its warranted. I have seen no nastiness whatsoever. You should have been on these lists back in 1999-2000 -- our current discussions are positively genteel compared to the old days. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Fwd: Re: XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
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
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
On 1/22/10 12:23 AM, Jason Eacott ja...@hardlight.com.au wrote: I sense more than a small amount of nastiness here, and I dont think its warranted. If that was due to my responses, I apologize. Please don't confuse curt and concise with personal nastiness in messages from me. -- Joe Hildebrand
[Standards] microblogging
About 18 months ago we had a flurry of discussion about microblogging over XMPP but that conversation fizzled out. In the last few days, we've had some renewed interest in the old microblogging proposal over on the WS-XMPP list: http://mail.jabber.org/pipermail/ws-xmpp/2010-January/000206.html I'd like to bring this topic back in front of the Council and try to get the original proposal published as a XEP so we can foster more discussion: http://xmpp.org/extensions/inbox/microblogging.html If anyone has input here, please do weigh in. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] DEFERRED: XEP-0214 (File Repository and Sharing)
XEP-0214 (File Repository and Sharing) has been Deferred because of inactivity. Abstract: While a protocol has been described for initiating a file transfer from one user to another, there is not yet a defined way for users to designate a set of files as available for retrieval by other users of their choosing. This extension defines a common syntax for this purpose which is based on PubSub Collections. URL: http://www.xmpp.org/extensions/xep-0214.html If and when a new revision of this XEP is published, its status will be changed back to Experimental.
Re: [Standards] Decloaking and Temporary Subscriptions
On 1/21/10 9:38 AM, Dave Cridland wrote: On Thu Jan 21 15:03:24 2010, Peter Saint-Andre wrote: On 1/21/10 3:44 AM, Dave Cridland wrote: On Thu Jan 21 05:40:07 2010, Peter Saint-Andre wrote: As to the temp-sub idea itself, sending something like the following seems that it simply won't work unless you know that the destination server and client support the tempsub extension (otherwise they will treat the subscription as permanent). presence type='subscribe' temp xmlns='urn:xmpp:temp:0'/ /presence Right, so it depends on what you want the failure case to be. If the failure case is that well, hey, you wanted to get in touch with the guy anyway, then this is great. Note that I'd expect something more like: presence type='subscribe' temp xmlns='urn:xmlns:temp:0' expires='20100122T00'/ statusJust wanted a quick call about Foo/status /presence I don't see a need for expires. What people really seem to want here is session-specific presence sharing, and when I send the request how do I know when the session will end? Well, except... If I want to call you via Jingle, and you come online 10 minutes later, I think I'd like that (offer of a) call to still be active. (Again, see the council logs - the concept of telephone tag). Maybe. What if it's 30 minutes? 2 hours? 2 weeks? What if I go offline and the request I sent you can't be acted upon? DIRECTED PRESENCE PRO - it's what we use today for one-to-one chats, groupchat, etc. In practise, one-to-one chats tend to have a presence subscription surrounding them. We may know it's possible, but in practise? For years, I've been recommending presence sharing between contacts who don't have presence subscriptions (casual chatting, if you will). People always say it's a good idea. Whether they have implemented it or not in their clients, I don't know. - adding the sesspres/ child makes the sharing request explicit but those semantics are already implicit The only person who did used to contact me without a subscription from time to time also never sent his presence. That's an awfully small sample size. So those semantics aren't what happens for ad-hoc one-to-one chat. Given the prevalence of the presence subscription model, I think ad-hoc chats are relatively rare. Again, small sample sizes. However, I'd like to have presence sharing in those situations. Not that I can claim to be a typical user. But, in general people have presence subscriptions, which is why I have not cared deeply about session-based presence despite the conversations at Summit 5 back in 2007. The Jingle use cases might well be quite different from ad-hoc chats. CON - interim presence changes are not delivered (but we might be able to change that behavior in rfc3921bis) Okay, so: ? PRESENCE SUBSCRIPTION PRO - it will always get through (no GTalk blocking etc.) - if you squint really hard, session-specific presence sharing looks like a presence subscription of temporary duration What, you have to squint hard to see an explicit agreement to share presence being like a presence subscription? You need an optician... ;-) Subscriptions in XMPP have *always* been long-lived. Changing them to also be temporary seems problematic to me. CON - it will always get through (aren't we routing around legitimate communication blocking?) No, I think this is a non-issue. GTalk block contact without consent, and I can sympathize with their viewpoint. I might even agree that it's a sane default for users - about the only thing I don't agree with is enforcing it on users. This doesn't change that - we're not routing around, we're ensuring we have permission, which seems to be the point. I'd be curious to see what the Google folks think about that. - session-specific presence sharing isn't really a presence subscription, which in XMPP is and has always been a long-lived trust relationship between two entities; overloading that trust relationship seems like a bad idea Presence sharing *is* a presence subscription. (A mutual one no less, although using subscriptions no longer enforces that). The only additional semantic we're adding is that both parties agree and accept this isn't going to be a long term one. That is precisely the aspect I dislike, because *all* XMPP clients and servers currently make assumptions about the meaning of a presence subscription, and those assumptions are violated here. That might not be a big deal, given how promiscuous people are with presence already. But it is a difference. In particular, the roster implications need to be thought through carefully. - the fall-through case is establishment of a long-lived subscription, which was not the intent of sending a request for session-specific presence sharing Right, but the intent of the sender was I'd like to share presence for a bit. If that's agreed to be shared naïvely as a long-term
Re: [Standards] Fwd: Re: XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
see below. Peter Saint-Andre wrote: 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. great question! actually I have built code, but it only solves a small part of the problem. I'm not sure a modified xep can fix this (maybe I'm wrong though). ok, so a scenario to think about: lets say I build a simple xmpp component based search service - some google like variant perhaps - and lets say that part of this service involves storing the last search criteria for each user, so private xml data seems ideal. Lets also now say that I want to make my search service available for simple mobile devices - midp1+http only. so I install an esb with the appropriate protocols for translation. (I've tried to keep this simple - an actual web service with html ui is also another obvious hop here) the device is simple so implementing the bosh protocol directly is too expensive in terms of memory and cpu(battery). at this point there are choices: let the esb establish connections as real xmpp users as required. Establish a single connection and use oauth or similar to carry the real intended user info. the first option requires that the esb knows the users real xmpp credentials, its totally unscalable, the search service cant access private xml storage, and the esb is free to do anything it wants on the xmpp network because as has so rightly be pointed out here unfettered spoofing isnt good. the second option is better - the user authorises the esb to interact with my service via oauth, so now at least we havent sold the farm by giving real credentials to anyone. the esb could choose to implement its own (different) user/pass and mappings etc but its not nececarry. but as in the first case, the service itself is still powerless to save the search criteria. It could of course save it locally, but thats far from ideal, and not the point of this discussion. The service may also have real reason to want to leverage many xep or other non xep component services in this way. I think thats pretty much the problem I'd like to see solved, and I think my initially proposed flow addresses this - but it doesnt address the proxy identity tracking part. the xmpp server is already the identity gatekeeper, and xmpp messages are always sent from a given users server, so for me it made sense to route to be proxied messages back to that server for verification. but how you get all the remote components users to know
[Standards] upcoming XEP deferrals
A number of XEPs are due to be deferred in the next 4-5 weeks. Here is my take... 1. XEP-0215: External Service Discovery http://xmpp.org/extensions/xep-0215.html I still find this interesting, but we've never received much feedback on it. Thoughts? 2. XEP-0232: Software Information http://xmpp.org/extensions/xep-0232.html I think this is dead in the water, given how strongly Council members and others resisted it last time. However, be aware that people still want this feature, and will use XEP-0092 instead forever. 3. XEP-0234: Jingle File Transfer http://xmpp.org/extensions/xep-0234.html I've been meaning to review this one again soon. We need to move this to draft along with the rest of the file transfer stack. 4. XEP-0247: Jingle XML Streams http://xmpp.org/extensions/xep-0247.html IMHO we don't need this one any longer, so it can lapse without issue. 5. XEP-0257: Client Certificate Management for SASL EXTERNAL http://xmpp.org/extensions/xep-0257.html I'll ping Dirk Meyer about this one. 6. XEP-0259: Message Mine-ing http://xmpp.org/extensions/xep-0259.html The author has some updates on the way. 7. XEP-0261: Jingle In-Band Bytestreams Transport Method http://xmpp.org/extensions/xep-0261.html This one goes along with XEP-0234. Reviews would be appreciated. 8. XEP-0262: Use of ZRTP in Jingle RTP Sessions http://xmpp.org/extensions/xep-0262.html This one depends on draft-zimmermann-avt-zrtp (a new version was published a few days ago). I'll ping the author of that I-D to find out whether he thinks it will move forward soon. I don't think any changes to XEP-0262 are needed. Feedback is welcome as always. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
