Understood, however at this point major reworking of the token endpoint is going to have to wait on the next release of OAuth.
I suspect that there will eventually be a 2.1. For now this should let us close the book on this 3 year odyssey and address some of the other issues like JWT etc. John B. On 2012-07-26, at 6:29 PM, Manger, James H wrote: >>> The changes introduced in Draft 29 had unintended consequences on >>> parts of the spec caused by Sec 4.3, 4.4 and 6 referencing Sec 3.2.1 >>> as part of client authentication. > >> this change breaks >> https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > and https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/ > > > An underlying cause of this issue is that a single URI (the token endpoint) > is overloaded for a dozen different tasks by a bunch of specs — and the list > of tasks is still growing. > > OAuth2 has built a RPC-style API, but almost pretends not to have done so by > using grant_type names/URIs and a parameter registry instead of a more formal > SOAP-style structure. > > John’s proposed note to the RFC editor should address the immediate issue. > Perhaps future enhancements, though, could consider a more RESTful approach. > I think that would significantly clarify some of the complexities OAuth2 > grapples with and minimise clashes between the various flows. > > -- > James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
