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." 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). 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}. 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. 4. The Username and Password Flow has oauth_client_secret in the example but not in the expected list of parameters. 5. Just call it TLS (not TLS/SSL). -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
