The initial access token is a OAuth bearer Access token (Authz). Like any bearer token it can be structured or not. Your concern is I think around some work BB+ has done to profile a structured token for this particular RS use. That is out of scope for the core of dynamic registration, as it is out of scope for OAuth core.
So http basic vs parameters makes no difference to you. The assertion profile only uses POST parameters for the assertion rather than headers so that should not be an issue for that authentication method. John B. On 2013-05-30, at 11:52 AM, Phil Hunt <phil.h...@oracle.com> wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
