Re: [Standards] Comments on SIFT
interesting - I've built a variation on this for offline messages, but allowing quite complex allow criteria. I couldnt make xmpp do it (I'm not saying xmpp couldnt, but just that I couldnt figure out how) as my case seemed to require altered routing rules and a few other issues surrounding my frequent, but momentary presence requirement, so I ended up just using xmpp as a transport. Cheers. Waqas Hussain wrote: While implementing mod_sift for Prosody, I saw some possibilities for improvement and had thoughts about issues. Some of these follow. 1. Remove disallowed child elements for filtered messages and presence. Here's a typical identi.ca message: message from=upd...@identi.ca/xmpp001daemon to=wa...@jaim.at type=chat bodyevan: RT @sil doom. the Shuttle computer I'm setting up for dad can't read the hard drive. Won't boot from USB, has no CD drive, I have no USB ... [23931040]/body html xmlns=http://jabber.org/protocol/xhtml-im; body xmlns=http://www.w3.org/1999/xhtml; : RT @doom. the Shuttle computer I'm setting up for dad can't read the hard drive. Won't boot from USB, has no CD drive, I have no USB ... a href=http://identi.ca/evan;evan/a span class=vcard a title=Stuart Langridge class=url href=http://identi.ca/user/279; span class=fn nicknamesil/span /a /span a href=http://identi.ca/conversation/24011046#notice-23931040;[23931040]/a /body /html entry xmlns=http://www.w3.org/2005/Atom; source titleevan - Identi.ca/title link href=http://identi.ca/evan; / link rel=self type=application/atom+xml href=http://identi.ca/evan; / link rel=license href=http://creativecommons.org/licenses/by/3.0/; / iconhttp://avatar.identi.ca/1-96-20090819204503.jpeg/icon /source titleRT @sil doom. the Shuttle computer I'm setting up for dad can't read the hard drive. Won't boot from USB, has no CD drive, I have no USB .../title author nameevan/name urihttp://identi.ca/user/1/uri /author actor xmlns=http://activitystrea.ms/spec/1.0/; object-typehttp://activitystrea.ms/schema/1.0/person/object-type id xmlns=http://www.w3.org/2005/Atom;http://identi.ca/user/1/id title xmlns=http://www.w3.org/2005/Atom;Evan Prodromou/title link rel=alternate type=text/html href=http://identi.ca/evan; xmlns=http://www.w3.org/2005/Atom; / link rel=avatar type=image/jpeg xmlns:ns1=http://purl.org/syndication/atommedia; ns1:height=353 xmlns:ns2=http://purl.org/syndication/atommedia; ns2:width=353 href=http://avatar.identi.ca/1-353-20090819204502.jpeg; xmlns=http://www.w3.org/2005/Atom; / link rel=avatar type=image/jpeg xmlns:ns1=http://purl.org/syndication/atommedia; ns1:height=96 xmlns:ns2=http://purl.org/syndication/atommedia; ns2:width=96 href=http://avatar.identi.ca/1-96-20090819204503.jpeg; xmlns=http://www.w3.org/2005/Atom; / link rel=avatar type=image/jpeg xmlns:ns1=http://purl.org/syndication/atommedia; ns1:height=48 xmlns:ns2=http://purl.org/syndication/atommedia; ns2:width=48 href=http://avatar.identi.ca/1-48-20090819204503.jpeg; xmlns=http://www.w3.org/2005/Atom; / link rel=avatar type=image/jpeg xmlns:ns1=http://purl.org/syndication/atommedia; ns1:height=24 xmlns:ns2=http://purl.org/syndication/atommedia; ns2:width=24 href=http://avatar.identi.ca/1-24-20090819204503.jpeg; xmlns=http://www.w3.org/2005/Atom; / point xmlns=http://www.georss.org/georss;45.5088375 -73.587809/point preferredUsername xmlns=http://portablecontacts.net/spec/1.0;evan/preferredUsername displayName xmlns=http://portablecontacts.net/spec/1.0;Evan Prodromou/displayName note xmlns=http://portablecontacts.net/spec/1.0;Montreal hacker and entrepreneur. Founder of identi.ca, lead developer of StatusNet, CEO of StatusNet Inc./note address xmlns=http://portablecontacts.net/spec/1.0; formattedMontreal, Quebec, Canada/formatted /address urls xmlns=http://portablecontacts.net/spec/1.0; typehomepage/type valuehttp://evan.prodromou.name//value primarytrue/primary /urls /actor link rel=alternate type=text/html href=http://identi.ca/notice/23931040; / idhttp://identi.ca/notice/23931040/id published2010-03-06T20:01:22+00:00/published updated2010-03-06T20:01:22+00:00/updated link rel=ostatus:conversation href=http://identi.ca/conversation/24011046; / forward ref=http://identi.ca/notice/23928915; href=http://identi.ca/notice/23928915; xmlns=http://ostatus.org/schema/1.0; / content type=htmlRT @span class=vcarda href=http://identi.ca/user/279; class=url title=Stuart Langridgespan class=fn nicknamesil/span/a/span doom. the Shuttle computer I'm setting up for dad can't read the hard drive. Won't boot from USB, has no CD drive, I have no USB .../content /entry /message Look at the size of that. Should I laugh or cry? This should be reduced to: message from=upd...@identi.ca/xmpp001daemon to=wa...@jaim.at type=chat bodyevan: RT @sil doom. the Shuttle computer I'm setting up for dad can't read the hard drive. Won't boot from USB, has no CD drive, I have
Re: [Standards] Enterprise Users Groups
Isnt this just an xmpp workgroups app? Fasihullah Askiri wrote: Hi All, We are trying to use XMPP in our application where there will be a user group like Finance or HR to which the application would want to add users. We are planning to write a custom XMPP component which would check for presence of the users in the group and should be able to direct queries from some other users to a member of this group. This application would eventually inter-op with an enterprise XMPP server so we would like to reduce the dependency on XMPP server configuration to a minimal. Also, ideally we would like that the users of the group are auto-subscribed and would not require the user to manually send a presence subscribed packet. I am not sure if pubsub or group is what we need, please advice. Best Regards +Fasih
Re: [Standards] Enterprise Users Groups
Ignite has an implementation, and its supported with smack, I'm not sure what other implementations exist. Fasihullah Askiri wrote: Great!! What is the status of this. Is it a widely supported extension? If not, can I still use this by writing an external component maybe. On Wed, Feb 24, 2010 at 2:01 PM, Jason Eacott ja...@hardlight.com.au mailto:ja...@hardlight.com.au wrote: Isnt this just an xmpp workgroups app? Fasihullah Askiri wrote: Hi All, We are trying to use XMPP in our application where there will be a user group like Finance or HR to which the application would want to add users. We are planning to write a custom XMPP component which would check for presence of the users in the group and should be able to direct queries from some other users to a member of this group. This application would eventually inter-op with an enterprise XMPP server so we would like to reduce the dependency on XMPP server configuration to a minimal. Also, ideally we would like that the users of the group are auto-subscribed and would not require the user to manually send a presence subscribed packet. I am not sure if pubsub or group is what we need, please advice. Best Regards +Fasih -- +Fasih And be steadfast in patience, for verily God will not suffer the reward of the righteous to perish (11:115)
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] 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
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
to be clear I am talking about cross domain, because I dont think its reasonable for every new service/component/whatever to require users to create new accounts on the local domain should that service require the use of third party services. By plugin I mean server component or vendor specific plugin (by whatever means). Dave Cridland wrote: On Thu Jan 21 03:48:41 2010, Jason Eacott wrote: what I mean is that xmpp clients are the only entities with any power. they are the only entities that can interact with anything on a clients behalf. this is very different from the webserver paradigm where a user remotely logs in and then the server has power to BE the user, reuse other webservices as the logged in user (via any number of authentication schemes) etc. Internally within a security domain, this is simply not the case. Within a security domain, servers can (and do, in some cases) act as the user. A classic case is the widely deployed auto accept/auto subscribe feature in some servers, which sends out subscribe[d] stanzas per-pro the user. ok maybe I wildly misunderstand xmpp?(its definitely possible). If I have an xmpp server at somewhere.com, and install a pubsub component and a personal xml component at pubsub.somewhere.com and xml.somewhere.com and my own new service at new.somewhere.com, are you saying that new.somewhere.com can access xml.somewhere.com on behalf of any user registered at somewhere.com? even so, this is a very limited case as most users of my service will be remote. With xmpp its also possible to use other webservices, but critically NOT xmpp services! its not possible for example for an xmpp plugin to access a users pubsub node, or private xml storage AS the owner unless the plugin knows the users id and password and opens its own client connection. Again, this is only true if you're crossing the boundary of a security domain. Otherwise, no, pubsub code could reach into the XEP-0049 store authorized as the user - it's really only cross-boundary authorization and delegation that are missing. does this boundary include subdomains? I thought it did in which case components are generally unavailable for reuse by other components. In the specific case of an XMPP plugin (whatever that is) accessing a user's pubsub node in another security domain, then in principle the user could allow this by setting the affiliations suitably on the domain, or by the plugin simply requesting a subscription. This could, of course, be made smoother, with a pawn-ticket system to instantly grant the subscription, perhaps. this is true, but requires serious intervention by the user. My service wants to create a pubsub node for its own use, but its preferable that the currently interacting (and probably remote domain) user own the node(for whatever reason). Its not possible without the user correctly creating their own node and configuring it appropriately. this is pretty unreasonable request to make of my users I think - and if I need 6 other services... also pubsub is about the only xep with such rich auth control anyway. You cant use a bosh server with your existing xmpp account without giving it your user/pass details. Well, there are currently two forms of BOSH server implemented, there's the built-in BOSH listeners of ejabberd, and Openfire (possibly others), and then there's the pure proxy style of Punjab. With the former, handing over credentials is equivalent to handing them to the server anyway. With the latter, then the SASL exchange itself is passed through, so in principle, if a mechanism is used which is secure against MITM attacks, the credentials are safe. (In practise, most SASL mechanisms designed recently assume the presence of TLS, but it'd still require some effort on the part of a BOSH component operator to get your password). ok, for a pure client usage of bosh (javascript etc) this is true (as long as you trust the javascript is talking directly to a bosh server, but for something like a serverside impl of a web ui chatroom, which itself uses bosh to connect to the xmpp network (or even just direct connect) then you have to give the webui provider your xmpp credentials first. if xmpp supported some extra (pluggable, extensible) auth scheme then this could be mitigated. the alternative which exists now is to use XEP-0235 oauth but it would require that the chatroom component in use is itself an oauth producer. It pains me to see all the cool xmpp component functionality about that I can only leverage from a client application. I dont know how this can best be resolved but I really think it needs to be. Allowing xmpp server level oauth style authentication could work, albeit a bit heavy, as might other strategies. OAuth is fine for inter-domain authorization delegation, but it massive overkill within a domain. agreed - and I'm not saying the answer is oauth, its just 1 way I know that could work
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
Joe Hildebrand wrote: On 1/21/10 4:06 AM, Jason ja...@hardlight.com.au wrote: if xmpp supported some extra (pluggable, extensible) auth scheme then this could be mitigated. You want something more pluggable and extensible than SASL? no this is not about replacing any such protocols. I dont know how to send stanzas from a component as an arbitrary user from an account of another domain. please tell me how! this is exactly what I need. (in my experience the stanza is sent but the recipient server rejects it, as it should). The messages are rejected because they are spam. Why do you want to impersonate people in another security domain? I can't think of a reason that's not evil. Oauth is all about impersonating other users, thats all it does!, are you suggesting there are no usecases for Oauth?
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
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. 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 ...). 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. previous posts in this thread have said there are other options available but I don't yet know what they are.
Re: [Standards] Decloaking and Temporary Subscriptions
Matthew Wild wrote: ... You could include this tag in your presence to MUC rooms for example, and the server would automatically send the MUCs your new presence when it changes - currently this is sent individually to each MUC room by the clients (ick.). Though MUCs want only the presence of a single resource (not all, like Jingle does), hmm. 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)
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
Hi Mathew - first of all, sorry for diverting this, thanks for rethreading. what I mean is that xmpp clients are the only entities with any power. they are the only entities that can interact with anything on a clients behalf. this is very different from the webserver paradigm where a user remotely logs in and then the server has power to BE the user, reuse other webservices as the logged in user (via any number of authentication schemes) etc. With xmpp its also possible to use other webservices, but critically NOT xmpp services! its not possible for example for an xmpp plugin to access a users pubsub node, or private xml storage AS the owner unless the plugin knows the users id and password and opens its own client connection. You cant use a bosh server with your existing xmpp account without giving it your user/pass details. It pains me to see all the cool xmpp component functionality about that I can only leverage from a client application. I dont know how this can best be resolved but I really think it needs to be. Allowing xmpp server level oauth style authentication could work, albeit a bit heavy, as might other strategies. just my 2 yen. what do u think? 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. Regards, Matthew
Re: [Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
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
Re: [Standards] XEP-0235: OAuth Over XMPP is not enough.
So heres a simple usecase. Lets say I want to create a simple web interface to an existing xmpp service, and I'd like users to be able to be represented on the xmpp network with their own existing accounts if they have one. The service should also be able to subscribe my user to pubsub nodes, and otherwise use it as widely as some authorisation rules allow. the only way I can do this right now is if I can convince users to give my service their jid password. Even if the service itself supports oauth/facebookid/openid etc it still couldn't access private xml storage, or modify my account settings etc. What I'm suggesting is that perhaps it should not be the requirement of each service to directly support this, but that a pluggable, extensible system exist that the xmpp servers themselves support that can be transparently leveraged by these services. With oauth in particular, services and users privacy is reasonably maintained, without something like this there is the possibility that service (A) can become aware that user (A) is also subscribed to services (B) and (C). great care would need to be taken in defining a solution. Cheers Peter Saint-Andre wrote: On 11/26/09 8:34 PM, Jason Eacott wrote: Hi all, I'd really like to see a much tighter integration of XMPP and Oauth. Oauth is a protocol which should allow an entity to act on behalf of another. In XMPP terms I believe this should mean that a user/jid should be able to allow any XMPP service(bot, component, user) to become its proxy for any specified services. The authorised proxy services should be able to effectively spoof the users identity. This is not how the existing xmpp oauth XEP works, and in my opinion the current XEP is a poor solution. In the HTTP world almost every website(service) requires its own user/identity login, so requiring each service to maintain its own Oauth consumer token lists and oauth implementations is entirely reasonable since those services already manage their own users. In the XMPP world most people have a single JID, which is their global account for accessing every service. I believe XMPP must address Oauth at this level. This would enable xmpp services to send messages on behalf of any user without requiring user/pass credentials (the services would of course have access to oauth access tokens secrets), without requiring a component be deployed on the same xmpp domain as the user, and without requiring an explicit xmpp connection be established for the proxied user. This would also allow xmpp components to make use of ANY existing XMPP service or XEP, enabling real service reuse by other services, without the requirement to reinvent those services (something that seems to happen a lot in the xmpp world). For example, and imaginary serviceA that needs to use XEP-0049: Private XML Storage, and XEP-0016: Privacy Lists to fulfil its service requirements. Currently serviceA would either be impossible or extremely complex to implement. I could also greatly reduce the resources required by servers running such services since full user connections would not need to be established in order to send messages on 3rd parties behalf (where the 3rd parties jid is not on the same xmpp domain as the service). simply signing the message and sending it from any jid or component would be enough. For a service that wants multiple rights from a user, it should be able to ask the user and require a single response (ie the user that is assigning multiple rights should be able to assess the requirements and respond with a single response, not visit 10 different service providers to individually authorise them). The results of all this I think mean a new standard is required for the auth management, and new rules required for what a server recognises as the from address. I hope this is vaguely readable, Thoughts anyone? It sounds dreamy, although I'm not clear on the use cases here and why they are so compelling. I also don't like the part about new rules for from addresses, because I don't think that's necessary with OAuth. Also, note that OAuth is in a bit of flux right now. Once the OAuth WG at the IETF produces OAuth 1.1 or OAuth 2.0, I think we'll have a clearer vision of where XMPP fits in the picture. Feel free to join that mailing list (quite active of late) to make sure that OAuth is flexible enough to handle non-HTTP scenarios. I'll do my best to make sure that happens, too (I'm co-chair of the WG, after all ;-). Peter
[Standards] XEP-0235: OAuth Over XMPP is not enough.
Hi all, I'd really like to see a much tighter integration of XMPP and Oauth. Oauth is a protocol which should allow an entity to act on behalf of another. In XMPP terms I believe this should mean that a user/jid should be able to allow any XMPP service(bot, component, user) to become its proxy for any specified services. The authorised proxy services should be able to effectively spoof the users identity. This is not how the existing xmpp oauth XEP works, and in my opinion the current XEP is a poor solution. In the HTTP world almost every website(service) requires its own user/identity login, so requiring each service to maintain its own Oauth consumer token lists and oauth implementations is entirely reasonable since those services already manage their own users. In the XMPP world most people have a single JID, which is their global account for accessing every service. I believe XMPP must address Oauth at this level. This would enable xmpp services to send messages on behalf of any user without requiring user/pass credentials (the services would of course have access to oauth access tokens secrets), without requiring a component be deployed on the same xmpp domain as the user, and without requiring an explicit xmpp connection be established for the proxied user. This would also allow xmpp components to make use of ANY existing XMPP service or XEP, enabling real service reuse by other services, without the requirement to reinvent those services (something that seems to happen a lot in the xmpp world). For example, and imaginary serviceA that needs to use XEP-0049: Private XML Storage, and XEP-0016: Privacy Lists to fulfil its service requirements. Currently serviceA would either be impossible or extremely complex to implement. I could also greatly reduce the resources required by servers running such services since full user connections would not need to be established in order to send messages on 3rd parties behalf (where the 3rd parties jid is not on the same xmpp domain as the service). simply signing the message and sending it from any jid or component would be enough. For a service that wants multiple rights from a user, it should be able to ask the user and require a single response (ie the user that is assigning multiple rights should be able to assess the requirements and respond with a single response, not visit 10 different service providers to individually authorise them). The results of all this I think mean a new standard is required for the auth management, and new rules required for what a server recognises as the from address. I hope this is vaguely readable, Thoughts anyone? Thanks Jason.
Re: [Standards] UPDATED: XEP-0253 (PubSub Chaining) (XMPP Extensions Editor)
I still think a small modification to XEP-0248: PubSub Collection Nodes to allow remote node association would make XEP-0253 totally redundant and simplify things a lot. just my 2 yen. Date: Wed, 18 Nov 2009 12:53:15 -0600 From: XMPP Extensions Editor edi...@xmpp.org Subject: [Standards] UPDATED: XEP-0253 (PubSub Chaining) To: standards@xmpp.org Message-ID: e1napev-0003y5...@athena.jabber.org Version 0.2 of XEP-0253 (PubSub Chaining) has been released. Abstract: This specification defines a method for chaining pubsub nodes together, resulting in lightweight repeaters for pubsub notifications. Changelog: Specifed protocol flow for the chained subscription. (psa) Diff: not available URL: http://xmpp.org/extensions/xep-0253.html
[Standards] oauth and xmpp server responsibility
Hi all, I've returned to this because my usecase seems to warrant some ownership by the server. in my setup I have an xmpp component acting as my server application. each server maintains data for the users on that server. but 'users' never log in directly to these servers, but always via some 3rd party application which connects as a simple xmpp client and makes oauth requests on behalf of users. so user-http etc-3rdpartyapp-xmpp client-somexmppserver-needs to route the message to the appropriate server based on the oauth user. since the users all have real xmpp addresses, it seems it could be a reasonable to have the xmpp server itself accept the oauth request (instead of my server component) and vet it against data that could be stored in users private storage (or a new xep just for auth keys permission option storage and matching). If this were in place then any individual (or app with suitable oauth permission) could save tokens permission data to a users private storage. Then an app with granted authority could send an oauth message, which would be vetted and forwarded to the users own xmpp server for processing (or sending again if its a message to elsewhere I guess). The forwarded message should have a new xml fragment included to indicate the original sender, and the various tokens that were included. of course this is all doable with custom components for everything, but why not allow developers to actually use all of the existing xmpp infrastructure and any custom apps, via oauth without having to reinvent everything. One last thing. the existing oauth spec doesnt support the idea that a message may need to carry nested authorities (or messages with authorities). If I have a proxy setup something like user-serverapp1-mule ESB-serverapp2 where muleESB is acting as a proxy for messages from app1 to app2, but it has its own xmpp identity Then to avoid mule needing to check authorities itself, 'app1 oauth user' needs to be wrapped by mule and a new auth added for 'mule oauth app1'. I dont know how this should best be done. If the existing oauth xml spec allowed for arbitrary stanza subelements then a sensible nesting of messages could be sent and processed without the need to change architectures or create other custom message formats workarounds. Thoughts? thanks Jason.
Re: [Standards] xmpp oauth query
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/
[Standards] xmpp oauth query
Hi All, 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 ;-) thanks Jason.
[Standards] help pubsub filter
hi All, I found this post http://mail.jabber.org/pipermail/standards/2008-May/018810.html and I need exactly this functionality. I'm wondering if anything like this actually progressed, I haven't really found anything that seems quite right in the XEPs did I miss something? Ideally I'd like to be able to do something like this: create a pubsub node. use something like stock market ticker stream as publisher input to the node. have each subscriber able to filter the notifications (at the/a server) by arbitrary payload content - ie stockname=abc and price x This is not my actual usecase, but its a perfect fit for what I need. Thanks Jason.
Re: [Standards] DEFERRED: XEP-0248 (PubSub Collection Nodes)
This saddens me too. I just assumed nobody was interested in my suggestion since I heard absolutely no feedback. Jason.
Re: [Standards] Standards Digest, Vol 69, Issue 17
You should probably re-read the spec: all the fields are optional. You can also provide a time, a uri and you have text and description fields at your disposition if the other ones are too restrictive. true you can provide a time and a uri, but neither are documented with any intent to BE a location. They are strictly ancillary data. I guess they could be kludged to represent the wrong thing in a closed private system but that doesnt sound like a good idea. I understand that this was strictly designed with Earth locations in mind though. :) indeed - this is also a problem. the spec should take into account non Earth based locations, as well as virtual locations (in virtual online worlds, and websites etc), or custom concepts of location. Basically anything modern English useage allows us to say we are somewhere - see u on myspace/facebook/someBarInSecondLife etc. Cheers. Pierre-Luc -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: http://mail.jabber.org/pipermail/standards/attachments/20090825/d2f18996/attachment-0001.pgp -- Message: 3 Date: Wed, 26 Aug 2009 03:14:48 +0200 From: Florian Zeitz florian.ze...@gmx.de Subject: Re: [Standards] Adding countrycode to XEP-0080: User Location To: jeac...@hardlight.com.au, XMPP Standards standards@xmpp.org Message-ID: 4a948c88.8030...@gmx.de Content-Type: text/plain; charset=ISO-8859-1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason wrote: For my current useage this spec is too limiting to physical locations. parts of related specs allow for location types that are not representable by country/gps etc, things like URLs, or TIME. (you can be conceptually @ a web location, time, or some other unknown, perhaps virtual representation of location), it would be nice if this spec were flexible enough to accomodate such notions. Can you possibly explain in more detail what your current usage is? I personally think there is merrit in having this namespace/XEP specifically bound to physical location. For websites your currently browsing there is User Browsing and there is also XEP 0202 for getting an entities time (although I don't know how that fits in the context of locations).
Re: [Standards] Adding countrycode to XEP-0080: User Location
For my current useage this spec is too limiting to physical locations. parts of related specs allow for location types that are not representable by country/gps etc, things like URLs, or TIME. (you can be conceptually @ a web location, time, or some other unknown, perhaps virtual representation of location), it would be nice if this spec were flexible enough to accomodate such notions.
Re: [Standards] XEP-0248: PubSub,Collection Nodes
not really, but I have had a bit of a think about it. Since the existing mechanism for adding/removing nodes is via forms, I couldn't easily add a new field per submitted value without requiring multiple form submissions. (could possibly do it using the 'result' type and item tags but I doubt it would work. just highlights a small limitation of the forms capability. ) So I was thinking perhaps something like this (added a delimiter and a formatted value entry for foreign/remote nodes.) : from 6.3.1 Only One Collection Node text-multi for the pubsub#collection field should probably be set to true. 8. Associate an Existing Node with a Collection Example 18. Node owner modifies node configuration iq type='set' from='ham...@denmark.lit/elsinore' to='pubsub.shakespeare.lit' id='associate1' pubsub xmlns='http://jabber.org/protocol/pubsub#owner' configure node='princely_musings' x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field field var='pubsub#collection-delimiter' value#/value /field ... field var='pubsub#collection'valueblogs/value/field field var='pubsub#collection'valuepubsub.denmark.lit#blogs/value/field ... /x /configure /pubsub /iq same for node config Example 19. Node owner modifies node configuration iq type='set' from='b...@shakespeare.lit/globe' to='pubsub.shakespeare.lit' id='associate2' pubsub xmlns='http://jabber.org/protocol/pubsub#owner' configure node='blogs' x xmlns='jabber:x:data' type='submit' field var='FORM_TYPE' type='hidden' valuehttp://jabber.org/protocol/pubsub#node_config/value /field ... field var='pubsub#collection-delimiter' value#/value /field ... field var='pubsub#collection'valueblogs/value/field field var='pubsub#children' valueprincely_musings/value valuekingly_ravings/value valuepubsub.shakespear.lit#starcrossed_stories/value valuepubsub.denmark.lit#moorish_meanderings/value /field ... /x /configure /pubsub /iq I think this would be enough. no need to add and associate at the same time for remote nodes, I think everything else is still ok. All the existing messaging carries enough info for any endpoint to target the originator if it needs to, please correct me if I'm wrong, it's likely I've missed something important somewhere. Other features that I think would be tremendously useful , would be the ability for a node owner or (publisher?) to set chainable group based, and content based filters on outgoing data (is it already possible to filter incoming node data?). Its possible for individual end users to set filters, but if a node owner wants to restrict a certain group of node subscribers from receiving notifications for certain types of data, this would be handy. The content based part could provide a nice way to provide sanitisation/transformation of data en route (maybe a nice way to hook into an esb etc from a node would be a good solution?). thoughts? Thanks Jason. . I sincerely hope this group considers ammending this xep. Cheers. - Jason, this sounds interesting to me as well. Do you have some amendment text to propose? Thanks
Re: [Standards] XEP-0248: PubSub,Collection Nodes
Ok, but a URI is implied when you create a node, so it exists in some form regardless. If you dont want to specify a URI per node, then what about adding a server attribute/element in the xml somewhere for the collection management requests instead? I think this is really important for xmpp and would provide real interoperability between services. Why shouldnt I be able to create a node somewhere that effectively aggregates any other nodes data and/or events? Limiting everything to one machine just seems weird in a distributed system. What options does it leave for scaling to millions of nodes? I also think the its difficult for implementors argument is flawed since if the server implementors dont provide it, then the end users are forced to come up with their own workarounds, or worse choose another solution altogether. I would have thought raising pubsub events and listening to them either local or remote would be exactly what xmpp should be great at (users already subscribe and listen to the raised events, why not other nodes?), and should not represent a complicated implementation. reflecting pubsub from remotes into your local service through some means sounds like a huge hack, would likely be slow, and is what I want to avoid. I'm looking for an alternative to clustering service implementations in XMPP. I sincerely hope this group considers ammending this xep. Cheers. Brian Cully wrote: On Jul 29, 2009, at 18:58, Jason jeac...@hardlight.com.au wrote: This is a repost, I'm still hoping for a response. Re XEP-0248: PubSub Collection Nodes, It appears that there is no support for pubsub collections to contain remote nodes. I would like to be able to create a pubsub collection on a server, and add nodes from other servers to it). I'm wondering why this is? Because collection nodes and child nodes do not use a URI as parameters. Instead they reference node names directly which are only unique to a given service. The rationale is likely because of the difficulty for server implementors in dealing with nodes on non-local services. If you want this behavior you're probably better off reflecting pubsub from remotes into your local service through some means. -bjc
[Standards] Can I create a collection node somewhere, and add nodes from elsewhere(remote) to it?
Hi All, I'm quite new to XMPP and have been trying to figure out how I can make use of it with my current project. Thus far I've been thwarted by almost everything I thought I could do with XMPP :) Mostly I've been trying to figure out how to scale up xmpp based applications using the natural federation xmpp provides, but most of the xeps and extensions seem to assume clustering will always work. I thought I had found a nice solution for my project using XEP-0248: PubSub Collection Nodes, but I was surprised to find that it does not appear to support collections containing remote nodes. (just to be clear, I want to create a collection somewhere, and add nodes from elsewhere to it). I'm wondering why this is? It seems exactly the kind of thing xmpp should do and it would seem to be a reasonable way to scale out nodes. It would also appear to make XEP-0253: PubSub Chaining completely redundant. Have I missed something important? Thanks, Jason.
[Standards] XEP-0248: PubSub,Collection Nodes
This is a repost, I'm still hoping for a response. Re XEP-0248: PubSub Collection Nodes, It appears that there is no support for pubsub collections to contain remote nodes. I would like to be able to create a pubsub collection on a server, and add nodes from other servers to it). I'm wondering why this is? It seems exactly the kind of thing xmpp should do and it would seem to be a reasonable way to scale out nodes. It would also appear to make XEP-0253: PubSub Chaining completely redundant. Have I missed something important? If this really is a missing feature can it be ammended? Thanks, Jason.
