I'm going to disagree. We can treat the XMPP client/transport as the consumer, and a pubsub service as the service. We can use it to prove that this XMPP JID is approved by an HTTP based user to have certain access over HTTP. We can use a specialized XMPP client (like Twhirl) as the consumer as well as the authorizer over the two transports. Take this example:
1. Say you want LinkedIn to be informed LIVE whenever your Gmail contact list changes (additions, edits, and deletes). 2. Gmail and LinkedIn have agreed upon a certificate and secret for LinkedIn. 3. Gmail stores your contact list in an XMPP PubSub Node. 4. You go to LinkedIn.com and inform it that you want [your-user-here]@ gmail.com's contacts to update your LinkedIn contacts live. 5. LinkedIn, over XMPP, requests a "request token" from Gmail's pubsub service, signing it with the agreed upon certificate and secret. 6. Gmail, if the signature was valid, sends LinkedIn a "request token." 7. LinkedIn then redirects the user to a Gmail webpage. 8. On the Gmail Webpage, you have to log in or already be logged in. You are asked whether you approve of LinkedIn having read-only access to your contact list with live updates. You could optionally set a timeframe (6 months to expire). 9. You approve the request and Gmail redirects you back to LinkedIn. 10. LinkedIn, over XMPP, requests an "access token," again, signing it, and now using the "request token" that you approved. 11. Gmail, if the signature is correct, and the request token was approved, replies with an access token. 12. LinkedIn, over XMPP, subscribes to your Publish-Subscribe Contact List node using the access token. 13. From there on out (until the token expires if you set an expiration) gets updated every time you add/edit/delete items from your contact list in Gmail as they happen! Sure, maybe there are other ways of accomplishing this, but then take the Twhirl example: 1. Twhirl logs into twhirl.org via XMPP SASL-Anonymous and is assigned a random JID. 2. Twhirl, over XMPP, requests a request token from the identi.ca bot. 3. Twhirl, over the identi.ca HTTP API, with the user's account, approves the token. Now we have proof that this random JID is approved by the user to get updates. 4. Twhirl, over XMPP, requests the access token. 5. Twhirl sends presence to the bot with the OAuth access token via XMPP. 6. Twhirl gets updates from the bot via XMPP until presence is unavailable. This is a bit of an edge case, but in it, we use OAuth to prove that the XMPP JID is approved by the HTTP user. I'm perfectly willing to listen to other STANDARDS BASED ways of solving this. In short, the HTTP OAuth dance still has it's place in XMPP. Thanks, Nathan Fritz
