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>
[email protected] <mailto:[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]
<mailto:[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 <http://www.independentid.com/>
[email protected] <mailto:[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 <http://www.independentid.com/>
[email protected] <mailto:[email protected]>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
