> -----Original Message----- > From: Justin Richer [mailto:jric...@mitre.org] > Sent: Monday, April 18, 2011 12:35 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] MAC request URI normalization (query > parameters) > > Any instance of apache's mod_rewrite will bork up the request URL for > anything behind the rewrite. The server or client code behind a rewrite will > only see the rewritten URL and not the original request URL.
That's true for any normalization so not a valid issue (for this particular question). > Why not just pack the signed string in with the payload? You would then > have rules on verification instead of normalization. The client gets to sign > the > raw URL (or whatever bits, really) however it wants to, and the server can > decide if the signed bits adequately cover the full query or not. Any duplication of HTTP request bits for the purpose of signatures (or MAC) is a really bad idea (tm). This is my main objection to the JWT family of proposals in which HTTP request components are duplicated in each request. Why use any HTTP components at all? Just use one URI with GET for all your API needs and define an internal signed structure for the request... If you do that, you are basically moving away from REST and into SOAP. To me, this is a very clear line - absolutely no duplication what-so-ever. EHL > -- Justin > > On Mon, 2011-04-18 at 15:26 -0400, Eran Hammer-Lahav wrote: > > I would like to drop all the request URI parameters normalization > > logic and just use the raw request URI instead. A year ago during the > > discussion on my Token authentication scheme (which had that behavior > > specified), some people raised the issue that access to the raw > > request URI isn’t always possible on the client or server. This feels > > like a limitation that is no longer a real problem for any modern web > > development environment. > > > > > > > > If you know of actual deployment issues with using the raw request URI > > instead of the parameter parsing and sorting voodoo, please let me > > know. Otherwise, the next draft will drop that entire section. > > > > > > > > EHL > > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
