Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

I still "argue" that the initial client access token (not assertion) is 
really just an authorization token for the endpoint (like any other 
OAuth2 protected resource). There is nothing within OAuth2 that 
precludes a system using structured authorization tokens that contain 
claims and using that claim data as factors in an authorization policy. 
Whether a token is structured or opaque doesn't change it's use as an 
authorization token. Even in traditional OAuth2 deployments, most opaque 
tokens identify the client to which the token was given. So I don't see 
this initial client access token as an authentication token but rather 
an authorization token.

Maybe that few of "authentication token" vs "authorization token" is 
where there is confusion?

Thanks,
George

On 5/30/13 11:52 AM, Phil Hunt 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 <ve7jtb@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 <jricher@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
>
>