Luke & David, The different security characteristics of TLS client certs (or TLS-PSK, or TLS-SRP, or HTTP BASIC, or cookies, or IPsec...) vs oauth_client_secret-in-body don't require any change to the *flow*. The interaction model does not change.
We need to limit the complexity of adding new flows to situations were they are necessary: Web servers can keep app secrets, web clients cannot => separate flows. Web servers can redirect browsers, devices have no browser => separate flows. 3-legged involves 3 parties, 2-legged only has 2 parties => separate flows. "red" client auth, "blue" client auth => same flows work. This is not an issue about client certs -- certs are just one stark example. -- James Manger ---------- Subject: Re: [OAUTH-WG] OAuth 2.0: client_secret, state On Mon, Mar 22, 2010 at 5:11 AM, Manger, James H > 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." Luke said: 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. David said: Agreed with Luke. This should be a new flow if you're using TLS client certs. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
