On Sun, Apr 18, 2010 at 10:36 PM, Dick Hardt <[email protected]> wrote:
> > On 2010-04-18, at 10:28 PM, Eran Hammer-Lahav wrote: > > > > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On Behalf > >> Of Dick Hardt > >> Sent: Sunday, April 18, 2010 9:20 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] Issue: state in web server flow > >> > >> Why was the state parameter removed from the web server flow? > > > > I didn't want to both define a state parameter *and* allow for any other > client-specific parameters in redirection URIs. Because people made the > point that *any* client-specific parameters are required, I proposed to drop > the state parameter. After all, servers MUST send back whatever URI they > receive regardless of it being encoded into a state parameter. > > > >> Some AS may require the entire redirect URI to be registered, so the > state > >> parameter allows a client to maintain state across calls. > > > > I agree that this is useful, but it only makes the spec better if we make > its use more restrictive. Defining it makes it easier for servers to > validate the redirection URI, but only if the client is not allowed using > other client-specific query parameters with it. > > Agreed > > > > > If people feel strongly about putting it back, I suggest we only allow it > with callbacks without any query component as that is the only combination > it adds value. > > Agreed > Just to verify what is being proposed... is it: - We will allow callback URIs with query parameters, and - We will allow client state, but - We won't allow a callback with client state to a URI with query parameters > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
