The client should be capable of redirecting the user agent to the authorization server, so the client has to be an HTTP server. The authorization server then also redirects the user agent back to the client. I agree that the description needs clarification. Especially the text "...and capable of receiving incoming requests from the authorization server (capable of acting as an HTTP server)". I do not see a step at which the client receives a request from the authorization server. The authorization server only responds to the client's request (with the authorization token). At this point the client is acting as an HTTP client.
Zachary ________________________________ From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of David Recordon Sent: Wednesday, August 25, 2010 12:48 PM To: Stuebner, Christian (extern) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Web Server Flow - receiving incoming requests 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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
