On Fri, Apr 9, 2010 at 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]/";. > As a bonus, all of the redirect validation logic will need to be possible in JavaScript for the User-Agent profile. > 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
