No different issue. I was concerned about the initial client assertion being passed in as authen cred. It is a signed set of client reg metadata.
See we are confused. Hence my worry. :-) Phil On 2013-05-30, at 8:48, John Bradley <ve7...@ve7jtb.com> wrote: > I think Phil also had some processing reason why a Token endpoint or RS > wouldn't want to tale the authentication as a header, as the processing was > easier with them as parameters as they are potentially available to different > parts of the stack. That may have been mostly around RS, but the principal > may apply to the token endpoint as well. > > On 2013-05-30, at 10:21 AM, Justin Richer <jric...@mitre.org> wrote: > >>>>> >>>>> "client_secret_post vs client_secret_basic" >>>>> BASIC and POST are essentially the same just different ways to send the >>>>> client secret. If an authorization server supports both, both should work >>>>> for any client. So are both methods treated differently? >>>> I agree, and this was one of my original arguments for making this field >>>> plural (or plural-able), but there hasn't been WG support for that so far. >>> >>> I'm not arguing to make it plural. I think the authentication method is >>> just "client_secret". >> >> That was also an option that was brought up, but in the OIDC WG the >> counter-argument was (as I recall) that the two are syntactically separate >> and there's a desire to restrict to a single type, such as disabling >> client_secret_post. Basically, to make it unambiguous. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
