Thanks for the feedback! Inline... On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H <james.h.man...@team.telstra.com> wrote: > Thanks for writing this draft for OAuth 2.0, David. > A couple of comments. > > 1. CLIENT SECRET > Client authentication needs to be independent of OAuth. > The Web Server Flow sends oauth_client_secret to the access token request > endpoint along with other oauth_ parameters. This is a poor design. > > Consider, for instance, a service that authenticates clients with TLS client > certs. Such clients don't have a shared secret to put in the > oauth_client_secret parameter so they cannot perform protocol in this OAuth 2 > draft. > Even if client certs are rare, the issue is that there is no reason why > client certs should prevent OAuth 2 from working. > > Servers that can authenticate clients are likely to offer them various APIs > in addition to the OAuth get-a-token calls. The same client authentication > mechanism used for those calls should be reused for the get-a-token calls. > > I suggest dropping the oauth_client_secret, perhaps adding text such as: > "Servers that require clients to be pre-registered may require this client > request to be authenticated."
Agreed with Luke. This should be a new flow if you're using TLS client certs. > 2. STATE > OAuth has various parameter that are used to carry state for another party in > a message, which is helpful for building scalable systems. OAuth should avoid > duplicating these fields or defining their semantics when they are opaque to > the party carrying them. This will keep the protocol simpler, without losing > any functionality. > > oauth_client_state is unnecessary as it is always accompanied by > oauth_callback_url that can encode the state directly. The examples could > include, say, > ...callback_url=http://client.example.com/cb%3Fstate=FSR63fs&oauth_mode=... > to reflect likely cases. It is still simple to compare the callback to a > pre-register value if required (eg compare suffix, or compare ignoring > additional query params). Has there been any discussion of the oauth_client_state parameter on the list? I don't really remember it. > oauth_scope is unnecessary as it is server-specific and can be encoded > directly in the server-specific URIs. A client with no server-specific > knowledge has no way of using oauth_scope, which is a sign it is better > omitted from the spec and left to specific servers when describing their > access/authz URIs. I have no problems with a service saying its user authz > URI is, say, http://example.com/authz?scope={all|blog}. Scope is something that we've seen used by many OAuth 1.0 providers so adding a consistant parameter to represent it makes sense. There's still not alignment on what individual scopes actually mean, but hopefully we'll get there (outside of this spec). > And a few minor issues: > > 3. If you want to return error params in the body of a 401 the important > feature is setting Content-Type to application/x-www-form-urlencoded. This > isn't mentioned in the text or example. hmm, I'll double check but I think it's mentioned in the flows which contain explicit error parameters. There's an entire other debate about if it's too difficult to parse form encoded parameters in a HTTP response (versus a request where they normally are). I've also been asking folks to start documenting the error conditions they'd like to see represented. > 4. The Username and Password Flow has oauth_client_secret in the example but > not in the expected list of parameters. Fixed, thanks! > 5. Just call it TLS (not TLS/SSL). +1 to what Luke said. SSL means something to far more people than TLS does. > > > -- > James Manger > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
