I'm opposed to having both any parameters and a state parameter. Pick one. OAuth 1.0a allowed any client-specific parameter in the callback. The argument for adding a state parameter was to increase interop but that is only true if it comes instead of custom parameters.
EHL On 4/9/10 7:37 AM, "Evan Gilbert" <[email protected]> wrote: On Fri, Apr 9, 2010 at 12:32 AM, Eran Hammer-Lahav <[email protected]> wrote: On 4/8/10 11:11 PM, "Evan Gilbert" <[email protected]> wrote: >> >> >>>> 2. Section 2.1: "The authorization endpoint advertised by the server >>>> MUST NOT include a query or fragment components as defined by >>>> [RFC3986] section 3." Why do we disallow query parameters? If we want >>>> to enforce strict matching of callback URLs maybe we should just >>>> demand that. >>> >>> I don't like having both custom query and a state parameter. If servers have >>> to accommodate custom queries, then we might as well drop the special state >>> parameter since clients can just make up whatever they want. I opted to use >>> the state parameter because it makes pre-registering URIs easier, and it >>> doesn't cause parameter namepsace conflicts (which is still an open issue). >> >> I think I got mixed up a bit. The authorization server endpoints >> should be allowed to have query parameters. No state is passed through >> these, and also no matching done against them. >> >> Registered callback URLs for clients should also be allowed to have >> query parameters. If strict matching is enforced, at least for the >> query part, then no state that can be passed, so they have to use the >> state parameter. Parameter namespace can be an issue, one more reason >> to keep the prefix :-) > > +1 on callback URLs and authorization server being allowed to have query > parameters. Nothing in the spec prevents the authorization endpoint from including extensions. Right now the spec is silent on how extensions work which means the server developer has to be careful in adding new parameters and should probably prefix them with their company name or some other prefix to ensure they will not conflict with the core parameters and standard extensions. I also rather make it less appealing to extend the authorization endpoint because each such custom extension (not published as a standard) reduces interoperability. Callback URIs support client state which accomplishes *exactly* the same thing, but with full and trivial client support. So the feature is there, now we are just arguing over style. > Callback URLs might be a page on an existing web site, and we will be limiting > the usefulness of the Web & User-Agent profile if we disallow these pages to > have query parameters. Its trivial to add an endpoint that takes a callback and redirects it internally to the existing endpoint. Not trivial to do this. That callback adds latency and more importantly requires all clients do the proper redirect URL enforcement. Proper redirect enforcement is an essential security characteristic, and a small bug in URL parsing means that you've created an open redirector (for example, checking that the URL prefix is "http://www.mysite.com"; would be a bug, because attackers could use "http://www.mysite.com:[email protected]/";. What is the benefit we get from the restriction on callback URL parameters? It's not clear to me why we want this restriction in the first place. > Authorization server is probably less necessary, but don't see any good reason > to restrict. Its not. EHL
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
