In section 10.12 (CSRF):
5th paragraph: "A CSRF attack against the against the authorization
server's authorization endpoint"
One "against the" is redundant.
4th paragraph: "The binding value enables the client to validate the
validity of the request by matching the binding value to the
user
f the text I proposed could be
combined in whichever text is eventually decided upon.
-- Niv
On Fri, Aug 19, 2011 at 02:46, William J. Mills wrote:
> I proposed text that I think is more complete in a previous message...
> ________
> From: Niv Steingarten
>
against CSRF
attacks on the *client*, as opposed to CSRF on the *authorization
server*, is made explicit.
-- Niv
On Fri, Aug 19, 2011 at 00:13, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday,
On Thu, Aug 18, 2011 at 22:19, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 12:12 PM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>
On Thu, Aug 18, 2011 at 21:17, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 11:08 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>
On Thu, Aug 18, 2011 at 20:31, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 10:16 AM
>> To: Eran Hammer-Lahav
>> Cc: Torsten Lodderstedt; oauth@ietf.org
>
not allow CORS calls to
> that endpoint. I don't see how the measures proposed in the new section are
> relevant here.
>
> EHL
>
>
>> -Original Message-
>> From: Niv Steingarten [mailto:nivst...@gmail.com]
>> Sent: Thursday, August 18, 2011 5:49
Here are two very simple examples. They are very naive ones, but get the
point across and I would not be suprised if they could be found in the
wild:
Say a client has its authorization endpoint at
(1) http://www.domain.com/auth.php
A client requests access to protected resources by red
delaying the spec's release
> process)?
>
> regards,
> Torsten.
>
> Am 26.07.2011 19:29, schrieb Niv Steingarten:
>>
>> Would it be possible to consider adding this to the list of security
>> considerations?
>> Of course, the spec cannot cover all pos
mechanisms in many applications).
Is it too late to make such an amendment to the draft?
Thank you,
Niv
On Tue, Jul 26, 2011 at 02:40, Niv Steingarten wrote:
> Yes, I believe the vast majority of user-agents would block this kind
> of request if it originated from a JavaScript XMLHttpRequest o
y enforcing a real user interaction (password input,
> CAPTCHA).
>
> regards,
> Torsten.
>
> Am 25.07.2011 18:27, schrieb Niv Steingarten:
>
> Forwarded as per Eran's request.
> A couple of corrections to my original email:
> 1. By AJAX, I mean, AJAX like techniques (if the
les the request.
Thank you,
Niv
-- Forwarded message --
From: Eran Hammer-Lahav
Date: Tue, Jul 26, 2011 at 01:21
Subject: RE: Several typos in -20 and a possible security consideration
To: Niv Steingarten
Please forward this message to the oauth list at oa...@ieft.org.
12 matches
Mail list logo
