> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> Sent: Sunday, July 10, 2011 2:17 AM
> Eran Hammer-Lahav schrieb:
>
> >The security of the protocol relies fully (implicit grant) or partially
> >(authorization code) on the validation of the redirection
ppy to add this to the security document.
regards,
Torsten.
>
>If I had it my way, the specification would ban any type of dynamic
>redirection URI (other than selecting one out of multiple fully
>specified options). But this proposal was rejected (for no good
>reasons, just peo
...@lodderstedt.net]
Sent: Friday, July 08, 2011 1:23 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: [OAUTH-WG] state parameter and XSRF detection
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
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 inc
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
Sounds reasonable - subject to the content of the validation rules for a
registered redirect URI (section 10.11 TBD). The security considerations
doc (or section 10.13 of the spec itself which is TBD) should make it clear
that the state parameter must be provided by the client to prevent CSRF
again
On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt
wrote:
> 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.
