[Standards] XEP-0235: OAuth Over XMPP is not enough.
jason at hardlight.com.au
Fri Nov 27 03:34:21 UTC 2009
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
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,
More information about the Standards