The key here is that client authentication in this context is clearly HTTP authentication. This isn't about changing any functionality, but about how to be provide it. The two opposing views (generalized) are:
1. Limit section 3: the specification should simply rely on HTTP authentication and any new authentication scheme, such as the proposed client assertion credentials, be defined as new HTTP authentication schemes. There is nothing unique to client authentication in OAuth that isn't already present in other HTTP authentication schemes (and framework). 2. Expand section 3: the specification should explicitly define methods for authenticating the client using parameters instead of the HTTP authentication headers. The client password credentials reflects an existing, deployed practice, and the client assertion credentials provide an extension point desired by existing enterprise use cases. At the end, the resolution of this issue is going to be around where to draw the line between specifying no custom client authentication to inventing 2 or more parameter-based methods, and potentially calling out specific HTTP schemes as well (e.g. Basic). EHL From: [email protected] [mailto:[email protected]] On Behalf Of William J. Mills Sent: Thursday, April 14, 2011 8:56 PM To: Manger, James H; oauth Subject: Re: [OAUTH-WG] Revised Section 3 Authenticating a piece of software isn't how I view the utility of the client id and secret. It is extremely useful for site to site authentication where a trust relationship CAN be maintained. We really don't want to lose that functionality. ________________________________ From: "Manger, James H" <[email protected]> To: oauth <[email protected]> Sent: Thursday, April 14, 2011 8:47 PM Subject: Re: [OAUTH-WG] Revised Section 3 I'm certainly in favour of excluding client auth from OAuth. Dropping section 3 and just having a paragraph like the following would be preferable (with no capitalized keywords): In many cases an authorization server will require client authentication for requests to a token endpoint. Consequently, a client app that has credentials appropriate for that server should proactively use them for such requests. The actual mechanism for client authentication, and any provisioning of the associated credentials, is outside the scope of OAuth 2. I am not a fan of the client_id/client_secret parameters, but was resigned to their inclusion given existing deployments. Given those parameters are mentioned, OAuth2 should say: Various early deployments of the OAuth 2.0 concepts authenticated clients to the token endpoint using client_id and client_secret parameters in the request (alongside the grant_type parameter for instance). A server that accepts client_id/client_secret parameters MUST also accept the same credentials presented using the HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request header). The last paragraph of Thomas's "3.2 Shared Secret Credentials" is crazy (typo?). A server supporting some strong authentication mechanism must not be mandated to also support weaker BASIC and client_id/client_secret mechanisms -- and certainly not with the same secret! "3.3 Client Assertion Credentials". OAuth2 currently supports the concept of a client app swapping an assertion for an access token. Do people want the additional functionality of using assertions for generic client authentication? I assumed servers would prefer that clients swap an assertion for a token at one specific endpoint, then use the token for generic client auth in other requests -- in which case section 3.3 "Client Assertion Credentials" can be dropped. -- James Manger _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
