I think that the meaning here is that the client can handle the HTTP redirect back from the authorization server. Not that the authorization server is making a HTTP request directly to it. Agreed that it could be clarified. :)
On Wed, Aug 25, 2010 at 9:19 AM, Stuebner, Christian (extern) < c.stueb...@external.telekom.de> wrote: > I have a question regarding draft -10, section 1.4.1 - web server flow: > > "The web server profile is suitable for clients capable of interacting > with the end-user's user-agent (typically a web browser) and capable > of receiving incoming requests from the authorization server (capable > of acting as an HTTP server)." > > Neither figure 4 nor the sequence description below mention "receiving > incoming requests" again. > At which point is the client required to receive incoming calls? > Authorization code retrieval? Access token retrieval? Which interface should > be used to tell the AS which URI is to be called? > > In my opinion the "native application" flow covers mechanisms that could > also be applied to the web server flow (e.g. custom URI scheme, providing a > redirection URI pointing to a server-hosted resource, etc). I'm looking > forward to draft -11 to see what happens to the client profiles. > > Regards, > Christian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
