>> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
