Fair enough, but that doesn't make sense in this broader forum where discovery isn't assumed.
Phil On 2013-04-24, at 16:17, Mike Jones <[email protected]> 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 (alg > values) supported by the Token Endpoint for the private_key_jwt and > client_secret_jwt methods 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: [email protected] [mailto:[email protected]] On Behalf Of > Phil Hunt > Sent: Wednesday, April 24, 2013 3:55 PM > To: John Bradley > Cc: [email protected] 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 > [email protected] > > > > > > 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 <[email protected]> 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 > [email protected] > > > > > > 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 > [email protected] > > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
