On Mon, Mar 22, 2010 at 1:52 PM, David Recordon <record...@gmail.com> wrote: > On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H > <james.h.man...@team.telstra.com> wrote: >> 2. STATE >> OAuth has various parameter that are used to carry state for another party >> in a message, which is helpful for building scalable systems. OAuth should >> avoid duplicating these fields or defining their semantics when they are >> opaque to the party carrying them. This will keep the protocol simpler, >> without losing any functionality. >> >> oauth_client_state is unnecessary as it is always accompanied by >> oauth_callback_url that can encode the state directly. The examples could >> include, say, >> ...callback_url=http://client.example.com/cb%3Fstate=FSR63fs&oauth_mode=... >> to reflect likely cases. It is still simple to compare the callback to a >> pre-register value if required (eg compare suffix, or compare ignoring >> additional query params). > > Has there been any discussion of the oauth_client_state parameter on > the list? I don't really remember it.
Not sure if this was discussed or not, but I think client state can be really useful. Yes, client state can be added to the callback URL, but this makes validating this URL against a registered callback URL more difficult. This ties in with the fact that the validation of these URLs is not specified. It is easy to imagine an Authorization Server that does strict validation of callback URLs, in which case the only way to pass client state through is with this extra parameter. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
