gt;
> particular, the value of the ‘state’ and ‘redirect_uri’
> parameters.
>
> ** **
>
> EHL
>
> ** **
>
> ** **
>
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Aiden Bell
> *Sent:* Wednesday, July 20, 2
unteering to propose text?
EHL
> -Original Message-----
> From: bigbadb...@gmail.com<mailto:bigbadb...@gmail.com>
> [mailto:bigbadb...@gmail.com<mailto:bigbadb...@gmail.com>] On Behalf Of
> Bob Van Zant
> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer
e) which
> the client can use to validate the state value.
>
> In short, over specification does not solve ignorance. We can and should
> highlight the possible code injection attacks on both the client and
> authorization server, as well as other security concerns around the state
> pa
l.com<mailto:bigbadb...@gmail.com>] On Behalf Of
> Bob Van Zant
> Sent: Wednesday, July 20, 2011 9:29 AM
> To: Eran Hammer-Lahav
> Cc: Breno; OAuth WG
> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> The problem lies in the inherent trust
xecute a JavaScript script. Source code of script
> found
> > within request. Other browsers won't. Real attackers are more creative
> than
> > me.
> >
> > -Bob
> >
> >
> >
> >
> >
> > On Wed, Jul 20, 2011 at 9:11 AM, Eran Hammer-La
> In short, over specification does not solve ignorance. We can and should
> highlight the possible code injection attacks on both the client and
> authorization server, as well as other security concerns around the state
> parameter. But at the end, it is up to both the client and authorization
hav
> Cc: Breno; OAuth WG
> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> The problem lies in the inherent trust of the state parameter. The naive
> client application developer assumes that state goes out to the authorization
> server and comes
7;s the attack vector here?
>
> EHL
>
>> -Original Message-
>> From: bigbadb...@gmail.com [mailto:bigbadb...@gmail.com] On Behalf Of
>> Bob Van Zant
>> Sent: Wednesday, July 20, 2011 9:10 AM
>> To: Breno; Eran Hammer-Lahav
>> Cc: OAuth WG
>
10 AM
> To: Breno; Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>
> I think somewhere in here my original comments got lost. The spec, as
> written, provides no limitations on what can go in the state variable.
>
I think somewhere in here my original comments got lost. The spec, as
written, provides no limitations on what can go in the state variable.
If we don't define those limitations in the spec implementors are
going to define their own limitations (I'm on the verge of doing it
myself).
I propose that
On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav wrote:
>
>
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eliot Lear
> > Sent: Sunday, July 17, 2011 2:49 AM
>
> > One other point: if the redirection_uri can have fragments and can
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
> Eliot Lear
> Sent: Sunday, July 17, 2011 2:49 AM
> One other point: if the redirection_uri can have fragments and can be
> provided, why is state necessary?
First, I assume you mean query
On Sun, Jul 17, 2011 at 2:49 AM, Eliot Lear wrote:
> Bob,
>
> Just on this one point:
>
> On 7/15/11 5:35 PM, Bob Van Zant wrote:
>> The spec says that the value is opaque and that
>> I need to accept, store, and reply with exactly what the client sent
>> me.
>
> Where does it actually require you
Bob,
Just on this one point:
On 7/15/11 5:35 PM, Bob Van Zant wrote:
> The spec says that the value is opaque and that
> I need to accept, store, and reply with exactly what the client sent
> me.
Where does it actually require you to "store" the "state" contents
beyond the point where you issue
om: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Bob Van Zant
>> Sent: Friday, July 15, 2011 8:35 AM
>> To: OAuth WG
>> Subject: [OAUTH-WG] OAuth v2-18 comment on "state" parameter
>>
>> Hi everyone,
>> I'm in the pro
query parameters that are not properly
percent-encoded.
EHL
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Bob Van Zant
> Sent: Friday, July 15, 2011 8:35 AM
> To: OAuth WG
> Subject: [OAUTH-WG] OAuth v2-18 comment on &q
Hi everyone,
I'm in the process of implementing OAuth and I'm a little concerned
about the "state" parameter that a client can send as part of the
authorization request. The spec says that the value is opaque and that
I need to accept, store, and reply with exactly what the client sent
me. Can we i
17 matches
Mail list logo
