Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

[Justin Richer <[e-mail]>]

The thing to remember is that all of these parameters are bi directional 
since the configuration is echoed back to the client. On the one hand 
(C->S), it's the client stating its preference. On the other direction 
(S->C) it's the server specifying the client's configuration. So the 
server *does* say that the client must do authn method X in its 
response, using the same parameter. And if the client wants a method 
that doesn't get supported, then it doesn't get to use it. But at least 
it has a chance to know about that by looking at the server's response. 
Same goes with scopes, grant types, and others.

It is a singular value. At one point I had had it in there as an array 
(space separated list of strings, I think), but the Connect working 
group didn't want to make it plural at the time.

  -- Justin


On 04/24/2013 06:55 PM, Phil Hunt wrote:
> Right and if the client wants a method not supported then what?
>
> Why can't the client offer up a list of methods it is able to support, 
> say in order of preference?
>
> The text appears to indicate only one value may be passed.
>
> Given the way it is written. It seems better to just have the server 
> say the client must do authn method X in the response.
>
> Phil
>
> @independentid
> www.independentid.com <http://www.independentid.com>
> [e-mail] <mailto:[e-mail]>
>
>
>
>
>
> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>
>> In Connect the AS may support a number of token endpoint 
>> authentication methods.   The reason to allow a client to register 
>> using a particular one is to prevent downgrade attacks.
>>
>> If the client wants to always use an asymmetric signature you don't 
>> want to allow attackers to use weaker methods like http basic.
>>
>> So a server may support any number of methods, but it is reasonable 
>> for a client to specify which one it is going to use.   In a closed 
>> system that may not be that useful but in a open system where the AS 
>> has a looser relationship to the client it is important.
>>
>> John B.
>>
>> On 2013-04-24, at 7:30 PM, Phil Hunt <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>> Hmmm… what was the objective or use case for having the client being 
>>> able to choose in the first place?
>>>
>>> It seems to me that the AS will make a decision based on many 
>>> factors. As you say, there isn't any other place that enumerates the 
>>> various [authn] methods a client can use to access the token 
>>> endpoint.  So, why do it?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com <http://www.independentid.com/>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>
>>>> Seems reasonable to me, can you suggest language to add in the 
>>>> capability? Would it require an IANA registry? Right now there 
>>>> isn't any other place that enumerates the various methods that a 
>>>> client can use to access the token endpoint.
>>>>
>>>>  -- Justin
>>>>
>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>> For parameters to token_endpoint_auth_method, the spec has defined 
>>>>> "client_secret_jwt" and "private_key_jwt". Shouldn't there be 
>>>>> similar options of SAML?
>>>>>
>>>>> Shouldn't there be an extension point for other methods?
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com <http://www.independentid.com/>
>>>>> [e-mail] <mailto:[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>