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. On Thu, Jul 31, 2008 at 2:18 PM, Ralph Meijer <[EMAIL PROTECTED]>wrote: > On Thu, Jul 31, 2008 at 12:02:00PM -0700, Nathan Fritz wrote: > > 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. > > That we can doesn't mean we should. Both your examples can easily be > implemented by doing the requests for the request token and subsequent > exhange for an access token over HTTP as the OAuth spec specifies. How > access is granted, by the way, is unspecified. The only thing we would > need to spec is how to pass the access token over XMPP, to prove that > the sending party is indeed authorized to perform the associated action. > > 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. > > If you still want that, I can transform your examples to match my > hypotheses above. But I first need some sleep. > > -- > Groetjes, > > ralphm > >
