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

[Sergey Beryozkin <[e-mail]>]

On 25/04/13 00:28, Phil Hunt wrote:
> Fair enough, but that doesn't make sense in this broader forum where
> discovery isn't assumed.
>
I guess it is true, I wonder, even with the discovery, would real world 
clients be able to choose from a list of the supported methods 
dynamically ? They are probably pre-configured to work with a specific 
method.

Sergey

> Phil
>
> On 2013-04-24, at 16:17, Mike Jones <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>> What you’re missing is the part of the OpenID Connect flow where the
>> client first discovers the capabilities that the Server advertises. In
>> this case, it uses this discovery parameter:
>>
>> token_endpoint_auth_signing_alg_values_supported
>>
>> OPTIONAL. JSON array containing a list of the JWS signing algorithms
>> (algvalues) supported by the Token Endpoint for the private_key_jwtand
>> client_secret_jwtmethods to encode the JWT. Servers SHOULD support RS256.
>>
>> So in this use case, the client already knows what algorithms it can
>> choose from, and it makes the choice.
>>
>> Other OAuth flows could do the same thing, given either dynamic
>> discovery or a published algorithm list by the server.
>>
>> -- Mike
>>
>> *From:*[e-mail] <mailto:[e-mail]>
>> [mailto:[e-mail]] *On Behalf Of *Phil Hunt
>> *Sent:* Wednesday, April 24, 2013 3:55 PM
>> *To:* John Bradley
>> *Cc:* [e-mail] <mailto:[e-mail]> WG
>> *Subject:* Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
>> token_endpoint_auth_method
>>
>> 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]  <mailto:[e-mail]>
>>
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth