<HTML> <HEAD> <TITLE>Re: [jdev] OAuth and XMPP</TITLE> </HEAD> <BODY> Hey Peter, I’m fine with not having those flows explained in the next version of the XEP. However, are we going to explain that tokens need to be validated and that more flows with other Oauth servers will be needed? My knowledge of OAuth went from 0% to 1% in the last weeks so I guess that adding some basic explanation of how things work is going to be useful for implementors that are no OAuth expert. Thanks,   -- Gato On 7/28/08 2:04 PM, "Peter Saint-Andre" <<a href="stpeter@stpeter.im">stpeter@stpeter.im</a>> wrote: <BLOCKQUOTE>Nathan Fritz wrote: > > > On Mon, Jul 28, 2008 at 9:56 AM, Sylvain Hellegouarch <<a href="sh@defuze.org">sh@defuze.org</a> > <<a href="mailto:sh@defuze.org>">mailto:sh@defuze.org></a>> wrote: > >     Peter Saint-Andre a écrit : >      > Sylvain Hellegouarch wrote: >      >> Peter Saint-Andre a écrit : >      >>> Sylvain Hellegouarch wrote: >      >>>> Hi all, >      >>>> >      >>>> Following Peter last blog note [1] and XEP-0235, I'm pleased >     there is a >      >>>> formal definition on how to couple OAuth with XMPP but I'm >     somewhat >      >>>> disconcerted by the fact that the definition is per XMPP >     service. Why? >      >>>> XEP-035 specifies for a few of them (PubSub, MUC and Registration) >      >>>> but I'm >      >>>> wondering if that wouldn't have made more sense to define a >     service >      >>>> on its >      >>>> own. >      >>> Do you mean that an XMPP server could offer a generalized OAuth >      >>> service for use by things like pubsub components, MUC >     components, and >      >>> the XMPP server itself? >      >> >      >> Yes. >      > >      > Could you expand a bit on what you mean by that? I don't think >     XEP-0235 >      > (which I'm currently updating to reflect our discussions in Portland) >      > disallows a standalone OAuth service that's used by servers and >      > components, but that model seems to be a bit more sophisticated and >      > complex. >      > >      > /psa >      > >      > > >     Right. I can see it would indeed make it more complex and would prevent >     the solution to be implemented and deployed reasonnably soon. > >     However I didn't mean your XEP was forbidding a standalone service, >     perhaps a note in that spirit would make it clear that indeed you can >     write such service. > >     - Sylvain > > > Peter and I discussed an iq packet with the oauth namespace being used > to establish trust for a JID permanently.  Is that still going to be > included as an option? Yes, I'll add that use case in the next version of XEP-0235, but I think it's tangential to what Sylvain is talking about, because you could use the IQ exchange with a pubsub service, a MUC service, an IM server, or a standalone OAuth service that's used by all of the above. However I have no objections to standalone OAuth services, it's just that we'd need to define the interactions between said service and all the other services that might be deployed in a domain (e.g., how does the pubsub service check an OAuth token with the OAuth service). Those flows won't be in the next version of XEP-0235 but they might be in a future version, or in a future spec that builds on XEP-0235. /psa </BLOCKQUOTE> </BODY> </HTML>