I would be very happy with this approach, with the addition of discussing the role of the client identifier and that a binding to any client authentication is needed.
EHL > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Manger, James H > Sent: Thursday, April 14, 2011 8:47 PM > To: oauth > 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] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
