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
