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
