On Thu, Jul 31, 2008 at 3:33 PM, Nathan Fritz <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jul 31, 2008 at 3:07 PM, Blaine Cook <[EMAIL PROTECTED]> wrote: > >> I really strongly agree with Ralph here --- in all cases, the use needs to >> go to the Service Provider's website in order to grant permission to the >> Consumer (verify the token). Since HTTP is part of the flow, why not just >> use HTTP? It's well understood, libraries exist that support it, and it's >> easier to guarantee security (which is really important when you're talking >> about the exchange of secrets). >> >> b. >> >> >>> I haven't heard of a compelling reason to do the bit up to the consumer >>> getting the access token over XMPP rather than HTTP. It is likely that >>> all of your use cases require the HTPP OAuth exhange implemented anyway, >>> allowing you to use existing libraries. By providing a way to present >>> the access token over XMPP we have enabled the use of OAuth in XMPP with >>> minimal effort. >>> >> > But the proof that a given XMPP account is approved is less direct. Yes, > you use the access key over XMPP, but it breaks the consumer-service > paradigm. Perhaps my argument is weak, but shouldn't the consumer request > the keys through the protocol it is consuming on? I am, however, > reasonable. If there is no advantage for the requests to be made from the > same protocol as the access token is used in, then I bow out of this debate. > To be a bit more clear, if the token is used on a different transport than it was requested on, this brings us one step closer to a man in the middle attack. I think the service should expect the access token to be used on the same transport that requested it. What if the Authorization process is over XMPP as well via x-data-forms? 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." Also, by dropping XMPP as negotiating the tokens, you lose the inherit benefit of XMPP being natively resistant to replay-attacks. 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.
