I would like to request a consensus call on this. So far the few people who chimed in expressed their inclination not to include the normalized string in the request. If no one speaks up advocating the opposite, I will continue with the current approach of normalizing the request but not including it in the request.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, January 13, 2010 9:52 PM > To: OAuth WG > Subject: [OAUTH-WG] Include Normalized Request with Raw Request > > Authentication Open Question #2: Should the normalized request be > included with the request? > > In OAuth 1.0 the request is normalized into the signature base string by the > client and the server. The base string itself is never sent with the request. > Brian Eaton proposed [1] to include the signed string with the request, > removing the need for the server to regenerate the normalized string, as > well as allowing the client to use the included string to send additional > (signed) information that is not part of the HTTP request. > > This is a significant departure from OAuth 1.0, but one that does call for an > in- > depth discussion. > > Some advantages to this approach are: > > - the server can easily verify what is being signed > - the client can include additional parameters in the signed message > - the request remains valid even if changed by proxies or other > intermediaries > > Some disadvantages are: > > - the request is sent twice, once raw and once normalized > - it adds another place to make mistakes and create security holes if the > server uses the raw data without fully comparing it to the normalized > (signed) data > - since any server enforcing security will only use the data contained in the > normalized portion, it will create a de-facto standard for API requests (not > nearly as heavy as SOAP or WS-*) in which case the request itself is > normalized before sending. > > QUESTIONS: How do people feel about this? What are some other > advantaged and disadvantages of this approach? > > > EHL > > [1] http://www.ietf.org/mail-archive/web/oauth/current/msg00890.html > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
