The scope of assertion based client authentication is only in OAuth and only for the client calling the AS's token endpoint. Defining a general HTTP auth scheme for assertions would have a much broader scope and be much more difficult to standardize.
On Tue, Feb 19, 2013 at 6:54 AM, Sergey Beryozkin <sberyoz...@gmail.com>wrote: > Hi, > > Assertions like SAML2 Bearer can be used for authenticating the client. > Why a dedicated Authorization scheme can not be introduced, instead of or > in addition to "client_assertion" & "client_assertion_type" parameters ? > > IMHO, the following > > Authorization: SAML "base64url-encoded assertion" > > grant_type=authorization_code&**code=123456 > > is more in line with OAuth2 recommending not to prefer including client id > & secret in the body: > > "Including the client credentials in the request-body using the two > parameters is NOT RECOMMENDED and SHOULD be limited to clients unable > to directly utilize the HTTP Basic authentication scheme (or other > password-based HTTP authentication schemes)" - though it talks about a > password based scheme... > > similarly: > > Authorization: JWT "encoded jwt assertion" > > grant_type=authorization_code&**code=123456 > > Just a thought. > > Cheers, Sergey > > > ______________________________**_________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
