[Standards] XMPP client-centric? [was: Decloaking and Temporary Subscriptions]
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
A classic case is the widely deployed "auto accept/auto subscribe"
feature in some servers, which sends out subscribe[d] stanzas per-pro
> 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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards