I felt the argument provided was persuasive and that the current spec leaves
implementers open to attack. I get concerned when the core spec says "OPTIONAL"
for state and then Security Considerations says REQUIRED. The inconsistency
seemed to be a flaw in draft 20.
As to your comment about a ti
I think using phishing here is misleading. This is not a classic phishing
attack. I'm open to other suggestions.
EHL
From: Lodderstedt, Torsten [mailto:t.lodderst...@telekom.de]
Sent: Wednesday, August 17, 2011 3:22 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: AW: Authorization Code Leakage feedb
I would like to hear from the other 3 authors of the proposed change about
their reasons for changing the use of 'state' from recommended to required for
CSRF prevention. It would also help moving this issue forward if the 4 authors
can provide answers or clarifications on the issues raised belo
I've read the thread leading to this, and the proposed text and I do not
understand the attack. Can you provide a step-by-step scenario of how an
attacker gains access?
Also, it is unlikely that any major provider is going to require CAPCHA as part
of the authorization flow. This is especially
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Wednesday, August 17, 2011 1:13 PM
> > > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access
> > > Token, Refresh Token
> >
> > Not sure. What do others think? I put access token first because
Barry,
I personally think that this is both a very thorough and very timely
follow-up.
(You may consider a minor editorial: "As this writing" in the first
answer, should be "As of this writing." Could not catch anything else.
The only other suggestion is that maybe the response could omit
I'm sorry for the delay in getting this written. Because of the
delay, the working group has just a short time to review my proposed
response, below. Everyone, please have a look at the answers I
propose to send, and post any objections to this thread by the end of
the day on Monday, 22 August.
Comments inline.
On Wed, 2011-08-17 at 14:15 -0400, Eran Hammer-Lahav wrote:
> Thanks for the feedback.
>
> > -Original Message-
> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> > Of Justin Richer
> > Sent: Thursday, August 11, 2011 2:07 PM
>
> > 1.2/1.4: The
Thanks for the feedback.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Justin Richer
> Sent: Thursday, August 11, 2011 2:07 PM
> 1.2/1.4: The term "authorization grant" remains confusing and the
> introduction is riddled with jargon lik
Text sounds very good.
wrt title: this threat is about phishing another user's authorization code.
Because of the design of the protocol this requires the attacker to use another
redirect URI than used by the legitimate client. To make this the title sound
bit weird to me. Why not "authorizatio
This seems to include two separate items.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Anthony Nadalin
> Sent: Friday, August 12, 2011 8:29 PM
> To: OAuth WG (oauth@ietf.org)
> Subject: [OAUTH-WG] x-www-form-urlencoded
>
> In the text
This is fantastic feedback. Some parts moved to new threads.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Mike Jones
> Sent: Wednesday, August 10, 2011 2:39 PM
> 1.4. Authorization Grant: Change "resource owner authorization" to
> "res
12 matches
Mail list logo
