Few responses inline. On Mar 22, 2010, at 5:11 AM, Manger, James H wrote:
> 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." > It would be great to support client certificates as a means to authenticate OAuth applications. However, that should be a new flow, as it has different security characteristics. <snip> > 4. The Username and Password Flow has oauth_client_secret in the example but > not in the expected list of parameters. Mistake. It should not have client secret. This flow also could benefit from client certs, if available, but again, that is a new flow definition. > 5. Just call it TLS (not TLS/SSL). Many people are familiar with SSL, not TLS, and so this clarifies for those readers. _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
