On Thu, Jul 31, 2008 at 11:44 PM, Nathan Fritz <[EMAIL PROTECTED]>wrote: > > > What if there isn't any HTTP service? I think that omitting a method for > doing this is short sighted, and the argument of "you could do this over > HTTP" does not equate to "you should do this over HTTP." >
Can you present a scenario that you actually have to implement for in the next, say, 3 months where you can't use HTTP, but can use XMPP? > Also, by dropping XMPP as negotiating the tokens, you lose the inherit > benefit of XMPP being natively resistant to replay-attacks. > XMPP is not resistant to replay attacks, and shouldn't be presented as such. > Just because we *can* use HTTP in a non-browser based app, why would we? > XMPP is not tied to HTTP, and we shouldn't force it in an extension unless > it's an extension for HTTP like BOSH. > We should use HTTP here for three reasons: 1. XMPP is new to people. Implementing simple applications is difficult enough already, and requiring that they implement token exchange mechanisms to get started unreasonably raises the bar. 2. OAuth is tied to HTTP. There are existing implementations of the token exchange over HTTP, in production. 3. OAuth is tied to HTTP. Whether you use HTTP or XMPP to do the token exchange bits, you need to send the user to a web page to approve the OAuth request. In practice, no-one will use the XMPP-based token exchange mechanism (FireEagle won't, Ralph's work won't, any existing site with HTTP OAuth endpoints won't), so (1) it shouldn't be in the spec and (2) you'll have to implement the HTTP OAuth mechanism anyhow. If it turns out that there's a compelling reason to have the XMPP-based token exchange documented, then it can be added back in (without breaking the signing mechanism) or added as a separate spec. In the meantime, it just confuses the matter. b.
