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

Dave Cridland dave at cridland.net
Thu Jan 21 09:53:50 UTC 2010

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.

> 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.

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.

>  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).

> 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.

FWIW, most servers support XEP-0114, and (I'm told) most servers have  
a way of trusting a component to send stanzas from a specific  
account. The missing part of this is that there's no method for  
getting a response - there are some obvious solutions here, but many  
of them aren't needed, since other inter-domain authentication  
mechanisms work just as well.

In summary, then, whilst I do agree there's some work to be done  
here, I really don't think it's nearly as bleak a picture as you're  

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list