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

[Justin Richer <[e-mail]>]

John, I don't think that anybody's actually suggesting that we add 
server discovery in here. :) But since the server does echo back the 
configuration in its response, the client is discovering a few things at 
run time about what it can and can't do with a particular server. It's 
entirely possible that the client might get back a configuration option 
that it can't use (say, it can't do client_secret_jwt assertions but it 
can do

 From what I can see from this thread though there are two open 
questions that Phil's raised:


  1: Extensibility of token_endpoint_auth_method values, and where 
potential values are listed (IANA? fully qualified URIs for things not 
in the base spec?)

  2: Plurality of token_endpoint_auth_method (could be left as a string, 
made an array, or be a JSON-style optional plural: string value if 
singular or array if plural)



I think the first one should be addressed, but we just need to pick the 
method. I'm personally in favor of the same method we used for 
grant_type, which is short values in the spec and extensions as fully 
qualified URIs. The second one could break existing implementations (and 
other dependent specs), so if we change it, it has to be for very good 
reason.

  -- Justin

On 04/24/2013 07:23 PM, John Bradley wrote:
> In Connect there is a AS discovery before registration.
>
> The general pattern is the RP discovers the capabilities of the AS 
> authentication methods and algorithms supported by the AS.
> The client then picks the best options for it and registers them.
>
> It would in theory work of the client knowing nothing about the AS 
> pushed it's capabilities at the AS as you are suggesting and let the 
> AS pick.
>
> My general feeling is that discovery with the client picking the 
> options works best.
>
> In many cases the client doesn't need to register parameters as they 
> can be selected at run time once it knows what a server supports.
> The token endpoint authentication method was a bit of a special case 
> where even though it could be all dynamic and work, you do want to 
> register a choice to prevent backwards compatibility attacks.
>
> I don't really want to complicate registration by trying to make it 
> also cover AS discovery.
>
> John B.
>
> On 2013-04-24, at 7:55 PM, Phil Hunt <[e-mail] 
> <mailto:[e-mail]>> 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
>>>
>>
>