I believe this is basically how the draft-hardt-oauth-o1 Rich App profile worked. It probably could have benefited from requiring that response parameters were returned behind a # fragments on callback URLs. It also could use the callback URL on the access token request, and the refresh token should be optional, but besides that, I think it worked pretty well. If the client could handle callbacks, they could use them...if not, it gracefully degraded to the native application flow.
-cmort On 4/14/10 5:23 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: On Wed, Apr 14, 2010 at 4:24 PM, Luke Shepard <lshep...@facebook.com> wrote: >> Assuming simplification is the main driver, I think it is feasible to >> combine Web Callback and Native Application, with no penalty. > > How would that work? The Web Callback flow assumes the presence of a > client_secret, while the Native Application does not have a secret. The client_secret would have to be optional then. This may be needed anyhow to support an "unregistered" Web Callback flow. Also, the callback URL may need to be optional, because some native apps cannot receive a callback. The Authz Server will have to show a page with the verification code in this case. Marius
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
