Hi Eran, including dynamic values within redirect uris is standard practice today and is allowed by the spec's text so far. I don't mind to change it but the restricted behavior you prefer is a significant protocol change.
Moreover, I would like to understand the threat you have in mind and include it into our threat model. So would you please provide a more detailed description? regards, Torsten. Eran Hammer-Lahav <e...@hueniverse.com> schrieb: Allowing any flexibly in the redirection URI is a bad thing and the latest draft (pre -17) clearly states that. The main fear is that by allowing the query to be changed dynamically, attackers can find open redirector loopholes to abuse. I really wanted to make registration of the absolute URI a MUST, but didn't go that far. EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, June 27, 2011 2:22 PM > To: OAuth WG > Subject: [OAUTH-WG] state parameter and XSRF detection > > Hi all, > > while working on a new revision of the OAuth security document, a question > arose I would like to clarify on the list. > > The "state" parameter is supposed to be used to link a certain authorization > request and response. Therefore, the client stores a value in this parameter > that is somehow bound to a value retained on the device (the user agent) > originating the authorization request. > > The question now is: Would it be compliant with the core spec to use any > other URI query parameter encoded in the redirect_uri, instead of the > "state" parameter, to achieve the same goal? Probably the client already has > a working "legacy" implementation it does not want to change just for > OAuth2 compliance. > > According to section 2.2.1, the redirection uri could contain a dynamic > portion: > > "The authorization server SHOULD require the client to pre-register > their redirection URI or at least certain components such as the > scheme, host, port and path" > > So this should be fine. > > Any comments? > > regards, > Torsten. > >_____________________________________________ > 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
