> > > > >> 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. 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. Authorization server is probably less necessary, but don't see any good reason to restrict.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
