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.


Reply via email to