On Fri, Apr 9, 2010 at 10:43 AM, Eran Hammer-Lahav <[email protected]>wrote:
> 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. > We definitely need to support existing URL parameters - I don't see any solution for the latency and security issues brought up in the previous email. I don't know the additional use cases for client state beyond the URL - possibly this requirement can move. Possibly some of the folks who initially proposed client state can give context as to why this might be different than URL 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
