Re: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland

[Eran Hammer-Lahav <[e-mail]>]

The following comments require a proposed text. Without it, they will not be included in my next editorial revision. I will respond or incorporate the rest of the comments after the close of LC. Others are welcomed and encouraged to discuss this (very useful and thorough) list before LC ends.

EHL

From: Mike Jones <[e-mail]<mailto:[e-mail]>>
Date: Wed, 10 Aug 2011 14:38:40 -0700
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] Partial set of last call comments on OAuth draft 20 from Yaron Goland


1.4.1. Authorization Code:  Comment: “It seems odd that we can discuss the authorization code without also discussing the security issues it raises (e.g. passing secure information via a browser) and thus motivating the introduction of the refresh token. I would expect this to be referred to here.  Having read the security considerations section I can find no coherent discussion there either of the relationship between the authorization code and the refresh token and why one motivated the other. I think this is something important for implementers to understand.”

1.4.2.  Implicit:  Comment: “I find this section confusing. I think an example is all but mandatory here if the reader is to understand what is intended.  For example, when I first read this section I thought it was some kind of short cut used in cases where the client and authorization server had a close relationship and could share information such as the client’s identity so no access code was needed.  No where in here is any hint that this is about browser based clients who don’t have servers and who need a way to get tokens. Seriously. Try to read this section as someone who knows nothing about OAuth and tell me that you get the right idea back from it. It needs to be written to be both explicit as to its goals and clearer as to its means.”

3.1.2.4.  Invalid Endpoint: Comment on “open redirector”: “How many people even know what the heck an open redirector is? I think we need a section in the security considerations section that defines what an open redirector is and why it’s bad. Alternatively a normative reference to a complete definition somewhere else is also fine.”

4.1.2.  Authorization Response: Comment on “state”: “Don’t we have to provide some guidance on how large the state value can safely be? Otherwise we are asking clients to rewrite their state mechanisms every time they throw in support for a new protected resource server. We have to set expectations across the industry if we are to hope for actual interoperability.”

4.2.  Implicit Grant: Comment “I have run into multiple people (including myself) who have read the OAuth spec and came away completely confused about when the heck one is supposed to use the implicit grant flow for. It’s not immediately obvious that it’s a way to support standalone browser based clients. Can we put in an example or something to make it more obvious why it’s here?”

10.4. Refresh Tokens: Comment “As mentioned previously we really should explain why we introduced refresh tokens. Without understanding the intent of the mechanism it’s unlikely implementers will use them appropriately.”

10.7. Resource Owner Password Credentials: Comment on “password anti-pattern”: “Is it fair to expect that the reader knows what the password anti-pattern is? Shouldn’t some reference to a definition of this pattern be required?”

10.12. Cross-Site Request Forgery: Comment on first paragraph: “I challenge any reasonably intelligent person who does not already know what a CSRF is to read this paragraph and come away any clearer as to what is being discussed. At a minimum isn’t some reference to a complete definition of CSRF needed if there is to be any hope of user compliance?”

10.12. Cross-Site Request Forgery: Comment on “The "state" request parameter MUST contain a non-guessable value”: “Actually a non-guessable value won’t stop the attack discussed in the previous paragraph on its own. What’s also needed is a way to uniquely (and unbreakably) associate the state with a particular user so that if an authorization code swap occurs it can be reliably detected.”


________________________________