>"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.
We have the case where signed assertions are used for authentication and other cases where just client_id and secrets are used. I don't agree that client assertion credentials should be dropped or that HTTP Basic Authentication can do everything that we want/need and having to go the route of suggesting a new HTTP Authentication scheme while nice does not help us with the current OAUTH that we have been developing. Removing is a breaking issue. -----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
